Three Things I’ve Learned from Senior Developers after Two Years of Working
Yes, we’ve all been there. Nervous about our first job as a developer. Thinking “I don’t even know what a programmer really does!”. But don’t you worry, I’ve got your back. Or maybe you’re a senior developer looking for some ways to help that rookie at work to catch up some speed? This is for you as well.
Summer is around, which means a lot of you have recently graduated and will be entering work life soon. And you know what? It is super fun! Finally, you will be coding stuff solely for its use, not for the purpose of getting evaluated!
You will also start working in teams. I’ve been working in interdisciplinary teams in the public sector in Norway since I started, and I owe my team so much for the progress I’ve made.
These are the three most important things I’ve learned that helped increase my production speed after starting out as a newbie in the tech business.
1) Ask questions the smart way
One of the first links I received from one of my fellow team developers was a link on How to Ask Questions the Smart Way. Probably because I was asking many questions. Asking questions is inherently not a bad thing, but there is a fine line between sharing the knowledge that is necessary versus using too much of other developers’ time.
The guide is quite comprehensive. I would absolutely recommend reading it for the understanding of the open source community and the different types of personalities you will encounter among programmers.
The most important tip I learned from it however, is that when in doubt of asking a question, time box it. Use 10 more minutes to search for the answer yourself. You will either end up:
- Solving the problem yourself, or
- Learning something new, and thus be able to be more specific in your question.
A more specific question is easier to answer and also conveys that you have made an effort to try understand the subject yourself.
2) Don’t fool around, use the docs
Sure, Stack Overflow is a life savior at times, but let’s be honest. How often have you been stuck in the Stack Overflow jungle, trying out things that you really don’t understand, but has “worked for Matt and Chris, while it didn’t work for Eric”?
The docs can be troublesome to read sometimes, but once you get the hang of it, the truth is right there. By reading the docs and looking for what you need, you read a whole more and you get a much more comprehensive understanding of the of the programming language or framework you’re trying to learn.
Suddenly, you are the one helping the seniors and nitpicking on their code in code reviews (just kidding, we don’t do that, all comments in a code review are constructive).
There has even been developed tools that specifically help you with this. If you have a Mac, you can use Dash to gather documentation sets, with a support for over 200 APIs: Java, TypeScript, Ruby, you name it.
The docs contain the truth. Don’t waste your time on something that is potentially wrong.
3) Focus on one task at the time
Context switching costs. Wrapping your head around a problem takes time, in order to solve it the best way possible. To avoid this cost, focus on getting one task through the Scrum (or Kanban) board at the time.
Also, if a task seems stalled, there is probably a bottleneck somewhere in the process of how your team deliver functionality. That should be fixed. If not, it will only keep slowing the team down.
Taking on a new task in such a situation would only increase the scope of the board and make the load on the bottleneck even bigger. By increasing the scope of the board, I mean the amount of tasks in progress at the same time, and thus the range of functionality that the team is touching on at the same time.
The tester in your team is stuck on the task. Why? Ask her to find out the bottleneck and get the task done. Perhaps you need some new tool or way to generate test data to accommodate the task you just delivered — make it or make it happen. Maybe it is because a critical component in the test environment doesn’t have sufficient uptime? Raise the red flag and use your time to get it fixed.
Increase the throughput of the board, not the scope of it.
These point are my take away message after two years of learning as a junior software engineer. I wish you luck, all newbies soon to become skilled, and all seniors — remember you are invaluable to our development.
And to the senior developers that I’ve learned so much from the last couple of years (you know who you are) — thank you.