Ask HN: When are you considered a “senior” programmer?

How hard is that to learn though?

That seems like a fraction of the cost it takes you to learn OOP/SOLID/etc.

You will never have enough time to learn everything and be all things to everyone. Get this idea out of your head right now or you will never find happiness.

Senior is the difference between keeping your eye on the big picture and helping to move your team forward to the objective in a timely manner to achieve the business objectives that drive the company forward. It's the ability to step up and lead your team when called for. It's the ability to make decisions balanced between what's technically right in the short and longer term without losing sight of the end goal.

Never forget that you're not paid to deliver software just to deliver amazing software. The software you deliver is a tool, a means to an end. That may be to cut costs, it may be to increase profits, it may be the lifeblood that your company's stock price hangs on.

A junior developer may be amazing with the tools provided and may have some good architectural sense. They may need some, or a lot of hand holding. A junior developer generally has their head in the code most of the time and may but probably shouldn't be expected to understand or care about the objectives of the business as a whole. You give them a feature to develop and can largely expect that they will need all of the dependencies to hand. They may have a good handle on debugging and unit, integration and functional testing or this may be something they need to learn. This is OK.

An intermediate developer can be given objectives regarding code and architecture and left to their own devices and trusted to deliver on their objectives in a timely manner. By this time, you should expect to at least understand the business objectives and be able to think critically about the code they're providing in order to meet those objectives. I would expect an intermediate developer to have enough of a clue about architecture that handed a feature requirement and some architectural direction for how to integrate it, they could architect it competently and integrate it and know where to go to ensure any dependencies are satisfied. They will have a good handle on debugging and at least unit and integration testing. They may have a good handle on functional testing and debugging production code.

A senior developer is someone in my mind who who can be trusted with the business objectives, can chase down architectural advice, from an architect or UX input or whatever else they need to get the job done; they can communicate effectively with stakeholders and the business; they can be expected to dig in and fill any gaps that would prevent delivery or cause problems in production. They can delegate pieces appropriately and deliver what is expected in the allotted time frame. They may be someone that can step up as team lead/team manager, or lead from the back and be the glue that gives the team cohesion. They can be expected to have the discipline to take care of things properly when nobody is watching. They can be expected to help debug production issues and be among the first to muck in when the shit hits the fan to help resolve production issues.

So you see, the difference between junior, intermediate and senior doesn't have an awful lot to do with code or tools. You will expected to either be or become a master of your tools whether junior, intermediate or senior. You will be expected to do this on the fly, on the job, regardless of everything else that is going on around you. This is part of being in this industry. You will be expected to keep up with the codebase and dig in and understand it at whatever level you're at. These are all prerequisites for your job as a developer, they are not a prerequisite for your title. There's a big difference.

If you want to make the jump from junior to senior quickly, here's my advice: Find the most gnarly difficult problems your company is having and dig in and help solve them consistently. When you've put yourself through the wringer; when you've suffered the late nights, the stress, the anguish about whether or not you've got what it takes to do this job. Do this until you get to a point where you think you've seen every last problem that could possibly occur, and despite that, something else hits you out of left field and knocks you clean off your feet. Do this until when this happens, you just get back up and keep going. When you get knocked down and get back up when everyone else would say fuck it, when you can be trusted to make shit happen when everyone else would say fuck it - this is when you can call yourself a senior developer.

"Out of the 39 000 men and women that make up the United States Coast Guard there are only 280 rescue swimmers. This is because we are the Coast Guard's elite. We are the best of the best. When storms shut down entire ports, we go out. When hurricanes ground the United States Navy, we go out. And when the holy Lord himself reaches down from heaven and destroys his good work with winds that rip houses off the ground, We. Go. Out." - Ben Randall, The Guardian

Live by example.

FYI: beter -> better

1) When you drop everything you are doing to mentor other developers

2) When you get asked by the business to do something you question what they are asking and the motivation, and then determine the best course of action based on their motivation rather than delivering the specific task they asked.

That's it really, it's nothing to do with your coding ability but more to do with your mentoring ability and problem solving skills. This is what is valuable to your colleagues and the business. Any answer related to coding ability is missing the point, it's important, but after a few years most people are the same programming level - it's just some people can help at the team or business level which is what makes you senior.

In my experience, it depends on what the criticality of the issue actually is, and whether it's an improvement or whether it corrects a defect. I'm reminded constantly that our job isn't to drink coffee and crap code, but that our work is done within the context of a larger organization. We may not like some of the compromises we make for our coworkers but we need them to do their jobs as much as they need us. To do something properly, it behooves us to consider their professional needs as much as our own.