Working or Done

Last night I woke up in the middle of the night, worried about a specific problem in our model layer that I was sure was going to cause problems if it wasn’t resolved. I tossed and turned until about 2:30 when I got out of bed and went downstairs and fired up the laptop.  

Helping the Team

Perhaps you have experienced the struggles of on-boarding new developers into an already large team in the middle of a project. Everybody who comes wants to have a say in how things are done, no matter how late in the process they get involved. Here is a litany of the types of commentary that I

Fixed Feature Bids

I have worked with a lot of teams made up primarily of contract developers. Not teams from consulting firms, but teams of “assorted” contractors from assorted staff augmentation firms. Folks that have been doing “short term” staff aug work for a while – (by my definition not longer than a year) – have an hourly

Stretch Role

Hiring has some words that we use to describe what we are looking for: 1) Been There, Done That – you want someone who can do this job with their eyes closed. 2) New Blood – you want someone who will never say, “that is not the way we do it here”. 3) Fresh Meat

R.A.T.S. Delegation

In writing a recent post for my other blog about planning and delegation, I fell into a set of 4 principles that define how to delegate successfully. The principles are Responsibility, Accountability, Trust, Success or RATS. Here is the excerpt from that post:   But in reality, delegation in leadership is not about getting other

Software Engineering

I am not a fan of software methodologies, third party libraries, hyper-generalized frameworks or other so called productivity enhancers within the software development process. At the same time, I abhor the idea of a thousand developers at a thousand keyboards creating a thousand screens, features, pages and trying somehow to stitch them together into a