Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think you have found the issue to be honest, I think most people are expecting to be "senior" in place of "not junior" as soon as they prove they are good programmers. The senior title has been quite diluted by that.

Seniority is about experience and not skill in my opinion, we see many talented developers who don't qualify as senior because they simply haven't experienced enough situations. I expect a senior to have some war stories and a breadth of notable situations that they can walk me through, to demonstrate their ability to predict common issues and pitfalls, and to show how their experience helps their troubleshooting and informs their choices.

If I had told 20 year old me this, 20 year old me would have balked. 20 year old me was an excellent programmer, but he didn't know shit about long term software development.



I think the missing piece is the intermediate / non-qualified title. Junior implies to me someone who requires frequent hand-holding and coaching even on small scale tasks. Senior on the other hand should require cross-functional communication skills as well as technical mentorship. There's a huge swath of developers who fit between those (solid individual contributors who aren't necessarily ready to lead a project or mentor).


"journeyman"? Might be too dated, or too gendered these days, but yeah... some 'not junior' term that just indicates they're "better" (experience or skill or both) than the juniors, but without all the expectations that 'senior' should bring.


I've just always used whatever comes after junior / senior without a qualifier.


I get it, and do too sometimes.

For me, this most often comes up when acting as a reference for someone. The hiring person will ask me stuff, and often a 'senior' label question will come up. Almost invariably the person I'm acting as a reference for is beyond 'junior' connotations, and I think have to ask what the hiring person mean by 'senior'. Getting their definition helps me answer most effectively.

"Yeah, AB is pretty close to what you class as 'senior'. He's going to work well in a larger group with defined roles and a set schedule, which it sounds like you have."

"Well.. SJ is not 'junior' any more, but does need to have someone more senior to help mentor/check in on more advanced topics. If you don't have that - if this is a 'lone wolf' role, they may struggle some".


We have all the titles we need. We have junior for "that guy who can't do a fuckin' thing unless you tell him exactly what to type." We have senior for "that guy who can take a ticket and implement it." We have lead for "that guy who can take a business idea and implement it."


That should just be the title without prefix really, a Senior Developer should be providing more value than just ticket implementation.

These are just my opinions though, it differs from company to company. One place the difference between a Developer and a Senior Developer was a senior could be expected to own a feature and all the moving parts to get it deployed, eg: taking it to the board, organising all the approvals and business requirements with other teams etc. Other places senior just means "not junior" and the roles are the same, you just expect more talent from the senior.


> I expect a senior to have some war stories and a breadth of notable situations that they can walk me through, to demonstrate their ability to predict common issues and pitfalls, and to show how their experience helps their troubleshooting and informs their choices.

Yep. I've been doing this for... almost 30 years now, and... interacting with 'seniors' with 2 years of experience is really weird. My recollections from the 90s having worked inside a few places was that 'senior' had a lot more weight/heft to it. It indicated, at the very least, long experience (8-10 years or more) and some ability to at least work with other tech people (non-tech was a bonus).

Can't quite figure out when this shift started, but have definitely noticed title inflation as a regular thing over the last 10-15 years.

Have you ever taken down a database by mistake? Dealt with bad backups, "on production only" issues, rounding errors in historical data, security breaches, multibyte character set conversion issues?

"Coding" is eventually only a small part. Better coding skills up front can help prevent or mitigate some of the potential issues listed above, but only to a point. You're not always even the author of all the code in use; learning how to deal with that, maybe under pressure of "prod is slow/down", has an impact on how you consider these issues going forward.

EDIT: tangential story

I was at a meetup years ago, and one of the "senior dev/architect" folks at the company hosting the meetup was talking informally about IDEs. I jumped in a bit as I'd recently started with IntelliJ (this was... 2010, I think) and was excited to share a few bits that were new to me.

As I listened more, the guy was lecturing the meetup folks that "IDEs were really for juniors and newbs". Specific language is somewhat lost to the mists of time, but the gist was "This is your code, you've written it, you should know it inside and out; fumbling with slow IDE just burns productivity, wastes time, and just shows you don't really know the codebase."

I eventually interjected that it might be reasonable for him, personally, to know all the code in a system that he'd built up from scratch over the last 7-8 years. However, for anyone new coming in to the codebase, an IDE is invaluable because it makes the entire thing far more discoverable. Jumping around between sections helps you learn and narrow down bugs/issues much faster. "Well, you should just be asking your senior if you have questions" was the main response, and IDEs were still beneath him.

I realized a bit later he was actually giving a small pitch; as host of the meetup, they had an intro period, and they were recruiting. I'd heard about this company before - growing, funded and in a space I had some experience in. Had 0 desire to work there after talking to him. But "the senior architect" always knows best in many places. :/


> Can't quite figure out when this shift started, but have definitely noticed title inflation as a regular thing over the last 10-15 years.

I'll bet it can be tracked down by looking at job-hopping. That's how it happened to me in the early 2010s: I was never told I was promoted to senior developer, one day I was just invited to a meeting for all our senior developers to get opinions on something. I hadn't noticed before, but during the meeting I realized I technically was in the older half of all the devs in the office (in terms of time at the company, not age), just due to all the hiring that had been done in the previous year or two.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: