Advice For The Novice
Becoming A Better Developer, Part 2
So you want to become a better developer? This guide is divided into four parts. The previous installment was about starting a career, while the second (the one in your hands right now) is for juniors wishing to improve their careers.
Tips are shown in bold.
Personal experiences appear in colored boxes like this one.
Life As A Junior
So you are starting in our noble and worthy profession. What do you need to know to survive?
When you are a junior developer at a company, you want to be sure that there are really good people you can learn from. Most importantly, you want to actually learn from them. Do not be afraid to ask.
Ask to work with someone you respect.
You will probably have to do menial tasks, and will be tempted to think that they are below your level. But just think: who else is going to do them if you don’t? Boring, repetitive tasks are great candidates for optimization. Why not trying to automate them so that nobody has to do them?
Try to optimize your workflow.
Choosing A Tool Set
Like in any profession, what tools you use makes a huge difference in your daily work. Quite often you will have no say on the tools to use in a project: text editor, IDE, compiler, and so on. But sometimes you do.
Mandating an official dev environment is one of the first things done at many companies: big, medium and even startups. It is also one of the most futile, if not actively harmful. Code is text; you should be able to manipulate it using whatever tools are best suited for each task.
At mediasmart we don’t mandate an official text editor. Some of us use vim, others emacs, some prefer graphical editors such as GitHub’s Atom. I have been using vim exclusively for five years now. Even though I am by no means an expert user, it gives me a huge advantage: I have the same editor locally and on servers, it is light and efficient, and can be used anywhere. Even the bloated and inferior emacs can be used in this fashion. Just joking; any console editor is fine. But vim is the best.
No matter who chooses them, take the time to learn how to use your tools. It will pay off.
Learn how to use different tools, and choose the best for your daily work.
One of the most overlooked skills is typing. Do you peck with two fingers, or touch-type using ten? Some people contend that typing is just a tiny portion of the time of a developer, so it doesn’t matter how fast you type. I strongly disagree. Adding up the time spent writing code and communicating with others (mail, chat, docs) would probably make it worth it. But consider that everything else you do on the computer goes through the keyboard or the mouse. There is not much learning in the mouse, but using the keyboard 50% faster makes a huge difference in the long run.
Your keyboard is your basic tool. Learn how to use it well.
Reviews And Criticism
The best way to improve is having other people review your code. As Eric Elliott said just today:
In a mentorship culture with lots of pairing and code reviews, even novice developers quickly become great assets.
Be prepared to receive criticism. It is not always easy to have someone rip through your code and be cool about it. Most people get emotional. Keep in mind that knowing what you are doing wrong is the best way to improve.
One of my colleagues at mediasmart started at the same time I did; he had no professional experience. When I started commenting on his pull requests he probably felt that I hated him (and that I was a cold bastard); he got disheartened by all the negative feedback. Nowadays he takes criticism of his code as a pro!
I have never worked with anyone that was a great developer and did everything right from the start. But I have never worked with a senior that did everything right, either. I don’t do everything right myself, and I don’t expect others to. That is why we have code reviews and walkthroughs.
You are not supposed to do everything perfectly. Nobody is. We are all supposed to learn and get better.
Test Everything
There is a very small improvement that can make a huge difference in your work. Before you take any task as finished, test it. It would surprise you the amount of people that send something for review, or even to customers, without testing it first. The result: it implodes at first sight, making everyone lose their time.
I am a sucker for competitive cooking TV shows. When a dish is particularly nasty, one of the judges is sure to ask: “Did you taste it?” Almost invariably the contestant will answer no. Succesful contestants are always shown tasting everything.
Good professionals always test everything, so that you can trust that when you receive something from them it works the first time.
Test everything before yo deliver it.
Learn Strategies
While observing junior developers in the workplace, I realized that there was a crucial difference with their more senior peers. Faced with a hard problem, they tend to reach a point where they say:
I have tried everything but it doesn’t work. I don’t know what is happening.
And they give up. While more senior people never give up.
It helps a lot to know that the problem has a solution. All bugs can be detected and eventually corrected. It may lie in the place that you least expect, it may require lots of changes, but in the end you will solve it. Or someone else if you give up!
Every bug has a fix, and it is within your grasp.
As you learn to use more tools, you will have more arrows in your quiver, and this will help you try different approaches for problem solving. For instance, if you want to find and fix a bug, you can:
- follow the code,
- add traces to the code,
- google any error messages,
- use a debugger,
- comment out parts of the code,
- write an example that fails in a similar way,
- google for people with the same problem,
If it’s a performance bug the strategies vary:
- add traces with time measurements,
- profile the code,
- isolate the slow part and benchmark it,
- find a micro-benchmark with the same problem,
and so on. If you can’t figure out a new strategy ask someone else.
There is always another strategy to try out. Don’t be discouraged.
Ask For Help
A junior asking continuously for help is not the worst that can happen. Oh no. Far worse is a junior never asking for help.
At my current company we are all busy people, so we tend to let juniors on their own, and “let them float”. This strategy does not always work. A big, strategic development was assigned to Fran Barea, one of the junior engineers, to complement his work in tech support. The project did not progress as expected; in fact it missed all of its milestones. I offered help with it, and did a few joint design sessions. But still the junior engineer was overwhelmed, mostly by his tech support workload. After less than a year he was offered an attractive position at University and left. Since then, we try to keep a closer eye on juniors, and encourage them to ask for help.
Always ask for help if you feel lost.
When asking for help, quite often you don’t need someone to handhold you, or find the problem for you. Just asking what other strategy can be tried can be enough. And of course, do your homework before asking for help: try out the strategies that you know.
Asking for help must go after you have exhausted your own resources.
Find A Mentor
You probably know someone who is a senior developer, and you may learn something from them. So, why not ask them to mentor you?
I have had a few people ask me to mentor them over the last few years. I usually say yes, of course! However they seldom ask for anything. That is not how mentoring is supposed to work!
A mentor is someone to ask questions to. Or at least to tell them your plans, and ask for their opinion.
Look for a good mentor, and then use them!
By the way, you can contact me at alexfernandeznpm@gmail.com, if you need anything from me. I don’t know if I’m senior, but at least I’m old.
Conclusion
Life as a junior can be hard, but if you work hard it can also be very rewarding.
Part Three
The next installment is out! Dedicated to developers with experience.
Published on 2016-10-09, last edited on 2016-10-10. Comments, improvements?
Back to the index.