121–130 of 210 posts
In reality most of the world operates somewhere between “we’re a factory” and “we are unmeasurable Picassos.”
It’s not a huge stretch to combine thinking that “software is unpredictable” and “people pay up for predictability” so we should still try to tilt that way.
Programming is still a craft, not engineering, or manufacturing. A software house should work like bespoke tailoring, or fine cabinetry, or glass blowing. There's still no better training for programming than the equivalent of master/journeyman/apprentice. Apologies for the gender specific terms, but they are specific to how tradespeople operated from medieval times. The worst thing to ever happen to the practice of…
I've been in tech long enough to remember when you had to carve literally every line of code out of the firmament of the heavens to get anything done. Today the bulk of technical work is plumbing together literally millions of lines of "free" (as in freedom and beer) code to get some behavior that checks all the requirements boxes.
Going from the post some more, modern developers are more akin to line cooks that put ingredients together. There's value to that skill, but it's a reduced value as its easier to learn to plug together APIs than to craft a cache aware data structure and reduce the big-O of some algorithm while fitting it into limited RAM.
In most restaurants line cooks are almost a commodity (even the sous and executive chefs are to a point), customers don't know if the cook from yesterday quit in a rage and a new guy got picked up this morning who had also quit in a rage from the place next door. Follow the recipe and you get the same product to the customer.
News for the tech folks here, line cooks (even experienced ones) make shockingly less than the average fell off a bus tech-bro with a couple bootcamps and a github repo.
The average developer is today thousands of times more productive than the developers from 30 years ago because they don't have to build the ingredients anymore -- the industry is well bootstrapped by now. But if some future Co-Pilot LLM can turn one developer into 4, and effectively "auto-plumb" with minimal human direction then...
Consider the humble file copy. Or “automated scribe” if you will.
Copying is automated to the point where the enormous amount of copying our systems do has becomes invisible to us - and also lost as a point of economic differentiation.
And it’s meta useful! All our copying programs are themselves easily copied - with the same algorithms!
The point is that software writing, like mathematics, will always spend its time futzing around the edge of the known and unknown, because every area that gets fully known/characterized will get automated in a way that both solves that problem for everyone and scorches the economic earth of that activity.
Software work will always include an element of quest (research) into the unknown, in search of riches (economic value), in some aspect, whether that new area is glorious or tragically mundane.
Whatever area of software work a manager without software expertise can do themselves automagically, is like a fruit tree tamed so that it is easy to pluck fruit from, because it no longer has fruit.
The manager would no longer be doing anything differentiated or valuable if their problem statement wasn’t upgraded back into difficult to automate territory requiring pesky creativity and expertise.
Earlier quoted context omitted.
> Programming is still a craft, not engineering, or manufacturing. Programming can be engineering if you know how to do it. Engineering is, in a nutshell, a set of principles you learn and apply, and never deviate from , in work and life . Engineers always deliver the highest quality. Craftspersons do not know these engineering principles, or they disregard them. They invariably deliver faster than engineers, and the…
what are the engineering principles of software? does team A agree with team B what they are? is there alignment between academia and industry? Electrical engineering has Maxwells Laws and math. What is the math of software? Do teams A and B agree?
Earlier quoted context omitted.
>The whole point of... there are many things that in theory have a particular point but that when put in practice most often do not have any point at all - in such cases opinion seems to divide between those who complain that the people who put things in practice do so incorrectly and those who feel that if the practice when implemented tends to be wrong then it is the fault of the theory itself. I personally hold wi…
The theory of identifying something as being shit and then removing it is a bad thing?
Earlier quoted context omitted.
Our team had so many planning poker sessions where we spent 12 people * 2 dev hours trying to figure out whether stories were a 2 or a 3, management finally said it is always a 3. We were literally spending more aggregate time trying to decide effort, than the actual effort it took to complete these tasks. 2 and 3 are equal. 5 and 8 are equal. The question is simply "Is this a couple days, the whole week, or the whol…
The only reasonable estimates, ever: + That's trivial, it will be ready for testing before lunch. + I know how to do that, should be ready tomorrow/next day. + I can see how to do that but there are lots of other constraints - at least a week, might be more. + It's a big project, needs more planning and specification before it becomes a series of estimable tasks. Let's do that. + That breaks other things we care abou…
Earlier quoted context omitted.
> Programming is still a craft, not engineering, or manufacturing. Programming can be engineering if you know how to do it. Engineering is, in a nutshell, a set of principles you learn and apply, and never deviate from , in work and life . Engineers always deliver the highest quality. Craftspersons do not know these engineering principles, or they disregard them. They invariably deliver faster than engineers, and the…
what are the engineering principles of software? does team A agree with team B what they are? is there alignment between academia and industry? Electrical engineering has Maxwells Laws and math. What is the math of software? Do teams A and B agree?
Abelson and Sussman wrote SICP to illustrate the principles. Everything else in SICP is some means to that end.
They reveal that SICP is about engineering in the Preface to the First Edition:
> The techniques we teach and draw upon are common to all of engineering design. We control complexity by building abstractions that hide details when appropriate. We control complexity by establishing conventional interfaces that enable us to construct systems by combining standard, well-understood pieces in a "mix and match" way. We control complexity by establishing new languages for describing a design, each of which emphasizes particular aspects of the design and deemphasizes others.
I think - and it's only a think - that the author has ignored that a large part of what used to be called technical work is now commodified. I remember when a mail merge literally meant printing out lots of address labels and then manually sticking them onto a letter & envelope. Word 2.0 (?) solved that problem for the 1990s and MailChimp has commodified it for the 21st century. Double-entry book-keeping was technica…
What you say is true, but the amount of "grunt work" is not constant over the years. In fact, I think the amount of "grunt work" in teh tech industry is just growing and not shrinking; I think the following look is quite obvious: - amount of current grunt work: X - new tech Z appears that makes X be reduced to 0.1X - at the same time Z enables new ways of doing things. Some things become grunt work because they are a…
If you wanted to have a simple database application in the 1990s, Delphi, VB6 or MS-Access were most of what you needed to get it done. The UI was drag and drop, the database was SQL, but you almost never touched it, mostly it was wiring up events with a few lines of code.
The work was commodified out of the way! Domain experts routinely built crude looking but functional programs that got the job done. It was an awesome time to be a programmer, you just had to refactor an already working system, fix a few glitches, and document everything properly, and everyone was happy.
Then everyone decided that all programs had to work on Steve Jobs' magic slab of glass in a web browser connected through janky Internet, and all that progress was lost. 8(
Earlier quoted context omitted.
The problem is that beyond the boilerplate we aren't solving commodity problems most of the time. If you've worked in the same field long enough, you'll see that things certainly rhyme, but everyone has slightly different business requirements. At each level of the stack this grows, and so in total there's a ton of non-commodity, bespoke work to do. That's why no two products are exactly alike and we don't just have…
Unless you're SAP, you always need to customise whatever you build for every customer. You can have reusable components, but a full one size fits all solution is really hard.