The Lone Developer Problem

While it helps to have other eyes judging your work, expectations can also fade once your relationship with them starts to get closer. For example if you have a relationship with someone where you're both messy, you might be trying to make things tidy for each other in the beginning, but as you start trusting each other and letting your guard down things become messy.

Perhaps something like copilot that focuses on judging you rather than doing the work for you would help. Like a laundry list of areas in the code that are difficult to understand.

You could see the SQL Server 7 era database with tables names taken directly from AS/400 mainframe fixed field width text files. Then you could see the mid-to-late noughties era SQL Server 2005 tables, as part of the same actual database, with its more human readable table and column names, but it was effectively a copy of the old database. All the business logic was triggers and sprocs.

And then the latest iteration, which I was working on, had been broken into "micro"-services, with our service using a Couchbase cluster (which, by the way, was a bag of spanners, and which I will never use again if I can possibly help it) to store yet another partial copy of the same data, and then all the business logic at the "application layer" in the closest thing I've ever seen to an actual seven layer architecture. They were pretty keen on enforcing those layers so what you had was just a ton of boilerplate function calls. The cognitive load of understanding what was going on was completely unnecessary for a system that basically just stored names, email addresses, addresses and phone numbers. Actually it didn't store addresses: it stored references to addresses that were stored by a different micro-service. These kinds of decisions meant that most function calls that actually did anything were also RPCs. You can imagine how this all performed.

Latterly I discovered that the blasted AS/400 mainframe system also still existed when I had to work with some files it was spitting out, and had to write an EBCDIC to UTF-8 converter (not actually difficult at all) to do so with 100% reliability.

The main reason for all of this was dependencies: to retire any given iteration of the system you'd have to migrate all its dependencies (of which there were many) to use the new variant. This sometimes meant we still had to sometimes extend the capabilities of the old versions of the systems, even though almost nobody understood them. So yours truly ended up having to write a stored procedure that updated a bunch of both the SQL 2005 and SQL 7 era tables to get a particular business process to work, and this sproc was called by our new microservice.

Even with the number of people they had migrating dependencies was a huge undertaking that they were only just starting to look at when I decided to tap out. An interesting project and a valuable experience for someone, certainly, but something I realised I didn't have the patience or fortitude for. They weren't idiots though: they knew they had problems, and that they were being choked by complexity, but there's no easy route to getting out of that kind of situation.

But, as you point out, microservices are the result of Conway's Law and shipping your org chart, not necessarily the best way to build software all other things being equal. If your org chart fits comfortably inside a broom closet, then maybe you're not quite ready yet for microservices.

> An abstraction that omits important details is a false abstraction: it might appear simple, but in reality it isn’t. The key to designing abstractions is to understand what is important, and to look for designs that minimize the amount of information that is important.

- write documentation upfront (with Hugo or something like that) to explain what I'm building, why, how to use and/or compile it, and how to test it. i do this before i lay down any code. this also helps me re-justify the time investment i'll be spending on writing the thing. (it is much much easier to maintain documentation before you start coding than after. once you're in the zone, you're in)

- write behavior/end to end tests that describe what major components of the software will do and how they will interact with each other. these tests usually change, but I consider this a second layer of documentation

- make code as readable as possible, i.e. small functions, high modularity, reasonable var names, etc. i also use linters heavily.

- i try to break up major pieces of work into pull requests despite me being the only contributor and explain what happened and what the work introduces within them. i'll also add comments to sections of the code that don't make sense. i use PRs for this instead of git commits or (only) comments because i've found them to be much better at digesting large codebases, and they are great spaces for discussing changes within context.