Somewhere along the way we forgot about software craftsmanship

The problem is that people fall for shiny but low-quality things that break or are hacked into after being used for a week. And then they can't get their money back or cancel their subscription, or they are simply too lazy for it.

We're basically asked to produce a quick dopamine hit, instead of rock-solid long-term solutions.

I mean, given a choice between two boxes, one of which said "twice as many features", and the other said "crashes half as often", I suspect the majority of users would choose the "twice as many features" box.

Electron is just evolution at work. The OS vendors had decades to fix their system UI frameworks and make it easier to write cross-platform UI applications.

But they didn't because vendor lock-in was always more important to them, and that's how you get Electron. You reap what you sow ;)

Electron has gone a bit overboard with the 'everything but the kitchen sink' philosophy, but the basic idea of a platform-independent application development framework is sound.

I think the biggest benefit of craftsmanship is actually flexibility. Well-crafted code has a property of malleability without becoming a tangled mess. Its parts tend to be more orthogonal and less coupled.

I don't think that it's a binary choice of craftsmanship or shipping code; this may be true if you're a younger engineer. Mid- and senior- engineers can build well-crafted systems with less of a tradeoff for speed afforded by having more experience building and knowing where to add that malleability and where it would be wasted.

This above may be sad regarding the art side of things, but, well, it is what it is.

Meanwhile the folks stuck behind end up with the blame for these people's mistakes and the problems caused by their work, and get treated like poor performers because they can't just rush out features at the same lightning pace.

I worked in such an environment and that’s how it’s done. Demonstrate it to your team, set expectations, have conversations about what matters. Encourage improved processes.

As the people turn over naturally, make extra effort to hire people who want to work that way. However, expect that they will clash with the existing team so try to bring them into the "craftsmenship conspiracy". Two good hires might change a team of five, and three definitely will. If your average engineer stays two years, that'll mean you're replacing 2.5 of them every year, so you could aim for that by 2025.

Also, maybe start vocalizing and demonstrating what it is you want to see. Start a reading group around craftsmenship. Find ways to inspire them about how great it will be when you've got very few production defects or whatever it is that makes that team demoralized. As they say, "If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea."

The other thing is reward it. Not monetarily, but just reward effort that is improving the system. They will need time for these activities. When I manage my teams that develop long lived software I build in at least 33-50% of all time programming for technical debt repayment. There's no doubt in their minds that quality is extremely important. I'll also be extremely aggressive about abolishing deadlines. Unless there's a legitimate emergency, I'll assume all features are done when they are done. Also expect that they will find things to improve you never thought of or think is silly. Generally it's better to good people loose on technical debt than it is to be a dictator.

With the right people, this is the fertilizer that lets them produce extremely high quality work at a good consistent pace, for decades.

Also, maybe there’s an ironic counterfactual in payment and financial reporting networks, like Visa and Peppol. Peppol is not for profit, and Visa infamously facilitates five-way transactions with a huge degree of backwards compatibility.

As an aside, I wonder what code quality means to the author of TFA, and what craftsmanship looks like. Would be fantastic to get clear examples of this from the history of the industry.

We shipped every year, or maybe every 6 months. What this meant in practice is that every team got their features to "shoddy" state, but one team would always take much longer to get there than the others, and because we were in a "feature freeze" near ship dates, the teams who were waiting for integration could use that time to clean up their features, applying craftsmanship to make things "shipshape"; products could ship with one or two wobbly new features, and most of them pretty solid.

Now, with internet updates, as soon as a team gets to "shoddy", the feature ships; no one polishes; and all new features tend towards wobbly. (for the business this is an advantage, as features are stabilised only in response to demonstrated customer demand, but I think the enforced opportunities for cleanup on the old schedule, however disadvantageous for the business, were advantageous for engineering, as well as those customers who hadn't explicitly signed up for the beta program)