Post

This is a great example. Early career, someone might just consume a database schema, take it as given and code against it. To grow they need to transition from consuming -> critiquing -> redesigning and that happens if you know it, turn it over in your head, and think through could-have-beens.

I like your linked article on English as a specification language I spent a few words on that too setting up under-specification as a problem to later discuss over-specification. I tried to draw an analogy with legalese and the carton of eggs joke.

In order to properly motivate myself to write well architected code, I need the pain of having to deal with my shit architecture decisions. Anything that makes it too easy to churn out boilerplate (e.g llms) makes it way too easy to churn out tech debt spaghetti.

yepppp I 1000% agree I said something somewhat similar recently: bsky.app/profile/full...

gabby@fullmoon.id

Also, for coding specifically, if typing is really tedious **you notice** and that is often the best way to spot an opportunity to refactor and reduce duplicate code. People who type things out have a much lower tolerance for repetition and automate more of their work

yea i feel this. i attribute a lot of my proficiency at programming in general to getting used to environments like text editors without language servers and golfing, going through aoc/codingame, etc. going to look at the documentation is expensive time-wise and time matters, so you learn.

I guess I am a dinasour, this is the only way for me, I try to direct reference the language docs if I can't remember how it's done. The LLM stuff still feels slower, and stack overflow can give you hints, but it is best to know what your code really does

my profs pushed for this alot in 2018. i think it was to help prep for interviews, but it really does help (as much as i hated it back then x3)