Knolling

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.

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 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.

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_.

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?

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.

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...

Then what is the development of software that performs simulations of bridges, electronic circuits, aerodynamics, etc.?

it is not explained, only youtube link, cannot access