Hackers & Painters

Ideas ✅ Teenagers are now useless except as cheap labor in industries like fast food, which evolved to exploit precisely that fact. ✅ The way to create something beautiful is often to make subtle tweaks to something that already exists, or to combine existing ideas in a slightly new way. ✅ I had to figure out a program completely on paper before I even got into my computer. I apologize I did not program this way. ✅ The main thing they cared about at Viaweb was what kind of software you wrote in your spare time. You can't do anything really well unless you love it. And if you love to hack, you'll inevitably be working on projects of your own. ✅ Sam Walton got rich not by being a retailer, but by designing a new kind of store. ✅ Engineers will work on sexy problems like fighter planes and moon rockets for ordinary salaries, but more mundane technologies like light bulbs or semiconductors have to be developed by entrepreneurs. ✅ Surely, by now we all know that software is best built by teams of less than 10 people. ✅ In programming languages, what industry best practice gets you is not the best, but the average. ✅ If you want to win in the software business, take on the hardest problem you can find, use the most powerful language you can get, and wait for your competitors' pointy-haired bosses to revert to the mean. ✅ If you have two choices, choose the harder. The reason this works is that if one choice is harder, the only reason you’re considering the other is laziness. The trick just forces you to admit what you already know. On Programming Worse still, instead of patiently writing out a complete program and assuring myself it was correct, I tended to spew out code that was hopelessly broken and gradually beat it into shape. Debugging, I was taught, was a final pass where you caught typos and oversights. The way I worked, it seemed like programming consisted of debugging. For a long time I felt bad about this, just as once I felt bad that I didn't hold my pencil the right way they taught me in elementary school. If I had only looked over at the other makers, the painters, or architects, I would have realized there was a name for what I was doing: sketching. The way they taught me to program in college was wrong. You should figure out programs as you're writing them, just as writers and painters and architects do. Hackers can learn to program by looking at good programs, not just what they do, but at the source code. Like painters learn by copying great painters. Computers are just a medium for builders to build things. It was common for the master to paint principal figures and assistants to paint the background, but you never had one guy painting over the work of another. That’s a good model for collaboration in software too. If code gets hacked by 3 or 4 different people and no one owns it, it starts to feel like a common room: bleak, abandoned, and full of clutter. Divide projects into sharply defined modules with a definite owner, and interfaces that are carefully designed and as articulated as programming languages. Empathy is probably the single most important difference between a good hacker and a great one. It’s hard for unempathetic people to design great software because they can’t see the user’s point of view. “Programs should be written for people to read and only incidentally for machines to execute.” As groups get smaller, software development gets exponentially more efficient. Programmers also need to be system administrators to some degree. Big Companies Universities and research labs force hackers to be scientists, and companies force them to be engineers. Big companies don’t win by making great products. Big companies win by sucking less than other big companies. If you can get into a design war with a company whose software is designed by product managers, they won’t be able to keep up. You can win big by taking a bold approach to design, with the same people designing and implementing the product. Microsoft did this early. So did Apple. Where Is Hacking Now? Over and over, the same pattern: a new medium appears, people get excited, and they explore most of its possibilities in the first couple generations. Hacking seems to be in that phase now. People in a position to impose rules want them obeyed, but be careful what you ask for. You might get it. On Startups If you’re a hacker thinking about starting a startup, two things usually stop you: you don’t know business, and you’re afraid of competition. Neither fence has any current in it. There are only two things you have to know about business: build something users love, and make more than you spend. If you get those right, you’re ahead of most startups. You can figure out the rest as you go. You may not at first make more than you spend, but as long as the gap is closing fast enough, you’ll be okay. Underfunded encourages frugality. The less you spend, the easier it is to make more than you spend. Build something users love: start clean and simple, something you’d want to use. Get 1.0 fast, then improve by listening closely to users. Different customers are right about different things. The least sophisticated show what to simplify. The most sophisticated show what to add. Easy software comes from getting defaults right, not limiting choices. Don’t get complacent because competitors are lame. Compare your software to what it could be, not what competitors have. Use your software all the time. Viaweb was supposed to be an online store builder, but we used it to build our own site too. Don’t listen to marketing people or designers or product managers just because of job titles. If they have good ideas, use them, but you decide. Software should be designed by hackers who understand design, not designers who know a little about software. If you can’t design software as well as implement it, don’t start a startup. In a startup, no one can stop you. You can ship straight to the browser. No licensing deals, no shelf space, no middlemen. Big companies are scared of you. Startups can focus on one thing. Big companies can’t. Startups are a way to be in a situation with measurement and leverage. Small teams let effort show. And the real advantage is when you take the 10 best rowers and put them together. A startup isn’t just 10 people. It’s 10 people like you. The success or failure depends on the first 10 employees. Maybe the first five. Small isn’t magic by itself. The magic is selection. In a big group, the average drags you down. In a small group of peers, your work gets averaged with people who are also strong. How to Make Wealth If you want to get rich, the best bet is to start or join a startup. That’s been reliable for hundreds of years. If it was easy, everyone would do it. Money is not wealth. It’s how we move wealth around. The people most likely to grasp that wealth can be created are the craftsmen, the makers. A programmer can sit down and create wealth. A good piece of software is valuable. Characters you type can be a finished product. Everyone in a company works together to create wealth by making more things people want. Many employees work at one remove from the actual making of stuff. Not programmers. They think the product one line at a time. So it’s obvious to programmers that wealth is made, not distributed by some imaginary daddy. A great programmer on a roll could create millions of dollars of wealth fast. A mediocre one can create zero or negative wealth by introducing bugs. The top 5% of programmers write most of the good software. What a Job Is In industrialized countries, people belong to institutions until their 20s. Then you get up in the morning and go do things you don’t ordinarily enjoy doing, and belonging becomes part of your identity. A job is doing something people want, averaged together with everyone else in that company. College grads get told they need a job, like joining an institution is the point. A more direct truth: you need to start doing something people want. You don’t need to join a company to do that. A company is just a group working together to do something people want. Doing something people want is what matters. To get rich, you need measurement and leverage. Your performance has to be measurable, and your decisions have to have big effects. If a job feels safe, you’re not going to get rich. No danger usually means no leverage. You don’t have to be a CEO or a movie star. You just need to be in a small group working on a hard problem. On Difficulty Use difficulty as a guide. At Viaweb we had a rule: “run upstairs.” If you’re being chased by a big bully and you hit a staircase, go up. It’s hard for you, but harder for him. In practice: deliberately seek hard problems. If two features are equally valuable, take the harder one, because what’s hard for you may be impossible for competitors. The best defense is a good offense. Pick a hard problem, and at decision points, take the harder choice. Getting bought can be smart. Running a business is different from growing one. Selling lets you diversify. Acquirers get motivated by fear: a competitor might buy you, or you’ll grow and cost more later. What they really care about is users. They assume users tell them who has the best tech. If people aren’t using your software, it might not be marketing. It might be that you didn’t make what they want. VCs fear techno-weenies who solve interesting problems instead of making users happy. In a startup, solve problems users care about. Treat a startup like an optimization problem where performance is measured by number of users. Get 1.0 out fast. Don’t optimize based on guesses. Mind the Gap If you care enough to do something well, the best tend to be far better than everyone else. Once it became possible to get rich by creating wealth, society started getting richer fast. Technology increases leverage. Some people will use it. Others will keep scooping ice cream. Rich people matter because of what they do to get rich: they build the tractors that replace the horses. On Taste If something is ugly, it can’t be the best solution. There must be a better one, and someone will find it. So if you want to make something that appeals to people today and would also have appealed to people in the 1500s, there’s a good chance it will appeal to people in 2500. Good design is simple. And hard. It looks easy. It resembles nature. Good design is redesign. Experts expect to throw away early work. It takes confidence to throw work away: there’s more where that came from. Treat mistakes as natural. That makes them easy to admit and fix. Copying can be part of good design. Novices imitate without knowing it. Then they chase originality. Then they learn it’s better to be right than original. Great work often starts with: “I could do better than that.” Exacting taste plus the ability to gratify it is the recipe. Creators see flaws because worry made the work good. Balance hope and worry. Design for yourself. If you design for idiots, you’ll probably design something bad even for idiots. Morale matters. If you’re bored, the work looks boring. In software: always have working code. Short cycles keep you engaged. Design is for humans, and the designer is human too. On Languages Languages evolve like species. Dead ends everywhere. Staying near the main branches is a good heuristic. Beating the Averages When you choose a programming language, ignore what other people are doing. Choose what works best. A startup can’t do what the average startup does. Average performance means you die. When your software runs on your own servers, you can use any language you want. Desktop software is biased toward the OS language. At Viaweb, we didn’t know business. We were good at writing software. We hoped that would save us. It did. Competitors couldn’t match our software, and Lisp made our cycle so fast we could copy features within days. In business, there is nothing more valuable than a technical advantage your competitors don't understand. In business, as in war, surprise is worth as much as force. A startup should give its competitors as little information as possible. If they didn't know what language our software was working in or didn’t care, I wanted to keep it that way. Use the most powerful reasonably efficient language you can get. Anything else is a mistake. People can’t judge languages above their own because of the Blub Paradox. Competitor tip: read their job listings. The more IT-flavored, the safer. Oracle is safest. C++/Java is safe. Perl/Python is a bit frightening. If you start a startup, don’t design your product to please VCs or acquirers. Design it to please users. If you win users, everything follows. If you don’t, no one cares how orthodox your tech stack was.