Ask HN: When are you considered a “senior” programmer?
I have been doing web development for as long as I remember. I get by with tools that are needed for the job. I don't fancy the new and shiny. I just get things done fast and done properly.
But I feel like I'm always a step behind the rest. There's this guy in the team knows how to operate Amazon, or this guy who that knows how to use Spring, or this guy that knows how to scaffold a Java app in minutes. Sure, I can write in the Java language but I don't know Spring by heart. I can build and run containers, but I don't know how to launch them in the cloud.
When is one considered to be a "senior" developer? Is there a means to measure where I am? How do I get there?
161 comments
[ 3.2 ms ] story [ 235 ms ] threadOur industry is way too obsessed with fashion... sooner or later you realise that most of the "new" stuff is largely existing ideas re-hashed in a slightly different form. Senior programmers realise this and can pattern match to understand the role of various new technologies, and learn the details if and when necessary.
How do you get there? You already are, you just don't realise it yet.
I think that's wild speculation. That phrase could mean a number of things.
It could mean they engage in the industry, explore new technologies and make educated decisions which balance the risks associated with adopting new technologies and, in some cases, choose to use technologies that are fit for purpose but are not necessarily bleeding edge.
On the other hand it could mean they have failed to keep up with technological advancements and are using the wrong tools for the job, tools that can't deliver a modern web experience. He might be churning out shocking legacy code that someone else will have to clean up one day. Perhaps his employers are none the wiser and don't realize a different developer could deliver a better quality product in a much shorter time using the tools available today.
Given OP's examples of not knowing "Amazon" or Java Spring, both of which are ancient technology in web years, I would speculate the OP might fall into the latter category. Another strong indicator of this: OP has been doing web development "as long as [they] can remember". You'd think his coworkers or employers would have told him he was a senior developer if he hadn't figured it out himself.
Overall, insufficient information in the OP to make an assessment, but I would be very wary of pandering to someone's ego as it can do more harm than good.
Also, why would you know Amazon operations stuff if your job duties don't expose it to you? The OP was saying 'operate Amazon', not 'use Amazon APIs'.
Disclosure: I work for Pivotal. So do many members of the core Spring team.
To the junior engineer, "done properly" might have a different meaning. A senior engineer should be able to explain in detail what "properly" means.
Some times it's given to people instead of money.
Don't worry about the title. Worry about getting good at what you do, and an asset to your team and organization.
I would add that the senior engineer has a mature approach to selecting/recommending tools and frameworks, based on what is most valuable for the business and the team, rather than was is cool, good for their career or whatever.
It's not that I thought they were wrong in what they had to say, just there is an appropriate time and a place and being able to make that call is just as if not more important than the style of functionality being added. I find such seniors can be toxic at times. In essence there is more to being a senior than just being a great coder.
Adding a simplier design with functional code is a good thing. If there is a mid level developer that can't follow the current state of the art, than he is not a good mid level developers. Also "good" junior developers have mostly zero problems in understanding more functional code. I mean you don't need to understand Applicative Functors to use map/flatMap.
I mean there is a line which you should not cross too fast when introducing functional stuff, however most people just don't even try to understand the simple stuff even that it is way more simple than most while/for loops.
If it is a business requirement that good developers must be slowed down for bad ones to catch up, then do it by encapsulation and mentoring. Not by decreeing that good developers must act exactly like bad ones.
It should also be mentioned that responses similar to the examples have approx. no substance, detract from the quality of the conversation, provides no value to the team, and will likely only decrease mutual trust and respect.
The only consolation is that the system in question hasn't entered production yet, and probably won't for at least a year at the rate it's progressing.
I didn't find it in any way harmful.
- you are technically competent
- can handle design aspects of full stack (backend, persistence, frontend)
- have enough credibility and confidence to say NO to business people
- you can lead a small team of developers (2 to 5 people)
This is the most important part. Other points you mention are about your skills and you can learn them. This one, however, is in major part about your reputation, which you need to earn.
Going a step further, I'd say you're a "Senior" as soon as people around you start to treat you as one. You can be very knowledgeable but that won't be enough if you can't prove to others that your knowledge is relevant and solid.
Senior people have made the right mistakes, wasted weeks of time, and know what to avoid, what to embrace, and what to ignore. A senior dev can understand the requirements and figure out what is important and deliver something without a lot of external input.
This really sums it up, almost every other answer could be seen as a consequence of this.
You can learn from other people's mistakes, but the pain you feel yourself will make you never forget it.
As I've gotten older, I've started to appreciate how much farther a good developer can go rather than just these things. I think the kinds of things you talk about are things that most people can accomplish in 5-10 years. But how do you differentiate between that and someone with 20-30 years of experience?
Because the industry has been expanding so fast, we have perpetually been in the situation where most programmers are younger. But I don't think it will be too long before you will see half your team having 20 years of experience. If you ask yourself, "How am I going to improve after I've worked 5-10 years" and "How much better can you get" I think it is instructive.
My experience has been that you can get a lot better, but that it's very hard to see the difference from the perspective of being a junior or intermediate developer.
A solid general code understanding is also needed in my opinion. This includes things like using documentation over googling everything. If I pair with a senior and he types "golang how to do x" on every problem, I probably wouldn't consider him senior. (Not saying googling is bad. Just don't be a copy-paste-from-stackoverflow engineer)
With that, I also hate the term "senior engineer". I got friends with 3 years of work experience that are now "senior" because a company hired them under a senior position (basically more salary) and the companies after that just did the same because "well he already is a senior, right"? This also generates a strong in-balance inside the team with a hierarchy that shouldn't be there. I am usually advocating for getting rid of job titles and calling everyone just "Software Engineer"
I am now 6-7 years into my career and don't consider myself senior. When people in interviews ask me what my career goal is, I usually mention I want to be able to consider myself senior as the next step.
Heed your own advice. You might not like the current system of hierarchy, that's fine. And change it when/if you get the chance.
But in the meantime, don't abstain from senior positions (and salaries) that others get just because you don't like a concept. Play inside the system until you can change it.
Oh yeah, I don't. I am also applying on "senior" positions, but this is just my personal opinion on when I would consider someone / myself truly senior. Paycheck and job description aside.
They were forced to offer me position of senior developer and no other company after that dared to offer me lower position.
In my understanding, a senior engineer is an engineer that can contribute without the need for technical supervision.
Now, not requiring supervision is different to leadership. A senior engineer is often an individual contributor, not necessarily a team technical leader.
It can happen even with two years of experience.
A misapplied case of carrot and stick; using the carrot to beat you down is not how it works!
The company I work for has made more than a couple big sales in December from this phenomenon. Sometimes they never even deploy the software.
If someone like Donald Knuth would be forced due to economic circumstances to join a trendy web start-up, he'd be a junior working under a twenty-something senior with little more than some Javascript and MongoDB knowledge. The whole thing's silly, really.
I've been working (professionally) in this industry since I was 16 years old, I got my first job as a junior after tinkering with computers since I was 8 years old. At the age of 23, I've found it very difficult to earn the respect of the people around me because of my age.
I have the title of senior developer because I've had experience working on scalability issues and complex service based infrastructures, but many of my peers who are my age and recently graduated university and are still in their first junior roles often act like I haven't earned it - despite me graduating with a part-time degree in software engineering (okay, it's not computer science, but I'm still glad I did it.)
My point is that while age is generally a good indicator of knowledge and ability, it's not the be-all-and-end-all.
If you are adding value, you're doing it right. You are either a cost center or a profit center. Be the profit center and you will never want for a job.
I'm almost 50 and still in the game. If I'm honest, I still worry from time to time about being irrelevant, but if I'm still adding value, and I am, then what the other IT people around me think doesn't matter. Add value, learn as you go, gain in wisdom and understanding and you will always be cash-flow positive.
Don't make the mistake that so many do that you have to be working on something cutting edge or popular. Those jobs are nice, but I've learned--at least for myself--that I prefer the maintenance jobs. I enjoy taking something and making it better, even if it's just a quick fix, like two lines of code. Own everything you do. Be proud of your work.
You're still young with plenty of time to get where you will be going. Don't be in a rush to "prove yourself" to anyone but yourself and the man writing your check. Don't listen to naysayers, don't get trapped in the mindset that only the new, darling languages are worth investing in. Good programming skills are not language specific. Learn what you can. Use the correct tool for the job. Don't be a method man. Be the profit center.
It's also worth noting that the term "software engineer" isn't regulated here, while other engineering titles are.
No they aren't. Unlike in Canada, you can give yourself any title without actually having a license in that profession, as long as you aren't being fraudulent in your claim.
Just be wary of thinking you know it all, this applies to everyone, regardless of age or experience.
But another 5 years later, you notice how little you really knew. You become really senior at 10+ years. Just like the hype cycle.
To play devils advocate, why wouldn't Donald Knuth be the junior given that scenario? In that position he may actually know less relevant knowledge than the junior. I mean many startup/crud apps don't require advance algorithmic knowledge, more front end dev and ability to deliver relevant business value. I wouldn't expect that junior to join knuths team and be put in charge, why should we expect the reverse? Given time yes, If Knuth is more intelligent he could become better at startup relevant work, then he should be more "senior" not before.
https://www.britannica.com/topic/firm-specific-human-capital
Junior: Can do it with guidance and/or clear and non-transitional specs
Developer: Takes the ball and runs with it. Can walk a customer through requirements gathering and make recommendations. Will help guide junior developers.
Senior Developer: Can architect a system well. Can communicate equally well between executives, salespeople, management, and end users. Can and will mentor lower level developers. Can explain concepts on the fly to lower level developers and walk them through the development process in terms they understand. Takes initiative at learning new technologies.
Well yeah, I can do that, but isn't that normally the business analyst's job?
Also, maybe it's more about understanding the product? Just a thought.
(Yes, I am currently frustrated with our product management)
Just my personal opinion. Based on environment, this may or may not be a good gauge.
How do you learn to do this?
Experience building and supporting them. This is really just a definition based on my own experience and environments.
If you've been getting away with it, you're probably reaching a level of seniority that deserves a promotion.
Above that, it depends what you want to do. If you fancy managing people, you can be a team/tech lead, or if you don't, then there is the title of "expert"(only a handful of programmers who worked here 10+ years have those).
To sum it up I will use .NET as an example, in my eyes when someone says I am a senior .NET developer I assume that she/he has: - used UMLs, - knows how to write proper OOP and understands SOLID, - can use MS SQL and some kind of ORM, - uses some of the testing frameworks (e.g. NUnit), - knows how to deploy application whether on IIS, or install it with ClickOnce for example. - know how to handle source versioning (TFS or whatever is your poison)
I probably missed a few things, but that's about it for me. If a senor doesn't have these skills I assume first that she/he has great knowledge of company business which would make her/him a valuable asset, or that she/he got lucky, or it's a crappy company :)
Like unified modeling language?
That seems like a fraction of the cost it takes you to learn OOP/SOLID/etc.
As others have mentioned as a senior you can be left to implement changes without guidance, you will clean up issues as you come across them instead of leaving it to others, you suggest improvements, you make time to mentor and guide more junior members of the team, you know how to relate to muggles and you act like a team captain.
Knowing lots of different hosting environments and languages comes with experience. The approach you take to your role show's your all rounded skill set.