The end of "Just ask Sarah"

Simon should ask Sarah how to write an article without relying on an LLM

As the 'sarah' for an org I'm golden handcuffed to, avoid becoming the 'sarah' at all costs it will cost you so much in your career. I am a founding engineer self-taught from it/software security to full stack dev, and I pushed so we aimed to higher better engineers than myself. When they came in it was a full rewrite, a new abstraction and going down the same paths I learned the hard way not to go down. I was pushed out of enforcing hard-earned business logic, and we are still paying for it. Everywhere from not accepting the inherent complexity of the problem and over simplifying software to trying to get same features we had from 3 years ago. This then has made me the scapegoat for why the new engineers made xyz decision, and was the one in charge of fixing the shortcuts, bugs and workarounds. I have received promotions for this to be in charge of the veterans that didn't listen to me, whom still don't until it's a fire drill. Joke among colleges is I was the first 'agent' our company had, endless work, just enough authority to do current task, not enough respect/authority to solve the symptom. I understand this is also a failure of my office politics and am improving, however its hard to balance blunt productivity, slow careful positioning and letting people struggle with items I don't recommend until circle back.

Much appreciated! Thanks for the blog around ADR, I didn't know there was a full ecosystem for the approach and the AI tie in will help me sell the process

> founding engineer self-taught

This is such a toxic combination, becuse it requires significant people skills to get out of the "the kid who learned everything here and is grateful for it" and get proper respect as a professional. At some point the only option is changing jobs. I've seen companies matching your offer, finally realizing you actually have value in the market, but don't count on that, don't bluff.

I too ended up as the "go to guy", partly because I had a lot of enthusiamsm for my new job, and partly because the talent pool there wasn't very deep (or maybe they were smarter than me). It's fulfilling until it becomes unrewarding, I had to move on after almost 5 years. Still did consulting for them ocassionally for a couple more years.

>None of the three can easily be captured in code, but are trivial to capture as documentation.

Posts like this frustrate me. Not because of what they ask, but because of what they incorrectly assume. They assume that documentation can provide enough context, and that human knowledge is not needed.

Every bit of written documentation can and will be misinterpreted. And perfect clarity is impossible. A well-written ADR does not eliminate all ambiguity, because there is too much cultural context around the writing of the ADR that attempting to read it from some other cultural vantage point leads to bad assumptions. We can find this basic lesson from reading law (2nd, 14th amendments to the constitution), history (what did happen after Muhammad died?), philosophy (what in the world is Plato's cave talking about?), or theology (how should we translate Ephesians 5:22-33 and what does that mean) outside its original context with other people.

Just writing things down and thinking an AI is going to later perfectly understand what the intent of the author is... patently ridiculous. I do not intend to dismiss the idea that we should probably document more, but the idea that the AI can just take our documentation and competently understand all the decisions represented in them is ludicrous.