I agree, I have said it before, ChatGPT is like Photoshop at this point, or Google. Even if you are using Bing you are googling it. Even if you are using MS Paint to edit an image it was photoshopped.
> Identifying that habit as part of who you are is key to it being sticky.
This has always been key to me. I've succeeded to identify myself as a runner, as someone who speaks French, as someone who reads books. But my identification as someone who has meaningful programming side-project, who has a garden and so on is to weak to succeed.
In the same vein, at Volvo's factory outside of Gothenburg they have the obligatory museum. It's just that they don't showcase old, famous models. The museum is entirely built around car safety and how Volvo has worked with it. It is interesting with a company that has been so dedicated to their core values for such a long time.
I think that was a problem with many if not most cars before modern energy-dissipating crumple zones were developed. The front was built rigid to prevent the engine block from entering the cockpit and crushing the driver/passenger (which was a big safety problem at some point) but turns out that too much rigidity wasn't a good idea either…
The way this is told in elementary school in Sweden (source is Swedish) is that the Vasa was too narrrow, given it's height. So then the question is, how much wider should she've been to carry the extra height. Vasa's sister ship, Äpplet (the Apple) had a similar deck layout and was about a meter wider. As a layman, considering the technology at the time, it does not sound so much more wider.
A small amount of beam makes a tremendous difference in hull stability.
Anyone who's had experience with rowing shells will be quite aware of this. Beginner's / open-water vs. flat-water shells differ in width by only a few centimetres, but the difference in handling is profound. Both are unstable to the absolute novice, but even a fairly experienced rower from a wider shell will find the handling of a narrower one much more precarious.
(Both are also inherently unstable with CoG well above midpoint, but the dynamic stabilisation provided by the rower or crew is much more critical for the narrower, and faster, shells.)
>As a layman, considering the technology at the time, it does not sound so much more wider.
Think about the lever arm of that "other half meter" of ship that you're dragging up into the air when you heel the ship over plus the increased displacement of the half meter you're burying into the water.
Remember, ships aren't really subject to huge propulsive forces relative to their mass compared to land vehicles. So something like an extra meter is gonna make a pretty big difference.
And only if by "uses AI" you say it has AI inside the hardware but really it's a network-enabled thin client that calls out to a server wrapping GPT calls.
I once watched a presentation by Dan North where he said that a microservice should never be bigger than your head. What he meant was that all the code for the microservice should fit on your screen and you should be able to put your head against the screen and it should cover the code.
This is probably a common; lisp/scheme type of thought. Dan Friedman
also said something about how he only likes code that he can hold in his head to think about in the shower. I forgot the source, but it's in one of the talks. I think Sussman has also said something similar.
Anything you create in software should be able to fit in someone else's head. I.e., you should be able to think of it as a tractable arrangement of abstractions that let you reason about it in a precise, non-leaky way.
Those abstractions don't just poof into existence after the project is complete, though. You have to design them into the system and communicate them to the people who need them.
The abstractions also need to be precise and non-leaky enough to be useful. One of the most dangerous talents in software is the ability to create the illusion of tractability by using vague language. You can create an absolute mess and then describe it to management in a way that makes it sound well-understood. This is the most lucrative and destructive skill a consultant can have.
IKEA uses acacia for some of their outdoor furniture. From the comfort of my Poäng-chair from the late 80ies I disagree strongly with the sentiment that IKEA furniture scratches easily.
I did a period of two years as the CEO of a smallish tech-company (~ 100 employees, turnover of 15M€) and it was stressful as hell even if we were doing OK financially. The big thing is that you're the last defender, everything difficult or uncomfortable task ends with you having to pick it up, for everyone it's a choice to pass it on to the next level but for you it isn't. This combined with the monthly "grades" in terms of commercial result which was new to me coming from a tech background was tough. In the end I chose to go back to tech but it's not something that I want undone, it was a learning experience and these days I'm a lot more careful to let things slip through to the next layer.
This is similar to the experience that I had with Erlang. After having spent time with it, I was hardly every surprised looking at any code and my brain could deal with the actual problems at hand without having to figure out how to apply what I knew about the language.
Anecdotally, programmer colleagues that view themselves as artists are generally harder to work with than those that identifies as craftsmen. It's generally much easier to have a sound argument about someone's work if they don't view it as their art.
"Craft" is very much an emotional identity and art form, and for many people craft is fun as well - maybe not the exact same emotion, but for me craft is the quiet kind of fun.
I identify as a craftsman but I resonate with the above comment.
Ultimately programming is half technical (what does the computer do) and half human expression (reading and writing code).
The latter [0] is really more of an art than a science or an engineering discipline. Look at all the attempts to prove that one particular way of writing programs is more productive, comprehensible or maintainable than others. They all failed in unique ways, perhaps because human communication is highly complex and contextual. The only thing we all might agree on is "consistency is good".
[0] The former is in my opinion generally overlooked in many fields, even though it's the most measurable. But it is apparently often in conflict with with the latter unfortunately.
