Interesting thing I see is that LLM slop generators are actually quite efficient at generating documentation, both for the end users and for developers, and like human generated slop-docs, the more cycles you put into review and refinement of them (both human guided and LLM self-review/refinement) the better quality you get out. Investing even half the person-hours in LLM generated documentation generates higher quality, more complete, better organized and more readable documentation for me than "working with a team" of writers who all have to meet and re-meet and explain and re-explain ad-nauseum until we're all sick of the process and late for delivery of the documentation products.

When this documentation investment is made in the code, some remarkable things come out like: a project co-developed with Claude in Python took 10 interactive days to make. At the end, the Python was performing fine but a little on the noticeably slow side, so the LLM was told "do it again in Go" and 3 days later with very minimal prompting, the whole thing was re-implemented in Go, running 10x faster, and flawlessly performing the same functions which were developed in Python in 10 days - I believe precisely because a significant part of the Python project was: documentation of requirements, design specifications and automated tests.

You missed the documenting the code

Your words.

As for your job title, don't take this badly but "Systems Architect" is not at all the same as "Technical Architect".

If you're actually designing or at least tuning software development processes and coding standards across multiple teams (so, not just optimizing how teams work but also optimizing cross-team work), you're a Technical Architect.

A Systems Architect, when the title is properly used, just means that you're designing software whose operation spreads across multiple platforms (so, for example, multiple tiers in a multi-tier system).

Also there is quite a range in Systems Architect - knowing how to code in two or more platforms (say, STM32 and some Android, to make a bit of home electronics with a microcontroller be controllable from a smartphone) is not at all the same as knowing how to design a high-performance distributed system running in multiple machines, integrated with multiple external system working for ten/hundred of thousands of client front-ends and supporting things like Distribute Transactions so that any failures don't leave half-complete operations.

You can be a Systems Architect and be isolated form most of the concerns of the software development out there. especially if you're a team of one developing the software side of products based on some marketing person's idea of what customers supposedly want.

Unsurprisingly, Technical Architects are non-existent outside large companies and even there they're pretty rare.

Again, still making my point on Dunning-Krugger.

Oh, they "come home to roost" almost immediately - you just don't see it because whole teams are doing everything they can to hide it or ignore it - nightly manual data update statements, etc.. Here's just one real example.

In my last (read: final) job as a senior software engineer, I discovered dozens of serious problems with the system I was assigned to "maintain". They ignored all of them - wouldn't let me fix anything. Meanwhile I was responsible to solve production problems on the daily (duplicate data, insert failures, performance slow-downs, etc).

It wasn't long before the fact those problems weren't going away that they became problems I "caused". Meanwhile, all the fixes I wanted to make were ignored. I had one problem I dissected and and gave my boss a brief write-up of the scenario. He told me I needed to do deeper analysis. When I came back a few hours later with a considerably more detailed explanation, he didn't read it and complained of a "wall of text", which he literally told me to write. Then he created a random-number hack to "fix" the problem.

They did not grasp the concept of data normalization and primary keys as they had one particular table that represented two levels of detail (for example, account -> order). They put both in one table and had a code based special update to the "account" number so they would not get a PK violation rather than just fix the data structure.

They had as single database connection open all the time to handle all inserts in a singleton service, then launched as second one on the same database to process messages faster - and couldn't understand why it didn't double performance.

The main routine had a cyclomatic complexity of 360! I shit you not! And everybody agreed it was "95% working" even as we continued manually fixing (the same) problems daily.

Week after week, the customer (internal) would raise more data issues as "new" problems. I'd routinely ask two to three questions about the data set and explain that's the same problem that's been going on for six months, and if we could just get my PR reviewed, we can test it and deploy it.

All these problems were in a single service.

I was let go not long after the 1 month probation they soon initiated and told I was not performing at the level of a senior developer.

This is how delusional these people are. They refuse to acknowledge their flaws even after hiring someone specifically to solve them. They blithely call their monstrosities "successful" while committing many staff to late nights and weekends "managing" it.

Right, you're a little more than a seasoned programmer, buddy. You are extraordinary.

You can't expect "an operating system" or "a compiler" to be the bar for "doing anything 'serious'" 😂

Don't take this badly, mate, but you sound like me when I was a "kid" thinking I was truly the shit for all my technical achievements as a self-taught programmer.

Absolutely, really impressive 1 in a really-big-number kind stuff, just the most pure technical track imaginable and not the same as understanding software development the process as whole, at all.

Decades later, 3 countries later, several industries later, various different environments and kinds of projects later and all sizes of company later, I've figured out that they pay us the big bucks to make software for OTHER PEOPLE, to serve THEIR needs not ours needs and certainly not for our personal enjoyment, though a good dev will always find some enjoyment in cracking complex problems, IMHO - from were a fuckton of constrains and dependencies on what and how you make it and whom do you have to work with are born - and if you want to achieve something that's great in more axes of greatness than just pure technical impressiveness you need to actually learn how to effectively work in a team and with other teams even non-technical ones, including, beyond a certain point of experience, how to empower other more junior people in your team rather than just be pissed off at how little they know.

(And I don't mean going into the Management track, I mean staying the Technical career track and still progressing as a Software Engineer).

And don't get me started on the engineering-style concerns of software design around software live cycle in production and how to prepare for expected future directions of change.

Mind you I've crossed paths over the years once or twice with people who never moved beyond "technical excellence" as their one and only metric for software development (typically "rockstar coders") and they were invariably miserable people who bitch and moaned about "lusers" and how other developers don't know how to use the (not really properly designed for robust usage by people that can't read your fucking mind) libraries they made.

Unless you find yourself a nice niche where you can be a solo rockstar hacker, technical excellence is only a good software development metric up to maybe the 5 years experience mark. Beyond that, unless your career has stagnated you're supposed to be delivering the results the customers need to the customers and doing so in complex environments in cooperation with various teams, some of whom don't at all understand most technical language and certain don't have a fucking clue what "pre-emptive multitasking" means.

I consider myself as a seasoned programmer.

Is that hot pepper, salty, or both?