Web
developer.

What the work involves

• Turning a finished design into something that holds up on a slow connection and an elderly handset, rather than only on a fast machine at a desk.
• Making certain that a change made for one business cannot quietly break another one. A good deal of what we run is shared, and shared things fail in groups.
• Finding out why something broke, usually by reproducing the problem before changing the code. A fix made before the problem is understood is still only a guess.
• Leaving work in a state where the next person, frequently you, months later, can tell what it does without asking anybody.
• Noticing when an instruction looks wrong and saying so, instead of carrying it out neatly.

What you would be judged on

Whether it still works later. Not whether it worked the day it shipped, because very nearly everything works the day it shipped. These sites run unattended for long stretches on behalf of owners who will never log in to check, so a defect that surfaces in month four is indistinguishable, to them, from one that was there all along.

The second measure is whether your changes can be undone. A small dull change that has been proven beats a large clever one that probably works, and what usually separates them is whether you could reverse it in a hurry.

Who tends to be good at it

Someone who checks their own work instead of assuming it is correct, asks questions when something is unclear, and values a reproducible bug report more than an untested idea.

What would make this the wrong job for you

If you want to set the direction as well as carry it out, the reporting line above will chafe. And if novelty is what sustains you, be warned that most of this is maintenance and correctness applied to things that already exist.