Hacker News Reader

Comment by BulgarianIdiot | Hacker News Reader

"A programmer whose salary depends on being an unsurmountable middle man between boss and machine, declares that solutions for surmounting him are a lie." - The Onion, probably

View on HN

There are a lot more middle man then that, a lot of CEO and CTO i've met had an almost active disintrest in anything technical or even practical knowledge of there product, not knowing the priorities is in there own backlog or not knowing what an init system is or does but ask you how to start a process when a computer starts. Unbelievable what people complain about in meetings without having googles that problems in MONTHS. Most people just secretly hate technology and will grasp at anything that gives them an excuse not to care.

Even in a world where e.g. LLMs become capable of producing relevant, consistent, and accurate code by description alone - there will be programmers. The person hiring a programmer is not doing so because he himself cannot program (though this may, incidentally, be the case), but because he has other things that he would prefer to dedicate his attention and energy to. When you hire a janitor, it's not because you are incapable of sweeping and mopping. And by BLS numbers [1], 1 programmer is currently equal to about 4 janitors in terms of cost, which is pretty reasonable. So I doubt this calculus is changing anytime soon.

[1] - https://www.bls.gov/ooh/building-and-grounds-cleaning/janito...

[1] - https://www.bls.gov/oes/current/oes151252.htm

You do realize that low code solutions are actually the middle man between boss and machine here, don’t you? This is like comparing Node and Drupal and announcing that Drupal is the superior technology. Ick.

So's a compiler, and an operating system, and microcode.

I've upvoted this because it's funny and mostly true. However, the outputs from no-code and hand rolled are not equal. It blurs the distinction between custom and off-the-shelf. With no-code representing something closer to the latter.

There's a lot of money to be made in first trying to customize an off the shelf solution, then trying to replace it with low code one and finally implementing a custom one.

Sure. Yet any no-code derivative is therefore stuck with a general-purpose implementation. Which admittedly is fine in many contexts.

However, the distinction is important. You "assemble" no-code. You cannot buy a dog puzzle and reconfigure it to be a cat puzzle. IMO, this is the inherent limitation of a no-code toolset.

Also, users are handicapped by the developer's capability. That is to say, the efficiency and specificity of the tool's internal codebase represents an invisible glass ceiling for its users.

Reply on news.ycombinator.com