download here
Sun Apr 13 01:06:38 HKT 2008
From /weblog/software+engineering/team
Believe me, the objective was not to make decisions, but to create
the right environment so that the right decision would be made. http://tech.groups.yahoo.com/group/leandevelopment/message/1952 A nice set of questions to ask for a leader - http://jchyip.blogspot.com[..]3/questions-on-influence-and-growth.html In short, don't put your shoes on others' foot - http://www.inc.com[..]earned-in-the-army_Printer_Friendly.html 4 types of leadership style, well, I think he model leadership a little too simple - http://softwarecreation.org[..]s-the-best-leader-for-the-software-team/
(google search)
(amazon search)
Tue Mar 18 01:25:31 HKT 2008
From /weblog/software+engineering/team
1. Hiring is the most important thing you do at work and always hire people smarter than you 2. A manager’s success is all about making his/her reports successful in what they do 3. You cannot move up in the company unless you train your replacement 4. It is all about “relationships” and not “products” 5. Only viewpoint that matters is that of the customer 6. There is a big difference between products that customers will “buy” vs. products customers “like” 7. Be “market driven” and not be “marketing driven”. There is a big difference 8. Have technical and business arguments with colleagues as long as none of it turns personal 9. Have meetings before the meeting 10. Trying and failing is a lot better than failing to try 11. Execution is the key to being successful http://gopalshenoy.wordpress.com[..]arnt-at-solidworks-in-the-last-11-years/
(google search)
(amazon search)
Tue Mar 18 01:25:31 HKT 2008
From /weblog/software+engineering/team
XP style office setup http://www.scissor.com/resources/teamroom/ http://www.xp123.com/xplor/room-gallery/index.shtml Programmers who have good working conditions and a personal investment in the end result will often volunteer overtime at crunch periods, or just when they have a particularly thorny problem to overcome and don’t want to go home until it’s done. http://fishbowl.pastiche.org[..]ings_will_continue_until_morale_improves Use of kanban - http://www.infoq.com/articles/agile-kanban-boards
(google search)
(amazon search)
Fri Jan 04 11:23:56 HKT 2008
From /weblog/software+engineering/team
work from home guideline from sun - http://blogs.sun.com[..]y=designing_from_anywhere_best_practices Comment about working as independence consultant, a good reading that discuss some issue at HK or China limited this area of jobs - http://blog.nona.name/200801251.html
(google search)
(amazon search)
Fri Jan 04 11:15:47 HKT 2008
From /weblog/software+engineering/team
This is an excellent arguement -
It's only worth pairing on complex code, rote code yields no advantage.
I think there is a point to this - pairing is about improving design and minimizing mistakes. Rote code that's simple to write yields little opportunities for pairing to make a difference.
Except this: writing boring rote code is a smell. If I'm writing boring repetitive code it's usually a sign that I've missed an important abstraction, one that will drastically reduce the amount of rote code to write. Pairing will help you find that abstraction.
http://martinfowler.com/bliki/PairProgrammingMisconceptions.html Common pitfall of pairing http://blog.jayfields.com/2007/09/distracted-pair.html http://blog.jayfields.com/2007/09/uninterested-pair.html http://blog.jayfields.com/2007/08/spellchecking-pair.html Look like a good way to start pair programming http://magpiebrain.com[..]02/13/pairing-pattern-ping-pong-pairing/ http://c2.com/cgi/wiki?PairProgrammingPingPongPattern Discussing pair programming - http://www.codinghorror.com/blog/archives/000999.html Experience sharing of working with expert - http://dreamhead.blogbus.com/logs/13258146.html here is the disclaimer of the blog http://dreamhead.blogbus.com/logs/13258146.html
(google search)
(amazon search)
Sat Dec 08 15:18:41 HKT 2007
From /weblog/software+engineering/team
One nice article about teamwork: Directing (hi directive + lo supportive, for "enthusiastic beginners") Supporting (hi directive + hi supportive, for "disillusioned learners") Coaching (lo directive + hi supportive, for "reluctant contributors") Delegating (lo directive + lo supportive, for "peak performers") http://www.cmcrossroads.com[..]bbthreads/showflat.php?Cat=&Number=64809 Is it a people problem or process problem - http://blog.nayima.be[..]01/21/people-problem-or-process-problem/ importance of teamwork - http://www.butunclebob.com[..]leS.MichaelFeathers.ProgrammingOnYourOwn 5 Dysfunctions of a Team - http://www.anticlue.net/archives/000279.htm A Leaner Start: Reducing Team Setup Times - http://www.infoq.com/articles/pat-kua-onboarding-new , I think article "letting-go" is really insightful - http://www.thekua.com[..]007/09/24/onboarding-strategy-letting-go A good explanation of what is courage, and the result of didn't have courage. It also mention a bit of how to bulit courage within the team, but not much about it - http://www.xprogramming.com/xpmag/NotXP.htm A potential issue of focus too much on people, rely on few heros - http://jchyip.blogspot.com[..]12/people-over-process-misses-point.html Our agile process requires people to spend the effort to listen and talk to each other, working closely. You have to be a people person to like it. It doesn't suit sociopaths. Accidently hiring a sociopath is going to make XP impossible. Trust me, I know. To me this is XP's fundamental weakness. http://jchyip.blogspot.com[..]12/extreme-programmings-fundamental.html
(google search)
(amazon search)
Sat Nov 17 10:03:59 HKT 2007
From /weblog/software+engineering/team
Have the idea of starting minor interest group / user group of various technology inside a company. Hope someday it happened and these information help http://egjug.org[..]ow-to-make-a-successful-java-user-group/ Fishbowl (conversation), setup a small group from large group for team discussion - http://en.wikipedia.org/wiki/Fishbowl_%28conversation%29 http://jchyip.blogspot.com/2007/11/fishbowl-standup.html
(google search)
(amazon search)
Thu Aug 02 01:44:38 HKT 2007
From /weblog/software+engineering/team
Nice story and nice photo, really a master skill to drive the team to have same vision - http://www.taylor.se/blog/2007/06/26/team-vision/ Team Decisions: Consensus versus Consent, closely related to team vision establishing - http://www.maxwideman.com/musings/consensus.htm
(google search)
(amazon search)
Sat May 19 16:24:15 HKT 2007
From /weblog/software+engineering/team
Recently I help the company offshore some work to CN developers, many difficulty I've encounter, most difficult one is it is hard to share the vision and big picture to CN developers. This article mention a few good notes http://martinfowler.com/articles/agileOffshore.html , the one I think I am lacking is having short meeting with them often. I will see if we can have video conferencing so that we are easier to meet. The other tips here - http://www.theserverside.com[..]_id=45367&asrc=EM_NLN_1439070&uid=703565 but I think the tips list is too long and probably only apply to large enterprise
(google search)
(amazon search)
Sat Mar 03 12:43:34 HKT 2007
From /weblog/software+engineering/team
Various tools and approach to Preserving Knowledge, I think the best is to build custom webpage like what I does :-) http://discuss.joelonsoftware.com[..]iscussGroup=3&cReplies=#discussBody12480
(google search)
(amazon search)
Thu May 11 19:10:00 HKT 2006
From /weblog/software+engineering/team
Taken from Interview of Charles Simonyi ( http://www.shamit.org/charles_simonyi.htm ) , both the interview and the discussion are nice to read: http://discuss.joelonsoftware.com/default.asp?joel.3.341396 However, I will think if team work effective, 1+1 > 2
(google search)
(amazon search)
|