[mrheosuper]

>This is an area where I think experience actually hurts. I've seen senior engineers get bogged down building the perfect thing and by the time they get a demo, they realize it sucks. The implementation doesn't suck, but the product or feature itself actually sucks.

This resonates with me. Sometime i want to "turn off" my brain and write shitty code.

Back in the day, i made a lot of toy project. Sometime all the source code is in single file. No respect to modularity. But it was fun, and it worked. Now just try to finish a toy project seem much harder than ever.

[lordnacho]

Isn't this called the second system problem? When you've done it before, you feel like you need all the bells and whistles?

[mrheosuper]

You are right, this is the first time i've heard about "second system problem". Never know it has its own term.

[theryan]

The Mythical Man-Month by Fred Brooks is still a good read today and goes into depth about this topic. He called it the second system effect and considered it to be the most dangerous system an experienced developer will create.

His 'No Silver Bullet' theory may or may not stand up to what AI is doing today as well.

[skeeter2020]

From what I've seen it's standing up. His original statement/hypothesis is often misrepresented.

"there is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity."

If he had also included "volume" then AI would have disproved him! More anecdotally, the hands-on experiences of senior+ developers seem to firmly fall into the accidental camp, with the essence of software problem solving getting marginally easier as you'd expect with a new, powerful tool, but far from "solved".

[dasil003]

I agree with the quote as stated, but I would refactor it for a more powerful insight.

I do believe order of magnitude improvements in productivity and reliability are possible, but they don't come from technology or management technique, they come from simplicity. The simplest possible thing that gets the job done can be infinitely more reliable than whatever baroque contraption comes out of typical fog-of-war enterprise environments. The trick is having the judgement to understand what complexity is essential and how to distill things down to the most valuable essence. This is something AI will never be able to do, because the definition of value is in the eye of the human beholder.

[nemetroid]

It is interesting though that when he mentions AI as one of the non-silver bullets, one of the arguments is that the AI models of the time were problem-specific and not easily transferable.

[Bukhmanizer]

I think this is why often new languages get so hyped early on. A bunch of inexperienced people get to leave all the boring “best practices” back in their old languages

[Cthulhu_]

I think you can practice it; do some coding excercises, e.g. Advent of Code is coming up again, usually it's only the later ones that require some optimization or clever algorithms (...I never got that far). Or a constrained environment, you can't write long code in pico-8. Or time limited, like a hackathon or game jam.

[CaptainOfCoit]

Game jams and hackathons are a fun and easy way to get a lot better at scoping and saying no, and being able to predict what works or not once everything is in place.

It's a playful environment with low stakes too, compared to working in a startup, so really advice new programmers to participate in order to learn faster.

[saaspirant]

LLMs (Cursor) have pretty much solved this problem for me. I design the DB tables manually and let it run somewhat wild with implementation.