In last few months I have been assigned as a mentor to young developer who wanted to work as a student for our company. This is my first foray in being a mentor to someone, let alone a prosperous young talent. The first thing when I was told about this, panic kicked in. But then I started thinking about the time when I was a young developer starting out. What would I want to know? What would I want to learn?

Teaching someone a specific technology is pointless. So what could I teach my apprentice that he can, hopefully, take with him for entire lifetime?

I narrowed the list down to four points. So, to you young-lings, I’ve got this advice to offer:

  1. Think first, code later.
  2. Learn how to use version control and bug tracking software.
  3. Listen to your elders.
  4. Question everything.
  5. Get out of your comfort zone.

 

Think first, code later

This is at the top of the list, as many developers (me included) had that problem when they were younger. Relax, I am not claiming you are old now. I mean younger as in less experienced.

So what happens. A newbie developer, let’s call him Roger, gets a task. His first reaction is to jump and code it away, because that is what developers know best. Due to inexperience, he trusts his reaction and starts coding right away. And that is a wrong decision. By not thinking about big picture at the beginning, but tackling problems as they go along, Roger just made the worst decision possible. Not only that there is a high chance that his application will not be done according to specs, but he also risks shipping a product that will become maintenance and scalability nightmare.

And if you are thinking you do not care about maintenance or scalability, wait until your application gets used for a while and you are coding through the night to sort out weird bugs and performance issues.

All this problems can easily be avoided by ignoring reaction to code and sit down and think hard about what needs to be done. This will make architecture more optimal and scaling easier.

 

Learn how to use version control and bug tracking software

I am surprised how many young developers (Computer Science graduates included) don’t have a clue about version control or bug tracking. I partly blame colleges, as they do not teach these skills, but a vast majority of blame falls on our young-lings.

You see, until you get paid for a project you created, you don’t need version control or bug tracking. The problem is, that when you get paid for a product, version control and bug tracking become your best tools available and if you do not know how to use them, you are screwed. I can guarantee you, that without either, bugs will never get fixed, important features won’t get implemented, your code will be a mess and you won’t have the guts to throw away that piece of commented-out code because: “God knows, what is it for”.

With version control, you have a freedom of doing whatever you want to the code. After all, if you mess your code base completely, you can always do a full revert to last commit. Also, all version control systems offer a detailed log of changes (depending on commit messages of course), so tracking bugs and their fixes becomes easy and as painless as possible.

Bug tracking or issue tracking systems are used to store feature requests and bug reports. Logging a bug or a feature in bug tracking system means you only need to remember one bug/feature at a time as others are eternally stored in the system for you to see.

 

Listen to your elders

When I was growing up, this was the first thing burned into my brains. “Listen to your elders”, my parents used to say. And they were mostly right. You see, you also need to know if the person you are listening to is credible to give a good advice. But more about that in the next chapter.

Your elders (and again, I am talking experience-wise, not age related), have been through majority of issues, you, as a young developer, will encounter. Thus, they can offer you good advice (and most of the times even without asking), if you are prepared to listen. Now the mistake most young developers do is to think they know everything. Trust me, even if you studied entire library on the subject, you still don’t know everything and will need advice or help from elders. Don’t be a jerk and embrace it.

 

Question everything

From advice obtained to your code, everything should be looked over with a critical eye. Could your code have been done better? Is it optimal? Is the person giving you advice worth listening to? Is it worth optimizing that piece of code to run faster than the speed of light, when there are only two people using it? Not sure, do a code review.

Questioning everything will improve your technical and people skills. It will force you to write better and better code. It will tell you, when you need to step up or when you are overdoing it. It will gain you the knowledge of whose advice to respect and whose to ignore.

 

Get out of your comfort zone

The last thing I want to torture you with is something called the comfort zone. Comfort zone, by my understanding is a state of mind where you feel “right at home”. We, as humans, are notoriously bad at leaving our comfort zone. That is why people stay close to those who praise them. Comfort zone is a nice, comfy place that can put a person into a life-long dream state. If you want to develop yourself, that is exact opposite of what you want. You want to be wide awake, on edge, juices flowing. Thus, from time to time, you must do something that every fiber of your being opposes. It could be as simple as trying a new technique, it could be as radical as applying and delivering a presentation to a room full of people. It really doesn’t matter as long as it is something that will remind you how alive you can be.