Two years as a software developer: hints for newcomers
I started to work as a developer approximately two years ago. My idea of what software development is was simplistic then. I was familiarized with some general basics like version controlling or data structures, and could code trivial stuff on Python. But that was not enough to have a comfortable landing on the field, I must say. The real life context I saw myself in was very different to coding scripts at home, and what I had learned in college was barely useful. On top of this, I never managed to find a comprehensive road map exposing the set of skills I could work on from there. This made my learning process to be unstructured and based on momentary needs, which created knowledge gaps that happened to be problematic to fill later on. I do not think this was a personal problem, but an expected situation to find in a young field that uses young methodologies and tooling. So, hoping to help other newcomers, I would like to summarize the key points I think have helped me the most in overcoming that first stage and improving my performance.
1. Deliberate practice and reading.
It may sound like cheap advice, but remember that the key to improve is to put time and effort into it. Force yourself to understand how things work and do not settle with solutions you know are suboptimal. Learn about new paradigms, languages, frameworks. The best way to learn is to combine the great content that exists with some deliberate practice. Books, videos, courses, podcasts; there are plenty of resources. The most popular books like Clean Code or Code complete can teach a lot despite their age, and I recommend you to at least take a look at them. The pragmatic programmer had the biggest impact on me. You can read it here or listen to the Coding blocks podcast’s episodes about it. And of course, the Internet is full of discussions about other good programming books and resources in general. Go down the rabbit hole, find what fits you and use it.
2. Get a clear idea of what has to be done.
Programming is a tool we use to achieve other things. It does not mind how good you are at it if you misunderstand the objective. Therefore, you really need to understand what you are trying to do to be able to write good code. I think this is the single most relevant advice I have to give. For some reason it took me a long time to properly understand this, and I still struggle with it to this day. You can approach this by ensuring these points before starting to code:
- Understand what is the real problem to solve / the real feature to add.
- Understand what is the big picture of what you need to code.
3. Aim for a clean style.
There is a lot of noise about what clean code is, but its final goal is clear: to be declarative. We spend more time reading code than adding it, so we must prioritize to make code understandable. When purely talking about writing better code, I think this is the most relevant point. Take it seriously and get your teammates on board if they are not. My fifty cents on what to do to start writing cleaner code:
- Naming is the lower hanging fruit here. Spend time on it and get it right.
- Learn about design patterns and use them.
- Learn more about your language and frameworks’ syntaxes and conventions.
- Learn to exploit the language features. This is the key to achieve a good style, over mastery of syntax and conventions. Raymond Hetting clarifying this.
4. Know your IDE and learn to debug.
This is another point that took me too long. First, the quantity of time you can save by mastering your IDE is huge. Modern IDEs are complex applications made to ease the task of programming, and you should use it. Watch tutorials, ask your mentors and teammates about their setups and go the extra mile to get familiarized with shortcuts and extensions / plugins. This will take your game to the next level in no time. Second, debug code using the proper tools will make it way, way easier. Stop printing and logging around and learn to use your IDE’s debug workflow. If you use Visual Studio Code as I do, the official docs on debugging are solid.
5. Other points I consider relevant mentioning:
- Refactoring is normally harder than it seems. Don’t avoid it when necessary, but be careful.
- Tests are not optional. Test coverage is critical. Measure it and work to improve it.
- Repetition in logic is the only call for abstraction. Go DRY but not before needed.
- Follow the boy-scout rule.
- If you identify a problem, solve it as soon as possible. Don’t live with broken windows.
- Especially when working on server-side code, stay in touch with the final user’s points of view.
- You can find more bullet points from other developers in the 97 things every programmer should know collection.
- For more career-building oriented advice, this post from @patio11 is the best out there.
I hope these arbitrary points can help, but there is way more to learn. Keep working and reading. Effort will pay off.