The original point seemed to imply that having experience at fixing bugs wasn't a good thing. However, 99% of all the programming I do involve code someone else has written, even if only peripherally. Ie, maintenance (the vast majority of programming falls into this category), using a library, integrating software, porting software, etc.
Thus, I wouldn't necessarily want to a hire programmer who had little experience in debugging due to never creating bugs. I'd first think they were lying or a bit too arrogant to work in a team. But second, being able to deal with imperfect code is an essential skill. Being able to work without a specification or a formal list of requirements is a very useful skill also :-)
We used to have a spark generator that could greate about 3 cm long arcs (useful in vacuum leak testing). The acid test was pointing that at the chassis of some new instrumentation. It was usually quite enough to point it at the local ground.
--
fix (vb.): 1. to paper over, obscure, hide from public view; 2.
to work around, in a way that produces unintended consequences
that are worse than the original problem. Usage: "Windows ME
fixes many of the shortcomings of Windows 98 SE". - Hutchison
Heh ;). We had a somewhat safer version: a 24Vdc-operated contactor, whose (unquenched) relay contacts drove an inductive mains-operated load. We'd hook the 24V up to a flying lead with a stripped bare, untwisted/untinned end acting as a brush, and the contactor to a manky old aluminium plate. Brushing the wire lightly over the ally made the contactor chatter, made glorious sparks both on the plate and the relay contacts, and generated a burst of nasty noise. Anything that could survive close exposure to this was deemed shippable ;).
Later on we became a little bit more scientific and bought a Schaffner...
Nice post, sir. I see your point, and agree with some of it ;).
Pretty much. But there are levels of robustness that I'd expect of any piece of embedded code, just as Best Practice, and not as a function of a spec.
By this definition (which wouldn't be mine, incidentally), I agree.
I wouldn't expect code to run on an alien CPU without a review ("Best Practice"). However I wouldn't expect code to be so dependent on subtle features as to fall over when they shift - without at least some sort of defensive #pragma (and documentation) to guard against changes in any such features.
The product would then be out of functional spec, and cannot be expected to work correctly. Even the customer knows this ;). OTOH, I wouldn't expect a robust design to be sensitive to changes in independent clock frequencies.
I *always* include a rail-monitoring watchdogging reset controller, and always ensure the worst-case threshold is above the minimum Vcc. (Best practice again.) They're cheap, and guard against a huge range of problems. I feel naked and exposed without one.
This illustrates a philosophical point: if the kinds of environmental changes you describe can cause problems, then it's better to stop the code operating at all than to allow it to run incorrectly. (I've occasionally seen this idea extended to temperature sensors, but this is not done as routinely as monitoring rails.)
I'd buy that. But one can define the envelope and guard against going outside it.
However: most of the problems you've described are hardware-related. I was thinking more in terms of the software environment, but I accept that they are both inextricably linked. Both have to work ;).
I didn't mean to imply that troubleshooting was not a useful skill. Like you, I've done a fair amount of alien legacy code maintenance (although not
99%); my views are very much coloured by this experience ;). I think it's clear, though, that a tendency to rely on debugging as an alternative to good design is not a desirable attribute in a job candidate.
I've occasionally run into something like this. Occasionally there is a gulf between what I consider "Best Practice" and what is actually going on. Years ago I probably would have frightened them; in my dotage I've learned diplomacy and I figure I can help them. I love mentoring... it's how I learn too. Is this arrogance? Not sure. I consider myself a craftsman; I'm proud of my skills, certainly.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.