The Handmade Manifesto

Seems to me we oftentimes also forget the "not so outspoken" devs, that just tinker away, doing their thing, without announcing every fart to the world.

People doing great work, without putting themselves into the spotlight.

I agree. The fact is that I can now build a database and front end as a team of one. Ten years ago that would have needed a team of maybe 5 developers. Abstractions slow things down at the computer level, but bring a great deal of developer productivity. As always its a tradeoff.

> Hacker News tends to forget that.

I'm not sure it knew it in the first place. It's particularly entertaining when the web dev crowd chimes in on embedded system topics.

I spent the first twenty years of my career as an embedded systems engineer and there are two specific advantages I gained from that experience:

1) When your writing code for an underpowered microcontroller, you have a plan before you start. This plan includes execution speed and memory usage targets.

2) When you're sending thousands (hundreds of thousands or millions) of non-reprogramable devices into the field, you have a test plan (and comprehensive test suite) that guarantees correctness and performance.

Do you know your "machine"? For instance, if you're working with a language that runs on the JVM have you read the JVM specification? (It's the equivalent of your micorcontroller's data-sheet). The part of this manifesto I agree with is that you should thoroughly understand everything "beneath" your application.

I develop thermodynamic code for the oil & gas industry. I count the number of divisions in my code. Because a division is a really expensive operation if you need to do it billions of time.

So yes, there are still a lot of people worrying about performance, but a lot of them are coding in Fortran and this is definitely not sexy. Ok, now we also use CUDA, so this can go through the HN filter ;)

This is a great point. I put a high value on writing efficient software, but you have to know when to do it!

For instance, I wrote a script to download the O'Neill's tune collections in ABC [1] the other day. I wrote it in Perl 6, not exactly known for blazing performance. (It was a three line script, one of which was just a closing bracket. [2]) If I'd carefully written it in C++, it would have taken me at least 20x as long to write, and it would no doubt have been substantially more "efficient". But it would not have been significantly faster in execution, because it was using curl to download the ABC files that was the slow part.

[1] For instance, http://trillian.mit.edu/~jc/music/book/oneills/waifs/ [2] https://gist.github.com/colomon/ef8e4a8801d01b1d5813

> Good luck getting people to pay for it.

No luck needed. There's a metric ton of people who just crave well-crafted software. I have a project of that nature now and I am absolutely blown away by the amount of compliments and thank-yous sent our way. It's really quite something.

> ... when you're trying to meet business goals, speed of execution trumps quality of implementation every day of the week.

This is a topic I've been mulling over in my head for quite a while, contemplating writing about it and/or trying to give talks/presentations on it (I just have no idea where that would possibly be welcomed/appropriate within the developer community).

I'm curious about where and how you work that you find this to so consistently be the case?

---

Over the years, I've worked with multiple kinds of businesses on custom, from-scratch software. I'm not talking websites; I mean software on which they depend for actual daily business/employee operations. Perhaps I've been extraordinarily lucky in the last 8 years, perhaps I filter out the rubbish, but I have yet to work with a single client that values speed of execution over quality of implementation. In fact, the longer I do this, and the more I get to intimately know my clients and their businesses, the easier I find they happily pay more for quality of implementation. I rarely find myself facing earning less to provide speed of execution. They consistently pay a premium for quality implementation.

I don't negotiate on speed vs quality. Want speed? Cut features, not quality. Need a lower budget? Cut features, not quality.

I spend more time getting to deeply understand my clients, their businesses, and their goals than many other developers I personally know closely. I begin this on Day One, Meeting One--the first time I'm invited to discuss a project with a potential client.

I ask questions that get a client talking deeply about their business--what weaknesses/inefficiencies they're trying to solve with custom software, what goals they're trying to meet, what they've tried in the past, even what other developers/companies/options they've talked to or considered before me, and what has been offered/promised by my competitors. I drive the conversation to what kinds of business/operational features they're looking to automate/enhance with software, what benefits they're hoping to experience, what value they think software will bring their business.

I always take copious notes. I try to keep the client doing most of the talking. I probe and dig when necessary to really understand what they're trying to accomplish. Within a single meeting, I work to establish a base-level of trust by way of focusing the entire conversation on making sure my client knows they are heard and their needs/goals are understood. When I do take the floor and speak at length, it's to echo back what I've heard, what notes I'm taking, how I understand their needs, how I think we can solve those needs.

The first meeting is usually a long one. I never watch the time. I don't wear a watch. I don't glance at my phone. I get the client talking and keep them talking. I remain mindful of who is quiet in the room, and try to actively engage them in the conversation. I want the whole room in on the discussion, and I want them all feeling like they're part of this thing.

I say we a lot. By the end of an initial meeting, I've usually established an impression and expectation that I'm invested. And it's not bullshit. For me, at least, it's really damn genuine. I want the client to know that we can solve X, Y, and Z in a way that's going to bring great value to the company, and it's going to be of the utmost quality.

I never talk about speed. I rarely even discuss rates in the first meeting. I'm also rarely asked about them by the end of the meeting.

I usually close out these initial meetings with a brief outline of the process we will follow moving forward creating software to improve the business. I explain how I'm going to be doing the heavy lifting of distilling all of our conversation and my notes into a document that highlights and maps out all we've discussed as a complete guide to everything we think is important to helping the company.

Clients don't typically think in terms of features. They think about efficiencies, cost savings, goals, plans, ideas, and above all, value. I never ask them to give me a list of features to build. That's my job to provide them, based on understanding their business and its needs completely. If I can't take the time to do that properly, we're never even going to be worried about speed of execution vs quality of implementation. The project's going to be a disaster from the start.

We get back together some days later, after I've mapped out everything from our discussion into a semi-technical feature spec & roadmap. Everything is broken down into constituent parts. I include explanations that educate them on the process of building their software. I go to great lengths to make sure they understand technical limitations/expectations. I don't ever bullshit them or myself. I've taken to ranking things with a loose grading of technical difficulty and time required for different components of the software. I am always priming them for the price tag without ever talking about it.

When we get to the part of talking about the price, it's never awkward. They've been primed. I've earned their trust by being completely open and honest, and by listening and paying attention to their real needs. They see me as an extension of the company. We're in this together and $X is what it's going to take to get the value the company needs out of the software. When the price is too high, I walk them through prioritizing the features/components into a list of things they want to have now until it fits into their budget for "this phase". I never offer a choice of speed over quality.

> They want to know that they don't have to keep an expensive pain-in-the-ass "rockstar" developer around just to maintain and build on it.

My clients typically want to know they can keep me around forever to maintain and build on whatever I do for them.

From where I sit, it's all about earning trust. Maybe I'm just lucky. Maybe I work with a completely different set of clients. I just can't imagine having to deal with a client who seriously stresses speed over quality.

> I suspect the only way we're going to get to make software the way we want to make it is, if we also run the business using the software.

Or, if we build up enough trust that a client views us as an equal, invested in the business using the software. My clients practically treat me as if I was a partner in their business.

At the very least, there's really no luck involved here. There are better clients out there. Maybe it's time to start rejecting shitty clients.

I was thinking the same thing when I finished. What, how deep should I dig? What level is it 'handmade' enough?

I can relate. I remember working with Turbo/Borland Pascal on 80286. To this day it seems to me as faster than any C++ compiler I am using today on core i7. Granted, it is apples and oranges, but the difference in frequency alone is freaking 500x. The reason is TP was deliberately _designed_ to run as fast as possible: simple language to parse, monolithic single pass compiler, compilation to memory, cleverly designed file format. We became complacent and rarely anyone does that kind of architecting with ruthless focus on speed and simplicity.

He talks about abstraction layers, yes- although he's probably not arguing for assembly as much as fewer stacks on services on stacks on...

But it seems like the main theme is programming to the actual machine rather than the "frictionless vacuum" target machine that is oh-so-easy to assume. Like one of my favorite presentations, where a PS3 developer team details how simple choices in data structure arrangement got them orders of magnitude speedup because of how different arrangements interplay with the CPU caches. In OoO languages, it's easy to make a pathological cache virus.

The 'Handmade' part of this is (knowing the author) a reference to Casey Muratori's Handmade Hero [1], where he builds a game 'from scratch'. The game is written in C++, using nothing but the base OS libs (in his case, Win32), minimal reliance on the CRT, etc.

I'd guess they're talking about building programs with a level of care comparable to that project, meaning high performance memory allocation, no interpreted languages, high priority on fast execution and compile times, etc.

[1] https://handmadehero.org/

I undersand why unrolling loops is faster with current hardware, but does it ought to be so ? Maybe we are putting a lot of complexity in software to cope with limitations of hardware that could not exist anymore in a couple of generations (of hardware).

At a visceral level, I really love the concept. I've created my own game engines (before the age of ubiquitous, well-tested free engines), and I understand how to optimize code all the way down to counting cycles (which used to be easier).

At a practical level, though, I'm really, really sick of people creating Yet Another Framework. NIH is not something that needs encouragement.

And this "manifesto" will be used to justify NIH. It may not be the point of the authors, but people will absolutely point to it when they want to create something that's been done well already.

I totally agree that the right idea is to use exactly the tools for the job. Don't throw every new framework into your app and expect it to be fast enough. "Minimal and thin" is the right answer.

I've been doing a lot of JavaScript work recently, for example, and I often visit MicroJS [1] when I need something. Instead of the 100k+ of jQuery & plugins I can often find one library that's 4k and another that's 6k that together do all I need. If you need most of jQuery, ZeptoJS [2] is often a good answer.

That said, sometimes ecosystems are powerful. When you need nontrivial functionality, and the best options have a dependency on jQuery, it might still make sense to include jQuery. Development time still counts: Spending an extra 30 hours to reinvent a component is great if you're spending your own time on it, but when you're billing by the hour, it's a lot harder to justify if that component is available off the shelf and Just Works in about 5 minutes.

It's all about compromises. I do think that it's common to see developers throw in a component if it's even slightly useful, leading to the web of today where a single page might download and initialize 40-60 different libraries. It would be healthy if the pendulum would swing back in the other direction. But we really don't need 300 ways to do every single thing in JavaScript.

[1] http://microjs.com/#

[2] http://zeptojs.com/