Beginners and experts (Batchelder blog post)

[Steve D'Aprano]

On Fri, 29 Sep 2017 08:34 pm, D'Arcy Cain wrote:

> On 09/29/2017 03:15 AM, Steve D'Aprano wrote:
>> "Carefully-designed experiments" -- yeah, that is so totally how the coders
>> I've worked with operate *wink*
>> 
>> I think that's an awfully optimistic description of how the average
>> programmer works :-)
> 
> Better not hire average programmers then.

Okay.

Can I consider the top 10% of programmers, or must I only consider only those in
the top 1%?

If I'm on a budget and the code isn't that critical, can I consider those in the
top 20% for junior roles?


> I do "Carefully-designed 
> experiments" to find non-obvious bugs so I guess I am not average.

Okay.

By the way, *in context* (before you deleted the original text) there was no
mention about "non-obvious bugs". Greg Ewing and Chris Angelico were talking
about the general difference between the process used by novices and that used
by experts and how beginners often attempt to fix bugs by making random
changes, while experts don't.

I've certainly seen beginners make arbitrary changes to unrelated parts of their
code trying to fix a bug. Often many different changes all at once. So that's
another difference between beginners and experts:

- experts have the self-control to make only one change at a time, 
  when it matters; beginners don't know when it matters.


Oh, and I'd like to make a (moderate) defense of a kind of "bug fixing by random
perturbation". Obviously making unrelated, arbitrary changes to code is bad.
But making non-arbitrary but not fully understood changes to relevant code
sections can be useful in (at least) two scenarios.

(1) I know there's a bug in a specific chunk of code, but I'm having trouble
working out where. When everything else fails, if I perturb the code a bit
(reorder lines, calculate things in a different order, rename variables, etc)
it may change the nature of the bug enough for me to understand what's
happening.

That's not *random* or *arbitrary* changes, but they are changes not directed at
any specific outcome other than "make the code a bit different, and see if the
error changes". I'd like to say it is the debugging technique of last resort,
except its perhaps not quite as *last* resort as I'd like, especially in code
I'm not familiar with.

Its an experiment, but not really "carefully designed". Its more like "what
happens if we hit this bit with a hammer?" except that programmers, unlike
engineers, have the luxury of an Undo switch :-)


(2) I hate off by one errors, and similar finicky errors that mean your code is
*almost* right. I especially hate them when I'm not sure which direction I'm
off by one. If you have unit tests that are failing, sometimes its quicker and
easier to randomly perturb the specific piece of code until you get the right
answer, rather than trying to analyse it.

"Should I add one here? Maybe subtract one? Start at zero or one? Ah bugger it,
I'll try them all and see which one works."

This is only effective when you have exhaustive tests that exercise all the
relevant cases and can tell you when you've hit the right solution.

On the other hand, sometimes the bug isn't as clear cut as you thought, and you
really do need to analyse the situation carefully.


> I get the impression that many people here are above average too.
> 
> Personally I think you are being pessimistic about "average"
> programmers.  Perhaps you just know the sloppy kind.

One needs to only look at the quality of software, whether open source or
commercial closed source, to feel pessimistic about the ability of even
excellent programmers to write good, secure, bug-free code.

The complexity of code increases faster than our ability to manage that
complexity.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.