Developer’s state of mind — From junior to medior developer
I’m sure you know the feeling when you do something for the very first time. There is a lot of googling and struggling and it can be frustrating. It can take us hours or sometimes even days to make that something work. How can we get it done more effectively?
At the very beginning of my first programming job, I used my colleagues as google. I tried to ask them about every single detail. But I eventually was taught to always look up everything I possibly could before asking a question. That meant:
- Searching for an official documentation or books in the first place
- Looking for articles describing the topic and best practices (for example here on medium)
- Browsing stackoverflow
- Asking questions
Why did they want me to follow these steps? “It would be done much faster if they just told me how to do it” — This is a perspective of a junior developer. The whole point is to make juniors more effective. It’s not about getting a single task done as fast as possible. It is about learning to be better, writing higher quality code with less bugs, writing code which is extendable and we could build more code on top of it later on. By doing this, experienced developers are trying to pass their knowledge on to less experienced ones. We do it this way, so the next task will decrease the amount of questions and increase productivity.
Missed the previous article from this series? — Developer’s state of mind — Intensive learning “from zero to hero”
Personal experience
I have been doing software development for more than 8 years now. I usually have less experienced developers working on the same project with me. I always try to make the team as effective as possible. In a certain way, I demand a balance between how much time I spend helping a junior and what the junior is capable of doing on his/her own after I give a helping hand. If I sat down with you as a junior for an hour or two each day, and afterwards, you could work on your own for the rest of the day, then it was a good deal.
Let me show you with an example. Let’s say a task which you are working on would take me (as a more experienced developer) 4 hours to get done. If I spend 1 hour explaining something to you and then you are able to get it done, then it is a great deal because you saved me 3 hours. However, If I spend 4 or more hours explaining it to you, then it is not a good deal. I could have get it done by myself in that time.
We should aim towards this balance. It might not be there right from the beginning, but we will get better at it over time.
A perspective of a total money spent on development
We have a Senior developer earning 100$ per hour and Junior developer earning 30$ per hour (example hourly rates are from salary.com at 10/10/2019). The three scenarios bellow depict possible outcomes:
1. Senior and Junior developer sit down for an hour together, just briefly going through the problem. This way Junior developer may end up stuck or struggling for a long period of time on his/her own.
2. Senior and Junior developer work on the problem together for 2 hours, discussing it more deeply and thoroughly, leaving Junior developer with better understanding and spending less time on the problem himself/herself. This scenario has the best outcome in terms of effectivity = total money spent on development.
3. Senior and Junior developer work on the problem together for 4 hours. This way Senior developer might even end up doing some of the programming work for the Junior resulting in not so great balance and overpricing the task.
We should look for a balance between how much time someone spends helping us and hours spent working solo. I wanted to demonstrate how these scenarios affect overall cost of development. Would you like to be worth more money? This way of thinking will get you one step closer to it.
Thinking, learning, verifying, doing
Ok cool, now we understand a business point of view. We learned that we need to think before asking and we need to use both our times and time of others effectively. This way our boss will be proud of us. So what’s next? As I mentioned earlier, we need to use the time effectively. How do we do that?
I will tell you two different stories. The first story is myself working on a task 8 years ago. The second story is my colleague Matej working on a PHP project, a shorter while ago, on a project we collaborated on.
- I had to create a new page on an existing website built on Drupal 7. It was supposed to be a list of articles with some filters and a pagination. When I read the task description, I asked my colleagues a question “How do I do that?”. I was new to PHP and Drupal. I didn’t know anything. I was told “There is a module for that. It is called Views”. So I googled it, installed it, created the page, done. I submitted it for a review. It was done very quickly.
- Matej had to implement a websocket connection from the PHP to a remote backend. There was a big technical problem. PHP doesn’t support websocket connections in a way they are supported in other programming languages (like javascript). To make it understandable, we needed to make something work which is not technically possible. Matej searched for articles from people who already done something similar, searched for PHP libraries which would allow us to do as much as possible. He came up with an idea, put together as much information as possible and made sure he understood every aspect of the issue. Then he told me what the problem is, presented me some solutions with pros and cons and asked me how to continue. We discussed our points of view and then made a decision about an approach.
I know the second example was much harder to get done because it was much more technical and it required a lot more knowledge. But at the moment, we only care about the fact, that both of us were about to work on something we’ve never worked before. Therefore, both of us needed to learn something new to get the task done. Let’s stop here for a moment. Could you name the differences and implications of the two approaches?
My Drupal task didn’t go so well in the first story. I did it quite fast, yes. However, fast solution is almost never the best solution. I didn’t do my own research. What if there was a different solution than using Views module? What if I didn’t need to use the Views module at all? I used Views to create the page as fast as possible without understanding what is going on “under the hood”. In the end it made the page speed really slow. I didn’t know why it was slow. Guess what I did. I told my colleagues that it is slow and Views module sucks and I don’t want to use it. If I did my research, I would have found out that I need to be careful with the filters, because it does “magic” with the database (e.g. sql queries which requires indexes to work fast). I knew almost nothing about databases at that point, but I wasn’t searching for a solution or an explanation. I was searching for another quick way of fixing my issue. Duh.. This doesn’t look like a path to a medior developer.
In the second story, Matej made sure he understands everything. If he didn’t understand everything, we wouldn’t be able to decide which approach is best for us. Otherwise I would need to do the research part and decide afterwards. But I had my own stuff to do. What is so valuable about Matej’s approach? He presented me the problem with possible solutions. It took only a very little of my time. But that was more than enough to make a good decision and continue working. I needed him to have the overview of every aspect of the task. It is the only way to verify his idea and receive an objective response.
Conclusion
I wanted you (the reader) to have the overview of as many aspects and points of view as possible. We should look for a balance between how much time someone spends helping us and hours spent working solo. This is what I want you to take from this article.
Make the work of your mentors easier. Spend more time learning than coding. Ask questions which points you to a desired direction. Do your own research, create your own solution, ask for senior’s way of thinking, verify, compare, make decision, consult your decision with senior/team lead, then start coding. A senior developer is not a god. You can verify his/her idea too.
It could be, that at the beginning, many of your own solutions won’t be accepted, and you will need to write code based on someone else’s idea. Keep doing that and be sure to always understand ideas of others. The more you do this, the more of your ideas will get accepted over time. Why? We learn best by doing mistakes and inheriting the knowledge from others. Be creative. Get your ideas verified. It is better to find a mistake in the idea before you write the code, than finding a big mistake in the code which is already done, and loosing 2 days by rewriting it. Come up with bad ideas. Learn why they are bad. Look for different point of views. Think and work in a way which makes your mentor’s work easier. Take over responsibility from your mentor. If you are working on something, do the whole thing, don’t leave it unfinished waiting that someone else will finish it. Don’t pick the easy parts and leave the hard parts on your mentor. Find solutions to the hard parts.
Do you agree with me? Do you disagree? Do you have ideas or stories to tell? Please leave a comment below. I will be grateful if you do so. These articles are meant to help software engineers like you and me. Can we help each other? Stay tuned for the next story about developer’s state of mind coming out :-)
Big thanks to Matej Vilk for co authoring this article and for helping me correct logic and grammar mistakes in this article series.
