Great Software Engineers

Great software engineers...

Coding Skills and Code Base Ownership

• write efficient, minimal, consistently laid out code
• first write a suite of unit tests that validates that code to be written will work as intended (where unit tests are approriate, such as for core production logic)
• provide an appropriate level of non-mechanical comments and documentation, especially for API/public function headers, and for tricky parts of the code
• do not ever cut and paste code
• have a fanatical sense of ownership for the software code base, keep it clean, and aggressively refactor
• initiate discussion with others if they bring a different style to the code base
  

Architecture, Design, and Coding Skills

• can architect scalable, reliable, high-speed services spanning multiple machines
• design a clean, layered architecture of packages so that each package can be independently tested
  
• write efficient, correct multi-threaded code

Continuous Learning

• develop and express informed strong opinions about how to develop software
• read programming journals, programming Web sites, Computer Science books on their own
• continuously learn and try out new ways to build software, and bring that to bear on the company's software

Communication

• clearly and continuously communicate what they are working on
  
• volunteer honest completion estimates and always (roughly) meet them
  
• work with others in the sense that they are willing to give and take in a discussion about how to structure a piece of code, but then stick to the group decision like a lamb afterwards (without any whining or undercutting the group decision!)
• initiate meetings with customers and team members when appropriate
• seek others' help whenever they are "stuck" rather than staying in a stuck state until someone inquires
• communicate if the requirements or spec are unclear and propose the clarification
  

Personal and Interpersonal Skills, Self-Motivation

• show great enthusiasm and positive attitude about whatever project they are on, and evangelize about it to others in the company
  
• intensely finish (just) the current task (without over-engineering the solution) then come back and ask for a new one (or even better, propose it)
• really are completely done when they say they are, having changed all code affected and done an adequate amount of automated and maual testing (rather than leaving it to others to find bugs, remove commented-out code, etc. etc. later...)

The Five Warning Signs in Programmer Resumes

Once upon a time I found myself doing phone screens for some really bad candidates (and I assigned those phone screen to myself, I should add). So, I went through those resumes to look for predictors of poor candidates.

1. No degree or no G.P.A. listed or the degree is from a school you have never heard of (the single best predictor). A friend told me later that not listing your G.P.A. if it's bad is a suggested practice. OK... but now that I know that it won't do you much good anymore...

2. They have a non-CS, non-engineering bachelors, then at most a CS masters from a non-top-twenty school. From my own experience as a Master's student at Georgia Tech, many of these candidates re-trained because they couldn't find jobs in their original profession, and they are often unbelievably bad in programming, algorithms, and complexity analysis. Another indication of this type of candidate is one that chooses not do a Master's thesis but to take classes instead.

3. They list a large block of technology acronyms early in the resume, or they have been consultants for a long time for tech companies (that could have hired them but chose not to), or they have an inexplicably long resume. Beware of someone who has one year of experience but a six-page resume full of technology acronyms. Really short resumes (I've seen 10-line ones) always indicate a great candidate in the ones I've encountered, like Ph.D. students that are dropping out but don't know how to market themselves.

4. Nothing on their resume sounds hard or like they were excited about it, or proud of it. They seem to have no initiative or drive ("I was responsible for X, I was tasked with Y, ...").

5. There are numerous spelling mistakes in the resume or sentences so ungrammatical that you don't know what they are trying to tell you. 1-2 spelling mistakes are OK - you are looking for utterly incomprehensible sentences. (Even as a non-native speaker you'll have to communicate in English at least in writing, e.g. in code comments and documentation.)

All obvious, I guess, in retrospect... what I recommend is to tally up the score and if a resume has more than two of these "warning signs" I would not even go to the phone interview stage...

So who really is a good "team player"?

Seems like everyone describes themselves as a "team player" these days. The label "not a team player" also gets thrown around a lot (and especially by people who are even less of a team player themselves). Which brings me to the topic of this post: so who really is a good "team player"?

I have experienced three types of people:

Type A: Don't have a strong opinion and don't have much to contribute to defining the project's direction, but are willing to follow your lead. This isn't terrible, and having a minority of this type on your team may even be desirable, but, let's face it, they're not that exciting to work with and you don't learn much from them. About 40% of the people I have worked with are of type A.

Type B: Have a strong opinion and a lot to contribute, but cannot compromise. This is terrible. (Let's assume here that the competing project direction is equally valid from a technical perspective.) You learn something from them, of course, but they can easily bring negative value to the team or outright destroy it. The typical course of events is

1. a meeting or a series of meetings is held in which there is vocal disagreement over the direction of the project
   
2. given that no consensus can be reached, a decision is made by the team leader or by the team majority against Type B's recommendations (sometimes Type B will pro forma "agree" so that "the team can move forward" with a tell-tale resigned look)
   
3. Type B displays one or more of the following symptoms (a) makes fun of or talks negatively about the project to outsiders, (b) defiantly hacks his/her vision into the code as fast as he/she can without discussion, (c) authors a competing paper or piece of software, (d) withholds talent, (e) becomes very quiet, (f) uses the phrase "I told you so" and delights in any trouble the project may experience in the future.
4. The team dissolves or Type B resigns (at least from the team project if not from the organization), or gets fired.
   

I have seen the above sequence at least ten times by now. If you have a Type B on the team and you get to stage 1 you will inevitably get to stage 4. Type B's comprise about another 40% of the people I've worked with.

Type C: Have a strong opinion and a lot to contribute, are willing to compromise on direction, then push as hard as they can in the direction the group has agreed upon. Yes, these are the team players. Get a group of them together and miracles happen in terms of innovation and productivity and bonding. These are only about 20% of the people I've worked with. I sure remember every one of them.

"Freakonomics", Compensation, and Motivation

I recently read "Freakonomics", which talks about human responses to financial incentives. One interesting insight was that telling parents that they cannot pick up their kindergardener late works a lot better if you don't define a financial penalty. This makes a lot of sense, of course - if there is a defined penalty it makes it sounds like it's OK to be late as long as you just pay for it... Another interesting insight was that real estate agents keep their own houses on the market 10 days longer and sell them for 3% more than the houses of their clients. It turns out that their financial incentive for selling for a slightly higher price just isn't enough reward for the extra work that would be involved. "Freakonomics" is overall a good read, as long as you don't look for an overall point or take-away, it's more like an essay collection.

Related, I also recently read "The Seven Hidden Reasons Why Employees Leave" that I stumbled upon in the management book section of a Borders Bookstore. Tremendously valuable book - people managers should go through the checklist of seven periodically to see if their employees are at risk. Unsurprisingly, it says that compensation - while often stated in exit interviews - is rarely the real reason people are leaving. That being said, it recommends paying your employees 7.5-12% above market average which makes a lot of sense to me - as people tend to perform to expectation and as they want to keep a good thing going they'll put in extra effort and are less likely to leave. Given how expensive it is to replace an employee that percentage premium will easily pay for itself. (I've heard it said that no one pulls their weight for up to a year in high-tech jobs with a lot of domain knowledge to be acquired; "Slack" has a good quantification of turnover costs) .

"The Seven Hidden Reasons Why Employees Leave" also talks about the various forms of variable pay that are used. I'm really on the fence as to if variable pay is a good idea for software development engineers at all (outside of a yearly bonus or options/stock grant I mean). The Dilbert cartoon's "I just wrote myself a minivan" in response to being paid per bug you fix in your code comes to mind. It's probably best to stick to slightly above average pay and benefits, and to then focus on rewarding your employees with informal recognition, promotions, work of their choice (a la Google's 20% rule), special time off after an intense deliverable, sabbaticals... but that will all have to be the topic of a future post...

Welcome to "development"!

So I've decided to start a blog. It is called "development" because it is about

• software development - effective software engineering
• idea development - innovation in collaborative tagging, structured Wikis, and lightweight ontologies
  
• team development - effective team building and leadership
  
• personal development - my own professional and private growth

I hope to regularly record my experiences and insights here, primarily for my own benefit - but you are more than welcome!