Comment by ChrisMarshallNY
2 days ago
Part of that, may be what we measure “product” to be.
My entire life, I have written “ship” software. It’s been pretty easy to say what my “product” is.
But I have also worked at a fairly small scale, in very small teams (often, only me). I was paid to manage a team, but it was a fairly small team, with highly measurable output. Personally, I have been writing software as free, open-source stuff, and it was easy to measure.
Some time ago, someone posted a story about how most software engineers have hardly ever actually shipped anything. I can’t even imagine that. I would find that incredibly depressing.
It would also make productivity pretty hard to measure. If I spent six months, working on something that never made it out of the cręche, would that mean all my work was for nothing?
Also, really experienced engineers write a lot less code (that does a lot more). They may spend four hours, writing a highly efficient 20-line method, while a less-experienced engineer might write a passable 100-line method in a couple of hours. The experienced engineers’ work might be “one and done,” never needing revision, while the less-experienced engineer’s work is a slow bug farm (loaded with million-dollar security vulnerability tech debt), which means that the productivity is actually deferred, for the more experienced engineer. Their manager may like the less-experienced engineer's work, because they make a lot more noise, doing it, are "faster," and give MOAR LINES. The "down-the-road" tech debt is of no concern to the manager.
I worked for a company that held the engineer Accountable, even if the issue appears, two years after shipping. It encouraged engineers to do their homework, and each team had a dedicated testing section, to ensure that they didn't ship bugs.
When I ask ChatGPT (for example) for a code solution, I find that it’s usually quite “naive” (pretty prolix). I usually end up rewriting it. That doesn’t mean that’s a bad thing, though. It gives me a useful “starting point,” and can save me several hours of experimenting.
> When I ask ChatGPT (for example) for a code solution, I find that it’s usually quite “naive” (pretty prolix). I usually end up rewriting it. That doesn’t mean that’s a bad thing, though. It gives me a useful “starting point,” and can save me several hours of experimenting.
The usual counter-point is that if you (commonly) write code by experimenting, you are doing it wrong. Better think the problem through, and then write decent code (that you finally turn into great code). If the code that you start with is that as "naive" as you describe, in my experience it is nearly always better to throw it away (you can't make gold out of shit) and completely start over, i.e. think the problem through and then write decent code.
BTW: I guess I should be a bit more forthcoming about the way that I work. I know that we are always looking to ding others for not working the way that we do, but I find my way works for me, quite well. I won't tell other people that they are wrong, unless they are working for me. I am constantly learning new techniques and approaches, by staying open to, and observing, how others do things. I learn from the examples set forth by others; even ones that do things in a way that I may initially disapprove of.
"Experimenting" is a vital part of my process. I call it "Evolutionary Design,"[0] and it involves a lot of iteration. I have found that it's vital to UI[1], because I can almost never predict how UI will act, when actually presented to the user. The same goes for a lot of communication workflows. I have to "run it up the flagpole, and see who salutes." I almost always find that my theorized approach has issues, and I need to make changes. The old "Measure twice; cut once" approach to software development has caused me great trouble, over the years, and I have found that I need to adjust to new tools, and new contexts.
For example, right now, I am revamping one of my UI widgets[2]. It started as a minor tweak for iOS26, but I realized that it's a bit "long in the tooth," and that I can make it more robust, simple, and usable. I have been running the test harness all morning, seeing issues, and going back to the code, and tweaking.
[0] https://littlegreenviper.com/evolutionary-design-specificati...
[1] https://littlegreenviper.com/the-road-most-traveled-by/
[2] https://github.com/RiftValleySoftware/RVS_Checkbox
That’s often what I do. It saves me the “blind alleys.”
I find they often cause more trouble than they are worth, because they are completely wrong, and need to be “unlearned.”