“Code was never the hard part” is an insult to all programmers

[MIGHT HAVE INACCURATE IMPLICATIONS BUT PRESERVED FOR POSTERITY:]

In Germany I don't think that counts. "Software Engineering" as a title isn't regulated (as kcexn is asking for). The German term "Softwareentwickler" more literally translates to "Software Developer" (as opposed to "Ingenieur") but I don't see companies having problems translating that in job posts and even contracts to "Software Engineer". I've never seen "Softwareingenieur" used tbf.

Getting into Germany as a Software Engineer (for app development) is also as relatively frictionless as it gets in comparison to more-traditional engineering fields.

Verdi is the German trade union so they have to make these kinds of distinctions about which professions they can represent. Don't quote me on this one but I think Verdi represents very little of the modern "app development" software engineers. I guess those who work for more traditional German industries like auto-manufacturing can fall under their umbrella.

---

[LESS INACCURATE EDIT AND MY THOUGHTS IN LESS WORDS:]

In Germany "Ingenieur" (Engineer) is a loaded term with legal implications so "Software Engineer" is "Softwareentiwickler" (Software Developer) instead. But really this is an HR sleight-of-hand trick. At the end of the day, getting into professional Softwareentwicklung is the same in Germany as in elsewhere that calls it "Software Engineering" (and IMO is what kcexn was asking about anyway).

So you're saying a lead/manager that recognizes good programmers from bad programmers should be paid the most... rubs hands together

It's bad at anything that still requires constant human judgement. The only reason it can build apps and websites so easily is that human judgement was encoded in that a long time ago in many forms. It's a developed and aged practice.

While I'm sure some people just want to write code for its own sake, I've never met one. What I've seen is coders working in domains that vary in what is economical, coders who have varying understanding of exactly how much rigor is needed at any given time, coders who have quirks of personality that sometimes lead them down unproductive paths. Never have I met someone who thinks the code is valuable for its own sake. But they do misunderstand, or misapply their understanding of, the task before them.

I wanted to make this distinction because it changes the approach to managing communications. And it isn't just coders. Sometimes a manager isn't going to tell a developer "stop trying to hard and just slop it out" because the manager also has a self image that doesn't involve shipping swill to their customers.

And I do think sometimes it really is difficult to know exactly where to draw the line. What parts of the product need gold plating? Where is stress going to appear, what is going to cause unexpectedly annoying debugging? In hindsight you should have spent more time there, not here.

Maybe I've been privileged to work with people who care about real things- I've spent my whole career in relatively small orgs. I've self selected for that.

Actually, now I think about it, I do believe I've met (not worked with) someone who was very into the code for its own sake. This was at a research institution, using Haskell, where "experimenting with edgy functional programming" was, if not part of every project, certainly an accepted and deliberate part of the culture.

A craft can be extremely hard while useful output from it is relatively easy to obtain. Case in point, I used to be a very serious baker. I mean, very serious. It started when I was a child. I made sure I understood things at a molecular level, cared about first principles, redid techniques thousands of times, spent hours on the craft in every axis imaginable. And yet people who baked ten times a year sometimes made better cookies than I did. A friend once made a better carrot cake than mine because she didn't waste time trying to figure out how to "bring depth to carrots." and the many ways of modifying textures. She just picked a very good recipe and had the tastebuds to know it's good enough to make for people.

That didn't mean she understood baking better than I did. If something went wrong, I usually knew why and what to do about it. If someone gave me direction and wild requests, I could get us there, meanwhile she could not. If things didn't work out, her solution was more likely to be "find another recipe"... and finally, the part that "validates" the ego of bakers, if you looked at everything we both made, I'm sure mine was better on average.

BUT... if what people actually value is "who made a great carrot cake tonight?", then yes, baking is easy. All she had to do was find a recipe detailed enough for her and apply it without majorly messing up.

I think that's what the "coding was never the hard part" argument is getting at. The fact that programming has difficulty that people spend decades mastering it, or that the best programmers can do things ordinary programmers cannot does not tell you how much of that depth is actually required to produce the software people value. Which is, tbh, very little.

Anyway, I could spread this analogy further but this is long as it is so I will stop here. It just reminded me of when people accused me of "just knowing how to pick a good recipe" as a way of reducing my development efforts, and it made me laugh.