I want to start off by saying that this post is 100% about me; I’m making no attempt here to draw any parallels with anyone else or any conclusions about how anyone else can or should relate to tech work.
I’ve been a sysadmin/SRE/whatever for basically my entire working career, but recently (late 2021) I’ve found myself back in more of a dev role and I’m not a big fan and I’m trying to explain/figure out why. I like coding (I have taught myself many programming languages in my spare time and am currently a big fan of Rust) but I do not like coding for a living, and I think it’s not the coding I think it’s the software engineering.
A particular event that stands out to me on this topic is being asked to review someone else’s work when I arrived on a dev-oriented team and he started by showing me these vast documents he’d written that described the requirements of their system, the database structure, and the API endpoints and all possible valid calls to them in detail. Complete with diagrams in several places. And I was like “Oh, right, this is what a proper software engineer can do”, because the idea of trying to do that work that he was so proud of just filled me with horror.
And that’s the big difference: there’s a bunch of things that real software engineers are good at and often seem to enjoy that just bore me to tears. Sometimes very nearly literally.
I’ve had a really hard time characterizing what things, though; I think the short version is something like “I am a man of action” (cue Princess Bride reference). I want to do things that make tangible changes within a fairly short time. But having mostly failed to come up with a generalization, here’s some lists instead:
Tech work I enjoy, with a slight emphasis on things that involve coding or coding-adjacent work (as opposed to work that is purely about maintaining or connecting together extant systems, which I almost always enjoy):
- Things users are actively waiting on. I find it strongly motivating, and satisfying, to complete user requests.
- Small pieces of work; I am happiest when I am working on tasks that take two days or less. I’m just a really big fan of frequent success. This is directly related to user requests, as those are often quick turnaround.
- Problem solving, very much including debugging. “This code isn’t working right; I run it like so and I expected X to happen but Y actually happens, figure it out” is work I will always be happy to do.
- Adding well-understood functionality to an already extant code base.
- Figuring out how to do end-to-end tests of a system. I tend to find unit tests goofy because as an SRE I’ve seen many, many times when “this library is thoroughly tested and working perfectly” has no effect on the failure of the overall system.
- “Enjoy” is perhaps a strong word, but I am perfectly comfortable producing procedural documentation, and often am quite good at it. By this I mean documentation that describes a specific procedure/process; “here’s how to get started with this library”, “here’s how to use this tool to frob the wuzzle”, “here’s how we perform our monthly system upgrades”, etc.
Tech work I actively dislike, that doesn’t seem to bother the good software engineers around me:
- Green field design work. Just, at all. To be effective at design work I need to be dealing with a system I already understand and know where the problems are. Sometimes that means that I can be effective at green field design work if the task is “replace this thing that you understand deeply”, but large rewrites (those that take more than a month, let’s say) are almost always a bad idea anyway, IMNSHO.
- Working on the same piece of code day after day after day. By this I mean something like “Please go build out feature X. We expect it to take you 3 months”. Like, time-between-successes is measured in weeks or months, I guess is the point there.
- Producing large amounts of documentation (but see “procedural documentation” above), especially in advance, especially structured documentation. As a specific example, “hey we just had a great conversation about how the new API should work, please go write up a bare-bones database model, an API endpoint doc, and an entity relationship diagram” would probably not actually result in me interviewing with other teams, but I would certainly consider it, and my productivity would be so low as to be almost non-existent. As opposed to “we just had a great conversation about how the new API should work, go write some PoC code”, which I would be totally OK with and probably decently good at?
- Reading large amounts of documentation (anything that takes me more than about 30 minutes). Note that “reading documentation” and “referring to documentation” aren’t the same thing at all.
- Something hard to explain that I’m going to call “very structured programming”. This only really applies if I’m building something from scratch; matching the style of an existing code base isn’t normally a problem. But, like, if I’m writing fresh code and someone starts talking about design patterns I’m going to have trouble. Similarly, I get the impression that there is a vast body of work out there about the right way to write an API in terms of how paths should be structured and what verbs to use and how to format the documentation and so on, and just talking about it right now is making me want to take a nap. By contrast, “go build an API using this very opinionated library that will make you do it properly” is totally fine, because that’s doing and not thinking/planning/reading.