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

51–60 of 95 posts

Re: Nobody gets promoted for simplicity

#51

Post by bob001 »

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 "large complex task with multiple components" are all examples I've seen.

Re: Nobody gets promoted for simplicity

#52

Post by arwhatever »

abustamam wrote: post #37
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, othe…

The “Firefighter Becomes Arsonist” Organizational Anti-Pattern

Re: Nobody gets promoted for simplicity

#53

Post by tomxor »

Swizec wrote: post #41
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…

> 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.

Re: Nobody gets promoted for simplicity

#54

Post by RevEng »

This is interesting because I specifically look for the opposite in interviews and design reviews. Yes, sometimes complexity is needed to handle scaling, extensibility, observability, security, and privacy, but most of the time it doesn't. I have new engineers who jump to designing big complicated modular systems with multiple levels of abstraction and I have to tell them to slow down and try something simpler. YAGNI is a real consideration.

My principal is: you don't have to do it right now, but make sure you could do it if you need to. This mainly comes down to avoiding assumptions. Simplifying assumptions can make things easier, but designs that don't leave room for extension make it really difficult to add those things later. It's a difficult balancing act, but I greatly appreciate any engineer who recognizes it and can manage it.

Re: Nobody gets promoted for simplicity

#57

Post by RevEng »

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…

I haven't seen AI systems do this in my experience unless you specifically ask for it. Sometimes the outcomes can be a bit complex, but I find myself having to prompt it specifically when I want something more abstract.

Re: Nobody gets promoted for simplicity

#58

Post by kstrauser »

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 expiration?”

“Wait, this thing is spec’d to serve 3000 requests per day and an acceptable downtime of 20 hours per week? Kubernetes is cool, but why don’t we spin up a single VPS and run the whole stack on it?”

There’s a subtle art to talking dev teams down off a ledge, but sometimes the simple path is better in every way. Being able to spot those times is golden. And, of course, knowing when the simplest reasonable version is still quite complex and being willing to roll with it is equally important.

Re: Nobody gets promoted for simplicity

#59

Post by aprime7 »

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…

Honestly curious question: why do you think an interface adds complexity?

An interface specifies a contract that its users can depend on. Having one saves me from reading implementations of dependencies when reading a class.

Post reply on HN