Knolling(andri.yngvason.is)
andri.yngvason.is
Knolling
https://andri.yngvason.is/knolling.html
41 コメント
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.
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.
> it feels more like plumbing
Many times it's just the plumbing between wallets and accounts receivable.
Many times it's just the plumbing between wallets and accounts receivable.
Software development is a gigantic thing.
You can program microcontrollers.
You can simulate natural or artificial phenomena.
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.
You can program microcontrollers.
You can simulate natural or artificial phenomena.
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?
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.
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.
The same could be said about software engineering. Not everyone is engineering all the time just because you are.
I disagree with this.
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_.
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.
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?
We're agile thought, right?
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?
We're agile thought, right?
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.
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.
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.
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.
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...
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...
> Software development is a craft. We tend to call it “engineering”, but most of the time, it feels more like plumbing or carpentry.
Then what is the development of software that performs simulations of bridges, electronic circuits, aerodynamics, etc.?
Then what is the development of software that performs simulations of bridges, electronic circuits, aerodynamics, etc.?
That's mechanical/electrical/civil engineers who taught themselves to code, sometimes poorly!
The packages I've used are as user friendly as a marzipan dildo.
The packages I've used are as user friendly as a marzipan dildo.
so... what is knolling?
it is not explained, only youtube link, cannot access
it is not explained, only youtube link, cannot access
It’s a self-marketing term for an artist (?) named “Tom Sachs”. The first DDG hit is a link to him, and his invention of the term.
The fact we’re discussing this means the marketing gimmick worked.
The fact we’re discussing this means the marketing gimmick worked.
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.
[1] https://www.reddit.com/r/knolling/ [2] https://www.tested.com/search/?term=knolling
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.
[1] https://www.reddit.com/r/knolling/ [2] https://www.tested.com/search/?term=knolling
Wow, I'm familiar with his work but had no idea that he invented the term. Kinda of makes me like Knolling more, though. And him, as an artist.
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.
It's not "gnolling," the troll word that didn't catch on, but it could be.
https://www.urbandictionary.com/define.php?term=Gnolling
https://www.urbandictionary.com/define.php?term=Gnolling
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.
[0]: https://en.m.wikipedia.org/wiki/Tom_Sachs#Knolling
[0]: https://en.m.wikipedia.org/wiki/Tom_Sachs#Knolling
[deleted]
Basically arranging objects on a surface at right angles to each other, and ordering them into groups based on similarity.
https://www.curbed.com/2016/7/18/12215158/always-be-knolling...
https://www.curbed.com/2016/7/18/12215158/always-be-knolling...
Building a Wikipedia competitor that nobody asked for? https://en.wikipedia.org/wiki/Knol?wprov=sfla1
Spreading out your tools on your work bench so that they're all visible and accessible. Preparing for a productive work session, in flow.
It's not just about taking pretty Instagram pictures.
It's not just about taking pretty Instagram pictures.
Wait, how do I reconcile "always be knolling" with "avoid premature optimization"?
Through the wonderful glasses of hindsight, of course.
Cleaning up your workshop, and keeping it clean, is optimization of you, not the project you work on.
Any optimization done on yourself is always way overdue.
Any optimization done on yourself is always way overdue.
[deleted]
I go along with Alan Kay and call it Pop culture.
[deleted]
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.