[HN Gopher] Build your career on dirty work
___________________________________________________________________
Build your career on dirty work
Author : Tomte
Score : 178 points
Date : 2022-09-11 16:14 UTC (6 hours ago)
(HTM) web link (staysaasy.com)
(TXT) w3m dump (staysaasy.com)
| Ragingweb wrote:
| 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.
| Tade0 wrote:
| I would be careful with such statements.
|
| 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.
| TrapLord_Rhodo wrote:
| why are you letting clients impose deadlines? That's your job
| to tell them.
| Tade0 wrote:
| Not my call. This was a client of the company I was
| contracted to at the time.
|
| As to why they did this: refer to the "bottom line" section
| of my previous comment.
| wnolens wrote:
| 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)
| jpollock wrote:
| This does work. At least it works for me.
|
| There is a difference between doing a crappy job and solving a
| crappy problem.
|
| This is the difference between "toil" and "eliminating toil".
|
| https://sre.google/sre-book/eliminating-toil/
|
| 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".
| rdtwo wrote:
| I think this is partially true but it's important to make sure
| the garbage is on fire before cleaning it up.
|
| 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.
| vyrotek wrote:
| This advice in comic form.
|
| https://twitter.com/_workchronicles/status/13144369055015116...
| rdtwo wrote:
| I'm going to print this out and hang it on my wall
| mjr00 wrote:
| > 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.
| dasil003 wrote:
| 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.
| rdtwo wrote:
| 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
| RyanShook wrote:
| 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.
| namenotrequired wrote:
| 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
| cratermoon wrote:
| 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.
| ourmandave wrote:
| That's why I always start green field projects with already
| obsolete tech stacks.
|
| You're welcome.
| cratermoon wrote:
| There are many aspects of code that make it "legacy", but
| "obsolete tech stack" is only one, and certainly not the most
| important one.
| collsni wrote:
| This works, I can say so from self experience.
|
| 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.
| fanuelworku wrote:
| wwarner wrote:
| 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.
| cnorthwood wrote:
| There are more ways to quantify impact than money.
| derfabianpeter wrote:
| 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.
| fanuelworku wrote:
| scrotiemcboogs wrote:
| > 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.
| nnadams wrote:
| > 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.
| scrotiemcboogs wrote:
| > 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.
| ForHackernews wrote:
| > We've been to the fucking moon y'all, we can figure out a way
| to halve our Series-A-sized support queue.
|
| 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.
| scrotiemcboogs wrote:
| Speaking of human ingenuinty. I do concede that not everyone
| is a rocket scientist, though..
| humanrebar wrote:
| 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." """
|
| https://www.imdb.com/title/tt0697684/characters/nm0000632
| dehrmann wrote:
| If we can land a man on the moon but can't do X, maybe X is
| the harder problem.
| rzzzt wrote:
| Sounds like an X-Y problem to me.
| WalterBright wrote:
| That's true. Many problems seem simple, but are
| fundamentally insoluble. For example, crime rates will
| never be zero.
| shepherdjerred wrote:
| You're not being creative enough. Crime rate on the moon
| is currently 0%.
| babyshake wrote:
| On the other hand, we refer to really difficult problems
| requiring widespread coordination as being "moonshots".
| colechristensen wrote:
| 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.
| ttpphd wrote:
| 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.
| praptak wrote:
| This advice is about _recurring_ grungy toil work, aka "don't
| run your systems on human blood". So I'd say that's kind of a
| different advice.
| chrchang523 wrote:
| 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".
| danwee wrote:
| I don't avoid on-call for the reasons the article states. I avoid
| on-call because I don't want more money in exchange of my free
| time.
| cgh wrote:
| 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.
| honkdaddy wrote:
| 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.
| dicriseg wrote:
| 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.
|
| [0]: https://www.theonion.com/if-i-had-one-piece-of-advice-for-
| to...
| dangus wrote:
| > 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."
| hilariouswhip wrote:
| > 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.
|
| _Young Stalin_
| weatherlite wrote:
| Build Your Burnout on Dirty Work
| swivelmaster wrote:
| 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.
| ur-whale wrote:
| 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.
| SamPatt wrote:
| Good piece overall, but "only boring people are bored" isn't true
| when talking about their jobs.
|
| Especially when you're doing work beneath your ability, it can be
| boring and there's no reason to pretend otherwise.
|
| Your spare time is a different story.
| whatarethembits wrote:
| I actually like this kind of work sometimes, I can get it done
| quickly and work on my own projects or learn something new with
| extra time
| bigcat12345678 wrote:
| 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.
| ilaksh wrote:
| Right now I am solo (and barely getting by) so I am currently
| following the "Build Your Business By Doing Every Single ____ing
| Thing Yourself" model.
| orwin wrote:
| 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.
| jmyeet wrote:
| 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.
|
| EDIT: fixes as per comments below. Thanks!
| Noumenon72 wrote:
| Based on your last sentence, I think your first paragraph's "is
| not a function of how well you are liked" should not have the
| "not".
| Noumenon72 wrote:
| Also, I think "not tracking org properties" should be "not
| tracking org priorities".
| cgh wrote:
| > - 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.
| qwertygerty wrote:
| 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
| friedman23 wrote:
| If you do this, you get pigeon holed into this kind of work.
| davewritescode wrote:
| This is 100% absolutely not true
| rzzzt wrote:
| Perhaps parent is talking about their own experience. What
| does that mean for the percentage of true-ness?
| Animats wrote:
| 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.
| MisterKent wrote:
| The title is a bit misleading.
|
| 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.
| karaterobot wrote:
| 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.
| givemeethekeys wrote:
| 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.
| fnordpiglet wrote:
| 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.
| spaetzleesser wrote:
| "be working on a profit center rather than a cost center."
|
| Ideally work on something the CEO or another bigwig has passion
| for and understands to some degree.
| strikelaserclaw wrote:
| 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.
| WalterBright wrote:
| > that's how business often works
|
| It's how everything works.
|
| > it's not rational nor fair
|
| Life gets a lot better once one accepts and deals with reality
| and stops getting wrapped around the axle about fairness.
| tmpz22 wrote:
| 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.
| avgcorrection wrote:
| Walter put all of his non-conformity points into language
| design.
| WalterBright wrote:
| I'm bald and wear glasses. That's quite unfair. What do you
| suggest I do to redress this unfairness?
| groffee wrote:
| > What do you suggest I do to redress this unfairness?
|
| Stop being a spectator in your own life, take charge and
| start living it.
|
| > I'm bald
|
| Start taking wheatgrass supplements.
|
| > wear glasses
|
| Start palming exercises, it will give you 20/20 vision if
| you consistently practice.
| [deleted]
| sarchertech wrote:
| Evidence isn't great for either of those. Definitely not
| good enough for you to be so flippantly dismissive of the
| OP.
| whatarethembits wrote:
| 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.
| blowski wrote:
| Point well made. Clearly, though, some things _are_
| unfair and worth fighting against.
| holografix wrote:
| Funny, I always thought reality what up to us to define and
| create.
| bitL wrote:
| Basically, "don't get pigeonholed". It's similar to data
| engineers thinking they will do real ML some day and their data
| job is just temporary...
| mjr00 wrote:
| > 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.
| maxFlow wrote:
| > 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.
| crispyambulance wrote:
| > "don't get pigeonholed"
|
| 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.
| nostrademons wrote:
| 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.
| jjtheblunt wrote:
| > Being invaluable to the team gives you negotiating
| leverage.
|
| What if the team (or its product) gets cancelled?
| colordrops wrote:
| 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.
| bigcat12345678 wrote:
| Cost center is the critical path, they are the punching bag
| for others' failures.
| mkl95 wrote:
| > 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.
| seanhandley wrote:
| I'm from Lancashire in the UK and we have a saying here:
|
| > Where there's muck, there's brass.
| ISL wrote:
| 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.
| bitL wrote:
| Typically those companies requiring on-call periods give their
| employees pagers to keep during vacations...
| NegativeK wrote:
| A pager doesn't let you be unconditionally available for
| family/friends or far outside of the range of technology.
| cgrealy wrote:
| If you are on-call, you are not on vacation.
| zeroth32 wrote:
| 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!
| intellectronica wrote:
| 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.
| nus07 wrote:
| Sounds like -yet another day at Amazon :)
| frobozz wrote:
| 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.
| stingraycharles wrote:
| I don't read it the same way; I read that he got reassigned,
| as he was "dead weight" to his manager.
|
| Still bad, but probably means that all this was inevitable,
| and his manager already made up their mind before the project
| even started.
| frobozz wrote:
| 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.
| [deleted]
| [deleted]
| bluedino wrote:
| Bad management/company, not bad 'hard work'
| ClumsyPilot wrote:
| thats like 69% of all companies
| chitowneats wrote:
| 69% is notably far less than 100%. Stop chasing the wrong
| things.
| ClumsyPilot wrote:
| "half of my advertising is wasted money. Trhouble is, I
| don't know which half"
| kortilla wrote:
| >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.
| zeroth32 wrote:
| 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!
| tikhonj wrote:
| That is, companies are a meritocracy as long as "merit" means
| "making your bosses happy".
| Negitivefrags wrote:
| You say that like it's bad thing.
| ohgodplsno wrote:
| 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.
| Negitivefrags wrote:
| 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!
| Kamq wrote:
| 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).
| willio58 wrote:
| 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.
| agumonkey wrote:
| I'm trying to find books about strategics and tactics used in
| work groups.
| AndrewKemendo wrote:
| 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.
| zeroth32 wrote:
| 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.
| AndrewKemendo wrote:
| Fair enough! My apologies for assuming too much.
|
| Sometimes you just get hosed
| frobozz wrote:
| > 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.
| zeroth32 wrote:
| I dont want to argue about this specific case.
|
| But if direct manager promises pay increase or promotion,
| it is not binding or "official" as well.
| lostcolony wrote:
| 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.
| whiplash451 wrote:
| 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.
| nnadams wrote:
| > 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.
| andreimackenzie wrote:
| 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.
| galoisscobi wrote:
| 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.
| hoosieree wrote:
| 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.
| tokinonagare wrote:
| >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 :)
| CSMastermind wrote:
| 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.
| WastingMyTime89 wrote:
| 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.
| baobabKoodaa wrote:
| 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.
| dharmab wrote:
| 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.
| number6 wrote:
| Are there some advice you can give for writing good
| documentation
| dharmab wrote:
| 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.
| turtledragonfly wrote:
| 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
| bstpierre wrote:
| > 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.
| bitL wrote:
| 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.
| bitL wrote:
| Dirty work often leads to burnout, which is a career killer, so
| please don't build your career just on dirty work.
___________________________________________________________________
(page generated 2022-09-11 23:00 UTC)