BlogSeries - Define Your Work Environment: The People With Which You Work

One of the things I have been thinking about is the caliber of the people I would work with.  I think there are several types I would like to work with (or probably already do and like it!).  As I mentioned at the start of this series, this is my definition of my perfect work environment.  This almost definitely is not what you would see as the perfect environment and that is okay. I invite you to come up with your own ideas and put them together.

 

Technical PM - While I have had the type of PM I really like so far, I see that Microsoft's PM's are highly technical and I think I would like to see something like that in my dream environment.  I would like at least a PM that has had a technical background and that is what I have now.  They understand what it takes to ship software and are there to remove the roadblocks along the way.  The PM is also understanding and a good friend.

Technical Management - I always like management to understand what it is that I do.  When they themselves can sit down and whip out some code, I am dually impressed.  This management can speak very eloquently and can remove the bigger roadblocks for you.  In fact, that is what I have seen as the role of management.  They exist to take away distractions and allow you to make decisions.  Joel sums it up nicely in his post about management during a talk at Yale:

If there’s one thing I know, it’s that managers have the least information about every technical issue, and they are the last people who should be deciding anything. When I was at Microsoft, Mike Maples, the head of the applications division, used to have people come to him to resolve some technical debate they were having. And he would juggle some bowling pins, tell a joke, and tell them to get the hell out of his office and solve their own damned problems instead of coming to him, the least qualified person to make a technical decision on its merits. That was, I thought, the only way to manage smart, highly qualified people.

At Least One Developer Who Can Serve as Your Mentor - This is the person I would like to think of as a senior developer to my current level. This is someone you can turn to when you need help.  I think this is important because Google sometimes only gets you so far.  Having someone there that has already "been there, done that" on some of the technical issues you might have is great. I have a bad habit of outgrowing my mentor, although when I did that in my current position they hired one in as an architect, so I have been learning again.  This person should challenge you and keep you from going into a rut of non-learning.

At Least One Developer on the Same Level as You - You want someone around who you can swap stories with and talk about things some of the "cowboys" are doing.  This is someone you can talk about things you're doing and they appreciate them better than anyone else (except maybe your senior level programmer). This person could even be your former senior.  You don't want to be where you agree on everything because neither of you will ever learn. You look forward to the debates and the talks about goals that are lofty, yet maybe reachable.

A Few Developers Who You Can Mentor - These are the people who are junior to you in whatever language/methodology/patterns you are using.  You could be junior to them in other languages/methodologies/patterns.  I don't list them as junior to me because they may very well be my senior in many things.  You show them things and as you work with them, you learn things from them. Many times these developers will offer a fresh perspective on things.  You want to eventually bring some of these developers up to the same level as you and possibly even have them outgrow you.  Showing others the way of the pragmatic developer is a delightful thing.

At Least One Cowboy Coder - This person can solve your troubleshooting concerns on legacy items and make patches to legacy systems fast.  This person...

...you know on second thought, NO cowboys.  In my perfect work environment all of the legacy stuff is written with single responsibilities and "DRY" and takes only moments to update.  I want to be around people who act like they are part of the team and actually SHOW that they are part of a team. Cowboys end up costing the company much more in the end due to increased maintenance costs. When management finds a cowboy that just will not convert, they remove them from the company.  These are people that are often regarded as the "best" people by management. Cowboys are sometimes known as the troubleshooters and not the troublepreventers.  The following comes from a post on testearly.com:

People like troubleshooters [aka cowboys] because they can solve a problem when a project is under pressure such as getting that emergency fix out the door immediately. Without question, you need troubleshooters on your project. However, many times the (exclusive) troubleshooters are the ones that cause the problem in the first place, be it a hard-coded value, duplication of code or a large complex method only they can understand.

 

While we are on the topic of people not to work with, lets talk about the attitudes of people you are around.  There should be an atmosphere of realistic positiveness.  Everyone around you should generally love what they do.  I am excited about what I do.  I want that to be shared by those around me.  The caliber of those around me would be intelligent, honest, and passionate people. 

The next post will be on what industry would be perfect to work in.

Print | posted @ Tuesday, December 11, 2007 11:23 PM

Comments have been closed on this topic.