7 ms·

Falsehoods junior developers believe about becoming senior

98 points by kiyanwang 3y ago

screenoridesagb 3y ago
Junior Developer: Let’s get everything done! Senior Developer: nah nah projects don’t matter as much as using whatever tech stack I’m used to.
- hk__2 3y ago
  I have the opposite experience: junior developers tend not to do research on the tech stack and just use whatever framework they know with some shiny libraries on top of it.
- pavel_lishin 3y ago
  In my experience, this is backwards, though not always.
  - dexterdog 3y ago
    I've had a mix of it, but I am also often the guy trying to push a reason to use the new tech. Not necessarily a stack but usually a new database or service that fits the problem space well.
- dagss 3y ago
  Exactly opposite in my experience. Seniors (10+ years experience) knows what programming language or library or paradigm or monolith or microservice you use isn't THAT important they all have their problems and everything is a tradeoff. Juniors rewrite code to use their favorite language, rewrite to microservices, etc. But it could be we just have different definitons of "senior". The ones with a couple years experience, enough knowledge to be dangerous but not yet lots of experience and not seen enough bad stuff yet are the worst...
  - screenoridesagb 3y ago
    Senior developer wants job security having an unsupportable project or two doesn’t matter because 99% of the job is stretching deadline to line up with vacations.
    - dagss 3y ago
      Making projects supportable is good. Not distinguishing between objectively bad code, and code that you just don't understand right away because you didn't write it yourself and you do not yet have enough training to skim and understand other's codebases yet is not.
    - jnovek 3y ago
      Not sure where you’re working, but your senior devs are quite misinformed. Every layoff I’ve witnessed sliced quite a bit off the top because they’re the most expensive. Absolutely no regard for who was maintaining what legacy projects, often leading to months of setbacks while the remaining engineering staff tries to understand a critical yet unsexy tool or service that no one else was willing to touch. Having “special” projects is in no way a form of job security.
      - screenoridesagb 3y ago
        If your business is operating like this it’s not sustainable. You need 10 developers for every project so the senior developers can complain about meetings instead of exposing themselves to code review. That helps there supposed knowledge.
Warwolt 3y ago
What a bleak and depressing post
jitl 3y ago
This one is real: > Expectation: Once I become a senior, I will lead big projects, have a big impact, and tell others what to do! > Reality: I miss the times when people told me what to do. I’m very happy that I can just write code and do what I’m told on my current project — blessed with very strong collaborators. Being tech lead shaped person on a team and training/onboarding everyone is rewarding but draining, and it’s good to find ways to change it up.
- pavel_lishin 3y ago
  Yep. Whenever I'm leading a project, I try to leave myself something to actually do, so I can spend time doing the thing I actually enjoy doing.
  - Longhanks 3y ago
    Why do you lead projects if you don't enjoy doing it?
    - cebert 3y ago
      I’d imagine compensation comes into play. Why do so many software engineers go into management?
      - usrusr 3y ago
        Compensation not only in terms of getting more, but also in terms of keeping it from dropping off. Good luck fending off ageism if you don't shift into more managerial roles.
    - deleted 3y ago
      [deleted]
    - jitl 3y ago
      I do a bunch of stuff I don’t enjoy because it makes my life better in the long run. For example: laundry, if I don’t do it, then I have to wear dirty clothes and I am sad (and smelly). So it goes with engineering too. Sometimes (often?) I need to do something that’s not enjoyable in the short term to realize the best long path.
kqr 3y ago
I suspect a lot of this is a product of environment. When I had less experience, I saw all these flaws but could not affect them. Now I'm constantly worried what I'm looking at is not an actual flaw even if I think it is, but when I can convince myself, I can usually also recruit help from upper management to fix it. That is very relieving and much less frustrating. (This was not the case at my previous employer. They didn't listen to anyone internal regardless of experience.)
sam0x17 3y ago
#1 item that should be there and is missing is: "My first job will promote me and raise my salary when I "become" a senior dev"
- StableAlkyne 3y ago
  Yup! Easiest way to get a raise is to self-promote into a different company
  - syndicatedjelly 3y ago
    It’s also a great way to receive an undeserved “senior” title
  - 13of40 3y ago
    I've heard this a lot over the years, but honestly, as a hiring manager, I'm not going to waste my time with a candidate whose resume shows them hopping companies every year or two.
    - sam0x17 3y ago
      The average in this industry (startups) is ~2 years at best so that's a bit close-minded. A lot of startups don't even make it to the two year mark. 5 years is like a century. At Google average tenure is 1.1 years, so looks like FANG is following the trend as well. You're definitely missing out on the top 25% of the market if you only stick to people who (stupidly) stay in the same place with no diagonal upgrades for 3+ years.
      - syndicatedjelly 3y ago
        Most people don’t work at startups.
        sam0x17 3y ago
        We're on HN, friend ;)
1letterunixname 3y ago
Seniority means thinking about the bigger picture and influence. And at some MAAMG shops, it also includes steamrolling over and tearing apart others' ideas to get credit for your own ideas, initiatives, and impact.
- ldjkfkdsjnv 3y ago
  Steamrolling is arguably all that matters
- hiddencost 3y ago
  GAMMA or MAGMA?
xandrius 3y ago
It's just reads that the author works/worked at horrible companies. Also because someone gives you the title senior, you don't immediately become one: for me being senior is about changing one's mentality (through experience) that a problem can almost always be solved, and bringing that confidence to the team. As a junior one often worries whether they have enough skill, as a senior you know you do and whatever you don't know, you'll learn it. Boring meetings, working during the weekends, stress and awful legacy tech is not a necessity.
- TillE 3y ago
  I feel like it's only in the past few years people have been talking about "junior" vs "senior" except as literal job titles. It's a weird binary distinction when of course gaining experience is a gradient.
  - dexwiz 3y ago
    Because they are two different jobs usually. Juniors are more focused on code while senior trends towards planning, reviewing, and leading. In my experience a senior is just as likely to spec out some work and pass it on as do it themselves.
  - kelseyfrog 3y ago
    It is of course a gradient, however, on that gradient there exists an important threshold: can this person, under their own direction, produce positive net value? Juniors require your active guidance. Seniors require your availability.
    - blowski 3y ago
      I consider the size of relevant “horizons” - time, number of features, number of people. A junior should be able to have a positive impact working independently within very narrow horizons (a single function, 1 other person, 1 hour), and is showing growth as those horizons increase.
    - kqr 3y ago
dakiol 3y ago
Expectation: Once I become a senior, I will have more time to relax. Reality: It’s fine, I’ll finish the work on Saturday. The expectation is actually true in my personal experience. The more I know (and I know I don’t know tons of stuff) the more free time I have during working hours. It’s not that I’m solving NP problems or hard distributed systems problems or migrating TBs of data without downtime; i’m doing more complex stuff than when I was a junior, but all in all, I can control it and hence the relaxing time I have nowadays (compared to the hectic times when I was a junior)
lapcat 3y ago
Falsehood: The distinction between "junior" and "senior" developer makes sense and isn't just the figment of the imagination of some corporate ladder climbers who drank too much of the kool-aid. Let's say I drop out of college, found my own software company, and within a few years my company is valued at 9 figures. Am I a "junior" or "senior" developer? Does anyone give a crap? Keep in mind that in high school and college, one advances from "junior" to "senior" simply by aging one year and not failing.
- dexwiz 3y ago
  At that point you are an entrepreneur. The division only exists in large companies with highly segmented job roles. The more hats you have to wear, the less that line shows.
  - lapcat 3y ago
    > The division only exists in large companies with highly segmented job roles. In some companies, yes, but it's all relative to the company. Each company has its own job titles and levels. It would make sense to write a blog post about "How to get promoted to [title] in [company]". (And the honest answer might be self-promotion or brownnosing, for example.) The problem is that too many developers try to actualize and abstract these arbitrary job titles into some fundamental category of programming reality that exists independently of arbitrary corporate job titles. That's what I mean about drinking the corporate kool-aid. There are continual debates in blog posts and on social media about what "senior developer" means, with no reference to a particular company or job within a company, and I consider the debate to be all nonsense. It's worse than spaces vs. tabs, because at least spaces and tabs are real, well-defined characters.
    - dexwiz 3y ago
      This kind of discussion is in part due to pressures from HR, again something more common in big companies. To standardize hiring practices HR people do something called banding or leveling where they do try to define job levels and responsibilities across the industry. Primarily so they know what to pay people. Also so people can plan career tracks. Yeah it’s all Kool Aid but a lot of people are drinking it. Also there is a demonstrable difference between someone who just codes and someone who leads projects. Generally the senior path can be seen as a technical leader path, and that is transferable between companies. But the word senior itself has lost meaning. Senior at my company is squarely in the middle. Principals are the true seniors.
donatj 3y ago
> Reality: This legacy code isn't going anywhere, and neither am I. Let's fix some bug that happens once every full moon. I've been doing this for 18 years now, maybe I'm just getting old, but I prefer legacy code. It's got a history, it's got known issues. All greenfield is is problems you don't see, yet.
- layer8 3y ago
  I’m similar. Maintaining code in the long term is where the really interesting challenges lie. Greenfield projects can be refreshing at first, but after a while you realize that all you’re doing is create what will soon become legacy code. The proof is in the pudding, which is the legacy phase.
jollyoldpirate 3y ago
[flagged]
treflop 3y ago
I’ve been doing this for almost 10 years and I disagree with everything but the first and last point. (It’s true — I don’t have all the answers, and yes, I can be laid off, but so can the company disappear tomorrow.)
- hk__2 3y ago
  Could you expand on why you disagree?
  - treflop 3y ago
    > Expectation: As a senior, I'll get to play with the latest tech and build amazing projects! > Reality: This legacy code isn't going anywhere, and neither am I. Let's fix some bug that happens once every full moon. I still get to play with the latest tech to evaluate them — do I adopt them? Usually no, but that’s my choice. Sorry man, I tried building real projects with new tech as a junior and the tech always went to shit then too. Except for the occasional unicorn, new tech has never been fun. Plus I don’t know about anyone else, but I sure worked on legacy code too as a junior… I’m talking fucking ColdFusion at one point. > Expectation: Being senior means I can avoid all the boring tasks. > Reality: Endless meetings, documentation, and code reviews… Oh, and did I mention debugging legacy systems on Friday at 6 PM? I love meetings. That’s where I set everyone straight and tell them that they should consider this second option and it may save them (and me) a ton of money and time. There are the occasional overly-long meetings but I speak up and nip the problem in the bud. There are some boring ass meetings that have to be done like standup but I’m not even lifting a finger. It’s like being paid to do nothing. I also enjoy documentation personally. Code reviews are kinda boring, no cap. But whatever, it’s not that bad. I could be cleaning a kitchen at a restaurant or fixing a stripped screw. I’ve had to debug systems at inopportune times before but it’s happened like 5 times tops in my career. But overall, I get way fewer shitty tasks as senior. > Expectation: Has a million ideas on how to change this company 180 degrees! Let’s improve everything! > Reality: Knows that nothing will change without management approval and the necessary budget. I guess I don’t disagree with this one that much, but I never had much friction as a junior dev either. Honestly, the problem is that most people barely have a handle on what’s going on the company and they might suggest building a bridge when we’ve been breaking ground on a tunnel for four years — no shit your idea is not going to get any traction. Maybe read the room first? > Expectation: Once I become a senior, I will have more time to relax. > Reality: It’s fine, I’ll finish the work on Saturday. Can’t say anything other than I’ve never had to work weekends in my life at a software company. > Expectation: Once I become a senior, I will lead big projects, have a big impact, and tell others what to do! > Reality: I miss the times when people told me what to do. Sorry I just can’t relate to this one at all. I just love engineering, all my past projects have always worked out very well. Right now I’m building a DIY pressure-activated water pump system in my garage and I just bought all the parts while sitting in a Target parking lot, put it together in 15 minutes, and it just worked. I have all this knowledge and experience from doing this for 10 years and I’m still learning new things all the time and challenging myself, and when I put shit together, it works.
standardUser 3y ago
In my experience, the difference between junior and senior is the company wanted to keep the "senior" engineer and titles are free.
hnrodey 3y ago
I read through the article hoping to join the comments with several hot takes, but alas I'm disappointed. Well written and largely accurate. My primary disagreement is working into nights and weekends. If that's your thing then so be it, but I avoid it like the plague and my career has progressed quite well. I've remarkably committed during the work day and I don't fuck off - I just get my stuff done. Amongst the biggest risks that comes along with being a senior developer is that, at some point, your skillset adapts specifically to what THE EMPLOYER needs it to be. The trade-off we make is reduced risk of losing job (as the author called out). Even if you avoid layoff, at some point you will want to change jobs. Entering the job search after having an entrenched position that you grew into is like being married for 5-10 years and then entering the dating scene ... the new suitors (employers) want a mate (employee) with abs and a flashy sports car instead you're showing off a dad bod and well maintained minivan. It's a fine decision to make either way, just know the game you're playing.
hiddencost 3y ago
Do not work over time.
- cebert 3y ago
  Working extra can be a good way to differentiate yourself from others and more easily earn a promotion or additional compensation.
csmattryder 3y ago
> Reality: It’s fine, I’ll finish the work on Saturday. At no point have I ever worked outside of contracted hours, and at no point will I ever do so. Sorry, no, once I did and it lead to me leaving the job..! And it's harmfully perpetuating the idea that you're expected to do so when you're not paid for the labour.
- hk__2 3y ago
  > At no point have I ever worked outside of contracted hours, and at no point will I ever do so. Sorry, no, once I did and it lead to me leaving the job..! "At no point have I ever worked outside of contracted hours" but "once I did"? Anyway, you probably worked at large companies only; I work in a startup and if the other ops guy is offline I do work off-hours because, well, the website won’t go back up by itself.
  - sojournerc 3y ago
    If your website needs 24hr babysitting, you're doing something wrong.
    - marcosdumay 3y ago
      The GP is saying that his website fails outside of the contracted hours as well as inside of them. And yes, an emergency here or there is normal in smaller companies. If they start happening several times in a single year, it's a sign that something is very wrong, but it's not reasonable to expect them never to happen. Also, a small place will have scheduled out-of-hours work. Those can be well planed or not, and people can be well compensated or not, but they'll always exist.
    - hk__2 3y ago
      I never said that. There has been a hardware failure in the datacenter, something we could hardly have prevented.
  - deleted 3y ago
    [deleted]
deleted 3y ago
[deleted]
neilv 3y ago
Expectation: Programming is about finding a way, and I will be able to do that faster. Reality: You will be able to think of multiple ways or approaches easily, and narrow down the space based on various experience, often ending up with something different and better than you would've done as a junior.
wnmurphy 3y ago
When you're junior, it's really common to feel like everyone else but you knows everything already. The single biggest revelation of my career as a junior was when I realized that the core trait of more senior devs was not that they already know everything, but that they openly admitted they had no idea and plowed ahead to figure it out anyway. The key moment was when I had an ex-Google dev asked me how to use a basic git command, and then later in the day another one said something like "I have no effing clue. Let's figure it out."
- kubanczyk 3y ago
  Most google teams don't use git.
deleted 3y ago
[deleted]
nitwit005 3y ago
As someone who was promoted to senior developer three times (title dropped back down when changing firms), I can firmly state there is no actual standard for the title.
- suzzer99 3y ago
  It's like how architect could mean anything from Powerpoint showman to principal developer.
twodave 3y ago
One truth that I think bleeds through well in the opening part of this article is that the difference between junior/senior is a very local concept. And it can shift over time within the same organization.
ivanjermakov 3y ago
> Expectation: Once I become a senior, I will have more time to relax. This is not necessarily false if the metric is the amount of work done. Being able to complete a task in 1hr instead of expected 10hrs means that one can* have 9hrs to relax. * considering one care about free time more than doing more tasks
thr0waway001 3y ago
I've always found the programming world to lack the standards and rigor of other professions like being a medical doctor or an engineer where you need to join organizations and work under a pro for a few number of years before you can rightfully call yourself an engineer. This means that I've noticed, for example, that seniors in one company with lax standards, would be at best a junior in another company with higher standards. Heck I've even worked under these "seniors" and thought to myself: "in what world are you senior if I'm better at everything that you do? I can learn nothing from you." But all that to say, is that I don't blame seniors for not having sure footing. It's hard if you can't can compare yourself to a well defined standard or paragon of excellence.
- vladms 3y ago
  I doubt any profession for which the tools evolve as fast as programming can have "standards and rigor". Another root cause is that abilities of people (in any field) are hard to compare. Programming (and other) professions are in fact team efforts, and while we there are some assessments for individual abilities, good luck assessing abilities of teams before forming. Not sure it is a problem to solve at this point: we care about the results and we have a lot more working software than 20 years ago, so something goes well.
- senthil_rajasek 3y ago
  Comparing programming to Medicine is not a apples to apples comparison. Atleast, in the U.S there is huge shortage of medical doctors. Besides programming is ideal for a try/fail/learn approach on your own. A well known perl wisdom is "what you don't know won't hurt you" I am happy programming is an "open" profession.
- SilasX 3y ago
  >"in what world are you senior if I'm better at everything that you do? I can learn nothing from you." Whoa, sounds like they are better than you at some things! Marketing themselves, excuse-making, getting others to do the hard parts of their job.
  - 3y ago
deleted 3y ago
[deleted]
deleted 3y ago
[deleted]
MauranKilom 3y ago
I find this post very highly accurate in my personal experience (minus the "do it on a Saturday" part). And this is in a company whose departees often tend to eventually return precisely because it's actually not among the "horrible companies". Neither would I consider it "bleak and depressing", unless you actually believed those falsehoods. I would like to also highlight this article by Joel Spolsky: https://www.joelonsoftware.com/2006/04/11/the-development-abstraction-layer-2/ https://www.joelonsoftware.com/2006/04/11/the-development-ab... (It's concerned with the everything else in a company, but it applies equally to the senior vs junior responsibilities imo). If you are under the impression that "writing good code" is the be-all-end-all of being a software engineer, and that being a senior means you get to enjoy it more, then you're probably working in a company that is really good at maintaining this part of the abstraction layer. That's because the more senior you get, the more you inevitably get to be part of the system that allows more junior devs to keep their mind on writing good code. That means dealing with the meetings, timelines, uncertainties, bug triage, maintenance, documentation, compliance and customer/expectation management. So they don't have to.
sershe 3y ago
I think these are weird things listed, does anyone actually believe that? "As a senior, I'll get to play with the latest tech and build amazing projects", "Once I become a senior, I will have more time to relax", etc, I'm pretty sure I've never met anyone who believed that. I usually go by a very simple definition of seniority that applies broadly. What is the size of a piece that you can give to a person, and be sure it's taken care of? With appropriate support/resources, including more junior teammates on higher levels. As in, they own it, drive it, make sure it's aligned with the next higher level, deal with whatever integration is necessary with other pieces of the same size (i.e. how does this feature/service/platform/org work with other features/services/platforms/orgs). And you don't have to micromanage them. Specific level names depend on a company, but if someone can deliver a small feature, they are SDE I, or junior or whatever. If someone can deliver/own a reasonable-sized service or a large E2E customer-facing feature, they are a senior. If someone can deliver/own key customer-facing/financial metrics, a large cross-team initiative or basically a set of services / stack, they are staff or principal or whatever. If someone can own an entire org or a company maybe they are a TD/CIO :)

98 points by kiyanwang 3y ago

Junior Developer: Let’s get everything done! Senior Developer: nah nah projects don’t matter as much as using whatever tech stack I’m used to.

hk__2 3y ago
I have the opposite experience: junior developers tend not to do research on the tech stack and just use whatever framework they know with some shiny libraries on top of it.
pavel_lishin 3y ago
In my experience, this is backwards, though not always.
- dexterdog 3y ago
  I've had a mix of it, but I am also often the guy trying to push a reason to use the new tech. Not necessarily a stack but usually a new database or service that fits the problem space well.
dagss 3y ago
Exactly opposite in my experience. Seniors (10+ years experience) knows what programming language or library or paradigm or monolith or microservice you use isn't THAT important they all have their problems and everything is a tradeoff. Juniors rewrite code to use their favorite language, rewrite to microservices, etc. But it could be we just have different definitons of "senior". The ones with a couple years experience, enough knowledge to be dangerous but not yet lots of experience and not seen enough bad stuff yet are the worst...
- screenoridesagb 3y ago
  Senior developer wants job security having an unsupportable project or two doesn’t matter because 99% of the job is stretching deadline to line up with vacations.
  - dagss 3y ago
    Making projects supportable is good. Not distinguishing between objectively bad code, and code that you just don't understand right away because you didn't write it yourself and you do not yet have enough training to skim and understand other's codebases yet is not.
  - jnovek 3y ago
    Not sure where you’re working, but your senior devs are quite misinformed. Every layoff I’ve witnessed sliced quite a bit off the top because they’re the most expensive. Absolutely no regard for who was maintaining what legacy projects, often leading to months of setbacks while the remaining engineering staff tries to understand a critical yet unsexy tool or service that no one else was willing to touch. Having “special” projects is in no way a form of job security.
    - screenoridesagb 3y ago
      If your business is operating like this it’s not sustainable. You need 10 developers for every project so the senior developers can complain about meetings instead of exposing themselves to code review. That helps there supposed knowledge.

Warwolt 3y ago

What a bleak and depressing post

jitl 3y ago

This one is real: > Expectation: Once I become a senior, I will lead big projects, have a big impact, and tell others what to do! > Reality: I miss the times when people told me what to do. I’m very happy that I can just write code and do what I’m told on my current project — blessed with very strong collaborators. Being tech lead shaped person on a team and training/onboarding everyone is rewarding but draining, and it’s good to find ways to change it up.

pavel_lishin 3y ago
Yep. Whenever I'm leading a project, I try to leave myself something to actually do, so I can spend time doing the thing I actually enjoy doing.
- Longhanks 3y ago
  Why do you lead projects if you don't enjoy doing it?
  - cebert 3y ago
    I’d imagine compensation comes into play. Why do so many software engineers go into management?
    - usrusr 3y ago
      Compensation not only in terms of getting more, but also in terms of keeping it from dropping off. Good luck fending off ageism if you don't shift into more managerial roles.
  - deleted 3y ago
    [deleted]
  - jitl 3y ago
    I do a bunch of stuff I don’t enjoy because it makes my life better in the long run. For example: laundry, if I don’t do it, then I have to wear dirty clothes and I am sad (and smelly). So it goes with engineering too. Sometimes (often?) I need to do something that’s not enjoyable in the short term to realize the best long path.

kqr 3y ago

I suspect a lot of this is a product of environment. When I had less experience, I saw all these flaws but could not affect them. Now I'm constantly worried what I'm looking at is not an actual flaw even if I think it is, but when I can convince myself, I can usually also recruit help from upper management to fix it. That is very relieving and much less frustrating. (This was not the case at my previous employer. They didn't listen to anyone internal regardless of experience.)

sam0x17 3y ago

#1 item that should be there and is missing is: "My first job will promote me and raise my salary when I "become" a senior dev"

StableAlkyne 3y ago
Yup! Easiest way to get a raise is to self-promote into a different company
- syndicatedjelly 3y ago
  It’s also a great way to receive an undeserved “senior” title
- 13of40 3y ago
  I've heard this a lot over the years, but honestly, as a hiring manager, I'm not going to waste my time with a candidate whose resume shows them hopping companies every year or two.
  - sam0x17 3y ago
    The average in this industry (startups) is ~2 years at best so that's a bit close-minded. A lot of startups don't even make it to the two year mark. 5 years is like a century. At Google average tenure is 1.1 years, so looks like FANG is following the trend as well. You're definitely missing out on the top 25% of the market if you only stick to people who (stupidly) stay in the same place with no diagonal upgrades for 3+ years.
    - syndicatedjelly 3y ago
      Most people don’t work at startups.
      - sam0x17 3y ago
        We're on HN, friend ;)

1letterunixname 3y ago

Seniority means thinking about the bigger picture and influence. And at some MAAMG shops, it also includes steamrolling over and tearing apart others' ideas to get credit for your own ideas, initiatives, and impact.

ldjkfkdsjnv 3y ago
Steamrolling is arguably all that matters
hiddencost 3y ago
GAMMA or MAGMA?

xandrius 3y ago

It's just reads that the author works/worked at horrible companies. Also because someone gives you the title senior, you don't immediately become one: for me being senior is about changing one's mentality (through experience) that a problem can almost always be solved, and bringing that confidence to the team. As a junior one often worries whether they have enough skill, as a senior you know you do and whatever you don't know, you'll learn it. Boring meetings, working during the weekends, stress and awful legacy tech is not a necessity.

TillE 3y ago
I feel like it's only in the past few years people have been talking about "junior" vs "senior" except as literal job titles. It's a weird binary distinction when of course gaining experience is a gradient.
- dexwiz 3y ago
  Because they are two different jobs usually. Juniors are more focused on code while senior trends towards planning, reviewing, and leading. In my experience a senior is just as likely to spec out some work and pass it on as do it themselves.
- kelseyfrog 3y ago
  It is of course a gradient, however, on that gradient there exists an important threshold: can this person, under their own direction, produce positive net value? Juniors require your active guidance. Seniors require your availability.
  - blowski 3y ago
    I consider the size of relevant “horizons” - time, number of features, number of people. A junior should be able to have a positive impact working independently within very narrow horizons (a single function, 1 other person, 1 hour), and is showing growth as those horizons increase.
  - kqr 3y ago

dakiol 3y ago

Expectation: Once I become a senior, I will have more time to relax. Reality: It’s fine, I’ll finish the work on Saturday. The expectation is actually true in my personal experience. The more I know (and I know I don’t know tons of stuff) the more free time I have during working hours. It’s not that I’m solving NP problems or hard distributed systems problems or migrating TBs of data without downtime; i’m doing more complex stuff than when I was a junior, but all in all, I can control it and hence the relaxing time I have nowadays (compared to the hectic times when I was a junior)

lapcat 3y ago

Falsehood: The distinction between "junior" and "senior" developer makes sense and isn't just the figment of the imagination of some corporate ladder climbers who drank too much of the kool-aid. Let's say I drop out of college, found my own software company, and within a few years my company is valued at 9 figures. Am I a "junior" or "senior" developer? Does anyone give a crap? Keep in mind that in high school and college, one advances from "junior" to "senior" simply by aging one year and not failing.

dexwiz 3y ago
At that point you are an entrepreneur. The division only exists in large companies with highly segmented job roles. The more hats you have to wear, the less that line shows.
- lapcat 3y ago
  > The division only exists in large companies with highly segmented job roles. In some companies, yes, but it's all relative to the company. Each company has its own job titles and levels. It would make sense to write a blog post about "How to get promoted to [title] in [company]". (And the honest answer might be self-promotion or brownnosing, for example.) The problem is that too many developers try to actualize and abstract these arbitrary job titles into some fundamental category of programming reality that exists independently of arbitrary corporate job titles. That's what I mean about drinking the corporate kool-aid. There are continual debates in blog posts and on social media about what "senior developer" means, with no reference to a particular company or job within a company, and I consider the debate to be all nonsense. It's worse than spaces vs. tabs, because at least spaces and tabs are real, well-defined characters.
  - dexwiz 3y ago
    This kind of discussion is in part due to pressures from HR, again something more common in big companies. To standardize hiring practices HR people do something called banding or leveling where they do try to define job levels and responsibilities across the industry. Primarily so they know what to pay people. Also so people can plan career tracks. Yeah it’s all Kool Aid but a lot of people are drinking it. Also there is a demonstrable difference between someone who just codes and someone who leads projects. Generally the senior path can be seen as a technical leader path, and that is transferable between companies. But the word senior itself has lost meaning. Senior at my company is squarely in the middle. Principals are the true seniors.

donatj 3y ago

> Reality: This legacy code isn't going anywhere, and neither am I. Let's fix some bug that happens once every full moon. I've been doing this for 18 years now, maybe I'm just getting old, but I prefer legacy code. It's got a history, it's got known issues. All greenfield is is problems you don't see, yet.

layer8 3y ago
I’m similar. Maintaining code in the long term is where the really interesting challenges lie. Greenfield projects can be refreshing at first, but after a while you realize that all you’re doing is create what will soon become legacy code. The proof is in the pudding, which is the legacy phase.

jollyoldpirate 3y ago

[flagged]

treflop 3y ago

I’ve been doing this for almost 10 years and I disagree with everything but the first and last point. (It’s true — I don’t have all the answers, and yes, I can be laid off, but so can the company disappear tomorrow.)

hk__2 3y ago
Could you expand on why you disagree?
- treflop 3y ago
  > Expectation: As a senior, I'll get to play with the latest tech and build amazing projects! > Reality: This legacy code isn't going anywhere, and neither am I. Let's fix some bug that happens once every full moon. I still get to play with the latest tech to evaluate them — do I adopt them? Usually no, but that’s my choice. Sorry man, I tried building real projects with new tech as a junior and the tech always went to shit then too. Except for the occasional unicorn, new tech has never been fun. Plus I don’t know about anyone else, but I sure worked on legacy code too as a junior… I’m talking fucking ColdFusion at one point. > Expectation: Being senior means I can avoid all the boring tasks. > Reality: Endless meetings, documentation, and code reviews… Oh, and did I mention debugging legacy systems on Friday at 6 PM? I love meetings. That’s where I set everyone straight and tell them that they should consider this second option and it may save them (and me) a ton of money and time. There are the occasional overly-long meetings but I speak up and nip the problem in the bud. There are some boring ass meetings that have to be done like standup but I’m not even lifting a finger. It’s like being paid to do nothing. I also enjoy documentation personally. Code reviews are kinda boring, no cap. But whatever, it’s not that bad. I could be cleaning a kitchen at a restaurant or fixing a stripped screw. I’ve had to debug systems at inopportune times before but it’s happened like 5 times tops in my career. But overall, I get way fewer shitty tasks as senior. > Expectation: Has a million ideas on how to change this company 180 degrees! Let’s improve everything! > Reality: Knows that nothing will change without management approval and the necessary budget. I guess I don’t disagree with this one that much, but I never had much friction as a junior dev either. Honestly, the problem is that most people barely have a handle on what’s going on the company and they might suggest building a bridge when we’ve been breaking ground on a tunnel for four years — no shit your idea is not going to get any traction. Maybe read the room first? > Expectation: Once I become a senior, I will have more time to relax. > Reality: It’s fine, I’ll finish the work on Saturday. Can’t say anything other than I’ve never had to work weekends in my life at a software company. > Expectation: Once I become a senior, I will lead big projects, have a big impact, and tell others what to do! > Reality: I miss the times when people told me what to do. Sorry I just can’t relate to this one at all. I just love engineering, all my past projects have always worked out very well. Right now I’m building a DIY pressure-activated water pump system in my garage and I just bought all the parts while sitting in a Target parking lot, put it together in 15 minutes, and it just worked. I have all this knowledge and experience from doing this for 10 years and I’m still learning new things all the time and challenging myself, and when I put shit together, it works.

standardUser 3y ago

In my experience, the difference between junior and senior is the company wanted to keep the "senior" engineer and titles are free.

hnrodey 3y ago

I read through the article hoping to join the comments with several hot takes, but alas I'm disappointed. Well written and largely accurate. My primary disagreement is working into nights and weekends. If that's your thing then so be it, but I avoid it like the plague and my career has progressed quite well. I've remarkably committed during the work day and I don't fuck off - I just get my stuff done. Amongst the biggest risks that comes along with being a senior developer is that, at some point, your skillset adapts specifically to what THE EMPLOYER needs it to be. The trade-off we make is reduced risk of losing job (as the author called out). Even if you avoid layoff, at some point you will want to change jobs. Entering the job search after having an entrenched position that you grew into is like being married for 5-10 years and then entering the dating scene ... the new suitors (employers) want a mate (employee) with abs and a flashy sports car instead you're showing off a dad bod and well maintained minivan. It's a fine decision to make either way, just know the game you're playing.

hiddencost 3y ago

Do not work over time.

cebert 3y ago
Working extra can be a good way to differentiate yourself from others and more easily earn a promotion or additional compensation.

csmattryder 3y ago

> Reality: It’s fine, I’ll finish the work on Saturday. At no point have I ever worked outside of contracted hours, and at no point will I ever do so. Sorry, no, once I did and it lead to me leaving the job..! And it's harmfully perpetuating the idea that you're expected to do so when you're not paid for the labour.

hk__2 3y ago
> At no point have I ever worked outside of contracted hours, and at no point will I ever do so. Sorry, no, once I did and it lead to me leaving the job..! "At no point have I ever worked outside of contracted hours" but "once I did"? Anyway, you probably worked at large companies only; I work in a startup and if the other ops guy is offline I do work off-hours because, well, the website won’t go back up by itself.
- sojournerc 3y ago
  If your website needs 24hr babysitting, you're doing something wrong.
  - marcosdumay 3y ago
    The GP is saying that his website fails outside of the contracted hours as well as inside of them. And yes, an emergency here or there is normal in smaller companies. If they start happening several times in a single year, it's a sign that something is very wrong, but it's not reasonable to expect them never to happen. Also, a small place will have scheduled out-of-hours work. Those can be well planed or not, and people can be well compensated or not, but they'll always exist.
  - hk__2 3y ago
    I never said that. There has been a hardware failure in the datacenter, something we could hardly have prevented.
- deleted 3y ago
  [deleted]

deleted 3y ago

[deleted]

neilv 3y ago

Expectation: Programming is about finding a way, and I will be able to do that faster. Reality: You will be able to think of multiple ways or approaches easily, and narrow down the space based on various experience, often ending up with something different and better than you would've done as a junior.

wnmurphy 3y ago

When you're junior, it's really common to feel like everyone else but you knows everything already. The single biggest revelation of my career as a junior was when I realized that the core trait of more senior devs was not that they already know everything, but that they openly admitted they had no idea and plowed ahead to figure it out anyway. The key moment was when I had an ex-Google dev asked me how to use a basic git command, and then later in the day another one said something like "I have no effing clue. Let's figure it out."

kubanczyk 3y ago
Most google teams don't use git.

deleted 3y ago

[deleted]

nitwit005 3y ago

As someone who was promoted to senior developer three times (title dropped back down when changing firms), I can firmly state there is no actual standard for the title.

suzzer99 3y ago
It's like how architect could mean anything from Powerpoint showman to principal developer.

twodave 3y ago

One truth that I think bleeds through well in the opening part of this article is that the difference between junior/senior is a very local concept. And it can shift over time within the same organization.

ivanjermakov 3y ago

> Expectation: Once I become a senior, I will have more time to relax. This is not necessarily false if the metric is the amount of work done. Being able to complete a task in 1hr instead of expected 10hrs means that one can* have 9hrs to relax. * considering one care about free time more than doing more tasks

thr0waway001 3y ago

I've always found the programming world to lack the standards and rigor of other professions like being a medical doctor or an engineer where you need to join organizations and work under a pro for a few number of years before you can rightfully call yourself an engineer. This means that I've noticed, for example, that seniors in one company with lax standards, would be at best a junior in another company with higher standards. Heck I've even worked under these "seniors" and thought to myself: "in what world are you senior if I'm better at everything that you do? I can learn nothing from you." But all that to say, is that I don't blame seniors for not having sure footing. It's hard if you can't can compare yourself to a well defined standard or paragon of excellence.

vladms 3y ago
I doubt any profession for which the tools evolve as fast as programming can have "standards and rigor". Another root cause is that abilities of people (in any field) are hard to compare. Programming (and other) professions are in fact team efforts, and while we there are some assessments for individual abilities, good luck assessing abilities of teams before forming. Not sure it is a problem to solve at this point: we care about the results and we have a lot more working software than 20 years ago, so something goes well.
senthil_rajasek 3y ago
Comparing programming to Medicine is not a apples to apples comparison. Atleast, in the U.S there is huge shortage of medical doctors. Besides programming is ideal for a try/fail/learn approach on your own. A well known perl wisdom is "what you don't know won't hurt you" I am happy programming is an "open" profession.
SilasX 3y ago
>"in what world are you senior if I'm better at everything that you do? I can learn nothing from you." Whoa, sounds like they are better than you at some things! Marketing themselves, excuse-making, getting others to do the hard parts of their job.
- 3y ago

deleted 3y ago

[deleted]

deleted 3y ago

[deleted]

MauranKilom 3y ago

I find this post very highly accurate in my personal experience (minus the "do it on a Saturday" part). And this is in a company whose departees often tend to eventually return precisely because it's actually not among the "horrible companies". Neither would I consider it "bleak and depressing", unless you actually believed those falsehoods. I would like to also highlight this article by Joel Spolsky: https://www.joelonsoftware.com/2006/04/11/the-development-abstraction-layer-2/ https://www.joelonsoftware.com/2006/04/11/the-development-ab... (It's concerned with the everything else in a company, but it applies equally to the senior vs junior responsibilities imo). If you are under the impression that "writing good code" is the be-all-end-all of being a software engineer, and that being a senior means you get to enjoy it more, then you're probably working in a company that is really good at maintaining this part of the abstraction layer. That's because the more senior you get, the more you inevitably get to be part of the system that allows more junior devs to keep their mind on writing good code. That means dealing with the meetings, timelines, uncertainties, bug triage, maintenance, documentation, compliance and customer/expectation management. So they don't have to.

sershe 3y ago

I think these are weird things listed, does anyone actually believe that? "As a senior, I'll get to play with the latest tech and build amazing projects", "Once I become a senior, I will have more time to relax", etc, I'm pretty sure I've never met anyone who believed that. I usually go by a very simple definition of seniority that applies broadly. What is the size of a piece that you can give to a person, and be sure it's taken care of? With appropriate support/resources, including more junior teammates on higher levels. As in, they own it, drive it, make sure it's aligned with the next higher level, deal with whatever integration is necessary with other pieces of the same size (i.e. how does this feature/service/platform/org work with other features/services/platforms/orgs). And you don't have to micromanage them. Specific level names depend on a company, but if someone can deliver a small feature, they are SDE I, or junior or whatever. If someone can deliver/own a reasonable-sized service or a large E2E customer-facing feature, they are a senior. If someone can deliver/own key customer-facing/financial metrics, a large cross-team initiative or basically a set of services / stack, they are staff or principal or whatever. If someone can own an entire org or a company maybe they are a TD/CIO :)