Today I want to write about Architectural Decision Records and why everyone should be writing them, all the time. If you’re like me, you looked at the repo link and thought “dang, that’s alot. And everyone has opinions on them.” And I think you’re absolutely correct, and therefore you’ve already put ritual and taboo around them that you’re also thinking you don’t need in your life. But hear me out, I think the concept of the ADR needs to be less formal, and more of an every day occurrence.

Something I’ve been more and more aware of lately is the tendency of engineers, good engineers, to over complicate the hell out of something. Is it a product of the time they were working? Or is it something else? Seeing engineers come out the other side of the age of monoliths, I wonder if this is a major contributing factor. It could be, old habits die hard. Before we had “the cloud”, you had to build your own queues, callers, etc.

The two work types that I see are odds more often than not are the business projects and the internal projects. Why can’t we easily integrate these two types of projects into a single roadmap? What I think is the problem is product and engineering see two very different views of the code. Most people think code is a stable, structured thing, like steel in a skyscraper. But that’s where everyone is wrong.

Not posting anything of interest this week. Most of my energy is going to designing a new project I’ll quickly note that I’m in that weird spot between projects. The go parsing experiments project is done, with pretty good results given my limited knowledge of go. Hopefully this pattern can be helpful to someone in the future. The space between projects is weird to me, and I don’t 100% like it.

I messed up. Full stop. I had planned to write an article about basic coding. I had some idea in my mind, driven by rage, but I did the thing I call people out for: I didn’t write down enough context for myself to come back to that article. I wrote a few sentences, but I don’t know why I was writing it. So today I’m going to write about the importance of good note taking.

I was recently asked to review a proof of concept for a new design. It was frankly, a mess. The core tenet of this design is that it tried to solve problems the team has or may encounter. Ever. Full stop. The day after I was asked to look into a legacy system, written by someone completely different. It suffers the exact same problem, but this one was “successfully executed” and now contains a confusing net of data that will frankly take some of the best minds a long time to decipher what’s going on.