31–40 of 41 posts
LLMs are trained on data from humans. That means these “code ergonomics” apply equally to coding with AI. So this advice will continue to be good, and building with it in mind will continue to pay off.
The actual hard question is probably making even 10% of such wisdom and good intentions survive when the program is bombarded by contributor patches, or people taking Jira tickets. TFA talks about it in the context of strategy and tactics. Organizationally enforcing strategy would be the issue. And also that the people most interested in making rules for others in an organization may not be the ones best qualified to…
It would be cool to see a linter, or a new language, that makes good architecture easy and bad architecture hard. Like making state machines easier than channels. (Rust is sort-of good at state machines compared to C++ but it has one huge issue because of the ownership model, which makes good SMs a little clumsy) Or making it slightly inconvenient to do I/O buried in the middle of business logic.
I found "A philosophy of software design" to be a well intended but somewhat frustrating book to read. It seemingly develops a theory of software architecture that is getting at some reasonable stuff, but does so without any reference _at all_ to the already rich theories for describing and modeling things. I find software design highly related to scientific theory development and modeling, and related to mathematica…
> related to mathematical theories like model theory, which give precise accounts of what it means to describe something Perhaps too precise? APoSD is about the practical challenges of large groups of people creating and maintaining extensive written descriptions of logic. Mathematical formalisms may be able to capture some aspects of that, but I'm not sure they do so in a way that would lend real insight. "How can I…
The relation between an interface and an implementation to me is very much the same as between a formal theory and a model of that theory.
I agree that in practice you'd want to use heuristics for this, but I think the benefits would be similar to learning a little bit of formal verification like TLA+, it's easier to shoot from your hip if you've studied how to translate some simpler requirements into something precise.
For a book like this you'd probably not need more than first order logic and set theory to get a sense of how to express certain things precisely, but I think making _reference to_ existing mathematics as what grounds our heuristics would've been beneficial.
Earlier quoted context omitted.
I mean, we can definitively talk about simplicity/complexity in a fairly easy way when it comes to mathematical structures or data structures in my opinion. For instance, a binary tree that contains just a root node is clearly simpler than a binary tree with three nodes, if we take "simple" to mean "with less parts" and complex to mean "with more parts". Similarly, a "molecule" is more complex than an "atom". This is…
I think my issue with this generalization is assuming the code itself is where complexity is measured and applied. For example, the Quake Fast Inverse Square Root[1] takes into account nuances in how floating point numbers can be manipulated. The individual operations/actions the code takes (type casts, bit shifts, etc.) are simple enough, but understanding how it all comes together is where the complexity lies, vs j…
I think stating that "more stuff" in the program code and in the spec leads to more stuff to keep track of, and so we want to minimize complexity to maintain tractability?
I found "A philosophy of software design" to be a well intended but somewhat frustrating book to read. It seemingly develops a theory of software architecture that is getting at some reasonable stuff, but does so without any reference _at all_ to the already rich theories for describing and modeling things. I find software design highly related to scientific theory development and modeling, and related to mathematica…
The author is describing less a theory and more a framework or system of heuristics bases on extensive practicap experience. There's no need for rigor if it's practical and useful. I think your desire for grounding in something "scientific" or "mathematical" is maybe missing the forest for the trees a bit. Saying this as someone with loads of practical software development experience and loads of math experience. I j…
It didn't feel like a thought through whole, and I felt somewhat punished for trying to read along attentively.
I also found there to be a frequent conflation of e.g. the notion of modules and a classic OOP-class, to me it seemed like the author thought of them interchangeably.
To me there's enough theoretical computer science that can be used to help ground the terminology, even if it's just introduced cursory and with a reference for further reading. But at least then there'd be more consistency.
I'm not sure I think the book is invaluable, but I think it's a good contribution to the subject.
Earlier quoted context omitted.
> Just taking the notion of "complexity". Reducing that to _just_ cognitive load seems to be a very poor analysis, when simple/complex ought to deal with the "size" of a structure, not how easy it is to understand. Preface: I'm likely nitpicking here; the use of "_just_" is enough for me to mostly agree with your take. Isn't the idea that the bulk of complexity IS in the understanding of how a system works, both how…
I mean, we can definitively talk about simplicity/complexity in a fairly easy way when it comes to mathematical structures or data structures in my opinion. For instance, a binary tree that contains just a root node is clearly simpler than a binary tree with three nodes, if we take "simple" to mean "with less parts" and complex to mean "with more parts". Similarly, a "molecule" is more complex than an "atom". This is…
Earlier quoted context omitted.
Project managers shouldn't be running engineering. They are there to keep the trains running on time, not to design the track, trains and stations. The generally accepted roles are Product decides what we need to build, Design decides how it should work from user perspective, Engineering decides how to build it at a reasonable upfront and maintenance cost. This involves a fair amount of influence, because Engineering…
I disagree fundamentally with the modern division of labor. I’ve been around long enough to understand that it doesn’t actually have to work like this. I don’t think you can be an expert in generic “Product” just like I don’t think you can be a generic management expert. And I don’t think you can decide what to build or how it should work from a user perspective without taking into account how it’s built. In many way…
We do the work, we are responsible for whatever it is. Sure maybe some times you begrudgingly just have to do something you're told, but in my experience there's almost always room for discussion and suggestions. I think most devs just don't care. They do what they're told and blame others if it's ass.
Earlier quoted context omitted.
I mean, we can definitively talk about simplicity/complexity in a fairly easy way when it comes to mathematical structures or data structures in my opinion. For instance, a binary tree that contains just a root node is clearly simpler than a binary tree with three nodes, if we take "simple" to mean "with less parts" and complex to mean "with more parts". Similarly, a "molecule" is more complex than an "atom". This is…
If this is all so easy and obvious, why do all of the tools/metrics that measure software complexity suck?
Books by programming theorists often When they define 'complexity' as 'anything related to the structure of a software system that makes it hard to understand and modify the system,' they miss a crucial distinction: the complexity of a supermarket is not the same as that of a telecom company. The primary factor in complexity is functionality and requirements to implement, followed by non-functional requirements, the…
The problem I usually encounter is that whoever was there before me didn't do this. They just made a solution then added quick fixes until it became a monster, and then left. Now I first have to figure out what the code actually does, try to distinguish what it needs to do from what it happens to actually do, usually write tests because the people who write the kind of code I end up fixing usually don't write good tests if any at all, then refactor the code to something more reasonable.
This can easily take me days or weeks whereas the person responsible could likely have cleaned it up much quicker because they don't first have to figure out requirements by reading messy code. Then again if they were competent and cared about the quality of their work they wouldn't have left me that mess in the first place so I tend to just write it off as incompetence, fix it and move on.