Collecting and curating material is good and we should do it more
buttondown.email
buttondown.email
Is the lack of consensus why we don't have more curated knowledge? Or is the lack of curated knowledge the reason we don't have more consensus?
At risk of being accused of being on the A.I. hype train, it seems like having a writing bot that could distill the important points out of poorly written documents, and state them more clearly would be a huge boon. Hopefully it would allow an iterative process where someone could hone their offering to a point where they felt okay releasing it.
Personally, I like it. For me, there is no better way to achieve clarity than writing about something. So I don’t really understand why they like to avoid it. They apparently value clarity less than I do but that doesn’t explain it. “Everybody is different“ doesn’t really explain anything.
Unfortunately, I think the author is spot on, with the answer to why we don't have such kinds of work available, as he writes: "the work is hard and unrewarding".
Well that's suspicious. That's a sign of something.
Building things with matter needs to adhere to fixed principles corresponding to hard laws of physics. Working with bits is a different ballgame. It's creativity, psychology, improvisation. It's gardening.
> It's gardening.
Let a thousand bad analogies bloom!
I suspect one key difference between software engineering and physical engineering is that with software, you hit “it depends” sooner. The way you design and build a software system is extremely sensitive to the precise details of the problem you are trying to solve. There aren’t a lot of domains where there is One True Way to do something. The job of the software engineer is perhaps less about building the perfect “snap fit” (although it is at least a bit about that), and more about selecting from the vast array of “snap fits” that exist, and matching them to the specific problem.
Except, that's exactly what a whole book on manufacturing snap fits is about. Physical engineering is nothing but tradeoffs and 'it-depends' and that's why you end up with reference manuals on things like snap fits, where the point is twofold: an encyclopedia of the range of possible snap fits and how they can each be used; and some theory to help figure out the appropriate tradeoff.
Software numbers change too quick. The amount of CPUs in a system, the network speed, storage, etc. Why write guides on what tech to choose when the numbers changes so fast?
I think it’s also a sign of our professions immaturity that we don’t write more books like that. We don’t even have good dimensions defined on which to compare approaches.
I'd love a book on "Web Authentication Systems" that is a survey of approaches, real world examples, tradeoffs of different frameworks, core principles, etc.
They can be a slog, but the effort is worth it since the information is reliable.
I want to read the newer RFCs around JMAP next.
There is, at least, a book on writing text editors:
Yes, I am referencing that.
The OP is an excellent idea. But the times we've tried something like it the usual suspects abused it into near irrelevance. The most discussion I see around patterns is "dark patterns" in UX. If we are going to fully succeed the next time we have to find some way of keeping the usual suspects out of it.
Do you know how much Javascript I had to turn on to close your newsletter sign up?
More than I tried, and I tried a few.
I will not read your site.
It has an RSS feed with full articles available. I understand your desire to limit JS.
Case in point: compilers. This is a very well represented topic, both in print and online. But almost inevitably, what you do find in this space are “toy” compilers.
Pascal, for example, is a pretty simple language. By design, and by the nature of how Wirth does things. But slogging through even a full boat Pascal compiler is a slog for anyone. And none of the ones I know of offer much, if any, optimization. In fact most have pretty lousy error recovery as well.
I honestly don’t recall the state of, or how the original Oberon compiler was presented in the original Project Oberon book. And that’s about as close, I think, as you’ll get to a walk through and discussion of a “production” compiler.
Which is what would frustrate this kind of effort in software. Software is hard. The concepts can be straightforward but getting them implemented and a boatload of detail rears it’s ugly head, because while programming and programmers are all about abstractions, computers are all about details.
And those details bloat up the code something awful, to the point it’s hard to see the forest for the trees sometimes. How many times have we seen a snippet of code qualified with “but this isn’t production code, so don’t use this”, and, of naturally, half the plant cuts and pastes it into their next live release.
Mind there is an excellent example of this in action with Lion’s commentary on Unix v6. Someone sitting over your shoulder as you walk through the code. But v6 is stone knives simple, can you imagine a walk through a modern walk through a modern, production kernel with a qualified docent.
There are other examples, Implementation of 4.3 BSD for example, but even it, considering it’s size, is higher level. It’s not the source code.
I have a little program I wrote in Java. It’s a GUI wrapper for a 1000 line fractal generator. It wraps the options and the resulting image. But MY code on top of that is 4000 lines. For a GUI! By God, it must be doing SOMETHING! It was certainly more than I anticipated when I started. “How hard can thus be”.
I thought there might be value throwing up a YouTube going through it all, to show what happened and why, warts and bad decisions and all.
Not because it’s anything special, but it is “done”. It is “only” 4000 lines, so in actuality, rather short. And it’s not a contrived example. It was written to do something, and deal with all the imperfections in me, in the toolkit, and in the “real world” that it operates in.
Plus, as I was writing it, writing this “simple” thing, I was always saying “it’s almost done except for...”. So, perhaps there’s value in a commentary about how that manifest in this little thing.
A lot of sw practices and solutions are in the area of 'it depends'. That is where good (system!) domain knowledge, cooperation and argumentation comes into play.
More often than not, discussions are stalled because of ego, stubbernness, 'i know better', 'the standard practice says...' etc.
What's needed to arrive at good sw is good collaboration. 'I understood we need to implement this or that because the customer needs..., do you agree?' and 'the current system works like this so i would propose... what do you think?'
For some reason, it is hard to have such fruitful fully interactive, open and iterative discussions, which is a pity.