Maj 2019
I've been working in software engineering for more than five years.
Probably I should not call myself 'junior developer' anymore, but using the word 'senior' is also not that obvious in some cases. I would say that I'm right in the middle of a transition process.
Due to the fact that I'm not that far from being labeled as 'junior', and also not super comfortable with a word 'senior' (especially when sitting next to my colleagues), I decided to write a few words about the most meaningful changes in my own understanding the position of software developer.
Some of the points can be considered a bit harsh, some of them are more obvious, but all in all - I strongly believe in their value. Without further due, the list is as follows...
You were one of the best students in your class. You graduated from a well-renowned college. People consider you a smart one. You found your first job very quickly and your confidence went through the roof.
Suddenly, during the first week of your professional career, you discovered, that there are people smarter than you. You discovered that the topic you were so deep into, is actually much deeper than it seemed months ago. You discovered that the amount of resources you should probably get familiar with is just hard to imagine. You discovered that some people find the topics you struggle with not challenging enough.
And… all the doubts hit you unexpectedly and your self-confidence sinks down.
You may ask yourself - Am I even able to do this job properly?
The truth is, there’s nothing exceptional about your feelings. Additionally, it’s not that bad with your knowledge!
It’s worth for you to know that the path you are following right now has been described 20 years ago, thanks to two social psychologists - David Dunning and Justin Kruger - who were trying to investigate the correlation between self-confidence and the actual knowledge in a given domain.
The conclusion from their research (The Dunning–Kruger Effect: On Being Ignorant of One's Own Ignorance) was that people with “deficits in their knowledge” tend to overestimate their cognitive abilities but those who actually understand how things work under the hood are more likely to doubt in their skills.
So, for you, the moment you become more self-aware and notice that you know less than you think you know is actually a blessing! It simply means that you’ve already reached the “Mt. Stupid” and now it’s time to slowly get better.
After joining the industry dominated by knowledge workers, you may think that saying "I don't know" paints you in a negative light in front of others. You may think that such a strong statement proves how incompetent you are, making you irrelevant for your current employer.
As a junior developer, you may think that even the dumbest answer is better than no answer at all. "I don't know" means that you've failed. You haven't been prepared enough, you haven't read enough books, you haven't gathered enough knowledge from TED talks, you haven't paid enough attention while studying this topic.
That's the way in which the external world works. It’s obvious that it will work in the same way for developers, right? Do you know the pressure I’m talking about?
Except... it doesn’t. It doesn’t work in the same way because the devil is always in the details. Sure, there are cases where these three words can hurt your reputation (being not prepared for an important meeting, being not prepared for a knowledge sharing session, being not prepared for a debate about the topic you care about, etc.), but in reality, there is a long list of exceptions from this rule.
One of the examples I can think about is when "I don't know" helps the team save time on following the paths one is not so sure about. Imagine a meeting where its participants are standing in front of a very important decision that may have a huge impact on the project's future and you are being asked about some details regarding the technology you all want to use. You are not sure whether or not the answer you’re about to give is totally valid, so you have the choice now - either you can immediately ask for more time to double-check everything, or you can pretend that everything is fine and we can move on.
By picking the first option, the team is immediately able to create an action point from the meeting - “John will investigate XYZ and will give us the answer regarding...”. By picking the second option, the team operates under a false assumption that sooner or later will turn against them and will force them to rewrite a meaningful part of the system in no time.
Mature teams will definitely appreciate those who can admit that “they don’t know” because too often they have faced a situation where being partially sure made it worse in a very expensive way (in the context of both time and money).
On the beginning of my programming journey, my head was full of patterns and practices that in theory should help you avoid the 'legacy code trap'. It seemed so simple - when you do this and that your codebase is well-written and maintainable, but when you do something else, things go south. That's what the experts say, right? As a result of this kind of black and white thinking, every time I noticed the code that was not following the guide, I was immediately judging either the author, the project, or both.
As I started to gain more experience, I noticed that most of the projects I'm contributing to have exactly the same flaws. It seemed so weird! It shouldn't look like that remembering that there's this huge pile of books that should solve all those issues!
I was so naive.
There are plenty of real-life reasons like working under high pressure, deadlines, rotation in teams, switching managers, lack of motivation, or maybe project handovers that can have a negative impact on the quality of the code you're just reading. Sure, managers should do their best to help teams avoid all of that, but sometimes it's just impossible (sometimes there are no managers at all) and you end up with the code of quality lower than expected. It’s no wonder that from time to time you’re going to face code smells here and there because it just means that some work has taken place over there.
Let’s also remember that sometimes - what's even more interesting - avoiding perfection is a completely valid way of doing things!
For example, when there's a race between you and your competitors and the only way to finish first is to take some shortcuts and ship something which is 'good enough' you should postpone shipping the Mona Lisa of software development. Otherwise, in the future, there might be no projects you can contribute to at all.
I strongly believe that instead of an endless strive for perfection sometimes we should just chill out and avoid judging, stay more empathetic for those who maintained the code before us and stay focused on the more important things.
Also, let's not forget about the boy scout rule.
One of the biggest challenges that each of us has to face at some point is about mastering, or at least leveling up in the art of time management, because the more experience you gain and the more trust others have towards you, the more time you have to make your own decisions during the workday.
The question is - what do you spend the time currency on? Do you follow the path of real-life needs or personal wants?
As a front-end developer, I’m facing this challenge nearly every day, because working in this position means that you have a pretty good chance to discover another amazing-framework.js that is meant to solve problems that are yet to come in your professional life.
I see a lot of tools that could change the way in which I build projects and presumably make me happier and more efficient only by switching from “boring-but-working.js” to “fancy-but-experimental.js”. From time to time I’m really considering it because it’s so tempting, however, for most of the time, I prefer not doing so.
Over time I learned that it’s just how things work in this industry. Developers who want to avoid being labeled as the “cost center” should really aim to prioritize the needs of those whose problems we’re trying to solve higher than their own technical challenges and framework replacements.
Such a harsh truth, right?
Keep in mind that I’m not denying the value of technical roadmap at all! For sure there are strategic technical challenges which you need to solve from time to time to move forward, but… I would really encourage you to think more often about whether or not your project solves real problems and what are the everyday struggles of its users.
All in all, it’s about the right balance.
Being a young, energetic developer is a really amazing feeling. You have time for everything, new tasks come and go every day, every single minute you learn a lot of new things, so obviously you’d like to be involved in as many projects and opportunities as possible. You want to prove to everyone that there are no tasks that could break your passion and willingness to achieve new peaks in your career. We’ve all been there!
And then, on one sunny day, your mentor says ‘let’s close this task - it’s not worth it’.
Wait - what? How could you say that it’s not worth it?! I have time, energy, passion and also some bits of knowledge to resolve that issue! I can do it! Let me work on that!
As it turns out, sometimes the juice isn’t worth the squeeze.
Experienced developers have this extremely valuable skill of executing a cost-benefit analysis regarding each task that’s standing in front of them and just abandoning some of them. For juniors, though, it may be a little bit of surprise.
So why the heck one would like to abandon the task which is enqueued in the backlog?
There may be plenty of reasons for doing so:
In general, I could say that it’s all about priorities. The more experience you gain, the more opportunities you see in front of you, so it’s pretty similar to the previous point. It’s not only about whether or not you spend your time consciously and accordingly to real needs, but also if you spend the time doing the right things at all.