Comments on: Bear programming http://gojko.net/2007/12/26/bear-programming/ Building software that matters Fri, 18 May 2012 13:40:15 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: JaeRae http://gojko.net/2007/12/26/bear-programming/comment-page-1/#comment-24767 JaeRae Wed, 06 Feb 2008 16:42:39 +0000 http://gojko.net/2007/12/26/bear-programming/#comment-24767 also known as rubberducking for obvious reasons. also known as rubberducking for obvious reasons.

]]> By: Ben Northrop http://gojko.net/2007/12/26/bear-programming/comment-page-1/#comment-23511 Ben Northrop Thu, 03 Jan 2008 19:45:04 +0000 http://gojko.net/2007/12/26/bear-programming/#comment-23511 Never heard of bear programming - pretty hilarious. On one hand, encouraging self-sufficiency is good...although communication is good as well. If everyone only talked to their bears, and developed in silos, I think there'd be many problems with architectural consistency/coherency. Never heard of bear programming – pretty hilarious. On one hand, encouraging self-sufficiency is good…although communication is good as well. If everyone only talked to their bears, and developed in silos, I think there’d be many problems with architectural consistency/coherency.

]]> By: Ben http://gojko.net/2007/12/26/bear-programming/comment-page-1/#comment-23309 Ben Sat, 29 Dec 2007 11:02:45 +0000 http://gojko.net/2007/12/26/bear-programming/#comment-23309 My trick is to pretend that we're going to open source the project. It never happens, but it forces me to avoid shotcuts. - As much as possible, do it right. Refactoring internally is fine, but a published API is strict. - Simplify the client code and configuration. Avoid making users suffer and increase adoption. - Make code clean and dummy proof. Be strict on what you expose to users. - Consider use cases outside of what's currently required. Generalize the design. - ... -Protect your reputation, don't make it suck. :) Basically, instead of having a virtual person you have a virtual mob readily bugging you with support questions! My trick is to pretend that we’re going to open source the project. It never happens, but it forces me to avoid shotcuts.
– As much as possible, do it right. Refactoring internally is fine, but a published API is strict.
– Simplify the client code and configuration. Avoid making users suffer and increase adoption.
– Make code clean and dummy proof. Be strict on what you expose to users.
– Consider use cases outside of what’s currently required. Generalize the design.
– …
-Protect your reputation, don’t make it suck. :)

Basically, instead of having a virtual person you have a virtual mob readily bugging you with support questions!

]]> By: Kuniaki http://gojko.net/2007/12/26/bear-programming/comment-page-1/#comment-23306 Kuniaki Sat, 29 Dec 2007 10:33:54 +0000 http://gojko.net/2007/12/26/bear-programming/#comment-23306 Thanks to writing about ODD. (^^) > much more effective than just giving an answer straight away It's a good idea to use bear programming. I'd like to use it! Thanks to writing about ODD. (^^)
> much more effective than just giving an answer straight away
It’s a good idea to use bear programming. I’d like to use it!

]]>