Curious to hear about the things that helped improve your programming ability.
Learning some functional programming. It really influenced the way I think about code and make coding decisions.
The short answer is "practice"
The longer answer is, do it a lot. Listen in code reviews. When you investigate bugs, do actual root cause analysis, understand the problem, and understand how it got missed. Don't stop learning, study your languages, study design patterns, be intentional in what you learn.
I had good mentors that were hard on me in reviews. Developing a thick skin and separating criticism of you from criticism of your code will help a lot in terms of learning in reviews.
Source: 10 years in the field. (Senior SW Eng. Focused on embedded systems and VnV)
When I had to fix a bug, I made sure not to just fix the problem, but to understand it.
There's a massive difference between the two. When I was a junior I would often find out how to fix a problem by googling and trying different things until something worked, but I wouldn't understand why.
Then I started digging into what was actually going on under the hood and finding out the why of things - sometimes it was to do with a framework, sometimes a language, sometimes it reveals a fault in yours or someone else's programming.
But every single time you learn something new and it solidifies your knowledge of your tech stack and programming in general.
Also, one of the best phrases I've ever heard in programming is "every bug is a missing test" - these days the first thing I do with a bug is write a test to expose the bad behaviour - then you can go about fixing it with confidence and preventing regression errors.
Do challenging projects. Read code from better engineers. Work with better engineers. Try new languages that actually solve technical problems instead of just having nice syntax. Contribute to open source projects that you use. Actually read the manuals that come with your tools. Notice when it's taking you a long time to do something and reflect on it to find a faster way. Constantly tweak your workflow to be more productive.
And the most important of all:
Get a split ergomech keyboard.
Installing linux. If you are in a more comfortable environment you will be better at working
I've found windows to be much simpler for many things.
Often the case of just installing an application from an installer.
And there's WSL for when you want Linux.
I don't see how an installer is easier than typing a single command to get something from a package manager.
I think the second part of the comment is what's important:
If you are in a more comfortable environment you will be better at working
Maybe that is windows for you. I have barely ever used windows, so the concept of searching for installers online and running them just seems clunky and time consuming to me. It's just not what I'm used to.
However if you are willing to learn multiple systems, you might find that one is better than the others.
What really helped me get better as a software engineer was going out of my way to progressively learn as many software design patterns as I could and iterate over pet projects to refactor them to apply them in practice. It helped me write cleaner code that's far easier to maintain and extend, it helped me be far more efficient at onboarding onto projects, it helped me greatly improve my skills as a software architect.
Teaching. I work for a university now (I have zero work experience), but you can also just make youtube vids nobody'll ever see. Explaining how a concept works requires you to have such a deep level of understanding that you'll find it impossible to properly do wothout learning more about it. In the end you'll teach yourself more than you teach your students.
Practice! Frequently take on tasks that are above your skill level and then learn to do them while you're doing them.
I'm a new programming student and the single best thing I have done is just start trying to do projects. Sure I have VS Code or Eclipse in one window and maybe Stack Overflow or chatgpt in the other but I slog through it and it has been for more helpful than all the reading and tutorials.. I've learned far more. I wish I had started this years ago.
I think of it in terms of levels building on top of each other, or circles enveloping each other; also how I evaluate interviewees and new hires:
- Finishes the task, but needs handholding
- Finishes the task, figuring it out from docs, guides, and internet
- Finishes the task, proactively trying to make sure it doesn't return again as a bug or failing QA
- Finishes the task, designing things in a way so that devs don't need to put in extra effort in the future
In short, learning how to do something right, but also alternative strategies, how to pick the best option, and finally make sure you always end up with the right choice, or automatically do so, by design.
It's at core a matter of experience, but taking on new opportunities and reading up helps to accelerate that.
I often think about the learning pyramid and I find it lines up with my personal experiences.
The experiences which have made me better at programming are when I'm teaching others or when I've been working on projects in my spare time (practicing).
For example whilst I was still at university I decided to make a Discord chatbot and it really helped me build on what I'd already been taught.
Other than that I like reading coding standards documents, like this.
Learning that Imperative Programming is inferior to Functional Programming for matters that are critical for safety.
I could go on for a week but here’s some copypasta that mirrors why I wrote this (sorry not to write an essay in my own words). Honestly, there’s a lot more than listed here (like the inherent ability to parallelize any functional code basically out of the box) but let us take a stab at comparing them:
The functional programming paradigm was explicitly created to support a pure functional approach to problem solving. Functional programming is a form of declarative programming. In contrast, most mainstream languages, including object-oriented programming (OOP) languages such as C#, Visual Basic, C++, and Java, were designed to primarily support imperative (procedural) programming. With an imperative approach, a developer writes code that specifies the steps that the computer must take to accomplish the goal. This is sometimes referred to as algorithmic programming. In contrast, a functional approach involves composing the problem as a set of functions to be executed. You define carefully the input to each function, and what each function returns.
Advantages of pure functions
The primary reason to implement functional transformations as pure functions is that pure functions are composable: that is, self-contained and stateless. These characteristics bring a number of benefits, including the following:
-
Increased readability and maintainability. This is because each function is designed to accomplish a specific task given its arguments. The function doesn't rely on any external state.
-
Easier reiterative development. Because the code is easier to refactor, changes to design are often easier to implement. For example, suppose you write a complicated transformation, and then realize that some code is repeated several times in the transformation. If you refactor through a pure method, you can call your pure method at will without worrying about side effects.
-
Easier testing and debugging. Because pure functions can more easily be tested in isolation, you can write test code that calls the pure function with typical values, valid edge cases, and invalid edge cases.
What stops you writing pure functions in OO? Like linq in C#
And where does your state go? How would a list of products be represented in FP?
Do you have some examples of full applications written functionally?
I edited my comment to talk about imperative vs FP rather than OO vs FP because FP can actually be OO. What I meant was imperative.
Anyway, in most functional implementations, state is usually handled by a minimal top layer. Functional paradigms are helpful in keeping the complexity to a minimum.
I like to use the functional core, imperative wrapper design style.
-
Going freelance. All the stuff I learned in formal and informal study and from those around me pales in comparison to what I learned from having to craft useful, affordable solutions for a wide variety of customers in several different fields.
It's true that certain aspects of my technical knowledge took a hit, but creating line of business software solutions in direct collaboration with the actual end-users was a transformative experience.
One of the most important things I learned is that approximately nobody actually knows much about how to efficiently and effectively use a computer. About one third of my time was spent teaching people how to use computers.
Reading books. There are some great books on programming out there. I would strongly recommend a A Players Guide to C#. It's structure, practice problems, and explainations of the basics were far better than any free guide to programming that I've seen online. There are a lot of other great books out there too.
It also doesn't matter too much about a book being outdated when you are only studying the fundamentals.
A lot of the stuff you read online has never been fact checked or edited for clarity. Some of it is great, but most of it is not.
