(First of two parts)
Over my growth as a developer that landed me to fund a software company, I’ve worked and mentor young engineers. A recurrent question I get is how to become a senior developer? This is not a simple question, every place has its own definition for what a senior dev is. However, from my experience working with several companies of different sizes and maturity level, I’ve found that to be a senior developer goes beyond simply to be familiar with certain technology. Actually, you must be able to make good decisions, provide accurate estimations and deliver on time on regular basis, among other things. The following points are intended for young developers starting their careers, despite more experienced devs may find them obvious, this list summarizes what I’ve seen a few fellows struggling with.
Project
1) Know the priorities and keep them straight: This point is better explained with this simple analogy: Imagine you are building a house and in the to-do list you have to install the toilet and paint the window frames. Of course, all things in that list needs to be done. However, for the house to be inhabited the toilet is indispensable while the window frames are not. (And you have the option to install the toilet or paint the windows frames. Of course, both things need to be made, but if you don’t paint the frames the house may still be inhabited, but if there is no toilet, it can’t.) This might be an extremely silly example and you may argue there was a project plan and budget already approved, but in real life plans change and budgets get cut. The idea to take away here is always be aware of what is most important at any particular time and make sure it gets done.
2) Avoid assumptions and make powerful questions: Assumptions are the root cause to many problems, and the reason I dislike them the most is that they are perfectly avoidable. You need to be aware of the things you don’t know for sure and make powerful questions to leave no room for ambiguity. For instance, imagine somebody asks you to meet at Starbucks at 8, then you reply with a powerful question to know what Starbucks branch and whether the meeting time is 8 a.m. or 8 p.m. Therefore, you won’t be at the wrong place at a wrong time wondering: If I hadn’t assumed ...
3) Analyze before starting to code: When we are young, sometimes we are eager to show our value and start writing code as fast as we can. However, it is faster to think ahead how you are going to build things, perhaps even draw a couple of diagrams, rough sketches if you will, but something that helps you to have a clear picture in your head of the hurdles you may have to sort out and the questions you will need to answer. Then you can start writing code in a more secure way.
4) Make good decisions: This sounds silly, right? But I don’t mean it in a, don’t drink and drive way, but rather in professional scenarios. And how do you begin making good decisions? First, list all the variables that may affect your decision, like: how ease of the implementation, experience with the technology, performance, cost, etc. Once you have all the variables listed do the same with your different options. Now you are ready to analyze your options, you can use a simple technique such as a Pugh Matrix to compare the different options and support your decision in a more solid way.
5) Know your customer: I’ve known people working on codebases with neither the knowledge nor the interest in what problem the software was going to solve. To me, that’s what we call code monkeys and they will be replaced by robots or cheaper labor in a not so distant future. When you care, it shows, and people starts to listen to you, and ask you for your opinions and value them. And so it begins, step by step, your responsibilities increase, and so are your value and opportunities, and consequently your pay check.
Teamwork
6) Don’t be afraid to ask: I understand you may be afraid to look as an ignorant to your peers or your tech lead, but believe me when I tell you that good teams love to ship software on time, and hate delays and their causes. So they will probably be more upset when you failed to ask something and, as consequence, the project is delayed, than if you asked something trivial but get over the hurdle and learn the lesson.
7) Don’t be afraid to ship: Declaring something as done can be nothing short of a traumatic experience when you are novice, but remember, we get paid to ship products, plain and simple. So, instead of trying to find excuses to delay your tasks: ship, deal with the consequences, learn from your mistakes and successes, improve and iterate until you are not afraid any more.
8) Respect your more experienced teammates: At times you may disagree with the decisions your technical leader makes, and that’s ok, but before getting all angry because she/he is so wrong, I propose the following approach: Ask the reason for her/his decision, try to see and understand the whole picture, perhaps there are constrains you are not aware of. In any case it will be more useful for you to understand the decision-making process than simply throwing a tantrum because somebody disagree with you.
9) Balance between blind obedience, reckless disobedience and covering your ass: Let me tell you an anecdote to illustrate this point. I was working on a project as a Business analyst and among my responsibilities was writing some stored procedures where business rules were enforced. The customer acceptance test was to be carried in China and our technical leader had to fly there for the test. About a week before the release to the user’s test environment, the technical leader told me a business rule was wrong and how to fix it. What he told me did not make any sense to me and let him know that respectfully , when he insisted that I should change the stored procedure for the rule I asked him to clarify exactly what he wanted by email. He did and I proceeded to flag the message so it would be easy to find it later. Also, I made a special backup for the stored procedure code so I could grab it right away when needed. A week later, when testing in China that very same business rule did not pass the acceptance test and I got a phone call from my technical leader asking me why it was programmed that way and who asked for it. I told him, again respectfully, you did, let me forward you the email. So,30 seconds later he asked me how long would take to change it back. Right away, I just have a backup at hand. The moral of the story is sometimes you are right and your boss is wrong, in those cases I found better to ask for clarifications via email or any other traceable means and perhaps reply with your proposed solution. So, in case any problem arises you are covered and the right solution documented. You may think this is unnecessary but sometimes bosses throw subordinates under the bus, so I recommend being smart about it.
10) Answer emails: Please do so, if not for other reason by common decency, sometimes a simple Thank you! Or acknowledge will suffice is enough, and that makes a ton of difference versus not replying at all.
Top comments (16)
These are some good ideas.
I also offer:
From a command line of a Python enabled box, type
python -c "import this"
And you get:
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than right now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
Although I agree with your post, the harsh reality is that senior level is often granted to older people just for the sake of being older (or looking more responsible. mature, etc). More years don't automatically traduce into useful experience.
Every persons experience is different. I've not seen the same pattern where I've worked. Age, of course, does not garner anything but wrinkles. In my opinion, the environment you describe has a culture issue, and you should not wait to grow old there to advance.
I've heard this put very succinctly as: "There's a big difference between 10 years of experience, and one year of experience repeated 10 times."
Wow, that's bitter. Best move on before it eats you up inside. I speak from that much-maligned experience.
Yes, that is the red flag for me.
Hi. I'm a young engineer in Japan and very impressed by this article.
Could I translate this article into Japanese and share it on qiita.com?(an engineers' community for Japanese)
Ofcourse, I will indicate this article as the source.
:)
I've just published the second part
dev.to/veloceronte/the-road-to-sen...
Of course!, I feel honored
Great points here! My only thing to add would be to "work yourself out of a job"! People who write "job security" code will never become seniors because they can't pass on knowledge to make more seniors... Seniors help replicate themselves as best they can.
Knowledge has a curious property, the more you share, the more you have
Writing a beautiful code is art
indeed!
Part 2 of the series.
dev.to/veloceronte/the-road-to-sen...
Well written series. Kudos from India. :)
Thanks mate!
Saludos from Tijuana, México!
Exactly what my PM has always told me. Not so much about writing good code but adding value to it with consultative counsel and dependability. Bookmarking this as a constant reminder. Thanks Alfonso.