[jagged-chisel]

I have attempted, in vain, to bring this kind of thinking into the companies and teams that I have worked with. They don’t want it.

And in interviews, no one wants a Software Artisan. The cynic in me says that it’s because people want the job security of the typical bullshit position and don’t want anyone upsetting that.

[tkiolp4]

Companies don’t need software artisans. They need replaceable people who can do the job until they run out of investor’s money.

[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.

[WJW]

Not all companies float on PE money.

[Swizec]

The problem with hiring artisans is that most companies need a Honda Civic not an Enzo Ferrari.

If they hire an artisan it’s just going to be frustrating for everyone involved. The business will pay more than the value received and wonder wtf and the artisan will be bored out of their mind looking for fun projects to do.

[zrobotics]

One thing where that analogy breaks down is that a Honda civic is more highly engineered and a more refined product than a Ferrari. The Ferrari makes all sorts of sacrifices for performance and styling, sacrifices such as manufacturability, cost, and reliability. We tend to forget or underestimate the sheer work that Honda engineers spend making a car that is fuel efficient, crashworthy, long-term reliable, and affordable. A civic certainly isn't as sexy as a Ferrari, but stepping back and thinking about the sheer amount of human effort that went into making such a good machine at such a reasonable (compared to a Ferrari) price is astounding.

I would argue that software would be improved if it was approached in the same engineering fashion as a civic or corolla, what we have now is the engineering effort of a Ferrari with all the warts that entails but released to the mass-market. Ferrari can't invest the engineering effort to release as polished of a product as Honda or Toyota, but that's fine since it's a niche vehicle and the buyers accept the tradeoffs since nobody uses one as a daily commuter anyway. But a small team of software developers can release an under-designed product to market and that software is available nearly instantly worldwide with little limits. Making 1M physical items is far more difficult than having 1M users of a program.

[ahoka]

This is a false dichotomy.

[slowhadoken]

McDonalds isn’t looking for a chef.

[jagged-chisel]

Actually, you make a great point: these companies attempt to convince employees that they’re not McDonald’s, when that’s exactly what they are.

And I shouldn’t be falling for it myself.

[slowhadoken]

I’ve avoided working directly for the tech industry. I was contacted by Google and Amazon without ever having reaching out to them but that was right before the mass layoffs. Beside high level proprietary projects I’d rather work for myself doing whatever I want.

[invalidlogin]

Chef?

[slowhadoken]

I guess both work but chef makes more sense.

[rqtwteye]

Artisans don't scale.

[zelphirkalt]

What does scale?

[danielbln]

Pragmatism.