Oddbean new post about login | logout The trend is, write code, explain how it works later. If developers want to take themselves seriously I think they need to become engineers and practice design and design documentation, including writing specifications and publishing them. This is non-negotiable in many if not most corporate environments. It's not easy but you can't expect other engineers to build other implementations by reading yours. 1. because reverse engineering is a pita and not a proper way to implement a spec. 2. because often, they care more about getting attention for their "product" regardless if others can build on it. 3. they have a head start for funding and attention. Specifications have no wow-factor, and allow others to "take credit" for your work by implementing it. Upside-down incentives I guess.
Lol, yes, I naively tried to learn more coding by looking at nostr "examples".
“ because reverse engineering is a pita and not a proper way to implement a spec. “ 🤣 Hence why some of us exploit it for all it’s worth. Enjoy the show. 🤘
This is non-negotiable in many corporate environments because of higher ups needing assurances that things are going according to plan. Not because taking this approach builds good software. Where I work, the higher ups are always asking for requirement specs and design documents and I sink so much god damn time writing these while the implementation is already being written. By the time I finish a draft of a doc, the implementation is out of sync with the spec and it needs to be updated creating more useless work. The higher ups truly believe that specs are driving the implementation while all the devs laugh (and cry) knowing our code drives the spec. And this isn't just a me problem. Even our most senior engineers know this and are constantly updating the specs and hate doing it. Because they know its not possible to think of every little thing before starting to code. This is a garbage take by the kind of people who probably also believe having doctors, engineers, lawyers pass an exam and are certified means something. Its all performative, we're all hairless monkeys figuring it out.
Also difficult to tell if a solution actually solves a problem, and elegantly, if there's no spec, because the implementation is noise.
There's just something that really bothers me about: to get the benefits of this technology "Simply install my software" "Simply install my software". No, let me see why the technology makes sense. I have multiple layers of DNS Servers that are configured in a specific way for my "data center" I can't be replacing all of my servers with yours. I will NEED to make my own server/library whatever in order to use it an be compliant in my network. Some of us have big labs to run.
that's why complex languages, complex build systems, and complex (read: dynamic linked) libraries don't really help anyone that's why i say "on a long enough timeline, everyone becomes a #golang maxi" it satisfies all of these requirements, and you just made it clear why they are so important
I call that agile
You're going to trigger @Silberengel
hahaha fuck agile the biggest problem in software dev is architects, people who know how to keep features down to a small enough size that the work can be stable at the prescribed deadline at 3 years full time i started to get a bit of a grasp on architecture and i feel like i can pretty much be given a job description now, and within a couple of days tell you how long it will take, how many people it will need, and what features probably will need more time software architecture is like building architecture but different... instead of load bearing requirements and foundations and whatnot, we have feature counts, which have trees of features under them, and you have to elaborate them down to a certain depth to actually get the picture of how much is involved people and time are the main resources, as distinct from materials and labor and equipment... in my recent work i have also discovered that it can slow things down a lot if it's not easy to coordinate people's days to each other, remote work is really hard to do if people aren't "excessively" chatty about what they are doing because you can only sync up progress and deal with problems if people TALK ABOUT THEM anyhow maybe some day soon i'll actually get to architect for something bigger with more people, but for now, just continuing to do my own thing and notice the features and time involved so i can use this info later and to help my own work in the meantime