In the world of software engineering organisations, hierarchy is a bad word. And yet, there is a need to classify, in some fashion, the engineers into some structure that makes sense. And the way it makes sense largely differs from one organization to another, so much so that companies are wary about attaching any kind of significance to the labels of ‘senior’, ‘lead’ etc. that candidates come armed with.
In some places, the number of years you have been in the industry , in itself, is a way to get your foot through the door of ‘seniors’. In other, yuppier, new-gen organizations you are not deemed a true lead/senior unless you’ve churned out a couple of mission-critical frameworks for the latest rocket launch from NASA. There are seniors who can barely write 10 lines of code without having to refer to stack overflow. There are seniors who are regulars at every major open-source project that is currently working on the framework that they are interested in.
But what makes a true senior? What then, is the tipping point? Who is respected and who is laughed at as just another wannabe by his colleagues? Is it superior technical knowledge? Is being a Star Trek geek a pre requisite? Do you need to be someone who feverishly reads up on every latest framework update, is furiously abreast of the latest tools in their fields and churning out side projects by the dozens?
I think the singular most important trait is — ownership. Now this is a small word but with big implications. Think about it. Do you think you feel responsible for your code? Of course, I hear you say. I think through things before doing them, and always solve the bugs that come out of my code. I refactor and leave the place always a little cleaner than when I found it .
Ah, but is that all? I think people who are true seniors are the ones who feel seriously responsible, not only for the code they themselves produce, but also the product that their team comes up with. This means more than just superior coding and software designing skills. It means staying sharp on every line of code that you write, alter, or just come across. It means taking the time to find out why something is done in a certain way, if you come across it and find it wrong or inefficient. It means, more importantly, taking the time to actually change it to a better implementation.
It means communicating, not only within the team, but cross functionally. It means owning every library that you use and follow up on things that do not work the way they are supposed to. It means going through code reviews with hawk-eyed precision to keep a tight control over the code quality. It means, keeping an eye out on the technical horizon to see what the future technical road map for the team/organization could be. It means caring enough and being pushy enough to do the right migrations at the right time.
Ownership is a very small word with very big implications. I’m repeating myself, but I think the point is worth repeating. Ask yourself if you are the go-to person for the management in your company when it comes to their technology road map. Are you the one whose word carries weight? Are you the one adding value to the customer? If so, then you already are a senior, no matter what your title says.
