[ChrisMarshallNY]

> replaceable people

Until that mindset changes, the disasters will keep coming.

Achieving true "replaceable people" is a major task. I have seen it done (properly), and suspect most folks on this board would be aghast at the compromises that need to be made. I didn't like it.

I managed a team of extremely experienced C++ engineers that were really hard to replace, so I did my best to keep them on board.

As to "artisan"? I don't really care what I'm called. I like coding, and I like writing really good UX.

[luckylion]

Why do you think the mindset that everyone should be replaceable is wrong / leads to disasters?

I agree completely that it's not trivial and comes with its own trade-offs and side-effects, but when you achieve a good chunk of it, it brings a lot of flexibility, stability and peace of mind for everyone involved.

You can put more people on some task because it's not something only one person can do. You won't nose-dive when somebody leaves. And developers know that they can go on vacation and don't need to worry about what's going to happen to the rest of the team (I know that not everyone thinks like that, but in my experience enough people do).

[ChrisMarshallNY]

It's really a long topic, but the basic TL;DR, is that people are not interchangeable, unless you reduce the task to the lowest common denominator, and that means that we squander the talent of the most skilled, in order to cater to the least skilled. Basically, tell good coders to write bad code, because bad coders need to understand it.

We get "meh" results.

The issue is that everyone seems to be fine with "meh."

That's a shame.

The alternative is hire only good coders, and do what it takes to keep them around, and that's a really unpopular stance.

[sfn42]

I'd say good code is easier to understand.

Things get at least as complex as they need to be. Some things are just hard, but most things are fairly simple. The difference between a good programmer and a bad one is that the latter will make the simple things look complicated and hard to understand.

[ChrisMarshallNY]

> I'd say good code is easier to understand.

In my experience, this is highly subjective.

One of my employees was probably the best coder I’ve ever known. His code was well-structured, well-documented, clever, efficient, bug-free, and a total bitch to comprehend. He would regularly produce miraculous results. We worked together for almost 27 years.

I guarantee that a lot of folks here would call him a “bad coder,” because they would have difficulty easily understanding his code.

I find that when people talk about “good,” they emphasize traits that they, themselves, have, and disparage traits that they don’t have.

In the aggregate, results matter, and “results” are more than just getting today’s goals accomplished. It would be nice if that were the only concern.

For example, I ran a shop, where we maintained a huge legacy codebase of C++ image processing code. We had to maintain it, ourselves, as well as train others to work on it. This meant good documentation, good code structure, and good foundational substrate.

Introducing new coders to our codebase meant immersive training. Japan regularly sent folks over for months, to learn our code. These were top talent. Just about every one of our Japanese engineers had at least a Master’s degree in Engineering. It was a marquee corporation, and employed top-shelf engineers.

That’s quite different from hiring bootcamp-trained JS programmers, and expecting them to maintain Swift code. I know many people that insist that “any good engineer” can learn any language in a couple of weeks.

I’ve been at this game for a while, and have worked in quite a few languages. I’m smarter than the average bear, and have made fearful messes, because I didn’t understand the tools completely.

I have found that I can learn about 75% of a language quite quickly.

That other 25%, though, could take years, and languages seldom stay static, so I’m constantly catching up on the latest stuff. It also includes style, which is often an artifact of understanding how to use the language properly.

Also, learning a language is only part of it, as the APIs and SDKs are even more important. Learning those can be difficult, and I have often had to throw away years of work, when an SDK is swapped out. I’ve been writing Apple software since 1986, so I’ve had to do that a number of times. My first Apple code was in procedural Pascal and 68000 ASM. Adobe Photoshop is probably one of the oldest codebases still in use, and it started off as object Pascal, using MacApp 0.9 beta.

Tom Knoll was definitely top-shelf, and I was tasked with adapting some of his code for use in a different context, back in the 1990s. It wasn’t easy, but I did it, and learned to be a better coder, as a result.

Over the years, I have changed my opinions and points of view; frequently by screwing up, and also, by taking the time to understand code -and not just code, but also the reasoning-, of talented predecessors.

I remember once, hearing someone say “That ‘cruft’ you’re complaining about, is what I call ‘bug fixes.’”

I love coding, because I’m constantly challenged and humbled. I stand on the shoulders of giants, and am grateful for their example.

[lioeters]

> Tom Knoll

I recognize this name from the screenshot of Photoshop version 1.

https://www.webdesignmuseum.org/uploaded/web-design-history/...

Thomas Knoll: Complete Biography, History, and Inventions - https://history-computer.com/people/thomas-knoll-complete-bi...

Was he an "artisan of software"? I imagine back then most programmers were artisans, but maybe that's because I've only heard of the exceptional ones who made a mark in history with innovations that require an artisanal approach and not by mere "replaceable people".

(That term makes me throw up a bit, it's an insult to our humanity. I understand businesses and factories need replaceable people, but nobody wants to be one. Besides, if they're so replaceable, "AI" and robots will replace them in the near future.)

[ChrisMarshallNY]

He’s the original author of Photoshop, along with his brother John, who used to run the ILM Effects team.

I saw Photoshop before Adobe brought it. It was running on a Mac II, in a hospital, in Ann Arbor. Back then, it was still his thesis project.

I have no idea if he was an “artisan.” We never really thought of ourselves in such terms. Software was much more of a fun game, but the introduction of huge piles of money changed everything.