I think that I have reached a point in my career where I can share some wisdom and guidelines for young software developers. Many of the things that will be mentioned in the following text is basically a retrospective of mistakes (and some good choices) that I have made when I was in that situation. Therefore, here is a list of things I would say to my younger self if I had the opportunity:

1. Simple code

Junior programmers often tend to over-engineer a simple solution and use some fancy code. Also, you can see that young developers tend to write as little of code as possible using some one-line codes that replace a several lines of code and are hard to understand and impossible to debug properly. This is probably a result of juniors trying to impress their senior colleagues with their developer skills.

You do not have to do that. Follow one of the main design principles – KISS: Keep it simple stupid. Writing simple and understandable code is not easy. It requires experience and a lot of planning and thinking ahead: maybe someone else will maintain it, maybe someone else will have to reuse it etc.

2. Mistakes makes us human

Understand and accept that you can and will make mistakes. When a senior colleague offers some constructive criticism regarding your coding style or design pattern, do not take it personally or as an insult. They are probably only trying to help you learn and grow by asking tough question and pointing out potential problems that are present or can occur in the future.

The best way to accelerate the rate at which you gain missing knowledge is by exposing your ignorance. This also applies to senior developers. If you don’t know something, maybe someone else already had similar problems and can reduce the time you spend solving it. A rule of thumb is – if it is taking you more than 3hrs to figure something out, ask for help. However, make sure your questions are smart and structured and are not something that will get an RTFM (Read The F** Manual) response.

3. Don’t be a complainer

Junior developers are usually introduced to a company by working on an existing project. Some of those projects can contain code and patterns that may not best practices that young developers first learn about. Don’t point mistakes out and form an opinion that the people who wrote this don’t know anything. Maybe that was the best they could do in the timelines and circumstances. When you gain a bit of experience, and look at the code, you wrote a couple of years ago, there is a chance you will hate it.

4. Follow the codebase

After a while, a developer team working on similar projects, tend to agree upon a coding style and that usually comes after a lot of discussion and versions of the codebase. Don’t try to write code in your own style, or even worse criticize the style that’s been set. Express your concerns, ask questions but follow the guideline until it changes.

5. Read. A lot.

Senior developers and architects didn’t get those titles because of their age. They acquired a lot of knowledge by reading a lot of books, blogs, articles… and not just about programming. Expand your business knowledge by reading on basic people skills, management etc.

Start by reading about fundamentals of software development. Focus on specific programming languages and frameworks that suit you best and build a strong foundation. After that, move on to architecture, design patterns, performance, security etc.

It won’t hurt you to run a couple of side passion projects to help improve your skills. You can contribute by offering these projects to the open source community. You can also write a blog.

6. Find a mentor

When starting a job as a junior developer, you are usually assigned a senior colleague to help you with the ropes of the new position. Don’t take this for granted and don’t be afraid to ask that person about any programing dilemma you may have. If possible, ask for some pair programming sessions with your mentor. You write the code and while writing explain your approach and why are you doing it in that way. That way, your mentor won’t review just your code, but also your way of thinking and you get an instant feedback.

Be aware that putting all your eggs in one basket, which means relying only on your mentor’s advices, can backfire. By following what was said in section #5, you can evaluate if what your mentor is saying is correct and the right way to go.

7. Comments

There is always a battle of opinions when talking about comments in code. Some say that your code should be self-explanatory and others think that no code can speak for itself, no matter how well written, and it should be documented through comments.

In my humble opinion, developers should always write short, single responsible methods, which are easy to understand even without comments. However, don’t be afraid to put a comment for a complex piece of code, or if you make something obsolete, just in case someone else needs to easily understand why you did it that way. Good comments explain why, not what.

8. Be thorough

Even if your company/team has a QA department, do your own quality assurance before committing changes. Write automated tests or do manual testing for every change you make. Try to zoom out and anticipate possible impact your changes will have on other components and functionalities and test those too. This will reduce rework and bug fixing for you and for the complete project.

After all said, I will just add my favorite catchphrase that can be applied to every software developer in existence: “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live”.