Hacker News new | past | comments | ask | show | jobs | submit login

1-3 remind me of a great "I Can Has Cheezburger?" anecdote about being a successful CTO: http://www.scottporad.com/2010/11/12/what-it-really-means-to...



I wish more people knew about FreshBooks' rewrite. They had horrible code. And they slowly morphed it into a php-python-ruby mix which is (from my dev friends there) pretty damn good now. It's ok to have a setup or tools that are fucked, but FB would never be able to hold onto developers or iterate quickly on their product if they hadn't sunk at least 9 man-years on the clean up. A million bucks for a slow rewrite is worth the price when it mitigates the risks of a failed from scratch rewrite.


You ever played Weiqi? (Otherwise known as Go).

Unlike chess, stones don't move once played. They can only be captured. On a 19x19 board, you have to balance short-term gains with long-term gains. Since there are no left-right or top-bottom orientations, you often have to reimagine where you draw the lines of territory as you play. Sometimes, you can kill your shapes by playing too many stones. Better players can see where things will go, identify "dead shapes," and stop wasting time trying to rescue them. Sometimes you trade off bad moves for bigger gains. Sometimes you simply have to work with mistakes you made in the early game.

This is very much like writing code and getting it to market. You're trying to build something despite disruptive opposition even as the clock winds down.


Ah, but in Go there is the concept of good shape - you can play along similar strategic lines with both good and bad shape, but if you play your stones clumsily (write your code in PHP?), you will be vulnerable to many forcing plays and clever tesuji that may transform the position into an unwinnable one. It could happen during the middle game - bad shape may allow a group to be cut in half or have its eye shape pounded out of it - or in the yose, where you may need to make a very large number of moves to defend very few points (long development cycles to add features to a poorly written product?).

Therefore the analogy of Go justifies spending time making good shape with your code as you go along.


See (4) about unconscious incompetence.


Don't take the fun out of this! But that was a nice write up about Go and I enjoyed the analogy


:-D

I'm glad you said something about shape. It's something I'm stumbling through right now.


You might find "Making Good Shape" helpful, as it is one of the few shape focused go books available in english:

http://www.gobooks.info/k73.html

The problems are very challenging, but that shouldn't stop you from thinking about them and then enjoying the enlightenment of the answers after a minute. Very helpful material! Best of luck in your pursuit of a better game


Funny you should mention that. Right after you talked about shapes, I browsed through Sensei's Library and saw that too. Thanks for the recommendation.


For someone who's known of Go but never took the time to learn or play it, that's the best sales pitch for it I've ever heard. Makes it sound like it has the fundamental simplicity of checkers and the strategic complexity of chess. Adding it to my learning list now.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: