Is a programmer supposed to be self-sufficient

project-managementtesting

At my current workplace, we don't have any testers, the rationale for that from the management being: "if we had testers, you wouldn't test your own code at all". This kind of thinking seems to be detrimental to product quality, as while I do test my own code, there are a lot of things that I will miss just for the fact that I know the system inside out and don't know how to use it "wrong". Black box testing doesn't really work as I subconsciously avoid the pitfalls that a dedicated tester would fall into. A lot of my time goes into fixing bugs that have slid into production code and found by the end user.

The system in question is large but is developed solely by me. This has also caused some managemental duties to fall on my lap, such as defining schedules and working on specifications.

Should these kind of tasks be my responsibility? I see myself strictly as a programmer and nothing else. And if these are my responsibility, to what extent? When is a project so large that it requires testers? Should a programmer have to refine the specification, worry about management of the project or even provide customer support?

Note

Some might have got the impression that I am against widening my responsibilities – that is not the case, I'm eager to get a role that involves more management duties, but currently it is not in my job description. Until I'm officially employed as such or the additional duties start showing in my paycheck, I'm going to think of myself as 'just' a programmer. Unfortunately, as a junior developer, shifting to managerial duties is not going to happen very soon.

Excellent answers so far, keep them coming if you have something to add or personal experiences to share!

Best Answer

You do have testers. Only, you call them "end users." This is detrimental for all the reasons you describe; no matter how conscientious a coder you are, you're simply never going to be able to do a good enough job overcoming your own preconceptions about how the code is "supposed" to be used for you to find all the ways it can screw up.

You need to re-open this issue with management. By this point, it sounds like you have some hard data to back your case; the current hands-off approach to Quality Assurance both wastes your time and compromises your users' experience. You need to be careful in how you present this so that it's clear this is a structural problem and not a case of "You just suck at testing," but it sounds like a discussion that needs to happen.

It sounds like you're coming to a crossroads with this employer. If you're intent on remaining a programmer and nothing else, you may need to start pushing back and requesting that they start getting you the help you need to take some of the managerial tasks off your plate, either by bringing in somebody new or by expanding an existing co-worker's responsibilities. ("This isn't what you hired me for, and these tasks aren't going away. Time I spend doing this stuff badly is time I'm not spending on what I'm good at.") But that may or may not be realistic. Do you think you could handle moving into to a more managerial role if they gave you the resources and authority you'd need to get the job done right?

As to how big does a project need to be before it needs testers, I'm not sure how to precisely define that line, but I definitely think you've crossed it. You're spending more time than you'd like fixing bug reports coming in from actual users; to me that says it's time to spend more effort stopping the bugs from getting to the users in the first place.

Related Topic