Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nobody gets promoted for simplicity

terriblesoftware.org

Post reply on HN
Print view View original

31–40 of 95 posts

Re: Nobody gets promoted for simplicity

#31

Post by tabs_or_spaces »

I think the advice is good but maybe the title could be improved.

> But for Engineer A’s work, there’s almost nothing to say. “Implemented feature X.” Three words.

To me, this is the main problem. Engineer A is unable to describe the impact of their work, how the work affected the business. Your manager isn't responsible for promoting your own work, you are.

> Engineer B’s work practically writes itself into a promotion packet: “Designed and implemented a scalable event-driven architecture, introduced a reusable abstraction layer adopted by multiple teams, and built a configuration framework enabling future extensibility.” That practically screams Staff+.

Maybe it's just the narrow of the article, but if promotion only looks at complexity and not quality of delivery and impact on the business then this isn't a good engineering team to be in.

There are many cases where simplicity is celebrated and recognized. It's up to the engineer to know what the impact of their work is, if they can't do that then that's on them.

Re: Nobody gets promoted for simplicity

#32

Post by tonyedgecombe »

jtbaker wrote: post #15
ChadMoran wrote: post #8

I launched a technical feature on Amazon's retail platform that is responsible for 9 figures worth of revenue. When I launched it, it had no infrastructure. It was a collection of small changes across every core platform (Detail Page, Cart, Checkout, etc). At first people were like "Well, you didn't do much" but when they saw the value things changed drastically. It's a bit of marketing you have to do to help bring p…

How do you ascribe a revenue number like that based on one collection of changes in a huge system? Presumably there were a bunch of other features being released around the same time as it. Was there a lot of A/B testing around it?

Doesn’t matter, @ChadMoran is already on the fast track whilst you are on a pip.

Re: Nobody gets promoted for simplicity

#34

Post by p1anecrazy »

linehedonist wrote: post #21
losalah wrote: post #20

This hit a nerve because “simplicity” is one of those things you only notice when it’s missing, and most orgs don’t have a good way to reward “the thing that didn’t happen.” I’ve watched this exact dynamic play out: one person ships the boring implementation, nothing breaks, everyone moves on. Another person ships the “platform” version, there are docs, diagrams, an internal talk… and now there’s a subsystem that nee…

some bits of LLMese in this comment, to my ears at least. Especially "That’s the kind of impact that compounds"

Well, people shouldn’t start writing word salad just because LLMs were trained on structured text.

Re: Nobody gets promoted for simplicity

#35

Post by deathanatos »

tabs_or_spaces wrote: post #31

I think the advice is good but maybe the title could be improved. > But for Engineer A’s work, there’s almost nothing to say. “Implemented feature X.” Three words. To me, this is the main problem. Engineer A is unable to describe the impact of their work, how the work affected the business. Your manager isn't responsible for promoting your own work, you are. > Engineer B’s work practically writes itself into a promot…

> It's up to the engineer to know what the impact of their work is, if they can't do that then that's on them.

… the impact of my work is more often than not opaque to me, the person doing the work. More often than not I'm not the one setting the priorities, and way more often than not the real world impacts like "we brought in $X M with that feature you wrote" is quite simply not visible to me because "that's not what engineers do".

I would love to know these things, I'd love to have that level of visibility, but finance at tech companies is nearly always a black box. Best I get as an engineer is that I know how much cloud compute costs, so I can figure out the expense side of stuff.

If anything, I usually have to go for far more intangibles: "this internal manager was happy", "this adjacent team had all their wishes and desires fulfilled", etc.

Otherwise, stuff feels like it plays out like the bits you quoted from TFA.

Re: Nobody gets promoted for simplicity

#36

Post by dullcrisp »

al_borland wrote: post #30

I’ve also seen this show up with stable vs buggy code. Person A writes some code that just works, no one hears about it and the developer may tend to fade into the background. Person B made a lot of mistakes is always stepping in to fix problems and be the hero, and everyone forgets that they caused those issues in the first place. When it comes time for promotions, Person B is fresh in everyone’s mind due to the her…

Yes at least we can sleep.

Re: Nobody gets promoted for simplicity

#37

Post by abustamam »

al_borland wrote: post #30

I’ve also seen this show up with stable vs buggy code. Person A writes some code that just works, no one hears about it and the developer may tend to fade into the background. Person B made a lot of mistakes is always stepping in to fix problems and be the hero, and everyone forgets that they caused those issues in the first place. When it comes time for promotions, Person B is fresh in everyone’s mind due to the her…

I've been person B and got promoted to staff engineer once.

I'm back to being a senior in a new org and I try to be person A, but be extra communicative of what I'm working on and how it impacts and why it's important.

I find I spend more time trying to understand how to explain the value my work has to the business (screenshots, demos, docs) than trying to actually do my work. But I think it's important though, otherwise I'll be the person A who never gets promoted.

Re: Nobody gets promoted for simplicity

#38

Post by al_borland »

semiinfinitely wrote: post #24

* in idiotic organizations. I've was promoted for producing a significantly simplified replacement for an existing system that was critical. it happened because the culture rewards engineering excellence.

It sounds like they had a previously complex (and I assume problematic) system to compare it to. When complexity is causing problems and the job is to simplify to get rid of problems, it will be rewarded.

If it was made simple from the start, it would have likely been seen as an easy and solved problem, and you never would have been brought in, as no one would ever think about it again.

Re: Nobody gets promoted for simplicity

#40

Post by abustamam »

bruce511 wrote: post #13
jamesfinlayson wrote: post #9

Earlier quoted context omitted.

I haven't worked at that many companies to have an informed opinion, but I've certainly been at a couple of places where smart people went along with ridiculous complexity, but part of the reason was there was already a hugely complicated mess with way too many people working on it for a simple solution to be politically feasible.

While the post seems simple, it's arguably complex, as the comments here point out. Simple solutions are good enough some of the time, perhaps even most of the time, but often fall down with edge cases. But edge cases add up, and dealing with them is complicated. For example, calculating pay for hourly paid workers is a "simple" problem. Deduct start time from end time and multiply by rate. Covers 90% of the workforc…

I think it's important to understand the domain to know if those edge cases are likely to happen. If no one on payroll is ever on call, then no need to design for that. Solution works as intended. If it turns out we need a more robust calculator later, then we can design for that. But adding that complexity before the domain requires it seems unnecessary to me.

But also, just because there is complexity in the domain doesn't mean there needs to be complexity in the software. An elegant, simple solution could be implemented for calculating payroll or adding infinity. That's the hard part though.

Post reply on HN