In my experience, people who lean into doing dirty work just end up doing more dirty work. It's a recipe for being invaluable to the team, but not a recipe for career growth: they want to keep you around, but they want you to continue doing the dirty work.
The best of career growth advice I've seen work consistently is: be working on a profit center rather than a cost center.
You can be the best employee in the world, but if you're on an unsexy, money-losing area of business, you will likely watch people get promoted around you, because they worked on the thing that gets all the attention. Doesn't matter if their contribution to the success was insignificant, or that the one project was necessary for the other to succeed. It's just the halo effect of being on a winning team that does it. Yes, it makes no sense, and it's not rational nor fair, but that's how business often works.
Being invaluable to the team gives you negotiating leverage.
The other half of this strategy that the blog post left unwritten is: 1.) learn how to sell that dirty work and connect it back to the successes your high-growth company enjoyed in the marketplace 2.) apply to other high-growth companies who want someone willing to do their dirty work 3.) get a competing offer and 4.) negotiate that into a higher salary or stock package.
You can't clear a market without competition. All of the other career advice, whether it be "work for a profit center rather than a cost center" or "impress your boss" or "do the dirty work" or "take credit for other's success" or "don't take credit for other's success" means nothing if there's never a reason to give you a raise because you're going to keep working for your employer regardless of the terms.
>Being invaluable to the team gives you negotiating leverage.
In my experience that hasn't worked out. Being invaluable just means more pressure gets piled on you, and any reward or leverage you think you might be getting in return doesn't materialise. The credit you earn doesn't translate into anything tangible.
Managers just don't take into account the fact that you can and most likely will leave. The project ends up screwed but that's no longer your problem. I've seen it happen multiple times at multiple companies.
I’m in this spot now. Being invaluable to a project just means more work gets piled on me because it’s valuable work that needs to get done. I think I have something like 20 jira tickets in my board at the moment. Maybe half of them are complete with a deadline on Friday.
But it also puts me in a spot where my manager feels he has to micromanage me. If I up and quit, it’ll pretty much derail the project many months. And I do feel like quitting. Not because of the amount of work but because I have this micromanager breathing down my neck every day.
I was in this position recently. It's pure hell. I moved teams internally. Now I'm happy. It feels like an abusive relationship, you don't realise how bad it was until you leave.
You should really draw a line and tell the manager that if this continues that you will quit. Then it's up to them to either not micromanage you, split tasks to more people or make the deadlines more relaxed. If none of that can be done, you should 100% demand a salary increase. There's no reason not to, if they don't give it to you, you quit.
You have no obligations even if it feels like that. I've had the same exact situation so often and it always felt bad until I started drawing the line
> Being invaluable to the team gives you negotiating leverage.
A firm I know fired their lasts Perl developer, purely to cut costs. Their payments system was written in Perl. When it stopped working, they
asked my friend to step in.
He refused, said management should take responsebility for their decisions, and his manager got all pissy. Soon my friend left the firm too. The management is still earning bonuses and promotions. Nobody cares.
Nobody is invaluable. Every person and every product can be replaced, at a cost.
What "invaluable" really means is "a cost the company doesn't currently want to incur". That only works as leverage for as long as the company would rather acquiesce to the employee than incur the cost, and the employee doesn't generally know where the line in the sand is.
I think people tend to see themselves as invaluable when they really aren't. I've seen "invaluable" people quit or get fired, and it causes a rough patch, but the business recovers. Someone else learns, or the business decides they can do the same thing another way or decides that that system isn't actually as important as they thought.
> 1.) learn how to sell that dirty work and connect it back to the successes your high-growth company enjoyed in the marketplace
This is an incredible amount easier to do with flashy work. If someone leads a revenue-generating product, they can say "I lead this project that created $XM in new revenue". If someone made on-call less crappy, it's hard to quantify that. "We got 70% less on-call pages" is neat, but not really something the business cares about in isolation. You'd have to quantify higher stability on the product leading to not losing revenue, or reducing turnover to have a comparable metric.
Doing dirty work is appealing to other engineers, but it's a cost center for the business. They'd happily have a crappy on-call rotation unless you can demonstrate some kind of financial downside to it.
Everything you wrote sounds good in theory but it's not what actually happened to me. My employers actions indicate that they'd rather me leave and have to hire a replacement, even though this will cause them months of trouble, than give me a chance at doing high value work.
> Being invaluable to the team gives you negotiating leverage.
In my experience it hasn't panned out like that.
We desperately want to believe it, because we see how valuable we are to the business. But the reality is that the people making decisions rarely understand the value of the dirty work because they, themselves, have no interest in it. It could be absolutely critical to the business but they will happily walk away because they have no interest in understanding the work you do or its ultimate importance to their own goals.
Still gives you negotiating leverage, but just in a different way.
Doing all the grungy work means that a.) you can describe what grungy work needs to be done that a potential new employer and b.) you can describe the solutions you took to these problems. Basically, you can pass all the bullshit filters that savvy employers put in place, because you are not actually bullshitting.
You still make your money in the transaction, that point where you actually get an offer letter from an employer and negotiate a compensation package. But the input to that compensation package is based on how much value your new employer expects you to add to them, and a primary input to that is how much value you added for your past employer, and how much your new employer believes your claims of that.
To me, caring about life means I must care about fairness. It's not even social or political either - there is something metaphysical or strictly logical about it.
Suppose you lived in a universe where there was no fairness, ever. It was maximally unfair at all points and times. You would drink water and it would turn to sand in your mouth. You would wake up and spears would pierce your eyes. Every action you took to help ease your suffering would instead maximize it, in the most unfair way possible. That sounds like a description of hell to me. I would beg for death in such a universe.
Of course, what you actually mean is that you shouldn't care about fairness so much, you shouldn't "bend yourself out of shape" over it. Getting skipped over for a promotion isn't nearly as bad as burning in hell, obviously. If you don't whine about unfairness and instead just focus on your work, you might end up getting that promotion soon after anyways. In other words, it can be valuable to trade a little unfairness for a lot of "good stuff" (whatever exactly that means in the situation).
I think this might be true, but it sets a really bad precedent. The issue is not accepting unfairness when it is happening to you, but when it is happening to someone else. Imagine telling a coworker who thinks that they're being discriminated against due to their race that they should "accept the unfairness and just deal with reality". IMO they should NOT just learn to accept that. It is deeply unfair and unjust and cannot be worth whatever you get by being quiet.
Finally, it's definitely not how "everything" or even only all businesses work. There are plenty of businesses that are doing their best to promote fairly and honestly, it's just a really hard problem to solve. Maybe unfairness will always find a way to creep back in, that doesn't mean that you should just blindly accept it.
But not always… when you’re the shepherd you should spend emotional energy on fairness. But when you’re the sheep you should not. When you’re the sheep you give a little BAaaa and then move on.
The key is knowing which moments in life you’re the shepherd and which ones you’re the sheep.
I don’t like how your comment advocates for conformity to “reality”. Sometimes going against the grain is absolutely the right thing, especially when dealing with individual situations versus generic advice.
Wigs are an option, although I'd be more inclined to own it and lean into it, shaving it outright. I'm not bald yet, but hair loss runs in the family, so I'll likely be dealing with this at some point. Skin care becomes important - sunscreen will help keep skin smooth and ward off UV damage over the long term. I worry somewhat about self inflicted scar tissue from the exuberance of my youth, but I'll dynamte that bridge when I get to it.
> glasses
Contacts or lasik may be an option. While my vision is good, I get nasty migranes from squinting too hard in the sunlight, so I keep a pair of sunglasses glued to my face most of the time.
> Life gets a lot better once one accepts and deals with reality and stops getting wrapped around the axle about fairness.
Life gets a lot better if one is forewarned, and knows what they're getting into - when one has agency and choice about the tradeoffs they make, and can embrace their choices, fair or not, with both eyes open. While you're right to warn against obsessing over fairness, karaterobot certainly didn't appear to be obsessing so. In that context of replying, intended or not, your words can come across as a suggestion to discourage - if not outright ignore - the topic of fairness and it's consideration. This is a great recipe for getting taken advantage of - fucked over through apathy or ignorance when you didn't need to be, through failure to advocate for oneself or for those whom one cares about - and this is unlikely to make life better at all, and which is what I suspect what some people are reacting to.
Neither extreme - obsession with fairness, nor utter apathy towards it - are particularly great. It's fine to embrace and accept what can't be helped - but it's also fine to acknowledge, be aware, and perhaps even fight to fix what can be helped.
Strategically placed folding ladders or footstools are convenient for even tall people to change lightbulbs, and appropriately sized furniture will be more convenient for all sizes. Finding more considerate roommates that don't leave all the good stuff on the top shelves can also help. But I suspect you're talking more on the social or romantic front?
Proper diet, sleep, stretching, and exercise can apparently still add an inch or two for an adult. While it's perhaps not much, it's not nothing either, and perhaps worthwhile for the other health, mood, and quality of life benefits anyways. Before 25, it's even more critical - malnutrition can make those with even the tallest-trending genetics short, lack of physical exercise can reduce the amount of growth hormones your body generates, and even generally "good" diets can be missing some nutrients. Platform shoes are also a thing, although quite possibly counter-productive if seen as "overcompensating," as fucked up as that might be. Perhaps worth experimenting with to see how much the extra height helps - or doesn't help. Perhaps on your next vacation, if you're worried about how it'd come across to your social circle. People aren't the same height everywhere across the globe, either, if you want to see what being relatively taller might mean.
Because this is all predicated on height being both the problem and the solution - and that's almost certainly too simple. Money, fame, intelligence, kindness, confidence, wit, good humor, bad humor - there are many ways to win hearts and minds, and different things will work on different people. Some of those are easier to improve upon than others, and what's easy for who varies. Nobody has every advantage, and everyone has their weaknesses.
And while I'm incredibly hesitant to recommend any kind of serious surgical procedure for "cosmetic" purpouses - with all the potential risks and costs - limb lengthening surgery is a thing. At the very least, I'd experiment with some of the options involving fewer knives before considering surgery, to see just how much the extra height would help, and verify - or refute - if the "benefit" would be worth doing all of that.
Sarcasm should beget sarcasm, yet grief should beget earnest sympathy, and there's maybe some 1% chance I'm being entirely too uncharitable and you're being earnest all the way through, not taking the piss out of me at all, which would imply your dad is dying, not dead, yet without any mention of under what circumstances. Yet something so nausiatingly generic as to cover all that - perhaps "I'm sorry for your struggles" - feels like it would come off as insincere.
> who do you suggest I take the issue up with to get the unfairness resolved?
There are plenty of people one can try to blame for those whom have died. God, the medical system, the political system that created the medical system, the society that created that political system, the insurance companies that failed to step up and meet their contractual obligations, the people whose negligence or malice lead towards death... and while trials, wrongful death lawsuits, insurance payouts, holding people accountable, and social safety nets - won't make one whole - and won't make things fair - they can at least make things a little less horrifically unfair. Or, if improvements are made, can make things a little fairer for the next victim of life. But I doubt you would be asking your question, sarcastically or not, if there was someone so easy and convenient to blame - or even scapegoat. It would lose it's biting edge.
What’s wrong with being bald? I saw the writing on the wall in my mid 20s that my hairline was soon going to look like Lebrun James or George Jefferson (https://images.app.goo.gl/oJmeW1o7VFYgzUqX7). I cut all of my hair off. I’ve been wearing a bald head and most of the time a clean shaven face for the past 20 years.
Another benefit is that no one has a clue how old I am. No gray hair or receding hairline if you cut it off.
With strong enough motivation, one could dedicate their life to research in these areas. Much of mankind’s thrust forward can be attributed to such individuals. But this is easier said than done.
To date, no double blind study has either proven or disproven the efficacy of human sacrifice. So, we really can’t say if it would be a good idea to dismantle Chesterton’s Volcano. /s
Since we’re already splitting hairs here and there, I can’t help but point out that a double-blind study would likely be a wrong kind of study for this purpose (gods could use it to find out if virgin sacrifices are a must, or non-virgins could be just as good), and you probably meant to say, “randomized controlled trial”.
Speaking from 25 years of experience with dirty work, I completely agree that it’s not a great career path if you’re looking for anything other than more dirty work. Even your own team often doesn’t appreciate how much you make them look better. It’s too easy to be overlooked if you’re the one behind the scenes going above and beyond to ensure things are running well.
The best advice I can give is to be invaluable to your management and your company. Seek out and take advantage of the higher profile opportunities so you can gain the exposure you need for your career.
It's a tradeoff. I've been working on the front lines most of my career and it has lead to some amazing growth and achievements, but now that I've got children and want to spend more time with them I'm perfectly fine being in a cost center and staying out of the critical path. It does take some savvy to get visibility for your work but nothing a seasoned engineer couldn't handle.
What I mean by critical path is that the business or product will fail immediately if you don't do your job. That's certainly not the case with the "back office" sort of work that I currently do.
> It's similar to data engineers thinking they will do real ML some day and their data job is just temporary...
Hah yeah but this is just the reality of ML. "Engineer who only codes up awesome new ML algorithms" isn't a real job. For every 1 person coming up with exciting new algorithms, there's 500 people dealing with data pipelines, cleaning, maintenance, and operations. A while ago I got hired by a large SF tech company as a "machine learning engineer" and my team spent nearly all of their time writing Javascript web wrappers on top of scikitlearn. Thrilling stuff.
I've done this with mixed results as far as career satisfaction goes.
To be honest, getting pigeon-holed isn't always a conscious choice and once you realize that's what happened it's really hard to make a transition out of it. Sometimes the best approach is to play the cards you've been dealt.
As long as one does work which is personally meaningful, intellectually challenging, and which pays "enough" and has some stability, that all makes the sting of status-envy less of a bitter pill to swallow.
On the other hand there's no shortage of obsessively status-focused people out there. There's a guy on youtube whose channel is all about getting promoted at FAANG's, specifically, Amazon. That's it. Just practical deadpan advice on getting to "L7" (https://www.youtube.com/c/ALifeEngineered). I guess it's fine if that's what one _really_ wants out of life, but it seems like a recipe for profound meaninglessness for almost everybody.
It's crazy to me that's how you perceive his YouTube channel. Have you watched any of his videos? I've watched all of them and he feels far more focused on helping people become a better engineer than giving you a guide for Staff+.
> It's similar to data engineers thinking they will do real ML some day and their data job is just temporary...
This is unfair to DEs, not to mention inaccurate as of 2022. The statement assumes DEs are yearning to do "real ML" while suffering in their "data job" and waiting for a chance to move "upwards". Data engineering is a terminal career path by itself which may or may not support a dedicated ML function. In fact many of my DE colleagues switched from DS/ML/DL citing "model fatigue".
Now, "ML engineers" spending 90% of their time producing a workable dataset to get to the "real ML" is a different discussion.
At big tech the unsexy areas are the money makers. Everyone wants to work on the money losing parts. It's not actually clear to me which is better for a career.
Unless your dirty work can be communicated in terms of cost savings or value generated, stay the heck away. Otherwise you'll be stuck making the same shitty salary and your boss will keep making excuses on why you can't get a raise or promotion.
Your observation that doing the dirty work makes me invaluable for the team but has been really bad for my career is 100% correct. I've had this role for about 4 years and I wish I'd understood this earlier. I've been trying to leave for a few months now. The fact that I work in a profit center doesn't make your observation any less true.
Stick to the OKR model. There's always a 10x yield moonshot project in every company even if not officially put on a paper and called OKR. Work there, that's likely to get more money and attention than regular dirty work.
As a corollary also do the same in Personal life. You want to be chasing the 10x gain things. Not regular stuff.
In the days of the old this used to be called Do not sweat the small stuff.
>>Yes, it makes no sense, and it's not rational nor fair, but that's how business often works.
It is perfectly fair. If you were constructing a new building by definition its likely to have more life and last long than maintaining an older building. No matter how heroic your efforts maintaining the latter are.
I would say doing the dirty work in a profit center is the best way to become invaluable and begin working in areas you wanted to but found inaccessible earlier in your career. Then just repeat that over and over again until you’re where you want to be and enjoy it.
I’d say the hardest part of that advice is the identifying where you want to go and when you’re there, then allowing yourself to simply enjoy it rather than seeking the next thing. It’s easy to overshoot if you’re ambitious. I’m at the point of having overshot personally and trying to figure out how to walk my career backwards to where I was happiest.
I wish i could upvote you a thousand times. The path to a good career is focusing on the right stuff and digging deep. Think about where you work and what the most important products are at your company and what skills you need to become a valuable contributor there and move in that direction even if you are very far away from there currently. If you have 0 interest in the most valuable products at your company and you still want a good career, then move to a different company.
You are 100% right. Work on the high profile projects that senior management cares about. Bonus points for being good at translating tech details to business speak (as in how tech/problem X impacts $).
The first seven years of my career were spent mostly fixing crashes in a mainframe OS. When I first came to California, there were two piles of crash dump printouts six feet high waiting for me. Gradually I worked down the pile,
and time between crashes went from hours to months.
Then I got into high-security operating system development for DoD, which led to proof of correctness, networking, and other theory. The aerospace company was happy to hire someone who'd been deep inside a major operating system and had fixed that many crash-type bugs. I was happy to pivot to the problems of designing reliable and secure systems.
I like the take that "dirty work" might be unexplored space where impactful, relatively unexplored work can be done. However I reject the notion that simply doing dirty work will help you to advance your career.
Since the author says this has worked for them, let me give a counterexample: when I was a start-eyed new joinee in my current company, I was always down to do dirty work. Are builds broken? lets fix them. Do we have open tickets? Let's resolve them. Of course I also took it a step further. I wrote a proposal to untangle the ungodly mess that our builds had become and keep them good moving forward. I asked my manager to let me run an experiment fixing customer issues, and I did a writeup with my findings (positives) and recommendations moving forward.
This attitude had two unintended consequences.
First, the rest of the team stopped doing dirty tasks altogether. Hey, why fix the build or this flaky test? angarg12 will take care of it. I influenced the team's attitude, but in the opposite direction than intended.
Second, when I started to have conversations about promotion, all of this work didn't matter. I wasn't ready because I didn't have 'enough impact' or 'enough scope'. My documents went unread, my recommendations ignored.
So if career progression is your upmost priority, first understand well what your company values, and if/how dirty work connects with that.
Sorry to say this, but sometimes this is just true. As a newbie it is easy to think that a state of no bugs, no open tickets and 100% documentation and test coverage are the most valuable things a development team can strive for. But this is rarely the case. In most cases, it is just not worth it. Developer time might be better spent elsewhere.
Just because a work is dirty it does not make it automatically valuable.
> We’ve been to the fucking moon y’all, we can figure out a way to halve our Series-A-sized support queue.
Favorite quote from the article.
____
I think the concept of dirty work is important but isn't always as fruitful of a pursuit as the author makes it seem. There are plenty of cases of dirty work success stories, but there are just as many stories of automated runbooks that never end up being used or documentation never read.
What's important is to understand high signal dirty work. Listen for what is truly causing pain within a team or across teams and begin to pull on that thread. Talk to the stakeholders. Understand the ins and outs of the problem. Then go down the rabbit hole of getting hands dirty.
Counterargument by Jerry Seinfeld about thirty years ago:
"""
We never should have landed a man on the moon. It's a mistake. Now everything is compared to that one accomplishment. Now we go, "I can't believe they can land a man on the moon, and taste my coffee!" I think we all would've been a lot happier if we hadn't landed a man on the moon. We'd go: "They can't make a prescription bottle top open easily? I'm not surprised they couldn't land man on the moon. Things make perfect sense to me now." Neil Armstrong should've said, "That's one small step for man, one giant leap for every whining, complaining S.O.B. on the face of the Earth."
"""
The thing is landing a man on the moon took dedicating a few percent GDP of the most advanced nation in the world for a decade and scientists poached from the next n countries after the war: perhaps your X isn’t actually the harder problem.
Perhaps X just doesn't have enough geopolitical relevance to fund it with ridiculous amounts of taxpayer money.
If a problem that ought to be simple is actually hard, it's very likely that it's because whoever's making decisions doesn't want to pay for it.
Simple example: queues. It's a mathematically solvable problem but someone somewhere will think that hiring enough people to provide perfect service is too expensive and they're better off making people wait in line instead.
> Understand the ins and outs of the problem. Then go down the rabbit hole of getting hands dirty.
Yes, I think this nuance is somewhat lacking from the article. Do not sign up for every on-call shift or only do QA work all day. That's how you can become "that person," and you'll just watch your team expect that from you.
If you're early in your career, my suggestion is do different kinds of dirty work, switch it up as much as possible. Get a feel for as many as different things as possible. Then you'll be better prepared to leverage that knowledge, and you'll know when it's worth going down that rabbit hole.
> If you're early in your career, my suggestion is do different kinds of dirty work, switch it up as much as possible.
Spot on. This is massively important. Not only will you build a better picture of systems as a whole, but you'll also discover what is interesting and not interesting to you. Finding that out early on is invaluable.
The author mentions documentation as an example of dirty work that you could grind as a way to "build your career". Personally I enjoy writing documentation and I make an effort to write documentation in every project I work in, and I'm yet to see a single project where that work would have been valued. Nobody cares if you write great documentation. It's not a way to "build your career". I stopped reading the article at this point.
I have had the opposite experience. At every job I've had other than the first I've been praised for my documentation and it has opened up many opportunities for me.
The biggest piece of advice I can give is keep it short and put more important information up front. Every doc should start with a one-sentence plain language description of the thing's purpose and context.
Pascal once wrote in apology "If I had more time, I would have written a shorter letter". Be exactly as detailed as necessary and no longer.
I agree that overall, documentation is not a "career building" activity, but there are certainly some notable exceptions where the documentation is so good that people rave about it. A few that come to mind:
* The Bash manpage [1]
* FreeBSD docs, in general — the "base system" implementation and
documentation go hand-in-hand. If there's missing docs for a
built-in tool, that's treated as a bug.
* SQLite's documentation of the SQL language syntax [2]
[1] https://linux.die.net/man/1/bash
[2] https://www.sqlite.org/lang_select.html
> these are great places to look for high impact opportunities
I didn’t read the article so much as saying to grind through the dirty work, but to look at the existence of dirty work as a chance to (a) fix someone’s pain, preferably a lot of someones, (b) level-up your organization’s abilities in an area. At a job in the early 00s we had zero developer-facing documentation, so everything was an oral history project… this was awful, especially after we turned over a bunch of eng staff. I set up a couple of very simple systems for docs, and - this is the part that is the grind - started writing stuff down every time I had to answer a question from a coworker. It didn’t take long before I was mostly just pointing people to the doc system, and then eventually other people started adding to it. At that point it snowballs and basically the doc problem is “solved”. (There’s still work, but there’s a system in place that reduces the overall effort required.)
I don’t really disagree with you that docs are sometimes just a thankless grind, but I think the point is to find something that is dirty work but also has a really high and visible impact.
When you read someone's personal account of their career, and it doesn't match your experience, your response is to stop reading it? Wouldn't you want to keep reading to see why your experience and their experience are so different?
It depends, if it's a documentation read by many (e.g. an engineering standard), then it might boost your career ("everybody heard of baobabKoodaa!"). But in general, it's as you say.
> The lamentable work that many people avoid are great places to look for high impact, low hanging fruit.
Agree with this. When it comes to succeeding at work, especially at a big corp, I've always said something similar: after responsibility is abdicated, opportunity remains. Being annoyed at the present is often a position of power in the software world. Suddenly you have motivation to drive change and a bit of knowledge to get started. Of course you need the time and the freedom to use that.
One way I try to spend time doing the dirty work is by over-estimating. It's taken many years to really learn this, but I now over estimate tasks by quite a lot. This helps me not feel rushed, feel good when I deliver early, and gives me time to look around and improve something. Reflecting on previous tasks and what was annoying or oft repeated has helped me improve my process.
How estimation is marketed matters, too. Don't let your stakeholders think of it as an over-estimate. It's an estimate that considers the needs of the full software development lifecycle: automating tests, developing monitoring, refactoring to clean up old tech debt, etc.
Makes sense. It also must be nice to convey the dev lifecycle factors that go in to estimates.
Where I work refactoring is a trigger word and we are advised to never say the word when talking to management and it must never show up in any planning material/meetings etc.
Someone made the mistake of including refactoring efforts in their plans and they were asked to scrub it out.
This all boils down to how much you trust your management with the long-term health of the business. Not refactoring may actually be the right call. Maybe it will become a necessity later, maybe not.
If management just wants to flex their authority, you can inflate your initial estimates. It's only unfair when one side treats an estimate as a negotiation and the other side doesn't.
>One way I try to spend time doing the dirty work is by over-estimating. It's taken many years to really learn this, but I now over estimate tasks by quite a lot.
I'm only 4 months into the industry and I felt like a slacker for figuring out this trick. Now I feel better about it thanks to your comment :)
The truth is that what you actually do at work doesn’t really matter. The important thing is how your work is perceived and that is a function of how well you are liked which itself correlated with common background, cultural similarity and essentially innate quality of trustworthiness (there’s research on this).
Let me give you an example of how this can play out. Say you do the dirty work no one wants to do. These are are all possible outcomes:
- you get stuck with that and it becomes expected of you
- people feel that area still sucks so you didn’t have a lot of impact
- people really value your impact
- you’re viewed as having initiative and tackling hard problems
- you’re viewed as not tracking org priorities and instead doing work nobody cares about
- you get more opportunity to work in high profile projects because of your efforts
- you get less opportunities because you’re too essential in your dirty work
- you get less opportunities because you’re viewed as not working in what’s high impact
- you will get no credit for avoiding a catastrophic failure that didn’t happen. Worse, people may wonder what you’ve been doing (y2k anyone?)
All of these narratives can be constructed from the same set of facts. Part of this relies on your ability to communicate. A bigger part is networking. But the biggest factor of all is whether or not they like you.
> - you will get no credit for avoiding a catastrophic failure that didn’t happen. Worse, people may wonder what you’ve been doing (y2k anyone?)
This is so true it hurts. I worked for years at a certain Silicon Valley BigCorp on a low-level networking library with one other guy. We of course had bugs but we managed them and delivered on time. It was therefore assumed that our library was "easy" (it wasn't) and the buggy deliverables that made up other parts of the application were "hard" (they often weren't). So the folks who eventually delivered the buggy libraries got the recognition while we toiled more or less in obscurity. It was a bitter lesson in the importance of self-promotion.
I feel you.
In one of my jobs, despite the output being different, I eventually realised that management perceived the guys who bitch the most, as the most hard working. In reality, their bitching was a fascade to allow them slack. Quietly working through tough situations made it seem like all was well, even easy. The loud guys got all the attention, and praise; "wow, after all of that pain, you perservered, here is a nice bonus for you" :facepalm
You summed up my reaction to the article perfectly.
Anyone working in a large company can easily point a half dozen problems off the top of their head. This is especially true of software engineers who are detail oriented by nature. Lots of these ideas will overlap and find common cause, but some will be conflicting.
At the end of the day, focus and alignment is needed to avoid chaos. Therefore, it's best to go about these things incrementally, building awareness along the way, and ensure you have executive sponsorship commensurate with the investment you are making. The narrative should be designed to resonate with as many people as possible. If you miss the socialization process you will mostly get a big shrug at perf review time.
Even if the narrative is good often times there are other higher priority issues the org is dealing with. You need to make sure the problem becomes a priority before you show up with the fire truck. Typically you can pre position yourself if you see it coming as long as you can stay disengaged enough that the initial fire isn’t blamed on you.
This is just how big orgs work. Not startup mentality
> I think this is partially true but it’s important to make sure the garbage is on fire before cleaning it up.
Yeah. Especially true as the article mentions tech debt as an example. Too many times I've seen overeager developers early in their careers insist that the most important thing in the world is rewriting the old service written in C++/ASP/whatever, without respecting the fact that the old service has been dutiful performing mostly without issue for years, and the only time it comes up is the one time per year someone needs to go in and spend two weeks adding a minor feature or bugfix.
I spent the first part of my career following this kind of advice, working as hard as I could, and chasing some mythical prestige I thought would make me happy.
Now I make $320k, work remotely about 20h/wk, and have never been happier than I am right now, checking boxes and fixing bugs as a senior engineer on a minor product team at FAANG.
I don’t care if I ever get promoted, maybe I will, I probably I won’t. I get great feedback from my managers and I have a friendly relationship with my coworkers, most of whom are happily chomping at the bit to get promoted next cycle.
I realized during the pandemic how much better the world outside the internet is, and now I spend my spare time hiking mountains, painting murals, playing in a crappy cover band with my high school buddies, and eventually finding a wife to settle down with. I refuse to believe I’ll spend my time on my deathbed wishing I’d written more code and spent less time outside; life is just too damn short.
I’d like to give the exact opposite advice of this author - find an easy, comfortable, well paying job and fill the rest of your life with things that actually matter. I truly believe you’ll be happier for it.
> find an easy, comfortable, well paying job and fill the rest of your life with things that actually matter.
I think that's kind of what the article was about: raising your career status high enough so that you can get one of those nice jobs. You can't just pick a $320k job off of the job tree, that's almost 5 times the median household income.
Without having marketability, the task of finding an easy, comfortable, and well paying job is advice akin to "just win the lottery, that'll cover your expenses."
It's good work if you can get it! [0] But most people out there, even software engineers, aren't going to make 320k with minimal effort. I do agree with the overall idea that you should define "enough" for yourself, and slow down to enjoy life once you get there.
I did something like this back when I worked at a fast-growing startup that was eventually acquired. I built shiny new features, sure, but I also reviewed every line of code from before I joined, found major problems, refactored them and documented best practices so they could be avoided in the future, and made sure that the founder/CEO was aware of my work every step of the way. I was promoted to lead the team a few months later.
To be honest, I found refactoring and cleaning up tech debt to be just as fun, if not moreso, than building new features. And the user-facing results spoke for themselves: Less bugs and faster response times. Everybody wins.
The problem is that Dirty Work requires an order of magnitude more time and dedication to get the deserved recognition.
It's not that you fixed one person's mess, and you'll get a praise in the next perf cycle. You almost always need to show the majority of the team at least 3 times that you saved their asses. Then finally you can demand your work to be recognized. And right, even if everyone recognize your achievement, you still need to ask.
The author is advocating getting rid of dirty work by solving the problem. This can mean starting by doing the dirty work, i.e on call to identify the problems. Fixing them is what he is advising people build their careers on.
This is definitely something I have advocated for, and recommended to other people.
I'll add that a lot of the work that is referenced here is good at 80% done and only marginally better until it takes a giant jump at 100%.
Code coverage is a good example of this, getting from 0 to 80% code coverage is good. Getting to 95% code coverage is slightly more useful. Getting to 100% gives you leverage to find dead code, have actual confidence is things, prevent new features and code from not being tested (previous person go to 95% coverage, so a new feature might not dip the gate), and removes a lot of arguments around "I'll add tests later".
I've seen similar patterns with things like on call incident queues for hitting 0 incidents. And automated alerts becoming so reliable that engineers don't dismiss them as noise etc.
This works, but I'd add the following: always keep your eyes open for "dirty work" that you seem to enjoy more than most other people. That represents an opportunity to make disproportionate contributions.
Relatedly, you should prioritize building good working relationships with others who specialize in different, complementary types of "dirty work".
I agree with the premise of dirty work being more valuable. The trouble I see with the recommendation for taking on-call work is that it’s too easy to get “stuck” in that role without the tools to improve the process. There will always exist some amount of dirty/on-call work and reducing it is usually a business logic issue not a code issue. Maybe if you’re at a high-growth company you have the tools at your disposal to fix the process.
In that case, just working to get the on call team the resources it needs to fix the underlying issues sustainably would be a very valuable contribution
I'm generally on-board with the thrust of the article, but deep-dive volunteering for on-call work should be regarded with caution. Only do it if it is properly compensated and your time is valued (vacation days to compensate for your lost utility, for example).
If you're on-call and want to do anything outside of cell range or want to be unconditionally available for family or friends.... you can't.
I don't think i have the same career goals as the author, so not everything apply to me.
But he On call/support advice is golden, even if your aim isn't to become the best/most irremplaceable engineer in the company. Doing support and being on call for emergency (as long as the days you're on call are well defined and you're paid OT for it) is the best way to understand what the company/team is selling, how to debug the worst code the comapny wrote and why it was written like this. I probably don't have as much experience as other engineers here, but i've been at 4 different companies, and i became usefull way faster when i was put on support first.
There's an old corporate haha only serious saying, "If you want something done, give it to the busiest person you know."
Walk into any startup or 2 pizza team and ask who does the dirty work, there's always someone.
The question is why is it someone instead of everyone?
It's because enjoying doing dirty work requires certain personality traits, and two of those traits (people pleasers and inability to delegate) ensure the dirty work is forever diverted in one direction.
No comment on whether careers are built on such things.
> The Dirty Work Theory: The lamentable work that many people avoid are great places to look for high impact, low hanging fruit.
One person's KTLO is another person's promo project.
It's fascinating how much a project can be glorified in one-company and is dismissed at another. I had the (not necessarily thaaatt) strange path of working at Amazon to going to work at Siri/Apple.
When I was at Amazon, "client" work was not sexy; rather sharding a database is what all the magic-makers did. So, as a newly hired Java/Backend engineer at Siri, my first project, which I pitched for, was sharding our database for operational efficiency. Yay! Win! But, after about a year of that work, my manager (who's happy with my work) says ".. to get you promoted, let's get you on some more customer impactful work, where we can get you to demo some user facing features...". So, I dive head-first into the challenge on learning Swift/iOS stack and accelerate our team's services to run on-device; winner-winner-promotion-dinner!
Nobody at Siri wanted to touch the old server code. All the glory of WWDC+features+new_device_handouts were going to the folks working on client. The senior engineers who'd been around for decades across the industry were working on the client. They'd still fix server bugs nobody else could handle though. At Amazon, all the rockstar sr engineers had worked on services/distributed-systems for decades. But yeah, senior engineers (rockstars or otherwise) don't stick around at Amazon. They tend to leave after 2 years; weird.
That 18th month at Apple was the biggest learning so far in my career: someone's view of a KTLO project is another person's view of doing god's glorious work.
Some years ago I figured it would be a good idea to specialize in converting Angular 1.x applications to Angular 2+ - considering the former was supposed to be sunset eventually and nobody wanted to touch this with a ten foot pole this sounded like a good plan.
Bottom line is: garbage projects attract garbage management practices.
Projects I worked on in no particular order:
I:
1. I fix some longstanding bugs.
2. Client is happy and wants more.
3. Client gets back to us with new stuff and imposes a non-negotiable deadline because the marketing campaign already went.
II.
Contract in Switzerland. Financially very good, but the company that sent me there didn't manage to figure out our accommodation, among other things. I lost 5kg due to malnutrition because I had to figure out my housing situation by myself.
Also COVID put a wrench in those plans.
III.
Random offer that matched my experience. Wasn't too bad until I found that the client company sees us as first and foremost "a cost" and won't bother to keep us updated on important decisions. One key information regarding our deadlines was obtained by our tech lead by accident because he was called to an unrelated meeting.
I'm not sure "dirty" work is the right framing here. I'd consider those problems "hard work". They aren't neglected because they're perceived as less interesting but often because they require knowledge or abilities that many engineers don't have and aren't willing to put in the work to learn.
I built my career as a software engineer exactly like this. Learned all the pain points in mid corps/ corps and went on taking work in the "gutter". On call, learning rare languages (like COBOL), or unusual file formats (like AFP) and db admin (oracle especially) are parts of my tool belt to open black boxes and rebuild or refactor. But as mentioned before, this kind of work pays if you're freelancing, not as an employee, since you rarely get any kind of advance if you are providing meaningful groundwork. But you also need a lot of soft skills to be able to get information to provide the work, unentangle a spaghetti mess or simply get access to a specific server or codebase.
> So you’re in the on-call rotation, now what? Make pages approach zero. You can do it. Trust me, you can make pages trend towards zero. Many have done it on teams at the highest-scale companies in existence.
How about people own up to their mistakes instead of relying on random Joe who happens to be on call to fix it? I have been burned too many times by write only code written by some coworker who wants nothing to do with it. This is not just an on-call issue btw.
> Apologizing to angry customers
This is a terrible idea. Just because a customer is angry it doesn't mean you should apologize. SaaS customers are angry all the time because some 3rd party integration is returning a 5xx error.
How about people own up to their mistakes instead of relying on random Joe who happens to be on call to fix it? I have been burned too many times by write only code written by some coworker who wants nothing to do with it. This is not just an on-call issue btw.
Sorry for my french but
Jesus fucking christ, thank you.
I was being woken up constantly at last job due to a bug in the application because I was the Devops guy and this is exactly how I was treated. I spent weeks finding contributing causes to frequent failures. Gathered all the evidence I could find and begged for a fix, I scheduled calls with the product team; I poured over documentation and diagrams “this is the problem, this is inherent to the way these requests are being made, until it’s fixed we have no choice but to throttle the app”. I recorded a ticket each time I got paged and linked back to the team who owned the feature.
What was infuriating in the end was finally being told that they knew about the problem long before I brought it up and even HOW to fix it; it was just consistently being deprioritized by people who had the means to influence the decision on “fix this” or “write new shit”. Eventually I just suppressed the application in PagerDuty and stopped waking up whenever it would fail.
SLA slipped, customers complained, I find myself in a meeting being asked very aggressively “what’s being done about this and why are you ignoring PagerDuty?”
I said I wasn’t ignoring PagerDuty and presented a log of 20 something tickets I created linking back to the original “Please fix this request”. I told my leadership “I’m not the one ignoring this problem, I have been trying to get this addressed and prioritized for months”.
Laid off a month later. It’s becoming a growing reason why I want out of Ops and never want to return to it: companies hiring Ops people and treating us like the kitchen sink for work the company is too lazy to actually address and properly prioritize through staffing, planning or both.
Found that my company had a wealth of tech debt and powered through it for years. Super challenging to fix what others can or won't , tons of experience gained in the process.
At the top of my resume, I have "Polishes old code", and in the key skills says "Working with legacy/heritage code". I've never had a problem finding work.
This is some of the worse advice I’ve seen on HN in a long time. The type of work the author is recommending will at most keep you middling along in your career.
If you do ever want to get BigTech compensation they want you to be able to show “scope” and “impact” at anything beyond a Level 2 engineer. They also expect you to have some system design chops.
I strongly disagree with the advice given in this article.
Two main reasons:
1. This is essentially advice someone who puts his career ahead of everything else that matters in life, i.e. I'm happy to eat shit as long as it advances my career. If that's what you really want from your life, more power to you, but that's probably not for everyone.
2. Not everyone will have the skill level to fit that profile but if you happen to have been gifted with the luck to work on stuff for which you are truly passionate, you will both tremendously enjoy going to work every day *and* advance your career effortlessly.
This article sounds like a recipe for early onset depression. Everyone will have to regularly perform shitty, unpleasant work in their career, but unless you balance it with some amount of creative, fun and rewarding work, you're going to be miserable, and by way of that, not be very performant.
Conversely, I think this is one of the best ways to come up with startup ideas. Learn intimately why dirty work is the way it is, figure out sw to solve it internally, and once that works pretty well... replicate externally.
RE:Folks discussing limited career growth, if in a startup that's growing vs stagnant, these kinds of areas will likely be one of the areas will need more people+leadership as the company grows. Let's say you automate half your work but then the company has 5X growth. Before they'd need 5X more of you, though now the company "just" needs 2.5X of you. So you still get the ability to hire 1-2 more on your team. And that's just math if you're purely a cost center vs revenue driver. If you actually can help drive customer growth etc with your team, even more growth to be expected.
One of my first jobs out of school was implementing internationalisation libraries for an application that ran on Windows and a variety of Unixes (AIX, HP-UX and Solaris, if memory serves). It was predictably horrible and understandably no one with actual work experience wanted to do this tedious labour. In the course of my work, I found and reported/fixed various bugs in other parts of the application and built a certain amount of credibility in the eyes of my coworkers despite being so fresh-faced, mainly because I was in this particular trench alone. It showed me the value of tackling the ugly stuff as a chance to control one's micro-destiny, so to speak.
That said, if faced with that particular task now, I'd delegate it to a new grad in a flash.
This strategy can lead to career stagnation. Good software engineers should be willing to accept unpleasant assignments, like analyzing and fixing bugs under pressure. Fixing bugs in other people’s code be difficult and stressful, especially if there is a critical failure in code that is already in production. If you are consistently being asked to perform emergency fixes on code you did not write, then the company has a big problem. If management doesn’t have a plan to fix the fundamental problems then you should find a new job, or you will wake up one day and realize that you just spent the last three years fixing other people’s mistakes.
Toil isn't valued very highly. It feels good to do it, but it is fundamentally repetitive make-work. Removing the work is where the value is. The value is in scaling yourself, allowing your employer to see productivity improvements, and get more out of the same staff.
The value is in helping your employer climb "Charette’s Risk Escalator".
The right advice for the beginning of your career. But a recipe for being stuck at SDE2 unless you move towards high visibility work with a more direct line to new revenue (not just reducing costs)
Everyone needs it at some point. Everyone hates it. When it’s done you want to forget about it. Until next time …
My nasty niche is label printer software. If I search my support tickets for “love” it’s mentioned in a ticket almost every day.
That’s how much people hate label printing. Not shipping labels. I’m writing about custom labels, spreadsheets, date formatting, dynamic hide and show of text, swapping images, auto-shrinking text.
The stuff of nightmares.
People love an elegant solution, and they are willing to pay for it.
There is no secret recipe to career building. You can do great doing dirty work. You can end up nowhere working on trendy things. It's all about rebounding and using what you have learned to move forward.
The most impactful thing I have ever done for my own career is having an idea of what I wanted for an horizon a bit longer than just my next job and being very open about it. There are plenty of people around you who have vested interest into helping you and can't if they don't know what you are looking for.
Dirty work will help you burn out. I actually enjoy this type of work because I can complete it quickly and use the extra time to work on my own projects or learn something new.
This runs exactly counter to the site reliability engineering guide that the Google folks put together. Grungy toil work is bad for the worker and bad for the organization.
Sry there is no way at all to have high impact working on GDPR. The only way to have high impact is to make a lot more money than you’re paid, which is totally possible if you focus on solving real problems for customers. In other words, don’t be a cost center, be a source of revenue.
Interesting perspective that I’d like to challenge. Many European companies now face a future in which they’re banned from using US cloud services due to GDPR. Fixing that problem seems like having high impact.
Absolutely! But then why even work in software? There are a lot of much more impactful, dirtier jobs out there! You should maximise your impact and utility by being a garbage man. You may even do it for half the salary: even better utility for the community!
Not only did Steve Jobs contribute more utility to the community than 100 garbagemen, but also most of the people who collaborated with or reported to him did, too.
> Trotsky later claimed that Stalin amassed power as a bureaucratic mediocrity, but it was actually Yakov Sverdlov, assisted by Elena Stasova, who ran the Party machine. Stalin was not a born bureaucrat at all. He was a hard worker utterly dedicated to politics; indeed everything with Stalin was political, but he worked in an eccentric, structureless, unbureaucratic, almost bohemian, style that would not have succeeded in any other government, then or now. Lenin’s trust was won in the bank robberies and intrigues of the early years and, later, on the battlefields of the Civil War: Stalin was hardly in his office before 1920.
Really bad advice! Hard work does not pay, corporations are not meritocracy.
About 15 years ago, our corporation had orphaned project. Entire team of 5 developers quit without notice (found other job). Horrible code, no documentation, no tests, no spec, not even build system (was on one of the developers laptop). There was important deadline 6 months away.
I stepped up, worked 16 hours a day four couple of months, eventually got project back on track, and trained new team. As reward I got put on PIP (performance improvement plan) and eventually got fired.
Problem was:
- I worked for other division, for my manager I was dead weight. It was sort of emergency reassignment and paper work never got ironed out.
- I mostly worked from home, come to office barely. Some coworkers thought I left. Not keeping appearances was main excuse for getting me PIPed.
- My project was 1 month behind the schedule. I missed the important deadline.
- Senior manager who initiated my work quit, leaving me behind.
I am not sure what is the lesson here. But now I work in remote job, where I can do all my weekly work in about two hours. Way happier now.
Edit: this was official assignment from very senior manager within company. I saved them a lot of money on fines!
What you describe above is not what the article is describing.
To be honest the author doesn't do a great job at explaining the difference between meaningful dirty work, eg work that needs to get done in order to actually move the company forward, but nobody at the current company can do it, and trying to resurrect abandonware with no coherent vision or power.
The latter will almost always lose (I've been in similar positions) whereas you can indeed build a serious career around the former.
But this was the first case! Very important project for legal compliance, not some sort of abandonware nobody cared about. I had enough skills to put it on track, on official assignment from higher management.
Unless your line manager authorised the secondment (in which case, why PIP?), it wasn't on official assignment, it was just a personal request from someone who happened to be in a higher management position.
Telling the VP to get stuffed, you're only going to do what comes through the proper chain of command, is just going to get you fired immediately rather than PIPed.
Not saying there wasn't a way through this that could have led to a positive outcome, but the key takeaway isn't "do the dirty work", it's "make sure what you're doing has an impact, and has visibility from the people in charge of personnel decisions affecting you". Less work but greater visibility > more work and worse visibility. Part of your job is ensuring visibility or you will get shafted.
The lesson is : watch your own back. Communicate to people about what you do and (more importantly) what you are not doing and last, never take double assignments. Seems like you trusted your company a lot more than you should have.
>Hard work does not pay, corporations are not meritocracy.
The former is true, but the latter does not follow. The lesson of your story is that corporations are a meritocracy, but you need you need to work on stuff that helps your management directly.
If you’re working on something unofficially, you’re basically moonlighting so you’re taking a big gamble that it pays off into something better because you’re not doing your actual job.
This is really it right here. I actually find it amazing that such a significant percentage of people don’t actually understand what their job even is.
Your job is to work on what your manager wants done. It’s that simple.
Now if you have a bad mananger they may not be effective at communicating that to you. If that’s the case than it’s even easier to get ahead. You can be one of the few people that actually asks!
Your job is to be (continuously) profitable. In a way that upper management can see.
You can do everything your manager wants, but if you aren't profitable, you're going to be let go as soon as a recession rolls around (possibly with your manager as well).
It's possible to get fired if you're profitable, but much harder. And if you're profitable enough, your manager will get overruled (the exact bounds of what is profitable enough vary a bit by company).
> Your job is to be (continuously) profitable. In a way that upper management can see.
This is incorrect. Unless upper management is writing your reviews or you are extremely exceptional so you stand out, this is terrible advice. This is even worse if you’re ignoring your own manager’s requests in an attempt to do what you think “is right for the company”.
> you aren't profitable, you're going to be let go as soon as a recession rolls around
Not how it works at medium to large companies. When things aren’t profitable, they rank employees by ratings and then cut the bottom X%. When it comes to SWEs it’s much better to keep the good ones in unprofitable departments and cut underperforming people across the board. SWEs are not responsible for profit and their performance is going to be heavily based on manager reviews.
> It's possible to get fired if you're profitable, but much harder
It’s very rare to tie a specific SWE to profit. A department yet, a SWE not so much.
Your advice might apply to sales but it’s terrible for SWEs.
Are they meritocracy? How does it go with diversity and other noble goals? The only way for highly productive individual to get fair salary is to start their own business and do consulting. Or do shady stuff like over-employment!
That was official work, very senior manager pulled me out of project, and temporarily assigned me to different division. Not my fault paper work and finances between divisions never got sorted out, I did not even had access to that stuff!
It's a horrible thing and makes your job merely about pleasing the whims of some random C-suite instead of doing something productive for society. I'd rather work on an assembly line, at least the machine is consistent about what it wants and doesn't change its mind because it just read an article about NFTs.
Actually the author was very careful to qualify their advice as applying to work at high growth companies, rather than corporations or very early state startups, where this approach is much less likely to be effective.
Also, the example you describe, which I'm sure has left a strong impression on you, doesn't contradict the advice on offer. Again, the author explains what kind of dirty work they are referring to - problems that have enough reputation to make it obvious to everyone that solving them is extremely valuable.
Am I reading this right? You worked double time for months, and in that time you neglected your own job, without it being authorised by your line manager?
All so that a manager in a different department wouldn't look bad for losing an entire team in one go?
That's the lesson. Don't do that. Pick up extra work if you want to, but always do your own job first.
If you are reassigned, you are not dead weight to your original division, because you aren't working for them, you are on the books of the other division.
Also if you are reassigned, you don't have your original projects to get behind on, they are someone else's problem now.
Similarly, if reassigned, and you do the work of the new assignment there's no grounds for a PIP, and even if there were, your original manager wouldn't be the one putting you on it.
Appearances are soo important in jobs, much more than quality of work. This is why fully remote jobs are so great, people are on a more even playing ground.
The best of career growth advice I've seen work consistently is: be working on a profit center rather than a cost center.
You can be the best employee in the world, but if you're on an unsexy, money-losing area of business, you will likely watch people get promoted around you, because they worked on the thing that gets all the attention. Doesn't matter if their contribution to the success was insignificant, or that the one project was necessary for the other to succeed. It's just the halo effect of being on a winning team that does it. Yes, it makes no sense, and it's not rational nor fair, but that's how business often works.