Basically a programmer that comes in during the testing phase of a project and once a tester finds a bug, tracks down the cause. I enjoy this investigative process and am generally able to track down the cause of obscure bugs even in code that I have never worked on. I've done something like this internally in companies I've worked for, but I wonder if this is something people do on an independent contractor basis?
Tell me more
×
Programmers Stack Exchange is a question and answer site for
professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
|
|
Yes, this sort of job exists. It isn't a common one and it does take some specialized skills. It also has some certain requirements for it to exist. At a former place of employment, there was a department that startled the escalation part of customer service and engineering. It was called "sustaining engineering" (this is not an uncommon term for it - I can find references to my former employment and other companies searching on this job title) and had the role of identifying, fixing (both one off patch releases and reincorporating the code back into the main engineering mainline) the software. Sometimes this job involved travel (it was hard to remotely debug a core file through an air gap at a military site). It also involved building tools to make the identification of bugs faster for the front lines of support. The key to this department's survival was who it was answerable to - it was part of customer service. Engineering was driven by sales and marketing. They wanted new features out in the software, and they wanted the features out quickly. Thus, the engineering department wasn't active in the software once the release went out. On the flip side, the customer service department had to deal with the problems that were out there - and this is where the department was. If there was a bug in the software out there now, they had to track it down - reading core files, stack traces and sources to figure out exactly why the problem occurred and how to stop it for this particular customer now. Do note, that every person in the department had at least half a dozen years in the company - it wasn't one that consultants and contractors were brought into. It was mostly hired from within - from engineering (in this case, it paid better). |
|||
|
|
I've most usually seen this role called Support Programmer, and as other answers make clear, it's not generally seen as a high-status role, despite that fact that it is often the most technically demanding work available in a given organisation. I believe this latter point is one made in good old Facts and Fallacies. Being good at this work and enjoying it makes you a valuable rarity, but convincing people of that to a sufficient extent to do it as an independent contractor will not be easy; not least because in order to sell your services, you need people to acknowledge that they have error-prone and difficult-to-work-with software, and the people you need to sell to (or at least get approval from) will often be the people that wrote that software in the first place! If you have a good network of former employers and contacts, you might be able to build a good reputation, but it's getting that first independent gig that will prove hardest. And even then, be prepared to be resented by the devs whose software you are called in to troubleshoot... |
|||
|
|
I have at least 2 professors that do this on a regular basis for the Government (USA). And I know of, and have applied for QA positions, and I'm sure you know of this since you say you've done it internally. It all depends on how you market yourself, since I'm sure you can do it as a consultant based on what I've seen from my professors and coworkers. |
|||
|
|
Hot Fix TeamThis is a role often associated with a team of developers responsible for sending out quick fixes of customer reported issues. Often refer to as the hot fix team. They can bypass testing, code reviews, etc. to get the fix to the customer as quickly as possible. Their changes may or may not be rolled into the trunk by the development team. The developer will be responsible for reproducing the bug, but it's not required to automate the testing of that bug. They will then investigate the issue, fix the code and then there will be a hot fix issued only to the customers impacted by the bug. Hot fix teams aren't always populated with senior developers. They are mostly a team of developers who respond to the needs of management, and often come from a testing background. They should have a strong interest in learning how things work, and not afraid to get into source code they've never seen before. |
|||
|
|
|
Yes, at many large software companies they are called "Software Development Engineer in Test" (SDET). If you are good at it, just go to Google, Amazon, Microsoft, etc... and apply Or you could just get your Stack Overflow profile in the top 30% and setup your Stack Overflow careers profile. There are 6 SDET postings on http://careers.stackoverflow.com at this moment. I have a document from my company describing the SDET role, but I am afraid of inadvertently breaking my NDA. Email me if you would like more info. My basic synopsis is: SDETs have the same technical requirements as SDEs but they spend much of their time a.) checking the quality of code (i.e. via review board), b.) writing tools to automate build processes, c.) writing development tools, d.) maintaining and yelling at developers who write bad unit tests etc... At the company I work for, we have a really well designed set of development and deployment tools. SDETs also write many of these tools. As for tracking down bugs, that is often also a Support Engineer at many places. However, that position is much less "Sofware Developer"ish. |
|||||
|
|
In short: i would call it by different name. The question description for work described
Yes, there are professional software developers that are specialized in troubleshooting, tuning and maintaining real-world applications for variety of issues or bugs (such as Wikipedia defines troubleshooting as a repair of failed products or processes as quoted below:
|
||||
|
|
