A Tip for Closed Source Software Houses: Hold off on giving Commit Access

In the preface of Kent Beck's fantastic "Extreme Programming Explained" book he spells out the core principles of XP:

• If code reviews are good, we'll review code all the time (pair programming). 
• If testing is good, everybody will test all the time (unit testing), even the customers (functional testing). 
• If design is good, we'll make it part of everybody's daily business (refactoring). 
• If simplicity is good, we'll always leave the system with the simplest design that supports its current functionality (the simplest thing that could possibly work). 
• If architecture is important, everybody will work defining and refining the architecture all the time (metaphor). 
• If integration testing is important, then we'll integrate and test several times a day (continuous integration). 
• If short iterations are good, we'll make the iterations really, really short—seconds and minutes and hours, not weeks and months and years (the Planning Game). 

As someone who is, not only a programmer, but responsible for making sure the correct products make it out the door on time, only three of these are critically important to me:

• If code reviews are good, we'll review code all the time. 
• If testing is good, everybody will test all the time.
• If integration testing is important, then we'll integrate and test several times a day

The others are important, but for different reasons and we'll touch on them later in this blog. 

The list is very similar to a story Anthony Robbins tells in "Awaken The Giant Within". Someone asked him "How do you become a great public speaker?" and he essentially said "Talk in public all the time". Poor testing and Integration are, without a doubt, the two things under our control that will make a software project go off the rails. Crappy code is the other. Test all the time. Integrate all the time. Read the code all the time. But how can you do this effectively? TDD and Continuous Integration are well solved problems. The real challenge is getting others to look at your code.

Many suggest Peer Programming. Most developers I know don't like it or can only handle it in small doses and management often have a hard time rationalizing it. Personally I'm not a fan. I find too much time is lost because the development thought process hasn't fully gelled yet. It's gratuitous programming. But the motivation is sound. In the Open Source world, Linus' Law states "With Enough Eyeballs, All Bugs Are Shallow." We need to have visibility on our code and, I think, Eric Sink puts it most succinctly: "Read the diffs!" This is a great way to read the code after the developer has had time to get their thoughts together. My issue is that it happens too late. Once the code is in the revision control system you have to make immediate decisions on how to rectify any problems you find during the review. Revert the code and repair or wait for the repair with broken windows in your source?

I prefer Jacob Kaplan-Moss's perspective on granting commit bits ... don't. If lower level developers cannot perform commits it forces the higher-level developers (the ones trying to enforce the religion of the project) to review their code. They are looking for your use of coding style, of enforced idioms and documentation. If ... IF ... you can consistently code to the norms of the company THEN you are granted commit bits to the revision control system. You can then review other developers code, merge their patches and mentor them on what is important. So, I would make a slight variation to Eric's article and change it to "Read the Patches". 

For the corporate software houses that never let their source outside the door, you can still have the benefits of the open source world by making code review a mandatory part of your development process. No projectors, no print outs, no meeting rooms. Just turn off commit access. Right now ... how many people on your corporate development project should have their commit bits revoked? 

Revoke and Review is my new mantra.

How Do You Hire Software Developers?

I want to learn more about the s/w dev hiring practices used by software companies.

When the time has come to bring a new body to the team, how do you execute that process?

First, let's consider the job description ... do you write this up in an "ad" format? If so:

• Does the hiring manager write the skills requirements?
• Do you focus on tactical skills or fundamental skills (i.e. Joomla vs. core OOAD)
• Can you give an example of how you separate your must-have and your nice-to-have skills?
• Do you prefer a strictly business format or hyper / jumped-up / sell-sell-sell ad? Do you find it makes a difference?
• Do you have any examples of great job ads you've seen, written or responded to?

With your fresh list of requirements, how do you get new resumes?

• We just put an add in the 'Careers' section of our website and they appear
• We put ad in traditional print media
• We pay for ads on generic job websites
• We pay for ads on IT-specific job websites
• We pay for ads on Language or Technology-specific websites (django/php/etc.)
• We attend job fairs
• We promote through social media
• We recruit from the open source community
• We recruit from our open source community
• We only use contractors

Which gives the highest response rate? Which gives the best candidates?

Now that you've got a stack of shiny new resumes and you've filtered out all the noise, what's next? Some people like to do a phone interview. For the purpose of this post, I'm not interested in communications skills, availability, salary expectations, previous employment red-flags ... I'm interested in how you test their technical ability over the phone. The phone can be a great way to get some high-level data on the candidate, including:

• Some generic technical questions to weed out the weak ones.
• Team dynamic questions about difficult interpersonal situations
• Thinking process for debugging
• Logic/lateral thinking tests
• General understanding of algorithms or major systems

Sometimes companies will ask the candidate to do a take-away programming quiz. This is a relatively simple programming challenge that most developers should be able to solve in a few hours. The intention is not to focus on ability to execute under pressure but, assuming you have have access to all your normal reference material and resources, does the candidate exhibit good code craftsmanship? Can they following a coding style guide? Do they have bad coding habits?

Then do you bring them in for a face-to-face interrogation? If so, what is the agenda? Is this a single person interview or do you take them through a gauntlet of technical and business interviews? Do you issue more "think on your feet" programming or logic problems?

Do you think a take-away programming challenge gives better or worse results than a "think on your feet" test?

What do you think of the Google/Facebook approach where the key to entry is to compete in their programming challenges before getting an interview?

Ultimately ... how do you hire developers? Is it working? Are you getting the best developers possible or getting stuck with duds? What would you change?

Developer Skill Sets: There is no such thing as an Intermediate Software Developer ...

At every company I've worked, the performance reviews have been structured nearly the same way. Software developers are graded on perhaps five different traits:

1. Technical skills - How well do you code?
2. Debugging skills - How well can you do maintenance work?
3. Communication skills - Can you write effective email, documentation and talk to your team?
4. Business/Marketing awareness - How well do you know the market this company plays in and the competitors?
5. Time management - Can you focus on the task at hand?

The weight applied to each category varied depending on the developers position of Junior, Intermediate or Senior, Team Lead, etc.

While these are not bad, in the general sense, there are two very large buckets in the above list where a multitude of sins can occur: technical skills and debugging. Fine granularity is important to software developers when it comes to performance reviews. If you want a developer to exhibit great code craftsmanship, then you need to be explicit on what you value and reward.

What Can We Do To Revitalize The Old Developers Performance Review?

Let's look at the table stakes; skills every developer you hire should be able to exhibit before you hire them! These are not skills you want to teach on the job:

1. Solid core CS skills - algorithms, complexity, architecture, underpinnings, etc.
2. Operating system essentials - scripting, backup/restore, boot process, device management, remote access
3. Programming as a passion - They program recreationally and perhaps have a few side projects on the go. They never got into CS just because they thought it was a sound career choice.

I assume I'm getting these skills from a good programmer right out of school. More is nice, but I don't assume much more. Code craftsmanship is rarely taught in school. It comes from the school of hard knocks. Once you've been beaten into submission by a chunk of code you can start to think about how to do things better.

If we break Technical Skills and Debugging Skills down, what could this list look like? Here are the things I like to see in every developer that I work with:

1. Adheres to coding style
2. Correctly applies our core development idioms
3. Follows language best practices (knows "Effective [Foo]")
4. Maintains useful documentation 
5. Writes effective tests
6. Writes tests that act as teaching aids
7. Is able to focus
8. Contributes constructively in development discussions
9. Experience with dynamically typed, static typed and functional languages
10. Can grok new topics quickly
11. Understands scalability concerns
12. Understands usability concerns
13. Effectively uses Patterns
14. Refactors in a timely fashion

(What would your list look like?)

You give me a team of developers that have those skills and we will conquer the world! Obviously not everyone, especially anyone straight out of school, is going to have that skill set. The above list is really a road map to great code craft.

Personally, if over the years, I was given this list in my performance reviews it would have given me a lot more career direction than just "better technical and debugging skills". I would have loved to learn that I need to focus more on "writing tests that act as teaching aids" and that I'm considered great at "groking new topics quickly".

Given a suitable list, any company should be able to delineate what they think it means to be a Junior, Intermediate or Senior developer.

Perhaps:

• Junior: < top grade in 5 topics, 
• Intermediate: top grade in 5 to 9 areas and 
• Senior: top grade in > 9 topics? 

(What would work for you?)

I have a theory about this: There is no such thing as an Intermediate developer! You are either Junior or quickly on your way to becoming Senior. If a developer stays in the Intermediate designation for too long the company should re-evaluate their role in the company. Sounds a little harsh but, assuming they are being given every opportunity to advance, why are they not? Not everyone can be an astronaut.

More so, these skills are applicable to nearly any company. Most programmer job ads have stuff like this:

• Knows Struts, Hibernate and JSP
• 3yrs experience with Powerbuilder 6.x and Oracle Form Blaster 
• Has Cake PHP experience

While I understand the motivation of getting a developer that can hit the ground running when you hire them, I would argue that a developer with the craftsmanship skill set listed above would be handle any of those specific domains with little problem. I would also argue they could probably do it better than developers that only focus on those specific tools. There needs to be a balance. Yes, confirm that the developer has the specific skills needed by your company, but more importantly, make sure they have the Code Craft skills to not do more harm than good!

Would you hire a developer to work on your desktop graphical C# application if they only have Ruby on Rails experience? Would you change your mind if they could demonstrate great code craft and general language diversity?

This is a hard problem. How can a developer prove they have good code craft? Sadly, I don't have a good answer for that right now. I don't think certification is the answer. The closest thing I can think is their demonstrable participation in an open source project. I'm open to suggestions here and will continue to post my thoughts on the topic as they come.

Is Code Craftsmanship The Only Thing?

If code craftsmanship was the only thing that mattered to a company we would all be contractors … disposable drones brought in to do a task as needed. But we know this is not the case. The longer you work at a company, the more you should learn about how the company makes money. Who are their competitors? How do their products differentiate? Who are the key customers? How do customers use the products you create?

A developers value in a company is multiplied greatly by their awareness of these factors. The other part the performance evaluation and hiring criteria needs to take these factors into account. A very valuable software developer is one that:

1. Designs with product vision in mind
2. Identifies pending delivery roadblocks in a timely fashion
3. Researches new technologies, languages and tools applicable to our product mix
4. Helps improve our operational efficiency
5. Contributes to our competitive advantage

Software developers that write solid code and understand the business are your greatest assets. Guard them accordingly!

Your thoughts?