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
Well, if every person thinks this way we will never have a stable room of people xD
Maybe that’s a good thing?
Learning some functional programming. It really influenced the way I think about code and make coding desicions.
Agreed. Functional languages really raised my standard for what a language could be.
Stronger typing. More functional flow. Less dumb errors.
One thing that I found really fun and very educational was to find a protocol or format I found cool (something like XMPP, WebDAV, SSH, gzip, etc) and try to implement it in a place that wasn’t immediately obvious how (like, if you’re trying to learn Go, maybe don’t pick WebDAV, cause it’s already implemented in the standard library). I like to print out the RFCs or specs and put them in a binder. Then I read through and highlight important bits and put little sticky flags on the page. Then as I implement it, I’ll reference that printout.
It’s an incredible feeling when you get to the point that your software is talking to someone else’s software and it’s all working. And it really teaches you how the software you use every day really works under the hood.
Btw, I wouldn’t recommend the ActivityPub protocol. Even though it’s really useful and really powerful, I don’t consider it to be written very well or novice friendly. There are a lot of places where it is either ambiguous or just flat out contradicts itself. If you find a protocol like that, it can make you want to pull your hair out.
Ah yes! That is a great trick that kept me going doing software dev professionally.
Instead of trying to get the system I was working with to interact correctly with some shit enterprise system, I would find common protocols (or related protocols) and implement that well. Then I would discover more specifically where the shit enterprise system was behaving badly, and point to something politically neutral (like an IETF RFC) to help get us out of a rut.
It made debugging so much easier. Those specifications and open-source implementations have had much more engineering talent put in them than what I was usually dealing with.
You seem knowledgeable, could you go a bit more into detail why you wouldn’t recommend activityPub?
Did you hear of nostr?
What protocol do you recommend and why?
If you don’t mind me asking.
I would recommend email for this. It’s a text-based protocol and the original RFCs 821/822 are pretty straight-forward. There are some additional rabbit holes related to content encoding, but if one can implement a simple MTA, a huge amount of the magic of the internet becomes accessible.
I would not recommend trying to build a “production grade” MTA, as there is a lot of minutia to get right, and it’s easy to screw up.
“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
git blameIf the comments don’t match the code then someone failed to properly review it.
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.
Never 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
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)
23 years in and I don’t think that there is better advice here. Listen. Practice. Experiment.
If it’s something you want to get good at, do it as a hobby. Pick projects that you don’t know entirely how to do. Adversity is a better teacher than anything else I’ve run into.
Learn other languages too. I learned more about C from a year of rust than two decades of C.
The only caution I’d add about doing it as a hobby too is that it’s super easy to burn yourself out. I think that’s why so many of us get into woodworking and gardening lol
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.
Test driven development has really helped me understand bugs and functional changes well. Doing a red green change has done wonders for me over the years.
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 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.
I don’t see how an installer is easier than typing a single command to get something from a package manager.
Because it often isn’t a single command.
Finding some project that I really enjoyed working on, and just absolutely going ham on it. That’s the best way to learn.
This is The Way.
- 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.
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.
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.
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.
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.
For me this works best regardless of the field
- Learn basics
- then do this for rest of your carrier
,.-> Learn more ., .` `' ' \ | | . / ', ,- `'' Practise -'`Basically learn bit more -> use it immediately in any project - > rinse and repeat.
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.
