body blog

as an addendum to previous post: although i mentioned one of the johanna rothman’s articles in the list of links, she really warrants a separate mention.

i really, really liked her manage it! book (published by pragmatic programmers). at first it seemed a bit dry, compared to weinberg’s writing (he contributes an introduction), but the feeling goes away after a few chapters.

i just feel so comfortable with her take on project management – there is no agilist zealotry or flashy theatrics. she is indeed very pragmatic – she acknowledges different organizations and different projects and teams, she introduces options and alternatives and explains the reasons for each. there are practical tips as well as a larger overall motifs that drive them.

but back to subject of this post – a few weekends ago i spent a whole day combing through her excellent hiring technical people blog. once again, it is perfectly pragmatic, i especially enjoy her style as she explores the ideas, not necessarily presenting them as truths handed down from above.

compare this with joel – he recently cleaned up and released his writing on hiring (smart and gets things done – which i already purchased). i really appreciate many of his ideas, and i think he’s done a great service to the industry by popularizing them, but i do not find myself trusting him fully as a reader – there is too much glitz and posturing, desire to shock and awe. plus he keeps forgetting about being humble – he is an owner of a boutique software company – he is damn good at what he does, but it means just that.

in any case, i have ordered johanna’s book on hiring technical people. she also co-authored another book on project management from pragprogs – behind closed doors: secrets of great management, which i am yet to read.

finally, her site contains another blog on project management, as well as a collection of articles, links to her guest blogs on other sites, etc. she is also a regular at annual amplifying your effectiveness conference, which i really should be going to.

I am a little concerned that this space does not see much of the technical content in past few months. One of the main reasons is that the stuff I spend most of my energy on (and also the area where I currently learn the most) is organizational - everything from project delivery to team dynamics. It is surprising how much of it is dysfunctional, so all the reading that I have done in the past and seemed only marginally applicable now becomes incredibly relevant, supported by real-life examples.

One of the books I really enjoyed recently was Jerry Weinberg's "Becoming a Technical Leader." Very down-to-earth and personal book that is pragmatic, relevant, and simply rings true. Here's a couple quotes:

So perhaps a better leadership question is this:

If you had to take a trip with someone else driving, would you prefer a driver who

1. has never had an accident, but would likely be indecisive if an accident occured
2. has had an average of one accident a week, but was very adept at making decisions in emergency situations

Sad to say, many people seem to prefer (2). That's why Armistice Day has been replaced by Veterans Day. Peace is more difficult to organize, but war is more heroic. Really good organizing seems to lack drama.

Why is it that we reward programmers who work all night to remove the errors they put into their programs, or managers who make drastic organizational changes to resolve the crises their poor management has created? Why not reward the programmers who design so well that they don't have dramatic errors, and managers whose organizations stay out of crisis mode?

Organizing is not about solving problems, but avoiding them. Once you're in the throes of the problem, it's too late to do really effective organizing. Perhaps the biggest obstacle to effective organizing is our eagerness to reward ineffective organizing.

And another one:

A problem-solving leader's entire orientation is toward creating an environment in which everyone can be solving problems, making decisions, and implementing those decisions, rather than personally solving problems, making decisions, and implementing those decisions.

This is where I probably struggle the most in my current team (for many reasons) - giving away trust to acquire trust; in other words, delegating (the book has a whole chapter on it).

Weinberg's "Secrets of Consulting" is next (kudos to Muness for pointing him out to me).

Since our team at work has just been formed, we were asked to submit a few things that we should get, one of them being a list of books. The team does application/integration architecture and implementation. Below is the list I came up with in half an hour, escaping work on Friday night. A lot of these are available on Safari, but since most of these books are technology-agnostic (i.e. not reference texts), they age well, and therefore should reside on a bookshelf.

Must read/must have:
-----------------------------------
- Enterprise Integration Patterns : Designing, Building, and Deploying Messaging Solutions (0321200683)
- Patterns of Enterprise Application Architecture (0321127420)
- Peopleware : Productive Projects and Teams, 2nd Ed. (0932633439)
- The Best Software Writing I: Selected and Introduced by Joel Spolsky (1590595009)
- Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity (1590593898)
- Refactoring Databases : Evolutionary Database Design (0321293533)
- Working Effectively With Legacy Code (0131177052)
- Service-oriented Architecture : Concepts, Technology, And Design (0131858580)
- Enterprise SOA : Service-Oriented Architecture Best Practices (0131465759)
- Enterprise Service Bus (0596006756)
- The Pragmatic Programmer : From Journeyman to Master (020161622X)
- Refactoring : Improving the Design of Existing Code (0201485672)
- Head First Design Patterns (0596007124)
- The Mythical Man-Month: Essays on Software Engineering (0201835959)
- Design Patterns: Elements of Reusable Object-Oriented Software (0201633612)
- Rapid Development (1556159005)
- Hackers and Painters: Big Ideas from the Computer Age (0596006624)
- Service-Oriented Architecture : A Field Guide to Integrating XML and Web Services (0131428985)
- Applied Cryptography (0471128457)

Very good/really should own:
----------------------------
- Agile Software Development (0201699699)
- Extreme Programming Explained : Embrace Change (0321278658)
- Practices of an Agile Developer : Working in the Real World (097451408X)
- Agile and Iterative Development: A Manager's Guide (0131111558)
- The Inmates Are Running the Asylum : Why High Tech Products Drive Us Crazy and How to Restore the Sanity (0672326140)
- Behind Closed Doors. Secrets of Great Management (0976694026)
- Ship it! A Practical Guide to Successful Software Projects (0974514047)
- The Art of Project Management (0596007868)
- The Timeless Way of Building (0195024028)

Wishlist:
---------
- Thinking In Java (0131872486)
- Planning Extreme Programming (0201710919)
- Test-Driven Development : By Example (0321146530)
- Why Business People Speak Like Idiots : A Bullfighter's Guide (0743269098)
- Effective Java Programming Language Guide (0201310058)
- Domain-Driven Design : Tackling Complexity in the Heart of Software (0321125215)
- The Psychology of Computer Programming (0932633420)
- John von Neumann and the Origins of Modern Computing (0262011212)
- The Art of Software Testing, Second Edition (0471469122)
- Punished By Rewards: The Trouble with Gold Stars, Incentive Plans, A's, Praise, and Other Bribes (0618001816)
- The Cluetrain Manifesto: The End of Business as Usual (0738204315)
- Data Crunching. Solve Everyday Problems using Java, Python, and more. (0974514071)
- The Algorithm Design Manual (0387948600) 

Probably there are a few that I am missing, especially in the non-tech department. Some of these are also listed more for the culture shock value, to get people thinking. Also, these are not developers' books per se, considering that folks should have a developer background and the nature of the group's work.