The Programmer Identity Crisis

Full disclosure: I am old.

When I started programming for Corporate™ back 1995, it was a wildly different career than what it has become. Say what you want about the lunatics running the asylum, but we liked it that way. Engineering knew their audience, knew the tech stack, knew what was going on in "the industry", ultimately called the shots.

Your code was your private sandbox. Want to rewrite it every other release? Go for it. Like to put your curly braces on a new line? Like TABs (good for you)? Go for it. It's your code, you own it. (You break it, you fix it.)

No unit tests (we called that parameter checking). No code reviews (well, nothing formal — often, time was spent in co-workers offices talking over approaches, white-boarding API… Often if a bug was discovered or known, you just fixed it. There may have been a formal process beginning, but to the lunatics, that was optional.

You can imagine how management felt — having to essentially just trust the devs to deliver.

In the end management won, of course.

When I am asked if I am sorry that I left Apple, I have to tell people, no. I miss working at Apple in the 90's, but that Apple was never coming back. And I hate to say it, but I suspect the industry itself will never return to those "cowboy coding" days. It was fun while it lasted.

100% agreed. It’s just full of business assholes and vibe coder script kiddies now. Everything has turned to shit.

I started around the same time. No unit tests but we did have code reviews because of ISO 9001 requirements. That meant printing out the diffs on the laser printer and corralling 3 people into a meeting room to pour over them and then have them literally sign off on the change. This was for an RTOS that ran big industrial controls in things like steel plants and offshore oil rigs.

Project management was a 40 foot Gantt chart printed out on laser printer paper and taped to the wall. The sweet sound of waterfall.

Try game dev. It's still like that today.

> And I hate to say it, but I suspect the industry itself will never return to those "cowboy coding" days. It was fun while it lasted.

I don't think the industry will return to it, but I suspect there will be isolated environments for cowboys. When I was at WhatsApp (2011-2019), we were pretty far on the cowboy side of the spectrum... although I suspect it's different now.

IMHO, what's appropriate depends on how expensive errors are to detect before production, and how expensive errors are when detected after production. I lean into reducing the cost to fix errors rather than trying to detect errors earlier. OTOH, I do try not to make embarrassing errors, so I try to test for things that are reasonable to test for.

Back when I started in the late 2000s you had much clearer lines around your career path and speciality.

There was a difference between a sysadmin and a programmer. Now, I’m expected to be my own sysadmin-ops guy while also delivering features. While I worked on my systems chops for fun on the side, I purposely avoided it on the work side, I don’t usually enjoy how bad vendor documentation, training, etc. can be in the real world of Corporate America.

Depends. I see the teams around me slowly being corralled like cattle, no longer doing the corralling. My own team is still chiefly cowboys but the writing is on the wall and as we grow younger we lose more and more footing in this battle.

Unfortunately, the problem with cowboy coding is that it takes one idiot in the team to ruin it for everyone. As company grows, there are more and more idiots by pure chance, which means you need bigger and bigger walls to contain the blast radius. If you have a team of trustworrthy engineers then cowboy coding is extremely efficient, but it simply doesn't scale, especially considering how difficult it is to evaluate the quality of given candidate when hiring.

I believe that cowboy coding might still be practiced in small companies, or in small corporate pockets, where the number of engineers doesn't need to scale.