The conversation

Lessons learnedExperience excerpt · English

Managers should encourage their engineers to spend time trying to simplify architecture and reduce …

… Managers should encourage their engineers to spend time trying to simplify architecture and reduce code, infrastructure, and package dependencies. Smart engineers can learn to think simply over time, but this will not happen automatically. (I plead guilty to gravitating toward complexity in the early part of my career, but I have since learned better.) Managers should place emphasis on using existing patterns wherever possible rather than re-inventing the wheel. Practicing laser focus on delivering value, evaluating solution dependencies with an eye to keeping things simple, and accurately modeling the problem domain in question. Rather than trying to fight with engineers about implementation approaches, managers should try to guide engineers toward arriving at these conclusions themselves. I have also found that stressing simplicity as a key performance metric for engineers is a useful tool.

Original discussionAsk HN: Strategies for working with engineers that are too smart?474 source comments · at import
2

What was this responding to?

Parent context · original excerpt

ST

Uhh, please don't listen to any advice in this thread which says "fire your highest performing engineers". You will literally turn your project into a "legacy" system overnight. You're a manager. Your job is to focus their priorities on business outcomes. If you're not providing focus they will run with whatever pet problems they have with the existing system. That's called doing their job. I would not worry about style or complexity. Style is irrelevant and complexity is driven by the business case. Don't try to write software that will last 100 years. Its going to be put on maintenance mode and never touched again the second your highest performing engineers leave or are re-orged.

Full original

Community replies 0

No community replies yet. Add your perspective.

Replies from the source 2

Direct replies available in this import. Original-language excerpts.

UB

> I have also found that stressing simplicity as a key performance metric for engineers is a useful tool. Some of the smartest engineers I've ever worked with produce code that is so well crafted it feels simple when you look at it, but it's actually extremely clever. I think the conversation about "clever", "smart", "volatile" programmers tends to align the axis of _code_ complexity with cleverness, but often the cleverness is in finding the perfect simple solution.

Full original
AG

"Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better." -- Edsger W. Djikstra Complexity sells better because it's cheaper. This is not the, "look at this novel abstraction I wrote and proof of its correctness with respect to our specifications," kind of "complexity" that folks often mean. It's the hand-waving, just add the simplest patch you can to make it work for the business problem at hand , type of complexity. The kind of complexity that ends up with giant balls of "really simple" code that nobody understands entirely anymore. It sells better for all the usual reasons that driving slightly over the speed limit gets you where you're going a little faster. It's only a problem if you get caught or cause a collision.

Full original
Continue on Hacker News

Respect different perspectives. Share concrete experiences.

Sign in to post, reply, repost, and quote.