RSS feed [root] /team /weblog /software_engineering



title search:


Sun Oct 15 13:26:02 HKT 2017


Cool diagram showing what slow us down -[..]m/blog/2012/01/faster-faster-faster.html

Usually, not a good idea to grow a team too big too soon -

Taken from Interview of Charles Simonyi ( ) , both the interview and the discussion are nice to read: , However, I will think if team work effective, 1+1 > 2

What we should really care about is effectiveness and not efficiency. and effectiveness is often inefficient -[..]our-obsession-with-efficiency-dan-north/

Handling emergencies or crisis situations
Handling work stress
Solving problems creatively
Dealing with uncertain and unpredictable work situations
Learning work tasks, technologies, and procedures
Demonstrating interpersonal adaptability
Demonstrating cultural adaptability
Demonstrating physical-oriented adaptability
-[..]2010/12/8-behavioural-dimensions-of.html <- a simple way to check what make team move faster, and things that slow team down.[..]icles/speed-in-software-development.html

The emergency team, in our understanding, was supposed to work as a point of entry for new developers, so they could know the codebase better. However, we didn’t get into account that newcomers needed to check on some things with the “old” developers. That hindered the work, and we eventually switched back to ~1 month rotation principle. -[..]/how-we-handle-bug-fixes-and-rework.html

Your team’s strength is not a function of the talent of individual members. It’s a function of their collaboration, tenacity, and mutual respect. -[..]-best-decision-we-ever-made-4c0a99728fde

(google search) (amazon search)
download zip of files only