Lessons to a junior software developer

Here are a few important lessons and insights I've gained to help you grow on your software development journey.

1.Writing code doesn't magically become easier,

Writing code doesn’t magically become easier but the more you code, the faster you become at making the decisions needed to write it.

As a beginner, you'll always feel frustrated and overthink every detail. You constantly question your choices: "Should I use an if statement here or a for loop? and the compiler will scream at you a lot with cryptic error messages when you feel you just got it right.

Every language has its quirks and its own set of esoteric rules, and in your attempt to learn them, you will have a lot of headaches. But that's just the nature of learning, and programming is no exception. You will trip a lot learning how to dance, , and mastering an instrument requires you to memorize every note and key. However,  with consistent practice, the rules become ingrained, almost like an instinct or second nature, and that, my friend, is called mastery.

In the early days of learning Rust, there were so many rules, making it hard to imagine anyone being productive. But over time and with practice, I stopped getting tripped up by the rules. I still understand them all and keep track of them, but now I use them without even thinking subconsciously This fluency in Rust, maybe even more than other languages, came entirely from practice and learning. So keep practicing until it becomes natural and you will achieve mastery.

2.To get faster, you need a lot of knowledge.

For young devs, the most important goal is learn continuously. The more you learn, the more rewarding and enjoyable coding becomes. No developer appreciates stumbling upon errors and being left puzzled about what to do. And the key to having a wonderful coding experience is to get as knowledgeable as possible. You will need to know a few things, including:

1. Understanding the Problem domain: Before you code, take time to grasp the problem you're trying to solve. This involves understanding the "what" - the domain and its specific needs.

2. Mastering the tools and how to accomplish your task: understand the how. This includes familiarity with your preferred programming language, tools, and general software development principles. For backend engineers, that means learning about Rest, Http and the like.

3. And as a junior programmer, the most crucial thing you should know, is how to acquire the necessary information in the future. Yes, gaining knowledge about how to acquire knowledge. You should be familiar with stack overflow, GitHub, and forums, and don't be hesitant to read documentation for any language or tool you use.

Many programmers started their learning journey by watching tutorials, but to advance, you must go deeper into documentation and articles. When you don't understand something, you should be able to able figure your way around it and ask polite and reasonable questions. An AI chatbot, such as Copilot or Gemini, is an important tool in your arsenal that you should use extensively but with caution, as they are not a substitute for true documentation.

So develop a framework for learning and a systematic approach to problem solving. To learn how to perform most things effectively, always start with documentation and then move on to articles, tutorials, Reddit, and Stack overflow to get more details.

3. Learn Deeply or don't bother learn at all

To be honest, don't bother learning anything unless you're going to learn it well enough. And why? because you will be deluded into thinking you know everything, or you will become too lazy to go back and learn more. Many programmers with years of experience opt for half-baked and expensive solutions, such as purchasing a new NoSQL database, when thorough indexing, data modelling, and database optimization will provide twice the performance.

A 45-minute YouTube video isn't enough to make you expect anything, so don't be duped. It's simpler to learn deeply at first than to patch half-baked knowledge, and believe me, I still struggle with Git today because I never learned it well, but I'm confident in my SQL and data modelling skills because I did put enough energy into learning it well. So, do yourself a courtesy and set aside time to understand thoroughly the fundamental requirements of software development, such as your preferred programming language, SQL and NoSQL data models, and others. It's not about learning it all, but for the most important stuff, learning it well enough.

4. Know the rule to break it.

Software development is fundamentally about tradeoffs, and a guideline you learned as the "best" way may not always be the most efficient way to address your specific problem. It is important to learn the rules first so that you understand why and when you may break them later.

In the field of databases, there are usually golden rules, such as normalization in relational databases (like Postgres). However, in certain instances, denormalization may improve performance. What about the trade-off? You might lose some data consistency. This is only one example. In many cases, the "best practice" isn't the greatest or easiest solution. The idea is to first grasp the rules so you can make informed decisions about when to bend them. Remember that each piece of advise has its limitations. Bending the rules may sometimes be necessary for the best outcome, but do it with caution and only after learning the rules!

5. Take on hard projects, even if you don't finish them.

While gathering knowledge is crucial, pushing yourself with challenging projects can be an amazing growth accelerator. 

After learning Go and making small toy web apps, I attempted to build a video-sharing website. I didn't know any better, or I wouldn't have attempted, but I learned a lot from my mistakes. Taking on difficult projects allows you to identify your weaknesses very early on.

One of my weaknesses back then was how disorganized the codebase was; everything was a jumbled mess, and I couldn't get anything done. So I did the best thing I could: I paused the project and proceeded to learn everything I could about codebase structure and organization. I read The Gang of Four, Clean Architecture, Domain-Driven Design, and everything on Hexagonal architecture, and videos on the subject. Though I don't follow everything in those books verbatim (no one should), I believe that understanding how to design manageable and refactorable codebases was one of the most significant things I learnt.

6. Gain experience to value the right things.

While I have emphasized the importance of gaining as much knowledge as possible, most knowledge is not truly valuable unless you experience firsthand why you need it. There are a lot of things in software development that you will take lightly, regardless of how much you read about their importance. like reading how to drive does not make you a driver, so is a software developer with knowledge without experience.

You might not value testing until you find it difficult to pin errors or refactor codes, and you won't value logging or tracing until you experience the situation where logs will serve you. So try to get as much experience as possible, whether by taking on personal or open source projects or working on a production system. It helps you to value the right things.

7. Sometimes, the best solutions come unexpectedly.

Sometimes the best solutions arrive unexpectedly. Problem-solving isn't always about brute force or endless research. Stepping away from the problem can be just as valuable. So, take a break, go for a walk, or do anything else that will clear your mind; this is all you need to gain a new perspective on things that have eluded you.

8. You are not always wrong; others are as well.

As a new developer, you are typically the one making mistakes and misusing a package; nevertheless, every now and then, the problem isn't you but the package itself, and you have just encountered your first bug.

I once lost time thinking I was doing something wrong. It turned out that the bug had already been reported on Github. Software do get buggy, and even smart engineers make unusual design decisions that are just odd and counterintuitive. So, ask questions, look at Github issues, and check in the community, and you'll see that others are also prone to errors.

9. Be careful of blind ideologies

Last but not least, avoid blind ideologies or one size fits all. What do I mean by ideology? Any recommended solution that is not supported by a thorough understanding of the tradeoffs and specific use cases is an ill-informed ideology especially if shun other solutions.

Sometimes, even seasoned developers might recommend complex architectures like serverless, microservices, or Kubernetes when a simpler approach like a modular monolith would be more efficient. These technologies are powerful tools, but they're not the answer for every situation.

Every developer has their own ideology; I prefer and will always choose Postgres over MySQL, even though MySQL performs better in many instances. And I can't picture writing thousands of lines in Ruby or another dynamic language, despite the fact that successful organizations like Shopify and GitHub use it on a daily basis. So do better than me, and base every decision not only on personal preferences, but also on the best available option.

Worth mentioning

1. Watch language/tool conferences: this helps to stay updated and build a strong developer mindset.

2. Join online communities and follow subject experts: I check the rust community on Reddit once a week for new articles, crates, and other useful information.

3. Think critically: Consider edge cases, potential problems, and how to optimize your code.