Want to wade into the sandy surf of the abyss? Have a sneer percolating in your system but not enough time/energy to make a whole post about it? Go forth and be mid: Welcome to the Stubsack, your first port of call for learning fresh Awful you’ll near-instantly regret.
Any awful.systems sub may be subsneered in this subthread, techtakes or no.
If your sneer seems higher quality than you thought, feel free to cut’n’paste it into its own post — there’s no quota for posting and the bar really isn’t that high.
The post Xitter web has spawned soo many “esoteric” right wing freaks, but there’s no appropriate sneer-space for them. I’m talking redscare-ish, reality challenged “culture critics” who write about everything but understand nothing. I’m talking about reply-guys who make the same 6 tweets about the same 3 subjects. They’re inescapable at this point, yet I don’t see them mocked (as much as they should be)
Like, there was one dude a while back who insisted that women couldn’t be surgeons because they didn’t believe in the moon or in stars? I think each and every one of these guys is uniquely fucked up and if I can’t escape them, I would love to sneer at them.
(Credit and/or blame to David Gerard for starting this.)
The zone has indeed always been flooded, especially since its a title that collides with “integration architect” and other similar titles whose jobs are completely different. That being said, it’s a title I’ve held before, and I really enjoyed the work I got to do. My perspective will be a little skewed here because I specifically do security architecture work, which is mostly consulting-style “hey come look at this design we made is it bad?” rather than developing systems from scratch, but here’s my take:
Architecture is mostly about systems thinking-- you’re not as responsible for whether each individual feature, service, component etc is implemented exactly to spec or perfectly correctly, but you are responsible for understanding how they’ll fit together, what parts are dangerous and DO need extra attention, and catching features/design elements early on that need to be cut because they’re impossible or create tons of unneeded tech debt. Speaking of tech debt, making the call about where its okay to have a component be awful and hacky, versus where v1 absolutely still needs to be bulletproof probably falls into the purvey of architecture work too. You’re also probably the person who will end up creating the system diagrams and at least the skeleton of the internal docs for your system, because you’re responsible for making sure people who interact with it understand its limitations as well.
I think the reason so much of the advice on this sort of work is bad or nonexistent is that when you try to boil the above down to a set of concrete practices or checklists, they get utterly massive, because so much of the work (in my experience) is knowing what NOT to focus on, where you can get away with really general abstractions, etc, while still being technically capable enough to dive into the parts that really do deserve the attention.
In addition to the nice markers and whiteboard, I’d plug getting comfortable with some sort of diagramming software, if you aren’t already. There’s tons of options, they’re all pretty much Fine IMO.
For reading, I’d suggest at least checking out the first few chapters of Engineering A Safer World , as it definitely had a big influence on how I practice architecture.