Falsehoods junior developers believe about becoming senior
vadimkravcenko.com
vadimkravcenko.com
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.
Juniors require your active guidance. Seniors require your availability.
The one you propose is useful and how the literature on expertise defines a journeyman but the word "senior" is highly ambiguous.
Given context, an otherwise ambiguous word can be useful. "Senior" needs a lot of context, though.
(for thoughts on how to progress beyond "master", see https://news.ycombinator.com/item?id=39494801 )
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.
Heh, basically becoming senior means overcoming impostor syndrome? Aligns pretty well with my experience.
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.
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.
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”.
On call should be a rare event.
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.
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.
A senior engineer who does this is harming their team more than most other technical related things.
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.
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.
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.
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.
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.
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.)
> 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.
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.
And as others pointed out, because if I refuse to, I'd likely eventually be let go.
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.
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
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.
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.
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.
"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.
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.
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.
Becoming senior requires hard work and dedication.
> And it's harmfully perpetuating the idea that you're expected to do so when you're not paid for the labour.
What are you talking about? Seniors earn 2-5x the amount as a junior developer.
Coasting is what shitty PMs and managers do when their plans will only work if their peons are dumb enough to give them free labor.
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.
You can go above and beyond in 40 hours. Quality, intelligent work does not require overtime.
Hustle culture is simply wrong here. Luckily I could not care less about working at faang or whatever the fuck they're called these days.
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.
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.
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.
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.
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.
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.
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.
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)
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.
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.
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.
You’re a rare unicorn then, not the 99.9% case.
That's avoiding the question.
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.
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.
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 would like to also highlight this article by Joel Spolsky: 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.
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 :)
(It’s true — I don’t have all the answers, and yes, I can be laid off, but so can the company disappear tomorrow.)
> 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.
"My first job will promote me and raise my salary when I "become" a senior dev"
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.
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.
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.
If the private sector wants loyalty and commitment, it needs to start by being loyal and committed to its employees.
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."
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.
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.)
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
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.
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...
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.