Comment by davedx | Hacker News Reader

Comment by davedx | Hacker News Reader

It's a good discussion to have!

I've been in both sides of these roles over the years. I think the problems in the article really seem to be lack of technical design or leadership though, rather than problems with individual programmers or personality types. You can't have one guy leave, another guy come in, have the same issues then blame the people. The process is broken!

At any kind of head count beyond 5+ people, you need to have some kind of framework in place for choosing and deploying technology. You need someone (it could be many someones, or even the whole team) who thinks about architecture at each step of a project, especially the first part. Conversely, your org should try to intercept "architecture astronauting" early and balance simplicity with decomposition and integration goals.

Managing people can be like herding cats. Managing programmers can be like herding autistic cats. But you still have to do it.

The org in the article sounds like it's missing CTO/engineering management.

> The org in the article sounds like it's missing CTO/engineering management.

Not necessarily. I’ve worked in a company where the CTO itself was encouraging those employees. He established a clear list of goals to achieve to climb to the next seniority level.

To be promoted you _had_ to do stupid shit like hacking the framework (which was Angular so I let you imagine the potential), be the architect of the project, or make company-wide presentations of your original solutions.

Of course, a team full of people hacking things, trying to be the architectural leader and solving old problems with "invented here" solutions can’t really exist.

So you were either in the promoted hackers camp or in the camp of people trying to do their job of delivering value and quality at the lowest cost, which in a CRUD SaaS business means that most of the time you just have to do the old boring things "by the book" that have proven to just work. But if you were in this camp you were seen as underperforming because you didn’t do what was expected but also you were underperforming for real because adding a single API in the back or a component in the front was just a hell of stupid work.

The "high performers" were just the people who created this hellscape because since they invented it they’d be the only ones to have a full mental model of the team’s codebase.

Now I just avoid any company who promotes their team as "the most talented engineers" because it’s either false or worse. I’d rather work with average coworkers who have a life outside computers and who just want the work done by 6pm.

That sounds like a bad CTO.

It happens when companies are managed by people with non-technical backgrounds. They think they can employ “autistic wizards” to solve the lowly technical problems. One such wizard initially receives all the praise and then gets so out of touch with reality that they either implement a custom TCP/IP stack or they get frenzy with the modern buzzword tools.

> implement a custom TCP/IP stack

This but over HTTP of course, I heard it prevents issues with firewalls.

Have I seen a company-made HTTP over an internal RabbitMQ instance that had to de queue messages and call registered web hooks on our multiple apps ? Yes. And when I asked the CTO why we had to do like this, because we were losing all the rabbitmq purpose, the answer was that HTTP didn’t need firewall configuration so that we could spread our architecture everywhere over the internet.

I love the cats analogy. It reminds me of the book even tougher than herding cats (about tech management) https://www.amusingmulcahy.com/my-first-book-even-tougher-th...

No mention of autistic cats there as far as i remember!

Added to my reading list. Thanks

Well yes; the problem described in the post is often found in real life: how many Angular projects are simple CRUD apps that would work just as well in PHP or ASP? But I don't think the cause is clever programmers.

I think the main cause (as you say) is this:

> After all, the management in business environments is usually non-technical

Management in business environments is not only non-technical, it's also non-business. It specializes in managing people and timelines, without a profound understanding of either the business requirements or the technical solutions available to address them.

I don't know how one promotes a culture where management is technical but that should be an important topic to focus on in many (most?) organizations.

I love when a “timeline” is determined without even discussing the work with the people who actually do it. It’s beyond laughable.

Reply on news.ycombinator.com