I finally feel like I'm an adequate developer and thought to myself: 'What would have actually helped me with my learning / development etc. 10 years ago? First of all: I'm not saying that this is good advice for everyone, just that it would have been good advice for me. Of course, I still hope that one or two developers can learn from it and take something away with them.
How big is the trade-off between quality and speed and does the context fit?
I asked myself too often whether I had really taken everything into account and imagined scenarios in my head that a:e user:in could still carry out. This usually happened at the expense of the speed of simply knocking out features and learning from the bugs.
There are contexts in which it makes sense to cover a few extra mental distances, e.g. when you are working on data sets with tens of thousands of pages and you simply empty the production database (shit happened). If, on the other hand, you're working on a button that should only change color when clicked, it's perfectly okay if the color is suddenly red instead of green and you add a bug fix instead of writing the umpteenth unit test for the umpteenth error path.
Sharpen the axe before you go into the forest
In the beginning, I ran around with a bad development setup for a very long time, which ultimately prevented me from writing good code or debugging bugs properly. I preferred to keep hacking away at the bug with a blunt axe (printf & console.log 4tw) without thinking about maybe using the grindstone and working with breakpoints.
Find an editor you like, practice the shortcuts, learn Git, familiarize yourself with debugging and listen when a dev who looks like Galadriel (shoutout to 'The Rings of Power' 💯) tells you how to do it better.
If you can't easily explain why something is more complex than you thought, question the complexity
If your project manager asks you why the button still doesn't have the color green and you have to write a three-parter to explain why the whole thing is more complex than you thought, maybe question your approach.
You don't have to immediately get a message queue out of the magic box, with new frameworks that haven't yet overcome the alpha status, and turn the repository into a monorepo when a normal scheduler will do.
PS to myself: The former is fun for you, but takes longer and is not justified. Just create a hobby project where you can try out new technologies.
Ask all the questions you can think of, especially if they seem stupid.
In my early years, I struggled far too much with my Imposter Syndrome, thinking I had to teach myself everything and just not ask if I didn't understand something. Not only will you make it much more difficult for yourself to get started in programming and make many mistakes that will contribute even more to your Imposter Syndrome, you will also hinder the growth of your more experienced colleagues.
As the previous speaker Michel already wrote (grrr, I wanted that topic too), the best thing for a developer who is already thinking about retiring is a developer who asks: “Can you explain the V8 engine to me?” to realize that you have to return to the valley of learning and the journey continues.
Conclusion
In conclusion, I would like to say that programming is a constant learning process - for beginners as well as experienced developers. The challenges we face, be it imposter syndrome, the complexity of projects or refining our tools, shape us as developers. It is important to never lose heart, to ask for help and to always remain open to new insights. After all, it's not just about achieving technical progress, but also about growing together as a team. It's perfectly okay to make mistakes and enjoy the slow but steady journey of learning.
So: grind your axe, but don't forget to just go for it and learn from your mistakes. Happy coding!
