Curious to hear about the things that helped improve your programming ability.
Working with engineers that were better than I was and actually listening when they reviewed my code… Asking why and going from there.
“if you’re the smartest person in the room, you’re in the wrong room”
Unless you’re giving a lecture
Learning some functional programming. It really influenced the way I think about code and make coding decisions.
Agreed. Functional languages really raised my standard for what a language could be.
Stronger typing. More functional flow. Less dumb errors.
Reading code. Not just your primary language. But other languages too.
Most problems are already solved. Someone out there solved it. Maybe they didn’t solve it in the language you need. But fortunately, they provided their code on GitHub.
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)
If you’re a beginner:
I almost gave up programming once, I thought I was too stupid.
Then I learned Linux and figured out starting out in IDEs as a beginner is the worst thing you can do. It doesn’t teach you anything, it just lets you get the job done - the thing that you should avoid while learning.
If you can’t build your software with only CLI - you probably have no idea how technology you’re programming in works.
If you are intermediate:
Reinventing the wheel is a great way to learn how libraries you’re using actually work.
“I don’t need to comment this code, I wrote it so I know what it does”
And then
“Fuck, I should’ve commented this code, I have no idea what it does”
Comment. A lot.
Stage 2, “why does this code have nothing to do with the very detailed comments?”
Always comment the why, not the what/how. Bonus of doing this is you only need to update the comments when the why changes
Lol. That’s why we comment with “why”, rather than “what”. The answer to “what the duck where we even thinking?” usually doesn’t need updated until the commented code goes away.
git blameNever understood this argument, it’s the person’s responsibility who changed the code to update the comments if needed. Otherwise they just implicitly admit that they did not read it or understand the context, or just plain did not care.
It just never works. Its important documentation breaks if changes are made. The best docs are baked into unittests
I hear this quite a bit, and think there’s actually a good deal of nuance to it. I’ve seen places that insisted on comments for everything, and it was silly, a significant number of comments had no value. This made people not read comments, as opposed to other places I’ve worked with very few comments - when you ran across a comment you gave it more weight (something here was complex, or not as simple as it seemed).
So imo, use comments which can communicate effectively, but use them sparingly for important parts that are complicated, for the rest attempt to communicate with the code itself.
step 1: learn to comment everything. This will helps code reviewer to catch errors because your code doesn’t match the comments
step 2: write your code in a way that makes comments useless and stop writting them
step 3: write your code just like you did in step 2, but documents all the things that you didn’t do, or why the code is more complicated than the naive approach. If your arguments are weak you are not in step 3, but in step 1.
I find that writing detailed comments about things that aren’t clear in the code often lead me to a better, more clear solution. Same thing with writing detailed commit messages. So many times I realize something better during the message, I’ll finish the commit and then almost immediately amend that commit with the better way.
Yep, was going to say that refactoring my own code taught me a lot
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.
- Learning multiple programming languages. Each one gives you a glimpse into the problems that some very experienced devs thought were worth solving neatly.
- Switching to Linux. The whole OS wants to teach you about its innards all the time. You can actually debug problems in software you use. And you can script all kinds of things or even start contributing to basically any application. It’s just really good at teaching and motivating programming.
- Explaining things to others. It’s quite easy to have just superficial knowledge in tons of topics. And sometimes, we don’t notice, even if it’s something we do every day. Try to explain to a noob what Git is and you’ll likely struggle, both with the meta description and detail questions. If you then read up on the concepts you couldn’t explain, that will give you a much more complete image of Git and ultimately help you whenever Git becomes more complex.
This is perfect advice.
My take: actual, hands-on programming is way more rewarding than reading and watching tutorials.
I learned a lot at work (80% still self-tought, rest from interaction with other teams and other people better than me and with greater experience), and it usually came from needing to make my job easier, not to please the clients or management (scripting and automating things, Linux, DevOps, etc).
The other part through personal projects (again, out of need). You need to take on a project with real use to you. And you get to use the latest frameworks / technologies which you might not at your workplace, depending on the company. Working on personal projects will give you a different kind of fulfillment and will keep you remember that you love to code. Work is work, play is play.
And last, contributions to public, open-source projects. You need to read and understand other people’s code, get familiar with Github, write clean, documented code and respect the standards for the project. It will help you in the long run, and you could also add something to your CV.
As for the actual things to learn, don’t get stuck on learning just the framework, which does a lot for you out of the box by running commands or calling packages. Try to go in-depth in a programming language and play with the bare-bones, learn the intricacies. Learn for example how code runs and where. I have colleagues still thinking that queues are magical and asynchronous, they write a few lines of code and just work when deployed, without any actual knowledge of the architecture of the system they run on, this leading to no thought in optimization and speed of their code. Or they use the ORM exclusively, which, again, doesn’t help when shit hits the fan and you need to debug and optimize for bulk processing.
Also, learn a bit about cryptography and cyber security, even if only for yourself as a hobby. This is where I see a lot of developers lacking, to the point that most don’t know the difference between hashing and encryption. There is no project nowdays in the universe where security doesn’t matter.
The difference between a mediocre programmer and a good one might not be obvious during an interview, but they will show during the trial period.
Yep this sums up my experience quite well too.
I want to emphasize two things here:
- Learn reading code (by reading code…) of high quality open source projects. It helps getting new concepts and actual creative coding patterns for concrete problems (unlike learning all these “design patterns” in books that IMHO are often just boilerplate generation (hard take I know…)).
- Start coding (open source) projects, especially challenging ones, and keep pushing your limits, by trying to learn new smart things, how to achieve problem X. I stagnated in my workplace for quite some time, got unhappy (around COVID), scaled down working hours significantly (I have quite a spartan life, so I can fortunately afford it), and am coding a lot more open source since then. I think I almost learned more in the last 2-3 years until at least to the years of university (quite some time ago), maybe even more than in university, and have a lot more fun while coding. I think going in depth with a programming language comes automatically, when the project is fancy enough, I learned a lot of limitations of Rust (and thus basically reached the deepest level of (parts of) the language) while designing smart APIs.
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.
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.
Practice! Frequently take on tasks that are above your skill level and then learn to do them while you’re doing them.
deleted by creator
I agree with pyramid. Teaching someone else or doing it was indeed the best practice indeed anytime i wanted to learn something better.
Nothing. I’m still shit at everything as always.
Fake it til you… well fake it forever
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.
