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
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.
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".
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
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.
> 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.
>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 :)
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.
> 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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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!
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.
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.
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.
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.
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.
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 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.
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
213 comments
[ 2.4 ms ] story [ 220 ms ] threadFound 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.
Relatedly, you should prioritize building good working relationships with others who specialize in different, complementary types of "dirty work".
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.
EDIT: fixes as per comments below. Thanks!
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.
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.
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.
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 :)
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.
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.
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.
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.
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.
Who's 'we', kemosabe? I guarantee none of the overpaid yaml jockeys at my adtech firm have ever been involved in anything that flew to the moon.
""" 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." """
https://www.imdb.com/title/tt0697684/characters/nm0000632
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.
That said, if faced with that particular task now, I'd delegate it to a new grad in a flash.
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.
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.
> Where there’s muck, there’s brass.
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.
You're welcome.
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.
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.
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.
but you were laid off because you didn’t provide the value expected of you
it’s not reasonable to derelict your duties because you deem it so
your paid money to do a job management specifies not you
if you want power start your own company or quit. what you did was effectively embezzle resources from your employer.
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!
Others did. That's why we don't shop at Wanamaker's.
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.
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!
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!
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).
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.
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.
Sometimes you just get hosed
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.
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.
But if direct manager promises pay increase or promotion, it is not binding or "official" as well.
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.
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.
Still bad, but probably means that all this was inevitable, and his manager already made up their mind before the project even started.
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.
If you clean it up before it’s on fire you just become a lowly garbage man.
If the garbage is on fire and you positioned yourself to clean it up you are a hero and take credit.
If you are a really corporate pro you wait till the fire is mostly put out then sweep in for the photo op.
https://twitter.com/_workchronicles/status/13144369055015116...
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.
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.
This is just how big orgs work. Not startup mentality