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

81–90 of 95 posts

Re: Nobody gets promoted for simplicity

#81

Post by mekaron »

usrnm wrote: post #72
xmprt wrote: post #23

Earlier quoted context omitted.

In a functional org, the principal engineer's role would be to review designs to reduce complexity and new systems. The goal of the org (and engineers within the org by extension) is to deliver impact. The engineer who can ship the impact of 3 new features with simple implementations in the time that it takes one complex implementation to be build should be promoted.

> the principal engineer's role would be to review designs to reduce complexity Two questions: 1) How did this principal engineer get this title? 2) How is he going to get the next one?

> How is he going to get the next one?

By delivering, or helping the team deliver, outsized returns on engineering hours invested.

If a design is bloated, a good principal engineer should point out gaps, help simplify the solution and enable the team to deliver faster. That definitely gets noticed.

Re: Nobody gets promoted for simplicity

#82

Post by medi8r »

bob001 wrote: post #51
xiphias2 wrote: post #17

This is just not true, people get promoted for delivering impact whether the solution is complex or simple. The best engineer I know who can work with huge complex systems in a big company usually starts with a complex solution then after he understands what he wants to achieve thinks backwards and reimplements it in the fewest possible lines of code change with the already complex system.

There's exception and geniuses to every rule. In general however a simple solution will be much more difficult to argue a promotion around even if you make a ton of impact. You may get a top rating and a slightly larger bonus however not a promotion. Every large company has a ladder for promotions that includes many words that basically come down to "complex." "Drive a year long initiative" or "multiple teams" or "la…

Yeah that large company promo thing drives me nuts. Perpetual gaslighting "meh... that was too easy lel". Yeah thanks. Often stuff isn't easy but hard to explain why if the solution turned out to look easy.

What is funny is you can dance through the hoops for 3-5 years for promo. Or grind leet for 100 hrs and get it by jumping.

Re: Nobody gets promoted for simplicity

#84

Post by tripledry »

tomxor wrote: post #53
Swizec wrote: post #41

Earlier quoted context omitted.

> If an org wants to fix the incentive, I think the question to ask in reviews isn’t “how big was the thing you built,” it’s “did you make the system easier to change next quarter.” This has been my personal mission and motivation to go into management. I see my job as making sure engineers are rewarded for building the simplest thing that works. So far the best way to align incentives that I've found is a simple pol…

Yup, in a word, ownership. But that's an unpopular approach these days where many companies are obsessed with minimising the bus factor to the point that their IP is as replaceable as their employees.

Also, budgets. I have been vocal about being on-call, no problem for me as long as there is extra compensation (in our org there is).

No takers yet.

Re: Nobody gets promoted for simplicity

#85

Post by lhmiles »

kstrauser wrote: post #58

I’ve gotten promoted for simplicity several times. “Why are we jumping through hoops to make an Xbase file on a network share be accessible to multiple users updating data at the same time? Uh, can I introduce you to PostgreSQL?” “Hear me out: what if instead of deploying a fleet of web servers to handle 10M identical GET requests per second, we put a handful of servers behind a few Varnish caches with a 1 second exp…

What's the art?

Re: Nobody gets promoted for simplicity

#86

Post by brazzy »

The "Engineer A vs. Engineer B" scenario where B gets promoted for overengineering glosses over the fact that A would be delivering features much faster - you really think that would not get noticed?

I think overengineering leading to promotions can only happen in organizations so large that engineering managers are isolated from business impact considerations, because that is usually the overarching metric.

Re: Nobody gets promoted for simplicity

#87

Post by cottsak »

usrnm wrote: post #72
xmprt wrote: post #23

Earlier quoted context omitted.

In a functional org, the principal engineer's role would be to review designs to reduce complexity and new systems. The goal of the org (and engineers within the org by extension) is to deliver impact. The engineer who can ship the impact of 3 new features with simple implementations in the time that it takes one complex implementation to be build should be promoted.

> the principal engineer's role would be to review designs to reduce complexity Two questions: 1) How did this principal engineer get this title? 2) How is he going to get the next one?

1) not by keeping things simple I think. (sarcasm yes, but also mostly true)

Re: Nobody gets promoted for simplicity

#89

Post by f4c39012 »

cube00 wrote: post #49

I think of this every time I see hundreds of interfaces, all with single class implementations. The excuse always comes back "but it's extendable", how many implementations of a ConfigurationSingleton could you have in an application? Put the class in and if you need the interface later any refactoring tool can easily create it when you have that second class (which 99% of the time will never happen).' This is what w…

One great use of interfaces is for automated testing, the test class can implement the same interface specification as the code.

A long time ago I also used structuremap to automatically wire up default implementations of interfaces, which reduced the need to write boilerplate code enormously. It also helped separate concerns because separating out interfaces means I could concentrate on only the specification of the class.

Re: Nobody gets promoted for simplicity

#90

Post by dirk94018 »

Simplicity is hard. Mark Twain's 'I would have written less had I had more time' at the end of a letter comes to mind. Software dev's tendency to build castles is great for technical managers who want to own complex systems to gain organizational leverage. Worse is better in this context. Even when it makes people who understand cringe.

You would think that things not breaking should be career-positive for SysAdmins, SREs, and DevOps engineers in a way it cannot be for software devs. But even there simplicity is hard and not really rewarded.

Unix philosophy got this right 50 years ago — small tools, composability, do one thing well. Unix reimagined for AI is my attempt to change that.

Post reply on HN