By / In Knowledge/ On
I had a wonderful New Year’s Eve, and an exciting adventure on New Year’s Day, both of which I will tell you about later. Meanwhile, I’ve been dying to share some ideas that have been bouncing around in my head—the closest thing I have to resolutions this year.
Monads and Objective-C
Last year saw me transition back to technical production, so it’s no surprise my thoughts in 2013 center around reconciling those years of theory with practical engineering. One topic that got a lot of laughs last year was monads—specifically their inscrutability. I had the chance to sit down with computer scientist Erik Meijer last month and get a lesson in monadic patterns. I felt like I understood, but was dying for some examples in my native language, Objective-C. When a Bing search proved fruitless, I knew I had my speaker topic for 2013.
Stay hungry. Stay foolish.
I spent years making people laugh on stage until I got really good at it. Then I made the choice I so often make—to leave that comfortable expertise and become a novice again. First I went back and gave my “death deathy death death” talk another go, with improved—if still mixed—results. Going back to speaking on technical topics will challenge me further. Talking about something I started by knowing nothing about is a dose of my own advice. This will challenge the theories I’ve espoused to a generation of Appsterdam-trained App Makers beginning their careers with an emphasis on public speaking.
Do you have a better idea?
I’ve spent the past six years trying to get better at taking feedback. This year I’m going to try getting better feedback, with this simple question. It’s too easy to give something a minute’s thought. Too easy, in fact, to be useful. It’s too easy to fall into a situation where one person becomes the well of ideas and sink for complaints, who everyone expects to solve every problem, and accept every blame. It’s an unhealthy dynamic for families, teams, and individuals. Worse, it’s not productive. Complaints need to come with suggestions.
Luck is not a formula.
The world is full of people who had one success and are content to spend the rest of their lives talking about their formula. You can’t trust people like that, because one success doesn’t imply any formula other than luck, and luck is not a formula. Few are the people who have consistently performed again and again. Few who can show clear patterns of learning from failure to produce success. Repetitive success and learning from failure are the only ways to build a formula. Everything else is horseshoes and rubber chickens.
Success is exceptional.
One of the most challenging ideas to me was the Agile assertion that I should build a failure-based business strategy. I hadn’t even considered my strategies success-based, but I have seen how destructive failure is as an exception. I’ve been thinking a lot about how my reverence for excellence could mesh with a failure-based strategy where products are produced on the cheap and expected to fail, where success is the exception. For example, a lab where we could remix games to explore ideas with our fans, sending the best for expensive native development.
This is a business.
I have always been bad at business. I don’t care about money, I trust people implicitly, and I entertain the most ludicrous notions about honor. I’ll fire people for laziness or incompetence, but I’ll hire my friends just because they need to pay the rent. I’ve come to be convinced that signing contracts with friends prevents making enemies, but I’ve been so turned off by the recent cult of contracts I haven’t been good at it. While I’m not willing to compromise my principles when it comes to my customers, when it comes to my company, I always have to remember this first rule of business.
Engineering is hard.
Then there’s the first rule of engineering. For the past few years my trade has been in words, but returning to war has reminded me that my advantage has always been in suffering. What perhaps makes my story interesting is that I’ve come so far, and been through so much, but learned so much from it. While I often sum up my secret as “be kind, work hard,” the implementation detail has been a tolerance for pain. The biggest shock to people trying to bring their ideas to fruition is just how much work is involved, how much blood must be shed, how much sacrifice is required.
Honesty is adversity.
It’s easy to make promises. It’s easy to make excuses. What’s hard is honesty, and it’s honesty that makes engineering hard. We all hold honesty up as a golden ideal, but we all hate honesty when it’s applied to us. It is the honesty of a life laid bare that makes death such a terrifying experience, embodied in the idea of judgment. We hate those who judge us most when they make us judge ourselves. If you want to practice honesty, and you don’t want to be an asshole, you have to learn to be selective with your heart. Honesty is not free, so you should probably be paid for it.
Art through adversity
For 2013 I have embraced process and I have embraced pain. There are many who think process negates the need for pain. When you can convince me Thomas Kinkade was the greatest painter who ever lived, I’ll believe process can produce art, but as long as I believe that Vincent van Gogh was the greatest painter who ever lived, I will believe that art requires adversity. Process can never free us from that, but it can, like a high-level framework, relieve of us the suffering we don’t need to do, to free us to suffer for the things that matter, for the state of our art, for the experience of our user.