Programmers vs Developers
|A "programmer" is someone who does nothing but code new features and [if you're lucky] fix bugs. They don't write specs. They don't write automated test cases. They don't help keep the automated build system up to date. They don't help customers work out tough problems. They don't help write documentation. They don't help with testing. They don't even read code. All they do is write new code. In a small ISV (Independent Software Vendor), you don't want any of these people in your company.|
Instead of "programmers" (people that specialize in writing code), what ISVs need are "developers" (people who will contribute in multiple ways to make the product successful).
In a small ISV you can't afford to have people who think their only responsibility is writing code. There are far too many other things to be done, all of which are critical to having a successful product. If you were a BigCo, you would just hire more specialists until every job function is covered. But as a small ISV, what you need are fewer people who are more versatile.
Boundaries vs. Flexibility
This is a really important difference between small companies and big ones:
By the way, these are two very different cultures and ugly things can happen when they intersect. Flexibility and boundaries don't mix very well. A person who has been successul in one of these cultures often stumbles badly when they transition to the other one.
- In a small firm, most people wear multiple hats. It simply isn't feasible to have a person who focuses on just one small area. Small companies need versatile people who are content and capable to step in and do whatever it takes to help the company succeed. One accountant or bookkeeper handles basically everything. There is often a utility infielder who is always busy but nobody knows what they do. The key concept here is flexibility.
- Big companies have more specialists. Payroll is different from "accounts receivable" which is separate from "accounts payable". Architects do design. Programmers write code. Technical Leads manage programmers. Program Managers keep the spec and schedule. Product Managers do positioning and message. Evangelists do, er, well, nobody really knows what evangelists do. :-) Anyway, each person has a specific, well-defined job. The key concept here is respect for boundaries.
In a small ISV, every developer is first and foremost a programmer. The bulk of their time should be spent writing code and fixing bugs. But every developer also needs to be involved in other areas such as the following:
These things are the difference between a programmer and a developer. The developer has a much larger perspective and an ability to see the bigger picture. The programmer writes code, throws it over the wall to the testers and waits for them to log bugs. The developer knows it is better to find an fix bugs now, since he just might be the one talking to the customer about it later.
- Spec documents
- Configuration management
- Code reviews
- Automated tests
- Solving tough customer problems
When your team evolves from programmers to developers, your pecking order may change. Your best developer may not be the person who usually gets thrown the really tough problems. A programmer of amazing talent can be a lousy developer. Coding is a necessary but insufficient part of being a developer. Similarly, the less gifted members of your team can still distinguish themselves as excellent developers through their contributions to the non-coding parts of the product.
Author : Eric Sink
Source : Eric's Weblog