6 ms·

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"

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.

ThrowawayR2 4y ago
> "I would not worry about style or complexity." Given that the OP said that they were working on embedded systems, where reliability, efficiency, and often long support lifetimes are needed, this is very poor advice.
gureddio 4y ago
I don't agree with your points about complexity. Some developers will go off task and introduce complexity when it doesn't need to be introduced. You must have seen this in your career. As a manager, you should be putting up gates against this (code reviews, and politely rejecting proposals to introduce unnecessary complexity)
bitlad 4y ago
I disagree with you. You should fire the engineer strategically. Firing the engineer right away does have risk. But there is a great risk long term if the person is in the team and making the team toxic which will repel engineers with better character and better fit. In a long run, it will benefit team and organisation if the person is fired. I have seen companies shutdown due to the toxicity induced by engineers like first hand. I have also been part of the interview where I was super excited about the product the org was building but rejected the offer after meeting the team due to the toxicity.
washadjeffmad 4y ago
Thank you. This tone of this thread was so deaf to OP's actual requests, advice on perspective and communication, that I actually started to sweat a little.
ManWith2Plans 4y ago
I absolutely agree with the first part of this advice. As to the assertion that complexity is not worth worrying about, I could not disagree more. I have watched projects fail time after time because of complexity, dependencies, and lack of budget. 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.
- ubercore 4y ago
  > 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.
- agentultra 4y ago
  "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.
jmac01 4y ago
> Style is irrelevant Except when you want someone else to help with maintaining. What nonsense
deleted 4y ago
[deleted]
at-fates-hands 4y ago
>> Don't try to write software that will last 100 years. THIS. I've worked as a developer on huge, multi-year projects and I've worked on rip and tear six month projects and everything in between in the 10 years I've worked as a developer. None of the stuff I ever worked on was never maintained for more than 2-3 years after release before being nuked and built from scratch with some new fangled framework or database or data platform. When I first started as a developer, building your stuff to withstand the zombie apocalypse was something we all aspired to. We all wanted to be like the Y2K developers. You get called in 30 years after you retired to re-write your code because all these legacy systems are still running on the code you wrote when you were an angsty college graduate at your first development gig. The truth of the matter is companies don't need something that's bullet proof to last even 5 years any more. I've always felt in some regard, nuking products is done simply for upper management types to prove they're worth keeping around, more than these things need to be rebuilt.
- cgrealy 4y ago
  Your software probably won’t be running in 100 years, but in 10 years? 15? Absolutely possible. In fact, after 20 years writing software with various companies, the only ones that didn’t have code older than 10 years were the startups. But even then, that doesn’t matter. If you’re code is really complex, you’re going to struggle to come back to it in 6 months, never mind 6 years. Code should be as complex as it needs to be and no more. Write with maintainability in mind.
- lowercased 4y ago
  > None of the stuff I ever worked on was never maintained for more than 2-3 years after release before being nuked and built from scratch with some new fangled framework or database or data platform. OK... but... that's not universal. That's perhaps a symptom of resume-driven-development? I got a call in 2017 from someone asking about something I'd built in 2003. It was still in use. I worked with a team in 2015. Looked at their system 2 weeks ago - still using the same base foundation I'd laid out for them. I'm finishing up a project now rebuilding a system from 2005. There ended up being some IP and legal issues which ended up with "clean room rebuild" as the safest choice. But the system from 2005 was/is still running (for a little while longer). That you've worked places that rebuild/gut every 2-3 years... I don't know how 'normal' that actually is, save for JS front-end stuff, which seems to almost necessitate it.

ThrowawayR2 4y ago

> "I would not worry about style or complexity." Given that the OP said that they were working on embedded systems, where reliability, efficiency, and often long support lifetimes are needed, this is very poor advice.

gureddio 4y ago

I don't agree with your points about complexity. Some developers will go off task and introduce complexity when it doesn't need to be introduced. You must have seen this in your career. As a manager, you should be putting up gates against this (code reviews, and politely rejecting proposals to introduce unnecessary complexity)

bitlad 4y ago

I disagree with you. You should fire the engineer strategically. Firing the engineer right away does have risk. But there is a great risk long term if the person is in the team and making the team toxic which will repel engineers with better character and better fit. In a long run, it will benefit team and organisation if the person is fired. I have seen companies shutdown due to the toxicity induced by engineers like first hand. I have also been part of the interview where I was super excited about the product the org was building but rejected the offer after meeting the team due to the toxicity.

washadjeffmad 4y ago

Thank you. This tone of this thread was so deaf to OP's actual requests, advice on perspective and communication, that I actually started to sweat a little.

ManWith2Plans 4y ago

I absolutely agree with the first part of this advice. As to the assertion that complexity is not worth worrying about, I could not disagree more. I have watched projects fail time after time because of complexity, dependencies, and lack of budget. 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.

ubercore 4y ago
> 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.
agentultra 4y ago
"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.

jmac01 4y ago

> Style is irrelevant Except when you want someone else to help with maintaining. What nonsense

deleted 4y ago

[deleted]

at-fates-hands 4y ago

>> Don't try to write software that will last 100 years. THIS. I've worked as a developer on huge, multi-year projects and I've worked on rip and tear six month projects and everything in between in the 10 years I've worked as a developer. None of the stuff I ever worked on was never maintained for more than 2-3 years after release before being nuked and built from scratch with some new fangled framework or database or data platform. When I first started as a developer, building your stuff to withstand the zombie apocalypse was something we all aspired to. We all wanted to be like the Y2K developers. You get called in 30 years after you retired to re-write your code because all these legacy systems are still running on the code you wrote when you were an angsty college graduate at your first development gig. The truth of the matter is companies don't need something that's bullet proof to last even 5 years any more. I've always felt in some regard, nuking products is done simply for upper management types to prove they're worth keeping around, more than these things need to be rebuilt.

cgrealy 4y ago
Your software probably won’t be running in 100 years, but in 10 years? 15? Absolutely possible. In fact, after 20 years writing software with various companies, the only ones that didn’t have code older than 10 years were the startups. But even then, that doesn’t matter. If you’re code is really complex, you’re going to struggle to come back to it in 6 months, never mind 6 years. Code should be as complex as it needs to be and no more. Write with maintainability in mind.
lowercased 4y ago
> None of the stuff I ever worked on was never maintained for more than 2-3 years after release before being nuked and built from scratch with some new fangled framework or database or data platform. OK... but... that's not universal. That's perhaps a symptom of resume-driven-development? I got a call in 2017 from someone asking about something I'd built in 2003. It was still in use. I worked with a team in 2015. Looked at their system 2 weeks ago - still using the same base foundation I'd laid out for them. I'm finishing up a project now rebuilding a system from 2005. There ended up being some IP and legal issues which ended up with "clean room rebuild" as the safest choice. But the system from 2005 was/is still running (for a little while longer). That you've worked places that rebuild/gut every 2-3 years... I don't know how 'normal' that actually is, save for JS front-end stuff, which seems to almost necessitate it.