On Craft
drcathicks.com
drcathicks.com
> I have read a lot of long spiels about craft that frequently end in something like, software work isn’t like other work, and we shouldn’t be judged the same way. We are entirely unique. We are the special ones.
It might comfort the author to know that even within the realm of software engineering, there are insiders and outsiders. Some of the most important engineering work was made by these outsiders.
Growing up poor, self-taught, as the only programmer I knew around me, I felt like an outsider my entire life. When I finally began to associate with other programmers... I still felt like an outsider.
Here were people from structured family units with solid life skills, a college education, large support networks, a lack of systemic trauma, and a fundamentally different understanding of the world. I've begun to find my place in this world, but the feeling of being an outsider will never fully go away.
It's of little coincidence that my favorite kinds of music and other art are often categorized as Outsider Art.
My advice... find a way into that makerspace. Open up a REPL. Software engineering might entail a specific rigid and deep understanding of engineering principles, but software craftsmanship is for everyone. Personal computers were made for the average person to enhance themselves and the world around them, and we should never forget that.
Where do you typically hang online? Maybe we should think about how we could contribute specifically to young rural programmers in similar situations.
one guy who was younger than i was was talking about how he had a degree from a liberal arts college, and had just been coding on his own for a while, and that when he moved out there for work and was interacting with other coders in real-life for the first time (previously it had been only over the internet) he was learning how to pronounce the names of various daemons, libraries, projects, etc., and that he had understood the pronunciations differently when he was physically on his own. in my head i silently said to myself, "this guy is a junior coder and won't amount to too much" and made a note to try to associate with some of the heavy hitters to try and boost my career and status (and i guess if i'm being charitable to myself, also to learn).
that guy left the company maybe a year later. the company he went to, i think he started as a dev, later became CTO, and eventually CEO. while he was CEO, the company sold for over a billion dollars. and even when we were still working together, i did learn quite a few things from him. so yeah, i think it is easy for people to pigeonhole others, or to think that they are in a place of skill that others perhaps can't easily get to, but sometimes that kind of thinking is quite wrong. (also, at his new company he wrote some great blog posts on software development and operations practices that i really enjoyed and learned quite a bit from)
I didn't look down on them, but was heavily surprised to see how much they could teach me about software or work or life.
I don't consider recognising trees as craft... or ride-on mowers as blue-collar... or being afraid of someone on the street at night as recognising the "soon to be broken"... or that "cadence" is a safety measure. It's often the reverse, cadence suggests not stopping when safety/quality is often about anyone being able to stop the line.
As for the "family fixer"... I've known a few and the motivation has not been craft but as an emotional escape. Sit down and talk to your family? Nope, time to rehang all the pictures on the wall. I can recognise their panicked scan of their environment, desperately looking for something that could need attention. I think we often see "craft" type justifications for unnecessary work in software teams that are really avoidance of something more aversive.
Where I find the "fixer" perspective interesting, it's understanding that the world is mutable and that you have the power to change it. It's a more natural human instinct to accept things that are causing a problem. It's not even lazinesses holding people back, it's not seeing the possibilities.
This relatively new attitude creates motivation to even further divest in quality and prefer creating cheap things that break fast, because we won't invest the time and money needed to fix them anyway.
Whether the grandfather was, or would consider himself to be an insider, we can’t glean and don’t know, respectively.
It’s a sort of longing piece, and that’s OK, but not what I expected going into it!
However, it doesn't win me much support, these days.
People like us aren't really what the tech industry is about. I'm not sure that it ever was about it (which was why I didn't append "any more").
There was a fairly decent book, called Software Craftsmanship[0], that I read, many moons ago. I found it comforting. At least I wasn't a complete outlier, even if I was routinely treated with scorn for my approach.
Seriously? I feel for you.
In my experience many companies do recognize tech debt now, and the value in fixing it or implementing it the right way, although that was not so much the case in early 2000s.
That said, many times we do still have to argue for time to refactor vs adding new features.
I think that the best software craftsman is the one that can quickly add features without accumulating tech debt and the best way to do that is to just fix/refactor the other stuff around the feature addition immediately. It seems like the OP's grandpa was that kind of person.
Speaking for myself, I sometimes do take longer because I want to get it right, even if it does mean missing an internal deadline. It has to have the right "smell". I have learned that if we don't do that then, as cruft accumulates, 3am production incidents will be inevitable.
So, do take this to heart: if others did not understand it, it does not matter. You have already benefited from your approach :)
When I write software, I use what I call "Constant Beta." Basically, my software is at a release level of Quality, from the very start. It may be incomplete (thus, unshippable), but what's there, is ready for its closeup (Mr. DeMille).
Basically, before moving to the next feature, I make sure the one I'm working on, is complete. It may require coming back, after other parts of the program are done, but I always make sure that the API is clear, the documentation is done, and things like error handling and localization are in place, as early as possible.
Surprisingly, I work very, very quickly, despite taking so much care. There's a number of reasons, which would require a series of blog posts, but the results speak for themselves.
I have been in engineering situations where it is tempting to fix the loose table leg. The problem is that unless I go in every month and fix it I might be making things worse. What we need instead is a process that solves the problem permanently.
Moreover, it is likely the sitaution is much worse than it appears on the surface. The loose leg is a symptom of deeper malaise. It is likely the kitchen is dirty as well. The leg might be the canary in the mine. In fact the whole organization might be rotten to the core.
The real solution is to buy out the restaurant, fire the management, institute better processes, and then to create a culture that values the longer-term view.
The other approach is to do nothing. Leave the table wobbly to signal to other patrons to take their business elsewhere. The restaurant is on its last legs as a viable enterprise. Best to let economic forces shut it down quickly and without ceremony. Then it can be replaced by something with more solid foundations and firmer legs.
One example we, in our family, like to remember is how he fixed the car during a long vacation trip by his own when the engine suddenly stopped in the middle of the road. He realized the problem and used his constantly at hand pocketknife and a metal can box he found thrown on the sideways to fix the car. The mechanics had hard time to remove the fix in the garage and replace it with an original part!
Sounds like our grandfathers might have gotten along; mine had much the same spirit and ingenuity you described. Hopefully some of that is passed on to us :)
People from that era had to endure a lot of hardship - the depression, WWII. They often grew up on farms. This gave them a lot of experience with fixing and growing things. All around useful skills that most of us don't have anymore.
I'm stuck at home now, with nothing but spare time, so I've embarked on a massive refactoring project... if it works, it'll be awesome... if not, I'll have learned a few new things about the problem domain. The itch that triggered it is simple...
"Almost all of the transistors in a computer, at any given instant, are just waiting"> He had a visual vocabulary that amazed me
> do you know what it is like to make your whole life?
These two lines together hint at a kind of connectedness with the world that I sometimes feel (and observe in certain cases) an acute lack of. I see it in myself and in many people I care about, but also in the archetypes generated by the culture/society I'm embedded in. A lot of the time when I talk to people about this particular thing, they assume I'm being nostalgic, but I don't think so. I think we don't realize how many hard (as in "hard science") truths we really learn from casual observations of the wind and the stars and the trees.
In trying to make my pizzas round, I realize that there's a craft to it. It can't be all that hard since so many people do it, but I haven't got it yet.
Also, cooking is a craft. That's why a restaurant interview for a cook is often "make me an omelet." There are, indeed, some foods you can make strictly by following the recipe, but others take craft.
The craft here is to make it taste special, even for simple recipes like an omelette. That is why the chefs get asked this question.
As opposed to experience with ideas about a thing, models and abstractions and stories and such.
The former is of course infinitely deeper.
The latter, you could make a whole world out of that. And live inside it like a house.
Craft to me implies design, which this essay doesn't touch on much.
> He would point out risky work, bad decision making in the form of shoddy materials or shifting angles. He was offended by the trace measures left in the world that signified short-term planning.
But I definitely agree that the essay has a lot less to do with craft than you might think at first.
It's an investment in saying that the quality matters as much as the function, and in many cases the quality improves the function.