For the last few years, I’ve gone to work and written code, discussed architecture, attended meetings, etc. The job description has always been roughly the same – I’m a software developer. The job has always been different, though. The quality of software, the focus on design, the release process have all differed. It all boils down to one simple question: For whom do you create?

As far as I’m concerned, there’s three possible answers to this question:

• Clients
• Coworkers
• Customers

This is a considerable simplification, but most software groups really do fall into one of these three categories. Consulting companies and independent contractors create for clients. The IT division of a company creates for their coworkers. Those of us who sell software to end users are creating for customers.

Personally, I like to create for customers. I enjoy creating something for a broad audience. Design matters. Usability matters. When you release a product, it’s something you’re really proud of. Customers influence what you do, but you retain the right to make decisions. If a customer requests a feature, you can step back and try to figure out what they really want. If it doesn’t help the majority of your customers, you have the ability to say no. The ability to say no gives you power. Without it, you’ll end up with tons of features that serve a minority, and your software will become hard to use.

As you move up the list, you lose your ability to say no. It’s possible, though harder, to reject an idea when working for coworkers. Internal development teams really have a tough time saying that they won’t add a feature because it will make the software more complex. How do you say no to the senior vice president when she demands the feature? Usually, you just don’t. You create software that’s partially designed by people who know what they’re doing and partially designed by people making demands.

At the client level, you really just can’t say no. You can say, “it would be better if we did it a different way,” but when they say to you, “this is what we’re paying you for,” you’re stuck. I used to work for a company that worked with clients. They got around this by asking various clients what they wanted, then creating something that all of the clients would want to buy. It was very customized software, but customized to what they thought clients would buy rather than what they demanded. Basically, they turned client work into customer work because they had bad experiences working with clients in the past.

Every aspect of software development differs in these environments. Distributing software is much easier when you distribute to coworkers because the environment is consistent. Design is much more important when creating for customers because the software needs to appeal to the customer. Agility and breadth of knowledge are important skills for developers working at client facing software shops.

If you’re looking to work for a new company or are just getting started, think about who will be using the software you create. Think about what that will mean in your day to day tasks. Everyone has different interests, so there’s no wrong answer. I love making software for customers. Even on the days when it feels like everything is going wrong, I still get satisfaction from what I’m doing. At the end of the day, I’m proud of the software I create, and that’s what matters to me the most.