It seems like software development has been a sort of modern-day trade for at least the past decade or two, sort of like smithing was 1000 years ago.
Sometimes people come to you with odd requests, and there's definitely a creative side to the more interesting problems, but there's also a lot of churning out nails and horseshoes. Still, you're unlikely to go hungry.
I like the comparison to organizing a workshop. Everyone has their own preferred environments, editors, scripts, etc. And you'd probably feel as uncomfortable using someone else's .vimrc as an ancient smith would have been in an unfamiliar forge. A craftperson's tools are like clothes; it feels uncomfortably weird to use someone else's.
Software development is a craft. We tend to call it “engineering”, but most of the time, it feels more like plumbing or carpentry.
Just like engineering and it's the reason why bridges don't fall, planes fly and engines work.
There are only so many ways one can design e.g. a DC/DC inverter.
My cousin is a graduate student in electrical engineering doing commercial projects on behalf of the university and half of his work seems to be picking, testing and combining various pieces of off-the-shelf hardware so that they eventually do the thing that's required.
The other day he showed me a ridiculously precise and stable sine wave generator which he ordered specifically for some kind of sensor project.
You can recognize-process sensors that measure the world.
You can train deep and neural networks.
You can manage hundreds or thousands of computers.
You can create web servers, services on Internet.
You can create web clients.
You can create apps for people to use or apps for companies to use.
Each of those areas has their own specific issues, and make development totally different.
To say that software development is a craft because what you do in particular is craft is just not being conscious about the huge landscape of possibilities out there.
I do software development and most of my work and my team's is software engineering.
Well, to be honest, some of my work is actually engineering, but I feel like most of it isn't, and by most of it I mean things such as: adding small features, finding bugs, fixing bugs, dealing with users.
To be clear: a craft is not a "lesser job" than engineering and very often requires just as much ingenuity. My main goal with writing the article is to keep myself honest about what my work is about most of the time and not to think too highly of myself.
Are you absolutely sure that most of your time is spent analyzing and designing and not implementing or doing routine maintenance?
May I ask why the distinction is so important? If I properly understood your article you are advocating for diligently paying off technical debt. In isolation this is desirable of course, but in practice we have to choose trade-offs with other objectives. As the grandparent wrote, the things people who call themselves "software engineers" actually _do_ are incredibly diverse, both in domain and scope (compare a 3-week POC by two people to a 2-year project by a team of 5). Different situations call for different trade-offs and the actual value you add as an experienced developer is knowing how to balance the various aspects, one of which is technical debt.
You are correct. The distinction is actually less important than the main point of the article which is that diligently paying off technical debt in a long term software project pays off because it allows you to move faster.
The distinction helps me being honest with myself about what my role really is, and this means that I am less likely to be overly clever where it is not needed, which would lead to technical debt.
That makes a lot of sense. And I wholeheartedly agree that (in my experience) many long-term software projects suffer from neglected technical debt, resulting in poorer quality and longer development time (and a lot stress of everyone involved).
> To say that software development is a craft because what you do in particular is craft is just not being conscious about the huge landscape of possibilities out there.
The same could be said about software engineering. Not everyone is engineering all the time just because you are.
I want a clean, well organized workspace (or house, or room, etc.) as much as anyone but the process of tidying, or organizing, should not be mistaken for anything other than a time bank from which we make deposits and take withdrawals.
It is possible to keep a space tidy and organized at all times, but that implies constant and immediate reaction to all misplacement and disorganization.
To put it into computing terms, it is the same thing as running a CPU with no cache or a display with no buffer[1]. These things are possible, but they require immediate responses and prioritizing efforts becomes impossible. You simply must deal with these instructions right now.
That's possible in human terms, with physical workspaces, but it drives people crazy and is practically impossible. If you view clutter and disorganization as a time bank, or time buffer, you can make judicious deposits and withdrawals that suit you and your environment.
[1] Yes, you can run a display with no framebuffer - it is called "racing the beam" and is described in a wonderful book about the Atari VCS titled _Racing the Beam_.
The article is about the importance of keeping your code clean. Do you disagree that it's important to keep your code clean?
I'm sorry, I don't see how your analogy with computer architecture applies. Like with all things, knolling can be taken to an extreme, but as I understand it, the idea is to keep shared work stations clean and ready for the next person or yourself and to keep things organised while you're working, in such a way that you don't have to go looking for tools that you need.
As time passes it looks to me clearer and clearer IT is reinventing a huge number of wheels and they all end up less than round.
An organizational leader (head of X, Director, group manager, project manager, team leader, etc) must be neat, tidy, organized. What a shocker, right? But take a loot at your superior's computer screen at work. 278 files right there on the desktop. Many of which have (1), (2) or even (3) in the name. How many unread notifications in his bar? How many tabs opened in his browser for weeks/months?
I'm a Director (of software engineering, not the cool kind who directs movies). I keep no important files on my desktop (usually stupid screenshots to be shared, or quick notes for myself). My email inbox has zero unread messages. I have no unread Slack messages. My directory structure has basically been unchanged since 2002. I backup my files regularly to "the cloud" and to a local drive on my desk. My source code, and some notes, are all in a distributed version-control system (ok, we all know it's Git). I keep our internal Wiki up-to-date as I delete, or archive, items that have become irrelevant or misleading. Some of us aren't as you have stated.
Now, my physical desk at home is a friggin' mess. I need a larger one.
Couldn't agree more. Software development is a craft, not engineering. And a tidy system keep things consistent and it enables us to make changes easily. Well written.
I go back and forth on this. The craft part is important and most of us take pride in that. However, often an engineer's part is to "take the craft out of the job" so that things become predictable and maintainable. Once the thing you're working on is large enough you cannot end up in a situation where everything collapses when the craftsman packs up their saws and hammers and takes off to a more interesting project.
I feel like you are missing the point of this post (or maybe I am?)
I think the point IS that you want things to be predictable and maintainable, so quit writing code that is supposed to be clever more than it gets the job done in a tidy and direct way.
Yeah, but then talking about craftsmanship is not a productive way to get there. Indicative of craft production is that things are unique, unpredictable, take a lot of time, cost a lot, require specialised maintenance, depend on the specific skills of the workers available at the time, and so on. Planning is virtually absent and things happen when the craftspeople think that sounds like a fun challenge for the day.
This is in contrast to e.g. mass production where humans are reduced to replaceable cogs and everything is build from meticulous blueprints by a separate department and planning happens in a waterfall-style way.
Which is in contrast to lean production where small cross-functional teams work on end-to-end stuff from the beginning of the project in quick iterations and with tight feedback cycles.
Yeah, I went back and read it again. What the OP advocates is actually not what I think of when I hear "craft" but actually closer to applied software engineering principles. Or rather: craft at the lower level, creating clean code line by line and software engineering at the higher level, creating something maintainable.
One way is to always keep your thing ready for any change.
Another way is to always wait to improve a thing for change when the change is required.
And the truth is sadly, as is always the case in life, a combination of the two. The experienced engineer can predict which parts need the constant buffing because they'll be on the critical product path and which ones you can let be without them rotting. In fact, that predictive skill is likely one of the top markers of productivity.
If you don't have it, you can probably simulate it by working twice as hard and keeping twice as many things ready, and if you manage to work n times as hard to keep all the things ready, your system will appear to be superhuman. But realistically, you will appear to not have done much critical work because of all the stuff you do, maybe a tiny fraction will be important.
I've been doing a lot of reading about craftsmanship and making things lately, and developing software for about 15 years now. I've found the following books and links to be really well-written and deeply considered covering craftsmanship, skilled work, modern and historical ideas and explorations of the topic, and generally an interesting listen/read:
Cræft, by Alexander Langlands - This is probably the least relevant to building software, but was the first book I read on the topic. It mostly deals with discussions of the history of making things like stone walls, waddle walls, roof thatching, and the like. It's a fun read that I like to put on while I'm working in the yard.
The Craftsman, by Richard Sennett - I just finished this book, and found it to be a fantastically interesting discussion of the idea of craftsmen, craftsmanship, doing skilled work, problem solving and the relationship to problem finding/discovery (this resonated with me as a software developer in a big way) and various facets of all of the above. The author discusses the development of the linux kernel as a reference for madern skilled craftsmanship, which was a pleasant surprise.
My next read is The Nature and Art of Workmanship, by David Pye. It's been referenced by a few other sources that I've watched or read, so I'm very much looking forward to it.
I also really enjoyed an episode of The Woodwright's Shop called "The Spirit of Woodworking", where Roy Underhill discusses (in a somewhat goofy/silly way) concepts like ego, presence of mind, mindfulness, tool usage and jigs, etc.. It really resonated with me, in particular when he discusses ego and how that can relate to what you're doing when building things, as I've found the removal of ego and shifting of perspective to be a huge part of growing as an "experienced" maker of things myself. I can't find the direct link to the video, but it's about half way down the list on this season: https://www.pbs.org/woodwrightsshop/watch-on-line/watch-seas...
The best summary I could find is on Wikipedia [0]. Summary: put stuff away that you aren't using and keep things you need together and within easy reach.
I would say it's a bit larger than that, at this point.
There's (of course) a sub-reddit for folks who like to watch others knoll.
One proponent is Adam Savage from Mythbusters [2], and often refers to the term (and knolls model sets, tools and so on) and I don't think it's being done in reference to Tom Sachs any more.
I feel a little grosser knowing that but this activity, of maintaining your space, I like so much. The term "de-cluttering" comes to mind but it's so obviously a chore, a cost, maintenance, a reactive price. Anything that sounds active, moving forward, sounds much better.
Sometimes people come to you with odd requests, and there's definitely a creative side to the more interesting problems, but there's also a lot of churning out nails and horseshoes. Still, you're unlikely to go hungry.
I like the comparison to organizing a workshop. Everyone has their own preferred environments, editors, scripts, etc. And you'd probably feel as uncomfortable using someone else's .vimrc as an ancient smith would have been in an unfamiliar forge. A craftperson's tools are like clothes; it feels uncomfortably weird to use someone else's.