What makes a rockstar developer?
In the previous post, we came up with some traits characteristic for every good developer, and talked about two of them — good code quality and code predictability.
Now, we’ll cover next two — delivering on time and being communicative. These aspects are not so commonly seen even among senior developers and it’s important that every developer understands them properly.
Delivering in satisfactory timeframe
Based on my experience, that’s the trickiest part. And probably the most important one. The reason behind it is that a lot of developers have minds of Carl Sagan… meaning they easily get lost in time and space.
You probably know a guy who can’t decide on a solution even after the sixth meeting. Or a guy who asked about his progress, says he’s on it, but he had to stop for few hours just to understand one tiny thing he came across. Or the one that conducted his research for few days to find out that the solution won’t work after trying to implement something. Or yet another one, who found a weird thing in code and spent too much time on trying to fix the imaginary problem.
That’s not bad, it actually means that they have the level of curiosity and ambition that makes them love what they do. This is really important in this job. But as it is with many other things — you’d better keep it under control.
You might think, alright, I know where he’s going, I lose my time and the company loses money. Yes. And no. Yes, the company loses money in some cases, but even more important aspect of a developer losing time on an irrelevant thing, is the impact it has on that particular developer.
Have you ever seen a cyclist who developed an award-winning form just by thinking and reading about cycling? Probably not. He might have read about cycling basics, maybe someone passed that knowledge to him. But then he got onto his bike and he kept cycling. That made him successful.
The first thing you need to understand (if you haven’t already) is that you gain experience and master your skills by doing things, not thinking about them. I’m not asking you to skip the research phase of your work. I’m just asking you to be reasonable about it. Get a basic overview of the topic, gather necessary information and resources you need to start, and jump into it. There’s no point in reading whole API’s documentation before you even try to connect. Some things will cause problems anyway, you can’t predict them in 100%, so don’t worry about problems that will pop up along the way. Sure, you need to know if your task is doable at all, but that’s the purpose of planning sessions or a good reason for having a software architect in the team.
Alright, but how does it influence you? Here’s an example. Let’s say you need to do a research on a topic and you can take two approaches:
- get the overall understanding in 1 day and start coding,
- read the documentation for 5 days.
If you chose the first one, you dive deep into the problem. On the day 2, you encounter first problems which you finally solve in the day 3. You improve the thing you do and solve more problems on days 4 and 5. It basically means that by acting as soon as you can, you have an extra week of gaining experience, which would be lost if you chose to read the docs for 5 days. This is the fail sooner, succeed faster rule which brings a lot of profit to your skill set.
Same goes for having discussions and debates on development stuff, approaches, possible solutions — just ask yourself if the result will justify the loss of time. If you’re not sure — probably not. Ask someone more experienced or more decisive for advice if you can’t figure it out.
Furthermore, losing time heavily influences your position in the company. Let’s be honest about it — thinking about problems instead of solving them may change the way people perceive you and your work, which probably won’t be beneficial in the long run. You’re not going to be trusted with tasks that require dynamics, experience in the system or exceptional solving skills, and that may lead to frustrations on both sides.
To sum up this part — go for it as soon as you can. This way, you gain more experience, things are done and you keep relationship between you and your company on a satisfactory, happy level.
Communication
Communication is a brilliant tool which can help you overcome any problems you get into, and will help you improve in the three virtues mentioned before. Not convinced? Let’s think about such cases:
- Not sure if you still need to improve the code you’re working on further (or how to do it)? Ask other (preferably more experienced) developer. He/she will be able to tell you if code quality is acceptable and will stop you from improving things that are already okay. If something isn’t right — you’ll get a piece of advice or at least a recommendation of the person whom you should talk to.
- Need help to determine if the feature you made works properly? Ask a QA engineer. He/she usually knows the system better than you and can say what impact your change may have, or what possible traps lie ahead.
- Not sure if you can actually do the thing you are asked to? Ask an architect or set up a meeting with your peers. Their experience and knowledge will help you to sort things out.
Try talking with people. Turn off Slack for a while and walk around the office to chat with them. You’d be surprised how many interesting things happen when you’re not focused on your computer.
Basing on my own experience, there are also some elementary pieces of advice which can help you in communication:
- You can really get rid of almost every problem by talking with people. Finding the right person is a matter of some experience, but it definitely helps. And it’s really good to have a break from coding from time to time.
- Don’t be afraid to admit to the lack of knowledge. This makes you more human, proves you know your skills and limitations and makes people feel you’re a partner, not a moron.
- Problems with transparency? Not sure what your teammates are doing? Become a role model, share your status even when it’s not necessary. A simple chat message will do. You’ll be surprised how soon they’ll follow.
- Stuck on a problem? Go with 30/60 rule — ask for help if you can’t solve a simple issue for 30 minutes and a hard one for 60 minutes.
- Ask people for feedback about yourself. If they will be resistant to make it straightforwardly, ask your leader to gather that feedback for you.
- Ask for people’s thoughts on solutions, views — this really can open up your eyes for a new perspective.
Not everyone is a social beast — and that’s perfectly normal. The virtue of being communicative doesn’t mean you have to chit chat with every person in the office. That means you’re not afraid to work with people, talk to them, say what you think. It helps to save your time, build connections and improve your skills even faster.
A communicative developer is a developer who can handle almost every situation, either by himself or with the help of others. That’s why, companies know that good communication skills usually mean that a person can make things happen.
Are YOU a rockstar developer?
Did those points sound obvious? That’s totally great, because it probably means you are a marvelous developer. You’d be surprised how many code ninjas actually have issues with communication or can’t manage their time well. Similarly, many junior developers take detours on code quality or do it the other way round — spend too much time on polishing unnecessary stuff.
Go over those points once again, read my previous article, be honest and think whether you actually do those things the proper way. If yes — congratulations! If no — don’t worry, there are skills that come with time and practice. Think how you can overcome those issues. If you can’t think of any idea, comment below or send me a message and I’ll try to help you out.
I can share my tips for determining if the task I do is worth my time. If you’re interested, let me know in comments. And as always — heart it if you liked it!
