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.
The bit about working weekends and evenings was especially annoying to me.
What people who do that don't realize is that pulling late nights and weekends for a deadline more often than not just validates badly planned deadlines that were never going to work out. It's a vicious cycle: if you sacrifice your personal life to hit a deadline, then the people in charge of setting deadlines get a false idea of what "normal" is and you'll end up doing the same thing next time.
It's not that there's never a valid case for working after hours (like, say, a dedicated on call rotation), but I'm pretty firmly opposed to doing so to meet a deadline. It's unfair to yourself and your co-workers to teach product/management/whoever that work can be planned out on the assumption that your team will pull late nights to make it happen on an arbitrary schedule.
I don't think it's really about "the people in charge of deadlines". When you, as a senior engineer on the team, work crazy hours, all the junior folks on your team who look up to you (even simply because they also want a fancy job title down the line) copy that behavior. And then it becomes the new normal.
A dedicated on call rotation also isn't a valid case for working after hours.
If companies want their infrastructure worked on 24/7 they need to hire 3 shifts to take care of it. If they don't want to pay for 3 shifts they should shut their business down after hours like a normal business, not exploit people by making them work 24/7.
If you don’t like on call rotations then you shouldn’t be working on services that come with on call responsibilities.
However, suggesting that every Internet business needs to shut down after hours is one of the more out of touch things I’ve read in this comment section.
> not exploit people by making them work 24/7.
That’s not what on call rotation means. You shouldn’t be “working 24/7”.
I’ve spread this message far and wide across dozens (hundreds?) of industries. I’m sure we know but I think it’s helpful to be explicit: the mindset at the heart of this is not specific to software and can be found at pretty much every management level and it’s hurting everything.
At “best” you have an endless stream of overworked employees who burn out and get replaced when they stop being able to “keep up” but even then the business has no idea what things actually cost. They can’t do budgeting, they can’t do calculations, every report based on employee productivity is wrong.
Working beyond your means sets the company up for long-term failure.
Part of being senior is having enough business context to know when to pull late nights and weekends. If you're doing it because the gantt chart some PM created 18 months ago said project X would be done by next month but everything is off the rails, yes, it's foolish and unfair to work nights and weekends to make it happen. If you're doing it because re:Invent is in a month and your team has a new AWS service to announce, that's a much better reason. Or in the startup world, if there's a major client demo next week and you're quickly hacking in a new feature they've been asking for.
I agree that sometimes you need to do it in order to not totally screw up the business, but I think any case where you make that decision should require a postmortem where everyone involved in that deadline gets together and figures out why it couldn't happen during the team's regularly scheduled hours. If you do it quietly without making it very clear to the business that this was abnormal and should not happen again, then you're still feeding the false idea that it's okay to plan around late nights and long hours.
An early stage startup is a possible exception as long as your entire team is on board with it and getting a satisfactory amount of equity compensation. But the entire team has to be on board with working extra hours, it can't just be you deciding that for the team.
Maybe but then you are reinforcing bad planning and behaviour from management. Far better to reduce the scope or content so you don’t hit that deadline totally spent.
The good news for everyone is, you can't just make up a good reason out of thin air! (unless you're lying). There's either a critical business need, or there isn't.
This of course requires this senior engineer to be business-savvy enough to discern when there's a legitimate business reason given, and at big companies that may require knowledge of politics among the higher ups which may be opaque to most folks.
Easy. This dude is probably a business owner trying to neg their programmers into thinking that they're easily replaced cogs in a machine that should give their job priority over their life.
> Boring meetings, working during the weekends, stress and awful legacy tech is not a necessity
I did some mentoring in a program for juniors for a while.
The most common problem we saw was unrealistic expectations. Kids had grown up reading comment sections like HN and Reddit where people complained about every little thing and painted unrealistic pictures of what a job should be like.
Then these people grew up, graduated, and thought they were going to walk into jobs where they would work exclusively on passion work in greenfield projects with the hottest tech stacks, never have to sit in a meeting, and that they could work at whatever comfortable pace they wanted and nobody should be able to complain about how long it was taking.
There were frequent crises when people took their first jobs and got assigned to work on legacy codebases, for example. I lost track of how many times I had to explain to someone that a big company isn’t going to entrust the fresh-out-of-college (in this case, mid-tier college) junior to own a greenfield project in React, or how often I had to explain that deadlines are a fact of life in some businesses (e.g. those with contracted deliverables to customers depending on the product going live at predictable times).
Of course, there were other times we had to explain to people that their jobs were bad: People who had 25 hours of recurring meetings every week or companies that expected people to work 9AM to 9PM every day. This was very rare, though.
I don’t know the solution, but I can say that the way the internet talks about tech jobs as if they should never be the slightest bit uncomfortable is causing a lot of whiplash for juniors when they encounter reality. Sometimes you’re going to have to sit in some boring meetings or work on a legacy project. You shouldn’t be grinding away every weekend, but a job is sometimes going to be a little uncomfortable relative to some of the hyper-idealistic things we talk about online.
Agreed, it's absolutely true (in this and other things) that some people need to be advised "more than your current is better", while others need to be advised "less than your current is better".
I think you can teach that (at least at this org) the job is about professionalism, in a team, and what the actual nature of the goals is.
You really teach it by example. Articulating it can help, as a suggested interpretation of what you're demonstrating, but people will notice if you say one thing and do another.
Also, if they're still confused, tell them that much of what they've read on the Internet is for different kinds of organizations or individuals. (I'm recalling, for example, one of those influencer videos about day in the life at a FAANG, where almost the entire day is spent getting free food, walking around campus and bumping into other barely-20 friends and chatting and laughing like you're still carefree in school and don't know anything yet, plus a coding/debugging session and a product meeting, both of which seemed like fashion poses. Hahaha. Learn the professionalism, and have a life, but think more about conscientiousness than fabulousness.)
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.
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.
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.
I'd assume at least a three-layer distinction for this - juniors require guidance, seniors can provide it, but there's a lot of middle grounds and many years of work where you're not junior (at least according to this criterua) anymore but not yet senior.
There's no universally accepted definition of any term so I'm not sure how that's relevant. That's how I describe my own perspective, others are free to differ. Language can be vague and useful.
When it comes to being ambiguously defined, "senior" is not just any old term. A senior can be someone who's two years out of school, or it can someone of retirement age (senior citizen), or anything in-between.
Given context, an otherwise ambiguous word can be useful. "Senior" needs a lot of context, though.
By that guy's "executing a day’s work" definition. Usually it's used in the same sense as medieval - early modern guild terminology: After having apprenticed with your first master you set out on a journey to learn further from other masters of the craft in other towns. (Hopefully to graduate to master yourself after a while. No intermediary "expert" step in those days.)
But maybe that's what you meant. Sarcasm is sometimes hard to detect online.
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.
> It's just reads that the author works/worked at horrible companies.
Hard disagree.
> Boring meetings, working during the weekends, stress and awful legacy tech is not a necessity.
Boring meetings are not a necessity, but meetings are. (Article mentions no "boring" meetings.) If you don't think so, you're not senior enough.
Working on weekends is not a necessity, but when unexpected crap happens the senior engineers will be called upon whether it's a weekend or not.
Stress is not a necessity, but most people feel it out of increased responsibility. This is a personal/subjective thing, but it doesn't reflect that the company is horrible. Quite the opposite -- if you believe your work is meaningless, and feel OK with doing meaningless work, there's actually not much you can stress yourself about. It's only when you believe there's high stakes that stress becomes high.
As for legacy codebases, it doesn't have to be awful (also note "awful" is not mentioned in the article). A senior engineer who has worked on the project/team for a couple years probably had a role in creating it, or at least has the most experience with it, which is why it tends to be the senior engineer who has to debug it. And if you think overhauling systems just because they're almost 10 years old is always a great idea... well you're not senior enough.
To be fair, I suspect in the contemporary scale of "senior" titles, the stuff in the article is more akin to "staff" level roles than "senior" roles (the latter AFAICT basically means you're technically capable of doing things independently, which is what you're alluding to).
The realization that you need to hold meetings to align and share information with the team (and management), that if you don't fix the outage at 2am nobody else could, that you rather fix the issue in the legacy codebase yourself than assign it to junior team members and subject them to endless frustration... is probably beyond the experience of the typical "senior" level dev.
> Working on weekends is not a necessity, but when unexpected crap happens the senior engineers will be called upon whether it's a weekend or not.
But the headline for that section wasn't "senior engineers spend more time on a formal on call rotation", it was "it’s fine, I’ll finish the work on Saturday."
Unexpected issues should be expected and planned for with a dedicated on call rotation that is almost never used because you're setting time aside during the work week to fix common issues. Unexpected issues shouldn't lead to random senior engineers getting called when they're not expecting it.
And as for "I'll finish the work on Saturday", it's a hard red flag of a bad work environment if that's happening with any kind of regularity. Normal work bleeding onto weekends and evenings should be a five alarm fire that gets addressed immediately in any company that values their employees. It should not be in a list of things to expect as a senior engineer.
I generally agree with what you say. Except that I think it's more likely a red flag for the author of the article, not necessarily the company (but of course could be), depending on whether which side had the greater authority to set or influence the deadlines.
Sometimes it's easier said than done though. At some point of seniority you basically have to make the engineering estimates whether features/tasks could be done within a deadline. If you made a mistake, you might end up having to own it.
A problem can almost always be solved, the question is usually whether it's economical and/or timely to do so. If I have to learn a new skill to do something I have to factor that learning time into my estimates, so that management can plan enough time in the schedule.
> 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.
I probably never had the expectation expressed here, but the reality as a senior (as I see it) is “everyone has opinions on what to do, now it’s my job to corral them into something productive like so many cats”. If anything, I think the biggest difference between my prior expectation and my reality is how much more social than technical the responsibility can be.
its socio-technical. you have to balance the legitimate desire to leave people agency, but get them all on the same page. people don't like it these days, but consensus does wonders.
what _is_ purely social and hasn't been discussed here is the role a senior developer takes in shielding the team from organizational corruption. that's a much harder and painful task, and while the former gets easier as the team develops trust, the latter never seems to
I believe the sweet spot is a balance between coordination and autonomy. When I'm all alone with my decisions I trust them much less than after having gone through advertising them to peers, perhaps even refining them in the process.
The rubber duck may be wise, for a duck at least, but there are limits to how much you can trust its opinion. In fact even the rubber duck appears more confident when it might at any time ally with co-workers.
Ideally juniors will eventually grow to a point where you don't have to constantly tell them what to do.
Early career people just don't know how to make the right decisions yet. They need mentorship and help, that's expected and I'm happy to help as long as they're learning.
I hate it when I have to hold the hands of "seniors" though - often asking "what do you think?" or "what have you tried so far?" is enough to get them to do their jobs.
> I’m very happy that I can just write code and do what I’m told on my current project
In recent times I had two encounters with colleagues, one a being bit less and the other than quite a bit more senior than me, where they both expressed such a sentiment.
One phrasing used was "I follow the ticket like a slave" and the other phrasing was "I do whatever $BOSS tells me to do". Not once in my career would I have uttered something like that.
But I realize that I was lucky that in my early career I got a lot of rather ambiguous (and also ambitious) tasks paired with more autonomy than my actual experience justified. Don't know how I would have turned out as an engineer if I had started in a company where I would have been expected to simply do what I've been told.
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.
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.
It's wild how different experiences can be. Even as an intern I appreciated not being told what to do far more often than the opposite (and other managers definitely appreciated that within the organization; they tried to poach me a few times).
> 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.
To each their own, but this is in fundamental disagreement with how career ladders work.
If you do the bare minimum to get by, you meet expectations. If you want to grow your career, by necessity and definition, you need to go above and beyond in order to exceed expectations, and this requires hard work.
Companies like Google, Facebook, et al. have defined dexpectations in place that juniors must grow into a senior role in N years. If you don't, you'll be fired for underperformance.
So yes, if you're a junior, "just doing the job" is coasting.
> 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.
There are 2 cases you should be working on weekends:
1) First 2-3 years of career - In these times you learn by simply doing, so if you work on weekends you speed up your learning curve. Past 2-3 years you don't learn anything by doing normal work, so you need your weekends to do actual "levelling up".
2) You have equity in the business or you have a bonus structure that compensates weekend work.
If you are outside those 2 cases, and you are working more than 5 weekends a year (say 2-3 weekends per 6 months for true random business emergencies that almost everyone in the org has to do), you need to leave.
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.
> 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.
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.
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.
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.
Honestly, I din't resent these people, but at the same time it was a situation where I was hoping that the "senior" guy could help us out with the work we had and move our team forward.
Needless to say, they didn't last long on our team and we let him go cause he just couldn't keep up. It did, additionally, point out how shitty our process for hiring was as well.
haha I was in a similar situation myself. A manager asked me for an estimate to do a certain project involving software system S, and I replied back that I wasn't familiar with the deep inner workings I'd need to know, but if he gave me a day to poke around I could see what's possible with it and give a good estimate. He replied, "nah, don't bother, I'll just hire someone who's already an expert at it."
Fast forward three weeks, we had the new hire intended for this role. I went over to introduce myself to him. At this point, I wasn't upset, I figured that was a reasonable judgment call that could have gone either way, and was actually looking forward to learning from someone who was familiar with it. So after introductions, I said, "I'm glad we'll have you around, I hope I can learn from you about S," and he was like, "Oh, S? Man, I haven't used that in ages, I'd need at least a few days to get familiar with it."
Facepalm. I guess I should have just lied. Even with my help, I don't think he ever got to where I was on S.
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)
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.
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.
> 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.
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.
> 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?
But it was just one hypothetical example. The point was that the whole false dichotomy of senior/junior depends on a very specific context of given corporate structures and doesn't make much sense outside that context.
Of course nobody gives a crap about college degrees.
But if you actually led a team of software developers for a few years, created a product and the whole thing didn't fall apart, well, you're way more than a senior developer.
> Of course nobody gives a crap about college degrees.
That's missing the point of the example.
1) I was trying to allude to people like Bill Gates and Mark Zuckerberg.
2) I was trying to choose an example that would indisputably be considered a "junior" developer if that person were hired into a low-level role within an existing corporate hierarchy but also an example where the person indisputably took the responsibilities of a "senior" developer from the very beginning, led a team of engineers, and created great value for the company. Somehow these people are considered as "way more than a senior developer" despite having the exact same (negligible) experience level as a newly hired corporate junior developer.
It feels like the only difference is whether the person is high or low in the company org chart.
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.
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.
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 :)
> 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.
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.
There's an odd phenomenon where people become hiring managers and begin to think they're the sole authority on what other hiring managers care about, despite all evidence showing that it's an inconsistent, inexact science. Hard truth: if you're not a job-hopper, you have less varied experience of what it takes to get hired than those who are.
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.
Well you’re assuming that people who know how to game the system and earn money/collect titles are automatically in the top quarter of knowledge workers. I’d argue that knowing how to be a good software engineer has nothing to do with being good at interviewing, negotiating, and hopping jobs frequently.
The average FAANG tenure says nothing about the quality of those engineers. They might be good coders, but they have no experience with deploying, maintaining, and subsetting code. In other words, the vast majority of the field of engineering.
When you start on a team, you produce negative value. On day one, you've already cost the company a significant amount just in recruiting, signing bonuses, and randomizing the other engineers who had to interview people for your position. Where I work, I would guess the break-even point is about six months to a year, so there's a good chance someone who leaves after like 1.5 years is still a net loss.
Maybe it's a good way to game the system, but don't expect the system to cheer for it. Also, if you run across someone who worked at a place for a year and they claim they completely rewrote and revolutionized a legacy system, blah, blah, etc. you should take that with a grain of salt, because of course that's what they would say. They're not going to tell you how they hustled out the door a month before the performance discussions because they knew the hammer was coming down.
Empirically, companies are very bad at evaluating this cost. If they weren't, upwardly-mobile job hoppers wouldn't exist because the previous company where they generate positive value would have increased their salary over the salary they could get elsewhere. In practice we see that the companies are reluctant to give raises, hiring costs are considered capex, and there are inefficiencies in salaries because frictions cause employees to stay in roles that are not financially optimal, meaning there's a premium to accepting the risk of moving jobs.
Yeah, if companies recognized this properly, they would incentivize employees to stay, and would avoid things like layoffs at all costs. Google used to do this in the early days when they believed their #1 resource was human capital. Then the suits came in...
Your average company will dump you at the drop of a hat if it means their "shareholder value" is improved. If you're lucky, you get a couple months of severance.
If the private sector wants loyalty and commitment, it needs to start by being loyal and committed to its employees.
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."
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.
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.)
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.
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.
> 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
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.
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.
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...
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.
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.
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.
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.
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.
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.
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.