What can Contractors Learn from Employed Workers?

Having recently been on both sides of being a contract programmer and a fully employed programmer I think there is a fair bit each "side" can learn from each other.

Harder to Hide Things Under the Rug

If you work at a sizable company with talented peers it gets very hard to "hide things under the rug": such as bad code, poor documentation, ugly hacks, or non-unit tested code. If you're on a team, it's all about accountability. No one wants to make these kind of maneuvers, but when the pressure is on and the deadline is looming it gets easy to let things slip. Especially if you know that no-one is going to be looking under the hood. Just knowing that other programmers will be looking at my work is enough to "keep me honest". A good team environment uses code reviews to prevent these kind of mistakes. However, the one thing I dislike about code reviews is that they are after-the-fact. The programmer already spent the time to write the bad code (which will now have to be re-written ). That's why, when I was employed and was put in charge of leading a team, I implemented the code buddy system. When a new programming challenge is accepted ( a new feature or a bug ) I required programmers to find a code buddy to discuss a strategy to solve the problem with. These were usually really quick ( but in some cases could lead themselves to in-depth hour long conversations - a good sign that the code buddy system probably just saved days of re-work later ). After the code was completed, the programmer got with the same "code buddy" and did a quick post mortem on how it went ( did the plan work, etc ). This made code reviews much shorter and much more effective because the reviewer was already familiar with the basic problem and solution.

More than likely the client in a contracting situation is not going to be doing any code reviews with you. So how can you as a contractor prevent yourself from "hiding things under the rug"? First and foremost is to realize that you are just hurting yourself when you do "hide things", and you're going to end up paying for it in the long run. However, a few ways contract programmers can gain the same benefits:

• Contribute or start your own open-source projects. This will get you into the habit of having others looking at your code. The positive habits will pass into your other projects.
• Ask your clients if you can open-source components of their project and explain the benefits they will reap.
• Unit test, unit test, unit test. This won't catch everything, but unit testing is the closest thing to an automated code review.

Mentoring and Camaraderie

If you've ever had the pleasure of working with a developer more talented than yourself on a regular basis you know the difference it can make in your own programming. For many of the programmers I hired, it was the first time that they had worked with teams of programmers. It came as quite a shock to many programmers who were used to being the "guy/gal with all the answers". Those that lasted saw this as an opportunity to learn. After working on a large team of skilled programmers I know I personally was amazed at how rapid my skills improved.

Guess what my solution is for contract programmers seeking the same benefits? Same as above. Start or join an open-source project. You'll make mistakes, suggest stupid ideas, and be humbled more than once. But most importantly, you'll learn. Another, lower-impact and less time consuming alternative is to join developer mailing lists or IRC channels. They're a great glimpse into the conversations of often talented programmers.

Being Forced to Work with People You Don't Like

Yup, there are people in the world that you just won't like. When you're a contractor you have the freedom to cut out people you don't want to work with. Sounds ideal, doesn't it? The major problem is that you cut yourself off from learning about yourself and other people each time you do. I know that in my employed experience I've been forced to work with clueless project managers, indecisive clients, and programmers who were better at answering interview questions than actually programming. However, each time I was "forced" to work with someone I was "less than excited about" I learned something new. In some cases I learned something about myself such as what I value and don't value in different job functions. However, in most cases I discovered that my initial assumptions where either wrong, or overlooked other extremely valuable qualities. Don't forget that other people probably feel the same about you!

What can Employees ( and Employers! ) Learn from Contractors?

Investing Yourself

Being a contractor you are (with some exceptions) in control of your own success. And the only way you can be successful is if your projects and clients are successful too. Often employees are not as closely tied to the success of the project, or even their own individual performance. For example, say a contractor says they can do a project for $20,000 and then they spend over a year on it. They'll definitely be feeling it much more than programmer #467 on mega-project X that goes overbudget. I'm not saying that employed programmers don't care about success, it's just that their definition of success can be skewed. Employed programmers can end up defining success as coming to work on time, putting in their 40 hours, and completing their assigned tasks on time. Those qualities are important, but are meaningless if the project fails. Sure in the long run if projects keep failing you'll be out of a job, but being a contractor is much different. It's the difference between driving a car and riding in a car. Both people care about whether or not the car makes it to its destination (without any major accidents), but which one is more focused and attentive to the road?

Employers can help change this by giving their employees more control and stake in the project. Give meaningful performance reviews that are tied to rewards. Offer bonuses ( monetary or time off ) when teams excel. Keep employees informed of budgets and how their individual success and failure contributes to the overall success of the company ( and how that affects them right back). Don't forget that actions speak louder than words ( especially when you are trying to convince a group of people with above-average intelligence ).

Always Picking the Best Solution ( and Being Flexible to Change )

One huge ( and natural ) advantage that contractors have over employed workers is that they have the freedom and necessity to pick the best solutions for themselves. Freedom to pick the best tools, software, operating system, hardware, and processes is one huge draw of being self-employed. It's also a huge competitive advantage. Often times employed workers use what they are handed ( and can even be chastised for breaking the mold ). This makes some business sense. After all, it allows employers to make the most use of their money (eg. bulk purchases), and when everyone is using the same pipeline it cuts down on training and coordination. However, it cuts out opportunities to grow and improve. Don't forget that one of the key elements of evolution is mutation! Contractors certainly need every advantage they can get to survive and as a result are more willing to experiment, often find better solutions and tools ( cheaper and more effective ), and sit on the cutting edge more frequently.

What can employers learn from this? First, encourage employees to pick their own tools. They'll not only be happier they'll be more productive. Second, create ways for the best solutions to "float to the top" and the least successful solutions to "die naturally". A simple way to do this is to hold regular team lead meetings to share what strategies and tools are working and not working for them. Support individual teams' efforts to innovate and improve by making it easy for teams that consistently make good decisions on tools and processes to try out or purchase new ones.

Conclusion

So these are some of the lessons I have learned being on "both sides". The list is not conclusive, and there are definitely contracts and companies that don't fit what I've described here. However, I know I'm personally a better and more productive worker in either situation because of both experiences. Going from contracting to full-time employment ( or the other way around ) is like going to a foreign country. My advice: learn the language and the customs and share it with your less well-traveled peers.

Posted on Nov-15-2005