Who are software developers working for? This can be considered as a simple question and you might start with some simple answers like “for company X” if you are an employee or “for myself” if you are freelance. If you work as a consultant or an outsourcer, you could also name your customer, the people that pay you or your company to develop their software. It is however less obvious that you will think of your “internal” customers and say that as a software developer you are working for the accounting department, unless your IT function is directly included in this department. Maybe you will also name somebody if you think that this person has a big influence on your work. Many people at Apple would think they were working for Steve Jobs.
Even if you think that you are working for a single person, the answer to the initial question could be more complicated as you should also include your colleagues in it: project managers, business analysts, developers, testers or future maintainers. Your work product and attitude impact these people, even if they might not influence directly your income. The visions, time horizons and interests of these persons can be very different and sometimes conflicting.
Usually, your customer wants a “cheap” solution quickly. Your project manager might value more you reliability. As long as you are sticking to your estimates, the internal quality of your code is not so important. Your colleagues are interested in the quality of your code, but they might also put a high value on your “social” skills, especially if you share some office space. Future maintainers of your code will value good design and readability. I have found in the “Refactoring Ruby Edition” book a good quote that says “Any fool can write code that a computer can understand. Good programmers write code that human can understand.” You deal yourself with your own conflicts of interest: deciding between a quick short term solution or a “cleaner” long term design that need more time to be realized. How much do you include in the current iteration, how much do you leave for future refactoring? Your options might also depend of the current situation in your career or job position. If you are a new, you could be taking some extra steps to improve the “perfection” of your work and establish your reputation. If you have just started working for a company, you don’t want that your first piece of code breaks the daily build. It has the same consequences after two years in a company, but you know that there is only one chance to make a first (good) impression. Having a 0,5% record of build failure after two years is different than having a 100% after day one.
A software developer works for many different people. You have to manage these conflicts of interest and know that imperfect results are often part of our daily job. I personally have this type of feeling when I have to deal with code I wrote more than 6 months ago. The frontier between making people that you work for, including yourself, happy or unhappy is sometimes thin, but don’t forget this rule that apply also to software development: “Don’t do to others what you don’t want others do to you”. Know who you work for and try to be good with them.
Nice idea, but missing the important point:
First and foremost, you do everything you do for yourself, either because you (think you) need it or want it.
The trick is to acknowledge the multitude of stakeholders, to be alert for changes and to know the order of priority they have – and how you prioritize them.
The things that kick our developer’s a**es are the ones we didn’t see coming. The ones we see ahead are already on the risk list, backlog, critical path, plan, …
I agree that you can give the “for yourself” or “for fun” answer to this question. This is often why we learn to program as solitary developers. My “important” point is that, as a professional, you should look beyond this self-centered perspective… at least a little bit ;O) As we might have often make the remark “why does he/she code this like that ?!?!?”, we might also consider that we could be this “he/she” for another developer.