5 Tips You Can’t Afford to Miss as a Dev Rookie

If you’ve just started, or you are about to start a career in programming, you probably read many “Tips for beginners”. This is yet another article in that subject. So what is different? I won’t give you a single piece of advice on things like:

• which languages or frameworks it is best to learn right now
• how to stay motivated coach-like mentorship
• how to go through recruitment process
• I won’t also debate on whether it’s better to pay for a Bootcamp or enroll to online course.

I will actually address this article to people that already know how to code but perhaps miss some direction on what to devote time when self-learning.

I recently asked myself what was important to me as a developer for the first 2-3 years when learning curve was extremely steep and what habits introduced at the early stage of my development career made strong background for following years.

So going straight to the point, here are my tips.

Junior dev waving to his family seconds before his first release

Concepts and programming principles are important

Together with learning technologies, languages and frameworks do not forget to learn concepts and principles of programming. You won’t be good software engineer if you know 4 different modern JS frameworks, you consider learning fifth but at the same time lack knowledge on principles like:

• SOLID
• STUPID,
• YAGNI,
• KISS

And other magically abbreviated principles. It’s like knowing a lot of words in foreign language without grammar skills.

Code smells, anti-patterns and refactoring techniques are also an important concept. Majority of them are pretty straightforward so you can learn them without bigger trouble.

All of them help you create a cleaner and more robust code.

Amazing resource: https://refactoring.guru/refactoring/catalog

Dive into code review world

What it's like being a junior developer in a code review

Good code review is the best way to learn. Period.

If I had one superpower I would make all the people collaboratively review work of their coworkers - whether they are programmers, architects, politics or office-clerks.

There is no better way to spot errors you make, learn how to fix them and how to avoid them.

And there is no better way to learn what mistakes are done by other developers. and what it means to our mental health to read crappy code.

It’s improving our discipline by making us feel twice responsible for our code - we sign it with our name when asking for a Pull Request. And we’ll have to confront other people ready to roast every line of code we produced.

Don’t be afraid of reviewing code written by more experienced people. Even if you are a developer for a short time. You still may find readability issues, provoke discussion and deliver insights from the perspective of a person not so fluent in reading code (this is valuable).

If you look for a job and have few offers - ask about their code reviewing culture - think twice before accepting offers from those not performing any code review or performing it in a poor way.

Logs should be your main point of focus

Logs allow you to sleep better. They will make you more confident about tracking every unexpected behavior in the app.

Logs + automated tests are awesome duo.

Tests cover everything in the code you expect to happen. Also, they assure you other people don’t break this solid foundation. Properly configured logs, on the other hand, will show you that your app or some feature crashed in a way you did not plan.

Overall concepts in having entire logging ecosystem healthy would be:

1. Log things properly on the level of code and exceptions handling
2. Keep logs as clean as possible
3. Automate alerting when number of logs is bigger than expected (this goes beyond the typical junior developer skillset)

When it comes to point 1)

What you need to achieve with logs firstly is to understanding how your framework or logging library works. You want to:

• not log unnecessary things - you always should look towards uncluttering logs
• log important stuff the way crucial part of information are stored

Once you have this understanding try to fix all the places in your code where logging of exception is broken. With moderately small codebase and modern IDE it’s quite easy to search for every occurrence of "catch(" in the code. And for each occurrence:

1. Make sure exception is logged.
2. Make sure it’s stack trace is logged.
3. Make sure all the important params are logged.

Ok, you have it.

Now last step to become Not-so-Junior Log Ninja is to learn to handle logs in terminal. For the most of your time, you’ll have this comfort to use some web UI. However knowing how to deal with logs in the command-line is an important skill.

1. Learn favorite commands to view last X lines of log file
2. Get familiar with continuous log viewing
3. Learn how to grep
4. For logs in SQL database learn” \G switch” to be able to view them in a more handy way
5. Learn how to quickly transform machine-friendly timestamps into readable formats eg. SQL's "from_unixtime(col)" is a good start Learn how to filter logs basing on date using eg. "WHERE logtime BETWEEN DATE_SUB(NOW(), INTERVAL 4 HOUR) AND DATE_SUB(NOW(), INTERVAL 2 HOUR)" to get logs saved in certain 2h window.

Learning what NOT to do > learning what to do

Yep, you’ve read correctly. There is a distinctive difference between learning patterns and anti-patterns.

I’ll give you an example from my personal life. When I was at school I played chess a bit. I wanted to be better so I started to read books and tried to implement solutions from the books.

It didn’t work out though. To tell you the truth, it was a spectacular disaster.

I was using solutions I did not understand. I mean I understood more-less ideas behind each opening or defense but I was missing the bigger picture. Plus for each of them I was so focused on following the set of steps I played like a little monkey.

The result was I playing worse than before I had started to read those books. Shortly after I was not so psyched about chess and stopped playing.

This one tip is pretty personal and some people may not agree with it. It probably comes from how I learn things and perhaps it may not work for every other person.

In learning concepts and principles pay more attention to anti-patterns: what not to do, and what to avoid. In contrary following patterns is doing things in compliance with set of rules.

Following anti-patterns will always make your code slightly less crappy. Depending on the set of anti-patterns and how compliant you are with them - your code will be more or less improved.

But it will be improved.

Whereas following patterns can make you produce code that is even worse spaghetti than before. It happens if you do not understand the bigger picture of used pattern itself or try to implement them too much when not needed (a.k.a over engineering).

Minimize low-level feedback loop

Feedback loop is extremely broad and overall term. It may be related to:

• how startups collects feedback from marketing actions they perform
• how information flows in IT organization between different members of the team or different departments

But it also may define a set of low-level actions you perform as a developer.

Feedback loop means all the necessary steps to reproduce certain behavior starting from scratch to point when you get feedback - either code is working or not.

Ideally, unit tests should be your feedback and rescue mechanism. But as this article is addressed to junior developers - I assume some of you may not know how to write automated tests.

Learn to minimize feedback loop when figuring out why things are not working.

The ideal situation is to try split longer sequences of work into short ones - making clear save point where you know you can always start from.

Conclusion

I hope that I inspired you to improve something in your work. I wish you all the best in learning and getting better as a developer.

As the last tip I allow myself for tiny work-life balance mentorship: have some life except programming and your job. You’ll be useless for your company when over-worked.. and missing soft skills such as talking to other people.

If you liked this article follow me on twitter or subscribe to my blog to be up-to-date with everything I publish.