> Don't we already have enough gatekeeping in software development?

No. In fact I hope anyone who's actually worked in the software industry would see that we don't have nearly enough!

Look I'll agree with you about the evils of gatekeeping if we're talking about who gets to call themselves an artist or a writer. Those kinds of distinctions rarely create life or death consequences.

But software can. Not all the time, but certainly in medical, airplane control, banking and financial, and many many more areas.

I wish software would take notes from other engineering fields like structural or architectural. Can you imagine an engineer building a bridge who was like "I don't want to do the boring stuff like stress analysis or geological surveys, I just want to make cool shapes and build them!" Can you imagine trusting your life to a bridge built like that?

Software increasingly runs our world and real software engineers who work on things that really actually matter know they have a responsibility to "do all the boring things" because those things are essential to doing their job right. Hearing about major hacks and exploits every day like SolarWinds, Experian, Facebook that expose our personal information and put us at risk makes me feel like we desperately need more gatekeeping in our field to keep cowboys and hackers from getting the chance to get anywhere near these systems.

I've been in this career for 20 years and the thing I learn more and more is that writing code is perhaps the most trivial aspect of what we do. It's everything around it -- the process, the testing, the security, the collaboration and how teams and organizations operate that are the real challenges to be solved. Anyone can hack together some working code. The hard part is the systems and organizational structures in which it operates.

There are plenty of things to work on in software which are of no real consequence, but as the OP is finding it's pretty difficult to find someone who wants to pay you to work on something which has no value. That's called a hobby not a profession.

As important as those things feel after 20 years you must remember you are hired to write code. As easy as code is to write without none of the other processes are required.

If they wanted someone to just write documentation you wouldn't be hired. A technical writer would be.

If they wanted someone to just test you wouldn't be hired. A QA person would.

Same for whatever processes you create. They would hire a process specialist.

Same for project management. They would hire a pmp certified person first.

Same for business analysis and business requirement gathering.

As a developer there are better people to do all of those jobs at better rates. None of them can code. That's why you are hired. If you couldn't do that than your qa abilities don't matter.

Things have changed over 20 years. Not every company has a qa team or bas or support team. So these tasks end up being picked up by the developer. Often if this slows development teams are created of non-developer specialists. Some developers end up doing very little coding because your job is to go to meetings about projects that never start. But you are still hired to code they just need you on standby.

Anyone cannot hack together something that works. Only a developer can. A hacker would find ways to use an existing system in an unintended ways.

Gatekeeping over this makes you more management than developer.

The tao of programming has a different understanding of what a developer is and isn't

https://www.mit.edu/~xela/tao.html

Huh. Plus one to you -- you have meaningfully changed my opinion.

People are better at what they enjoy, but I know very few people who enjoy documentation. I have apent most of my career as what the gp would call a hacker. My redeeming quality is probably my love of testing. I despise formal methodologies and processes, and people who fall in love with tools or languages or language features are hard for me to work with.

I don’t understand that general lack of love for writing documentation. It’s a part I like very much in a project: explaining how it works, why some things are done a certain way, the limitations of the software, the possible configuration options... It’s funto write.

I definitely don't begrudge anyone who likes documentation - but we all have different parts of the dev cycle that we like - some folks love to architect solutions and hate implementation because of the fiddly bits and details - other people dislike the stress of having to come up with overarching approaches and get analysis paralysis but when it comes to splatting out the vision into code it's meditative. Still other folks love to break things and enjoy needling edge cases in unit tests (if you find one of these or are one of these - know their value, they are a hot commodity). Then other folks love the teaching/explaining part that comes with documentation.

I think that there is a way we can improve as an industry to let more people specialize into their niches (which would move us closer to a factory/assembly line sort of setup) but right now most developers are artisans that receive some vague ticket and produce code and everything for it as a result.

I appreciate the validation, as much as I like to see things eork, I also love to break things. Pathological unit tests are fun, but the real low hanging fruit is in finding how two services implemented the same service contract with different assumptions.