4 ms·

- Software is usually more complex than you expect it to be. - Software complexity is proportional to the number of engineers working on it. Hiring more people

- Software is usually more complex than you expect it to be. - Software complexity is proportional to the number of engineers working on it. Hiring more people will increase complexity. So, hire as few engineers as you can get away with to solve the problem. - There will be bugs. It’s inevitable. Blaming people will only make things worse. It’s possible to mitigate the problem with process (and that process assumes that there will be more bugs but streamlines how you resolve them). - Programming languages, tech stacks, and other areas of engineer preference largely don’t matter. Let engineers pick what they want. Remember that the good solutions are often free and have stupid sounding names.

dclowd9901 3y ago
On the process note, I’d say your best process is automating processes. Any sort of process that requires active thought is a huge effort sink. This is why so many devs hate Jira. It’s process that can’t really be automated.
scarface_74 3y ago
> Software complexity is proportional to the number of engineers working on it. Hiring more people will increase complexity. So, hire as few engineers as you can get away with to solve the problem. You haven’t heard of resume driven development? Or better yet - “we need to use K8s from day one” > Programming languages, tech stacks, and other areas of engineer preference largely don’t matter It very much does matter. I can easily and cheaply find a developer who knows and would be glad to work with React on the front end and Node on the back end to replace a developer who leaves. Some obscure front end framework and Elixer on the back end - not so much.
ghomem 3y ago
"Programming languages, tech stacks, and other areas of engineer preference largely don’t matter. Let engineers pick what they want. Remember that the good solutions are often free and have stupid sounding names." This is a dangerous statement. Some tech stacks are way more complex (and therefore more expensive) than others. You need to choose wisely what you use, because whatever you put in production will stay with you for at least 5 years (thumb rule...) and rewriting is a pain.

dclowd9901 3y ago

On the process note, I’d say your best process is automating processes. Any sort of process that requires active thought is a huge effort sink. This is why so many devs hate Jira. It’s process that can’t really be automated.

scarface_74 3y ago

> Software complexity is proportional to the number of engineers working on it. Hiring more people will increase complexity. So, hire as few engineers as you can get away with to solve the problem. You haven’t heard of resume driven development? Or better yet - “we need to use K8s from day one” > Programming languages, tech stacks, and other areas of engineer preference largely don’t matter It very much does matter. I can easily and cheaply find a developer who knows and would be glad to work with React on the front end and Node on the back end to replace a developer who leaves. Some obscure front end framework and Elixer on the back end - not so much.

ghomem 3y ago

"Programming languages, tech stacks, and other areas of engineer preference largely don’t matter. Let engineers pick what they want. Remember that the good solutions are often free and have stupid sounding names." This is a dangerous statement. Some tech stacks are way more complex (and therefore more expensive) than others. You need to choose wisely what you use, because whatever you put in production will stay with you for at least 5 years (thumb rule...) and rewriting is a pain.