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 I few fellow struggling with.
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 is 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.
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 ...
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 are you 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.
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.
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.
We 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 will 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.
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.
At times you may disagree with the decisions your technical leader makes, and that’s ok, but before getting all angry because he/she 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.
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 it. 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.
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 to not replying at all.
Zorbek Software House is a software development agency based in Tijuana Baja California, we can help you create beautiful concepts and products for the tech era.
Ensenada 2237 - 8, Colonia Madero (Cacho), C.P 22040 Tijuana, B.C.
You can find our delicious socialmedia content on Facebook!