7 ms·

The Handmade Manifesto

70 points by AlexeyBrin 11y ago

vinceguidry 11y ago
Good luck getting people to pay for it. I personally love the artisanal mindset, but when you're trying to meet business goals, speed of execution trumps quality of implementation every day of the week. They even coined a phrase for it, worse is better. There's a good reason the industrial revolution demolished the old guild system. When you prioritize speed of execution, you tend towards popular frameworks, which is the next line item on the typical client wish-list. 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. 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. Look at Patrick and Thomas.
- latitude 11y ago
  > 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.
  - tonyedgecombe 11y ago
    I was thinking about your product as soon as I saw this.
  - vinceguidry 11y ago
    What I should have said was, "Good luck getting your freelance clients to pay for it." If you're running a software business, which I see you are, with a product that serves a need that people actually have, in a way that they actually need it to be solved, then sure, they'll appreciate craftsmanship. Because you put the time and attention in before you put a price on it and asked them to pay for it. If you're asking them to value it before you put it in, then you're selling them Fort Knox when all they need is a bank. It's not just about software, it's about business too. If you want to make software the way you want to make it, you better be willing to sell it yourself. Freelancing allows you to make software and get paid for it without having to validate the business purpose behind the software. In many cases, the business doesn't need anything fancy, handing them a manifesto isn't going to score you any points.
- bobwaycott 11y ago
  > ... 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.
brandonmenc 11y ago
What does this even mean? Going back to hand-unrolling loops in assembler when writing business applications? The very smart people working on the layers this manifesto bemoans already do that for us.
- bontaq 11y ago
  I was thinking the same thing when I finished. What, how deep should I dig? What level is it 'handmade' enough?
  - bklebe 11y ago
    At the magnetized needle level, I think: https://xkcd.com/378/ https://xkcd.com/378/
    - Wistar 11y ago
      Or at the Mel level: http://www.catb.org/jargon/html/story-of-mel.html http://www.catb.org/jargon/html/story-of-mel.html
- mynegation 11y ago
  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.
- sliverstorm 11y ago
  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.
ObjectiveSub 11y ago
Meh, that group of developers didn't really die out. People tend to forget that there's tons of people still worrying about performance. I personally do computer graphics in video games. We still worry about every byte, cycle, cache miss, and instruction that we write. We still spend days trying to eek out another 100 microseconds from that tricky piece of code. Not every software developer is a web/business developer. Hacker News tends to forget that.
- sdoering 11y ago
  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.
  - rodgerd 11y ago
    HN culture doesn't merely forget about them - in fact, it aggressively excludes them. Brilliant assembler programmer who likes to finish up at the end of the day and play with your kids? Fuck you, where's your GitHub profile. Developing novel algorithms and prefer playing guitar at home to drinking at the pub? Fuck you, where's your conference talks. etc, etc, etc. The broader culture of which HN is a microcosm spends a lot of time and effort devising filters to make people invisible if they don't fit a relentlessly self-promoting profile which has a questionable relationship with the quality of their work. I don't see Knuth and Cutler spending a lot of time on Twitter.
    - stdbrouw 11y ago
      We cannot read what does not get written. We cannot discuss the merits and demerits code that is not public. I'm in full agreement that HN is an informational bubble. I'm not so clear on exactly what HN is doing to aggressively exclude people. And where you see exclusion, I see an attempt to encourage people to join the discussion: "hey, why don't you put this up on GitHub so we can take a look", "this would make such a good topic for a conference talk."
    - 11y ago
mehwoot 11y ago
The tradeoff is development speed. Sure, there is a whole lot of software written these days that isn't world class (In terms of anything really, not just execution speed) but at the same time a lot of it is software that is written at a reasonable price that generates value for businesses. Not every piece of software is handcrafted work of art. Some of it just saves X person Z hours of time at some mundane task, and we are able to make that software for X person because the same 6 layers of abstraction that make it slow also make programming accessible enough for it to be affordable. Nothing really wrong with that. But I guess I wouldn't begrudge someone choosing to develop handcrafted software, as long as they're not claiming that is the way everything should be.
- colomon 11y ago
  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/ http://trillian.mit.edu/~jc/music/book/oneills/waifs/ [2] https://gist.github.com/colomon/ef8e4a8801d01b1d5813 https://gist.github.com/colomon/ef8e4a8801d01b1d5813
dantiberian 11y ago
If this resonated with you, then check out Mechanical Sympathy [1], a mailing list all about writing code that is aware of how computers work and working with them. Martin Thompson's blog by the same name also has a lot of good information [2]. To the people who say "Who is going to pay for this?" look at all of the places that can measure the cost of slow or inefficient computing e.g. Wall St, Google, Amazon, e.t.c. They all invest in writing low level efficient code where it makes sense. [1]: https://groups.google.com/forum/#!forum/mechanical-sympathy https://groups.google.com/forum/#!forum/mechanical-sympathy [2]: http://mechanical-sympathy.blogspot.co.nz http://mechanical-sympathy.blogspot.co.nz
yaur 11y ago
I write media stuff. Code in the media pipeline proper gets ultraoptimized because it gets run between 30 and ~10k times per second. Code outside of the pipeline is largely written in python because the extra startup time, while non-trivial, is noise compared to the time waiting for PSI to be delivered. The point is that "computers are slow" is, at least in some part, because "just works" requires a mind-numbing number of operations.
toolslive 11y ago
Stable problems get high quality solutions.
Udo 11y ago
I saw this come up during the handmade hero screencast yesterday, and I appreciate the sentiment a lot. Although I have a feeling that Casey and his crowd would disagree, I believe this initiative touches only part of the problem, and worse, it could be interpreted as absolving programmers working at higher levels of abstraction from doing their part. Knowing what happens behind the scenes when you write a line of code is important. Question the decisions made by frameworks and libraries, and question whether you actually need them. Keep the stack minimal and thin. Choose the right tool for the job, and be knowledgeable of its inner workings. Resist replacing tradecraft with ritual, especially when programming in groups. These can (and should, in my opinion) also apply to web development, a huge category that seems to be all but despised and written off by the handmade people.
- SomeCallMeTim 11y ago
  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/# http://microjs.com/# [2] http://zeptojs.com/ http://zeptojs.com/
renox 11y ago
I agree and disagree: I disagree because one of the main reason why "the computer is slow" is the HDD: use a SSD instead for your main storage and it makes a world of difference (except if you use bloated websites). I agree because I remember BeOS: on the same computer it was much, much more responsive than Windows or Linux. It's probably much more practical to buy a SSD instead of hoping to replace all your bloated SW with leaner one..
Lerc 11y ago
While this doesn't seem to be very well expressed, I think the sentiment behind this is worth discussion. Computers do waste a huge amount of resources in the name of expediency, They are slow to do things, because it is simply cheaper to develop that way. I think there is scope for the sort of crafted code that is described here though. Not only as an artform but as a practical measure. For any small piece of code a compiler can produce a comparable result to hand written assembly. Entire programs that have been written in assembly tend to be much smaller, use less memory and run faster. That apparent contradiction is where the focus of crafted code should be. Most of the gains from hand crafted assembly do not come from finding the quickest way to do a simple calculation, but the additional attention that gets applied. It wouldn't surprise me if the majority of the gain comes from not instruction level optimisation, but calculation level optimisation. For example, how do you find the last word in a string? Have a look on stackOverflow and you will see examples in many language that are the equivalent to. var lastword = fullString.split(" ").pop(); The work done by this operation is easier and easier to overlook as things get higher level. I have often wondered on the merits of writing a virtual assembly instruction set that is platform agnostic (so compiles/transliterates to native) to explore this idea. It wouldn't be like JVM bytecode which implements higher level magic, and it wouldn't be like LLVM which is not aimed at being human writable. Some existing RISC instruction sets might be close to what is needed. There would be potential to write things in multiple instruction sets, If the interfaces between code sections are well defined (stack/register/memory passing) you could write modular code in a preferred Instruction set. This isn't practical for many applications, but I'm not convinced that doesn't have a possible niche.
whistlecrackers 11y ago
I should make software by hand, rather than typing with my feet. Good idea.
stdbrouw 11y ago
I'm reminded of the first industrial products. Handmade meant crummy and for poor people, whereas something from a production belt meant precision-engineered. But now that everyone can afford, say, a quality solid-state amplifier, suddenly it's hip to have the expensive point-to-point tube amp again. It's really about status and conspicuous consumption, but the snobbery is hidden behind notions of quality and authenticity. Now let's circle back to software. High-level programming languages, interpreted languages, libraries, frameworks... all used to be really cool. Until people realized that now everyone can learn how to code, so there's a need for something to separate the elite from the plebeians, something to separate the software engineers from the script kiddies... how about handmade programming, maybe that'll do the trick?
chrismaeda 11y ago
In DonaldKnuth's paper "StructuredProgrammingWithGoToStatements", he wrote: "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." (http://c2.com/cgi/wiki?PrematureOptimization http://c2.com/cgi/wiki?PrematureOptimization)
normloman 11y ago
I don't think we have to give up libraries and interpreted languages. Just stop writing shit code because your boss needs it done in 5 minutes. Of course, thats our bosses fault, not ours. And its a symptom of a larger cultural attitude that values short term profits over long term sustainability. I say, why bother!
agentultra 11y ago
If this strikes a chord you might also be interested in data-oriented design[0]. It's the primary philosophy behind Casey Muratori's Handmade Hero[1] which is where, I assume, the reference in the manifesto's title comes from. You should also watch Mike Acton's talk at CppCon[2]. It's really about giving up programming-by-folklore. It's about understanding the problem so that you understand the data transformations your program has to make given the hardware it will operate on. It's about doing the maths and following the numbers instead of modelling things in terms of abstractions. It's about letting go of the idea that our job is to write beautiful code. Our job is to solve problems. The problem is a human one. The computer transforms data to solve our problem. The code only needs to do those transformations which solve the problem. It's a philosophy I've picked up in part thanks to Mike Acton and Casey. I mostly work in dynamic languages but it has already helped immensely at keeping my code simple and forcing me to think about the data. This has a huge impact on writing fast, simple code. [0] http://dataorienteddesign.com/site.php http://dataorienteddesign.com/site.php [1] https://handmadehero.org/ https://handmadehero.org/ [2] https://www.youtube.com/watch?v=rX0ItVEVjHc https://www.youtube.com/watch?v=rX0ItVEVjHc

70 points by AlexeyBrin 11y ago

Good luck getting people to pay for it. I personally love the artisanal mindset, but when you're trying to meet business goals, speed of execution trumps quality of implementation every day of the week. They even coined a phrase for it, worse is better. There's a good reason the industrial revolution demolished the old guild system. When you prioritize speed of execution, you tend towards popular frameworks, which is the next line item on the typical client wish-list. 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. 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. Look at Patrick and Thomas.

latitude 11y ago
> 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.
- tonyedgecombe 11y ago
  I was thinking about your product as soon as I saw this.
- vinceguidry 11y ago
  What I should have said was, "Good luck getting your freelance clients to pay for it." If you're running a software business, which I see you are, with a product that serves a need that people actually have, in a way that they actually need it to be solved, then sure, they'll appreciate craftsmanship. Because you put the time and attention in before you put a price on it and asked them to pay for it. If you're asking them to value it before you put it in, then you're selling them Fort Knox when all they need is a bank. It's not just about software, it's about business too. If you want to make software the way you want to make it, you better be willing to sell it yourself. Freelancing allows you to make software and get paid for it without having to validate the business purpose behind the software. In many cases, the business doesn't need anything fancy, handing them a manifesto isn't going to score you any points.
bobwaycott 11y ago
> ... 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.

brandonmenc 11y ago

What does this even mean? Going back to hand-unrolling loops in assembler when writing business applications? The very smart people working on the layers this manifesto bemoans already do that for us.

bontaq 11y ago
I was thinking the same thing when I finished. What, how deep should I dig? What level is it 'handmade' enough?
- bklebe 11y ago
  At the magnetized needle level, I think: https://xkcd.com/378/ https://xkcd.com/378/
  - Wistar 11y ago
    Or at the Mel level: http://www.catb.org/jargon/html/story-of-mel.html http://www.catb.org/jargon/html/story-of-mel.html
mynegation 11y ago
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.
sliverstorm 11y ago
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.

ObjectiveSub 11y ago

Meh, that group of developers didn't really die out. People tend to forget that there's tons of people still worrying about performance. I personally do computer graphics in video games. We still worry about every byte, cycle, cache miss, and instruction that we write. We still spend days trying to eek out another 100 microseconds from that tricky piece of code. Not every software developer is a web/business developer. Hacker News tends to forget that.

sdoering 11y ago
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.
- rodgerd 11y ago
  HN culture doesn't merely forget about them - in fact, it aggressively excludes them. Brilliant assembler programmer who likes to finish up at the end of the day and play with your kids? Fuck you, where's your GitHub profile. Developing novel algorithms and prefer playing guitar at home to drinking at the pub? Fuck you, where's your conference talks. etc, etc, etc. The broader culture of which HN is a microcosm spends a lot of time and effort devising filters to make people invisible if they don't fit a relentlessly self-promoting profile which has a questionable relationship with the quality of their work. I don't see Knuth and Cutler spending a lot of time on Twitter.
  - stdbrouw 11y ago
    We cannot read what does not get written. We cannot discuss the merits and demerits code that is not public. I'm in full agreement that HN is an informational bubble. I'm not so clear on exactly what HN is doing to aggressively exclude people. And where you see exclusion, I see an attempt to encourage people to join the discussion: "hey, why don't you put this up on GitHub so we can take a look", "this would make such a good topic for a conference talk."
  - 11y ago

mehwoot 11y ago

The tradeoff is development speed. Sure, there is a whole lot of software written these days that isn't world class (In terms of anything really, not just execution speed) but at the same time a lot of it is software that is written at a reasonable price that generates value for businesses. Not every piece of software is handcrafted work of art. Some of it just saves X person Z hours of time at some mundane task, and we are able to make that software for X person because the same 6 layers of abstraction that make it slow also make programming accessible enough for it to be affordable. Nothing really wrong with that. But I guess I wouldn't begrudge someone choosing to develop handcrafted software, as long as they're not claiming that is the way everything should be.

colomon 11y ago
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/ http://trillian.mit.edu/~jc/music/book/oneills/waifs/ [2] https://gist.github.com/colomon/ef8e4a8801d01b1d5813 https://gist.github.com/colomon/ef8e4a8801d01b1d5813

dantiberian 11y ago

If this resonated with you, then check out Mechanical Sympathy [1], a mailing list all about writing code that is aware of how computers work and working with them. Martin Thompson's blog by the same name also has a lot of good information [2]. To the people who say "Who is going to pay for this?" look at all of the places that can measure the cost of slow or inefficient computing e.g. Wall St, Google, Amazon, e.t.c. They all invest in writing low level efficient code where it makes sense. [1]: https://groups.google.com/forum/#!forum/mechanical-sympathy https://groups.google.com/forum/#!forum/mechanical-sympathy [2]: http://mechanical-sympathy.blogspot.co.nz http://mechanical-sympathy.blogspot.co.nz

yaur 11y ago

I write media stuff. Code in the media pipeline proper gets ultraoptimized because it gets run between 30 and ~10k times per second. Code outside of the pipeline is largely written in python because the extra startup time, while non-trivial, is noise compared to the time waiting for PSI to be delivered. The point is that "computers are slow" is, at least in some part, because "just works" requires a mind-numbing number of operations.

toolslive 11y ago

Stable problems get high quality solutions.

Udo 11y ago

I saw this come up during the handmade hero screencast yesterday, and I appreciate the sentiment a lot. Although I have a feeling that Casey and his crowd would disagree, I believe this initiative touches only part of the problem, and worse, it could be interpreted as absolving programmers working at higher levels of abstraction from doing their part. Knowing what happens behind the scenes when you write a line of code is important. Question the decisions made by frameworks and libraries, and question whether you actually need them. Keep the stack minimal and thin. Choose the right tool for the job, and be knowledgeable of its inner workings. Resist replacing tradecraft with ritual, especially when programming in groups. These can (and should, in my opinion) also apply to web development, a huge category that seems to be all but despised and written off by the handmade people.

SomeCallMeTim 11y ago
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/# http://microjs.com/# [2] http://zeptojs.com/ http://zeptojs.com/

renox 11y ago

I agree and disagree: I disagree because one of the main reason why "the computer is slow" is the HDD: use a SSD instead for your main storage and it makes a world of difference (except if you use bloated websites). I agree because I remember BeOS: on the same computer it was much, much more responsive than Windows or Linux. It's probably much more practical to buy a SSD instead of hoping to replace all your bloated SW with leaner one..

Lerc 11y ago

While this doesn't seem to be very well expressed, I think the sentiment behind this is worth discussion. Computers do waste a huge amount of resources in the name of expediency, They are slow to do things, because it is simply cheaper to develop that way. I think there is scope for the sort of crafted code that is described here though. Not only as an artform but as a practical measure. For any small piece of code a compiler can produce a comparable result to hand written assembly. Entire programs that have been written in assembly tend to be much smaller, use less memory and run faster. That apparent contradiction is where the focus of crafted code should be. Most of the gains from hand crafted assembly do not come from finding the quickest way to do a simple calculation, but the additional attention that gets applied. It wouldn't surprise me if the majority of the gain comes from not instruction level optimisation, but calculation level optimisation. For example, how do you find the last word in a string? Have a look on stackOverflow and you will see examples in many language that are the equivalent to. var lastword = fullString.split(" ").pop(); The work done by this operation is easier and easier to overlook as things get higher level. I have often wondered on the merits of writing a virtual assembly instruction set that is platform agnostic (so compiles/transliterates to native) to explore this idea. It wouldn't be like JVM bytecode which implements higher level magic, and it wouldn't be like LLVM which is not aimed at being human writable. Some existing RISC instruction sets might be close to what is needed. There would be potential to write things in multiple instruction sets, If the interfaces between code sections are well defined (stack/register/memory passing) you could write modular code in a preferred Instruction set. This isn't practical for many applications, but I'm not convinced that doesn't have a possible niche.

whistlecrackers 11y ago

I should make software by hand, rather than typing with my feet. Good idea.

stdbrouw 11y ago

I'm reminded of the first industrial products. Handmade meant crummy and for poor people, whereas something from a production belt meant precision-engineered. But now that everyone can afford, say, a quality solid-state amplifier, suddenly it's hip to have the expensive point-to-point tube amp again. It's really about status and conspicuous consumption, but the snobbery is hidden behind notions of quality and authenticity. Now let's circle back to software. High-level programming languages, interpreted languages, libraries, frameworks... all used to be really cool. Until people realized that now everyone can learn how to code, so there's a need for something to separate the elite from the plebeians, something to separate the software engineers from the script kiddies... how about handmade programming, maybe that'll do the trick?

chrismaeda 11y ago

In DonaldKnuth's paper "StructuredProgrammingWithGoToStatements", he wrote: "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." (http://c2.com/cgi/wiki?PrematureOptimization http://c2.com/cgi/wiki?PrematureOptimization)

normloman 11y ago

I don't think we have to give up libraries and interpreted languages. Just stop writing shit code because your boss needs it done in 5 minutes. Of course, thats our bosses fault, not ours. And its a symptom of a larger cultural attitude that values short term profits over long term sustainability. I say, why bother!

agentultra 11y ago

If this strikes a chord you might also be interested in data-oriented design[0]. It's the primary philosophy behind Casey Muratori's Handmade Hero[1] which is where, I assume, the reference in the manifesto's title comes from. You should also watch Mike Acton's talk at CppCon[2]. It's really about giving up programming-by-folklore. It's about understanding the problem so that you understand the data transformations your program has to make given the hardware it will operate on. It's about doing the maths and following the numbers instead of modelling things in terms of abstractions. It's about letting go of the idea that our job is to write beautiful code. Our job is to solve problems. The problem is a human one. The computer transforms data to solve our problem. The code only needs to do those transformations which solve the problem. It's a philosophy I've picked up in part thanks to Mike Acton and Casey. I mostly work in dynamic languages but it has already helped immensely at keeping my code simple and forcing me to think about the data. This has a huge impact on writing fast, simple code. [0] http://dataorienteddesign.com/site.php http://dataorienteddesign.com/site.php [1] https://handmadehero.org/ https://handmadehero.org/ [2] https://www.youtube.com/watch?v=rX0ItVEVjHc https://www.youtube.com/watch?v=rX0ItVEVjHc