- You should only focus on one hole at a time. You’re not playing the last hole, or the next one; you’re only playing the hole you’re on at any point in time. If you don’t do this – if you’re rehashing a bad shot from thirty minutes ago in your mind, or worried about the water hazard three holes in the future – you will lose.
- Keep the hazards out of play. If you avoid the rough, the sand, and the water, you’ll be fine.
- Don’t aim for a hole-in-one. First, get the ball on the fairway. Then aim for the green. Then, get it near the hole. Finally, put it in the cup. Par.
- Know your own game. In other games, like basketball or football, it’s advantageous to know who your opponents are and how they play so you can adjust your game to blunt their strengths and attack their weaknesses. Golf is a game where the other person’s actions shouldn’t really matter; yours do. Just because Tiger Woods would use an eight-iron on one shot doesn’t mean that you should pick the same club. Know yourself, your swing, and your strong and weak points; take care of yourself, and you’ll take care of your game.
There were a few others, I’m sure, but these were the ones that resonated with me most strongly, because of the clear implications for business, dating, and life in general. Imagine only focusing on one task at a time during the day, avoiding pitfalls, doing good work, and knowing your own strengths and weaknesses! Golf clubs became symbols of these principles for me.
In thinking of them recently, I wondered if there were possible coding parallels:
- Focus on one line at a time. Don’t focus on ten lines from now, or the next test, or the next program. Don’t write a line while reworking in your mind what you wrote ten lines before. Focus on writing the best code you can right now, and then move on.
- Get your code to pass the tests first. Then, refactor it. Especially as beginners, it seems like a lot of people get caught up in writing perfect code from the beginning, and then they get stuck trying to hack their way out.
- Similarly, we shouldn’t be trying to write the perfect code from the getgo. In fact, we are continuously reminded to intentionally fail our code first, just to know the tests are working. We should write tests that don’t have anything to input, and THEN write something that fails, and THEN write something that passes.
- Know what you’re trying to accomplish, and don’t worry about what others are doing. They have their own game and ways of doing things; do yours, and get it to work.
I’ve been playing around with these ideas for a week or so. Then, this weekend, I was getting ready to cook some pulled pork when I thought of another lesson that had possible implications for programming: mise en place, or, as Michael Ruhlman wrote in Twenty: “Think.”
Mise en place: (in a professional kitchen) the preparation of dishes and ingredients before the beginning of service.
The idea is that we should get everything together, in order, and know what we’re doing, before we light the fire. Then, we won’t be scrambling around in the middle of cooking to grab ingredients that we realize we need at certain points. It just takes a few minutes to plan your actions out, but it can save our sanity when we’re in the kitchen and the onions are about to burn.
This idea came up because we’re learning about designing programs before jumping in to code them. The point is that, like cooking, we should map out what we want to do, with pen and paper, and then work on each step sequentially. The reason we learn this is because the beginner’s instinct is to learn what our task is, then jump in and start typing away, without thinking of how things should be laid out and what makes the most sense to start. The design-first approach makes a HUGE amount of sense, but it’s difficult to remember when we have an idea and sort of know how to get it done. But, like cooking, if you take a moment to put everything in place, the work – and final product – will flow much more easily down the line.
Souvenirs 