Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> I imagine a 10x engineer as someone who can consistently identify the fastest, cleanest and least complex way to get from A to B, reliably

Yes but... in today's software culture, the fastest cleanest and least complex solution is very rarely appreciated or even tolerated.

If you can solve all the requirements with a couple $5/mo VMs, you'll still be run over by the buzzword-compliant solution that requires 30 instances in a kubernetes cluster.



I’ll always appreciate the simple solutions, and that comes from being a solo, overstretched developer for much of my early career. What I observed is when more people get involved the solutions always take on extra complexity. This could be due to the need to make work for everyone on the team. To delegate responsibility. One person who has to set up a VM and push code and talk to customers does not need to complicate their life. But when you have a manager and a new hire and an IT department and have meetings then all of a sudden you divide and conquer and there needs to be enough churn to justify everyone’s role in the project. The one person who speaks up and says something like “yo we don’t need this CI and buzzword tech stack and containerizations, microservices and cloud functions, I have a LAMP VM already coded up that meets the requirements” they will certainly be shut down by the rest of the team.


> Yes but... in today's software culture, the fastest cleanest and least complex solution is very rarely appreciated or even tolerated.

Funny how this sentiment is as old as "kids these days".

There are reasons why complex solutions are needed. These reasons are so much valid, that certain areas legally mandate the complexity. While majority of those reasons are safety related, one of the aspects behind safety is reliability and maintainability.

Usually (!), there is a balance. What is the least amount of training you have to supply the person doing maintenance that they could grasp all the assumptions, constraints and links with other components to successfully work on a component? The more complex the system, the less complex an individual component, in a way it interacts with the rest of the system.

For example electrical power supply units. Some fields require PSUs to have galvanic isolation, which makes them much more complex than $2 aliexpress part. However, galvanic isolation means that there are e.g. no weird, parasitic interactions over grounding - it just provides power like a battery would. Swapping a battery with a medical grade PSU would not introduce hidden interactions with the rest of the world.

Likewise, in a software system, a single component becomes (or at least can become. Complexity does not necessarily yield that, but complexity is required to provide this) more isolated, easier to work on alone without introducing breaking changes in different subsystems.

Do you need complexity? Not necessarily. Maybe the project is small and relatively short lived. Maybe you are thrown into a decade old project with requirements and teams having been changed several times in that timeframe. Component isolation backed by complexity would probably be highly appreciated.


> legally mandate the complexity

That's often the rewards of lobbying by entrenched interest taking advantage of a captured congress.


> If you can solve all the requirements with a couple $5/mo VMs, you'll still be run over by the buzzword-compliant solution that requires 30 instances in a kubernetes cluster.

Officially triggered. Cuz lord knows that's how all my meetings go.

Why use a simple VM setup and some Ansible to keep it up, when we can put 4 more layers of abstraction in there and pay AWS / Azure / GCP extra money?

Who is gonna get that money? Depends on which provider "wined-and-dined" (cough cough) recently.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: