Re: Beginners and experts (Batchelder blog post)

[justin walters]

On Fri, Sep 29, 2017 at 12:14 PM, Bill  wrote:

>
> I'll write for the possible benefit of any beginners who may be reading.
> I guess by definition, if one still has a "bug" it's because one doesn't
> quite understand what the code is doing. And I would say you should lose
> your license if you "fix something", and don't understand why it works
> (within reason of course--some mystery's of library functions should
> probably remain so forever). So ADT (Any Damn Thing--I just made that up
> that acronym) you can do to understand your code better is fair game! : )
>   In fact, in my experience, the sooner you start getting a little bit
> angry, the sooner you'll get to the heart of matter.  Usually, what looks
> like a long route, isn't, in the end.  Don't be afraid to write *really
> descriptive* output statements, and do so even though you "don't need to".
> Besides for making you more productive, it will help soothe you : )
>  Beginners almost never need to...  I think that getting out of the
> beginner phase requires developing a certain amount of humility.  Just wait
> 5 or 10 years, any look back, and see if what I've written isn't more true
> than false.
>
> The only part I am unsure of is whether you are supposed to get a little
> big angry or not (YMMV).  I find 2 cups of coffee about right. That is, 2
> before and 2 after lunch. Of course, that does not include "meetings".
> --
> https://mail.python.org/mailman/listinfo/python-list
>

Reminds me of a bug I had to chase down recently.

I've been working on the front-end of this web application for a while.
It's an SPA built
with Vuejs. The bug arose in the login workflow. Basically, it went like
this:

client loads login screen -> user enters credentials into form and submits
-> client sends credentials to server ->
server verifies credentials -> server sends back auth token -> client
receives auth token and stores it ->
client redirects user to home screen -> home screen makes get request for
some data

Now, this worked perfectly fine everywhere except for Safari 9.1 on OSX.

A user could login just fine on Safari 9.1, but after that, no requests
would complete. Safari's dev tools
were no help because they were not showing any errors or any failed
requests. I checked the server logs
and found that no requests were even sent.

It took me 2 days to figure out this bug. I tracked it down to the function
that injected the authorization
header into all requests if the user was logged in. Based on
troubleshooting, I knew it couldn't be anything else.
That said, I was still confused because this worked on literally every
other browser(even IE 9).

After searching for people with similar problems and coming up with nothing
I got to thinking about the
asynchronous nature of JS. So, out of sheer frustration I moved the line of
code that stored the auth token
from one function to another, booted up my testing environment, and it
worked.

So, the bug was basically because Safari was waiting for a specific
function call to complete before
it committed the token to local storage even though the line of code that
did so was within said function.

So, two days worth of work to move a single line of code from one function
to another. You can only imagine
the tirade of curse words directed at apple during the above calamity.

Had I simply written a console log for every function down the chain, I may
have been able to find the
cause of the bug more quickly.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[Gregory Ewing]

Bill wrote:
Don't be afraid to write *really descriptive* output statements, and do 
so even though you "don't need to".


Yeah, often when I'm writing something tricky I'll proactively
put in some code to print intermediate state to reassure myself
that things are on track. Being more verbose with them than I
think necessary can save a few trips around the debug cycle.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[Gregory Ewing]

Steve D'Aprano wrote:

(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.


> Its an experiment, but not really "carefully designed".

I think it's more carefully designed than you give it credit for.
You still need to understand quite a lot about the program to know
what changes are likely to yield useful information, and how to
interpret the results.


Its more like "what
happens if we hit this bit with a hammer?"


In biology it's called a "shotgun experiment". "If we blast this
bit of DNA with radiation, what part of the organism does it
mess up?"


(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.


With off-by-one errors it's still pretty specific -- start
the loop at 1 instead of 0, etc.

But in cases like that I prefer to rewrite the code so that
it's obvious where it should start and finish.


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


And then there's "If you write the code as cleverly as you can,
you won't be smart enough to debug it!"

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[Chris Angelico]

On Sat, Sep 30, 2017 at 5:14 AM, Bill  wrote:
> I'll write for the possible benefit of any beginners who may be reading.  I
> guess by definition, if one still has a "bug" it's because one doesn't quite
> understand what the code is doing. And I would say you should lose your
> license if you "fix something", and don't understand why it works (within
> reason of course--some mystery's of library functions should probably remain
> so forever).

My programmer's license comes from MIT and it can't be lost.

https://opensource.org/licenses/MIT

Kappa

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[Chris Angelico]

On Sat, Sep 30, 2017 at 2:42 AM, Steve D'Aprano
 wrote:
> 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 :-)

Sometimes, when I'm debugging something with one of my students, I'll
say something like "Let's do something stupid". That prefaces a
suggested change that is, perhaps:
* logging something that, by all sane logic, cannot possibly be wrong;
* altering the form of a piece of code in a way that shouldn't affect anything;
* changing something that logically should break the code worse, not fix it;
* or worse.

They're still not "random" changes, but when you exhaust all the
logical and sane things to try, sometimes you do something stupid and
it reveals the bug. I wouldn't EVER tell someone to assume that
they've hit a language or library bug - but if you make a meaningless
change and now it works, maybe that's what you've hit. It does happen.

"Why does my program crash when it talks to THIS server, but it's fine
talking to THAT server?"

... half an hour of debugging later ...

"Okay, so THIS server supports elliptic curve cryptography, but THAT
one doesn't. Great. That still doesn't explain the crash."

... two hours of debugging later ...

"Huh. Maybe this library has a bug with ECC?"

That's pretty close to what happened to me today, with the exception
that I spent less time on it (because I had the library's source code
handy). But in any case, it's a good reason to occasionally try
something stupid.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: 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.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[leam hall]

On Fri, Sep 29, 2017 at 10:52 AM, justin walters  wrote:

>
> I got through writing all of the above without realizing that you meant you
> wanted to build a
> desktop application and not a web application. Though, I think the advice
> is still helpful.
>
>
Yes and no. Seriously thanks!

I am at first targeting a desktop app just to be simpler and to push me to
learn Tkinter. However, it's more likely to end up a simple web app once I
learn enough Bottle/Flask to make it work. Or I may just skip Tkinter for
the nonce and see if I can do it with web forms.

Leam
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[justin walters]

On Fri, Sep 29, 2017 at 2:57 AM, Leam Hall  wrote:

> On 09/27/2017 10:33 PM, Stefan Ram wrote:
>
>Some areas of knowledge follow, a programmer should not be
>>ignorant in all of them:
>>
>
> ---
>
> Stefan, this is list AWESOME!
>
> I have started mapping skills I have to the list and ways to build skills
> I don't have. Last night I started working on a project that has been on my
> mind for over a year; taking a CSV list of game characters and putting them
> into a MongoDB datastore. Now I need to figure out how to build an
> interface for CRUD operations using Python, pymongo, and maybe Tk.
>
> I appreciate the structure your list provides. Thank you!
>
> Leam
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>

Python web backends just happen to be my specialty. I do mostly Django, but
it doesn't
mesh well with MongoDB. Well, it does if you still use an RDBMS forsome
things.

I can recommend the following:

- Flask: http://flask.pocoo.org/
Small and light But not tiny. Not really fast, not really slow. Not a
ton of batteries included.
Tons of third-party extensions.

- ApiStar: https://github.com/encode/apistar
New kid on the block. Specializes in APIS. No template integrations.
Best for serving
JSON through a RESTful interface. Fairly quick, but not blazing fast.
Has the upside that any
web API can be exposed as a CLI API. Not a ton of third party
extensions available. Would
be a good choice if you don't want to build a desktop application
instead of a web application
as it will help design the API that something like Tkinter will sit on
top of.

- Sanic: https://github.com/channelcat/sanic
Another new kid. Python 3.5+ only. Uses the new async capabilities
quite heavilly.
Based on falcon. Blazing fast. No batteries included. Small number of
fairly high
quality third-party extensions.

- Django: https://www.djangoproject.com/
The old workhorse. Mature and proven. Best choice for reliability. Not
fast, not slow.
Huge collection of third party extensions ranging in quality. Though,
it is pretty heavilly
integrated with it's relational Db backends. If you decide on this, you
would need to
use postgres/sqlite/mysql to store all of Django's built in model
classes(tables).

I got through writing all of the above without realizing that you meant you
wanted to build a
desktop application and not a web application. Though, I think the advice
is still helpful.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[Chris Angelico]

On Fri, Sep 29, 2017 at 8: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.  I do "Carefully-designed
> experiments" to find non-obvious bugs so I guess I am not average.  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.

Based on any mathematical definition of "average", yes, I am pretty
pessimistic about the average programmer :)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[D'Arcy Cain]

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.  I do "Carefully-designed 
experiments" to find non-obvious bugs so I guess I am not average.  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.


--
D'Arcy J.M. Cain
Vybe Networks Inc.
http://www.VybeNetworks.com/
IM:da...@vex.net VoIP: sip:da...@vybenetworks.com
--
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[Bill]

Steve D'Aprano wrote:


(say). Reading error messages is a skill that must be learned, even in Python.
Let alone (say) gcc error messages, which are baroque to an extreme. The other
day I was getting an error like:

/tmp/ccchKJVU.o: In function `__static_initialization_and_destruction_0(int,
int)':
foo.cpp:(.text+0x7c): undefined reference to `std::ios_base::Init::Init()'
foo.cpp:(.text+0x91): undefined reference to `std::ios_base::Init::~Init()'
collect2: error: ld returned 1 exit status




Yes, that's the sort of character-building that I was referring to (that 
a beginner needs to learn!)They have to learn that if it "breaks", 
then there must be a simpler way to break it!  Hopefully one which will 
satisfy Log_2 (n).: )


--
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[Steve D'Aprano]

On Fri, 29 Sep 2017 03:28 pm, Gregory Ewing wrote:

> Chris Angelico wrote:
>> finding the bug is basically searching
>> through a problem space of all things that could potentially cause
>> this symptom. A novice could accidentally stumble onto the right
>> solution to a tricky bug, or an expert could search a thousand other
>> things and only get to the true cause after a long time.
> 
> What I think is more important than how *long* it takes is
> *how* they go about finding the bug.
> 
> A novice will make wild guesses about what might be wrong
> and make random changes to the program in the hope of
> making it work. An experienced programmer will conduct
> a series of carefully-designed experiments to narrow
> down the cause.

"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 :-)


> A result of this is that a true expert will never have
> to try a thousand possibilities. He will be able to
> search a space of N possible causes in O(log N) operations.

I don't think that, *in general*, possible causes of a bug can be neatly sorted
in such a way that we can do a binary search over the space of all possible
causes.

I also think it is unlikely that even the best programmer enumerates all the
possible causes before working on them. If you don't enumerate all the causes
first, how to you sort them?

In my experience, even good coders are likely to say "there's only three
possible things that could be causing this bug", and later on report it was
actually the fifth thing.

More likely, the experienced programmer is better at eliminating irrelevancies
and narrowing in on the space of likely candidates, or at least narrowing down
on the region of code that is relevant, while less experienced programmers
waste more time looking at things which couldn't possibly be the cause[1].

More likely, the experienced programmer makes better use of his or her tools.
While the novice is still messing about trying to guess the problem by pure
logical reasoning, the expert is using a few useful print calls, or a debugger,
to narrow down to where the problem actually is.

And experts are likely to be better at extrapolating "well, since that's not the
problem... maybe its this?". And you learn that not by pure logic, but by being
bitten by nasty bugs:

"I can't see any possibly way that this could be involved, but I came across a
similar situation once before and this was the solution... [confirms hypothesis
and fixes bug] oh of course, that's how the bug occurs! Its obvious in
hindsight."

More experienced programmers are confident enough to know when to walk away from
a problem and let their subconscious work on it. Or when to go and explain it
to the cleaning lady[2]. Or when to admit defeat and hand over to a fresh pair
of eyes who won't be stuck in the same mindset.

Even just getting to the point of being able to reason *where to start* requires
a fair amount of experience. A true beginner to programming altogether won't
even know how to read a stack trace to identify the line where the bug occurs,
let alone understand why it happened. I wish I had a dollar for every time some
beginner says something like:

"I get a syntax error. What's wrong with my code?"

and eventually after much arm-twisting is convinced to post the last line of the
traceback, which turns out not to be a syntax error at all:

"TypeError: object of type 'int' has no len()"

(say). Reading error messages is a skill that must be learned, even in Python.
Let alone (say) gcc error messages, which are baroque to an extreme. The other
day I was getting an error like:

/tmp/ccchKJVU.o: In function `__static_initialization_and_destruction_0(int,
int)':
foo.cpp:(.text+0x7c): undefined reference to `std::ios_base::Init::Init()'
foo.cpp:(.text+0x91): undefined reference to `std::ios_base::Init::~Init()'
collect2: error: ld returned 1 exit status


Of course, its obvious that the problem here is that I needed to install g++ as
well as gcc, right? :-)


> This doesn't necessarily translate into time, because
> in some situations the experiments can be very time-
> consuming to perform. But other things being equal,
> the expert's bug-finding algorithm is faster than the
> novice's.





[1] Although, the *really* experienced programmer knows that in sufficiently
baroque and highly-coupled code, a bug could be caused by *anything*
*anywhere*. (This is one reason why global variables are bad.)

I still haven't gotten over hearing about a bug in the Internet Explorer
routines for handling WMF files, which lead to being unable to copy and paste
plain text in any application.


[2] The place I worked had a cuddly penguin toy called Mr Snuggles, and the
programmers would go and explain the problem to him. It never[3] failed.

[3] Well, hardly ever.


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

Re: Beginners and experts (Batchelder blog post)

[Chris Angelico]

On Fri, Sep 29, 2017 at 3:28 PM, Gregory Ewing
 wrote:
> Chris Angelico wrote:
>>
>> finding the bug is basically searching
>> through a problem space of all things that could potentially cause
>> this symptom. A novice could accidentally stumble onto the right
>> solution to a tricky bug, or an expert could search a thousand other
>> things and only get to the true cause after a long time.
>
>
> What I think is more important than how *long* it takes is
> *how* they go about finding the bug.
>
> A novice will make wild guesses about what might be wrong
> and make random changes to the program in the hope of
> making it work. An experienced programmer will conduct
> a series of carefully-designed experiments to narrow
> down the cause.
>
> A result of this is that a true expert will never have
> to try a thousand possibilities. He will be able to
> search a space of N possible causes in O(log N) operations.
>
> This doesn't necessarily translate into time, because
> in some situations the experiments can be very time-
> consuming to perform. But other things being equal,
> the expert's bug-finding algorithm is faster than the
> novice's.

This is very true, which is part of why I said that in programming, it
takes one to know one - to observe a candidate and determine his/her
experimental technique, you basically need to yourself be a
programmer.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[Gregory Ewing]

Chris Angelico wrote:

finding the bug is basically searching
through a problem space of all things that could potentially cause
this symptom. A novice could accidentally stumble onto the right
solution to a tricky bug, or an expert could search a thousand other
things and only get to the true cause after a long time.


What I think is more important than how *long* it takes is
*how* they go about finding the bug.

A novice will make wild guesses about what might be wrong
and make random changes to the program in the hope of
making it work. An experienced programmer will conduct
a series of carefully-designed experiments to narrow
down the cause.

A result of this is that a true expert will never have
to try a thousand possibilities. He will be able to
search a space of N possible causes in O(log N) operations.

This doesn't necessarily translate into time, because
in some situations the experiments can be very time-
consuming to perform. But other things being equal,
the expert's bug-finding algorithm is faster than the
novice's.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[Larry Martell]

On Thu, Sep 28, 2017 at 5:08 PM, Chris Angelico  wrote:
> Yep. Pick anyone on this list that you believe is an expert, and ask
> him/her for a story of a long debug session that ended up finding a
> tiny problem. I can pretty much guarantee that every expert programmer
> will have multiple such experiences, and it's just a matter of
> remembering one with enough detail to share the story.

The software development process can be summed up thusly:

I can’t fix this
Crisis of confidence
Questions career
Questions life
Oh it was a typo, cool
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[Chris Angelico]

On Fri, Sep 29, 2017 at 7:47 AM, Bill  wrote:
> I won't claim to be any sort of "expert".  But one memorable problem, for
> me, was ultimately accounted for by the "inherent problem" of the floating
> point variables x0 and xo coexisting in the same module.  It's sort of funny
> if you think about it just right. FWIW, my job was to fix the problem, I
> didn't create it!

Today I helped one of my students debug an issue that was exacerbated
by a flawed shuffle function that, while capable of returning any
permutation of the input, had a bit of a tendency to leave things
early if they started early - it was about 8% more likely to pick the
first element than the last. Doesn't sound like much, but it increased
the chances of a collision pretty significantly. Now THAT was fun to
debug.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[Bill]

Chris Angelico wrote:

On Fri, Sep 29, 2017 at 6:59 AM, Bill  wrote:

Chris Angelico wrote:

Be careful with this one. For anything other than trivial errors (and
even for some trivial errors), finding the bug is basically searching
through a problem space of all things that could potentially cause
this symptom. A novice could accidentally stumble onto the right
solution to a tricky bug, or an expert could search a thousand other
things and only get to the true cause after a long time.

  some "expert"!   ; )


Yep. Pick anyone on this list that you believe is an expert, and ask
him/her for a story of a long debug session that ended up finding a
tiny problem. I can pretty much guarantee that every expert programmer
will have multiple such experiences, and it's just a matter of
remembering one with enough detail to share the story.

ChrisA
I won't claim to be any sort of "expert".  But one memorable problem, 
for me, was ultimately accounted for by the "inherent problem" of the 
floating point variables x0 and xo coexisting in the same module.  It's 
sort of funny if you think about it just right. FWIW, my job was to fix 
the problem, I didn't create it!


Bill

--
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[Chris Angelico]

On Fri, Sep 29, 2017 at 6:59 AM, Bill  wrote:
> Chris Angelico wrote:
>>
>> Be careful with this one. For anything other than trivial errors (and
>> even for some trivial errors), finding the bug is basically searching
>> through a problem space of all things that could potentially cause
>> this symptom. A novice could accidentally stumble onto the right
>> solution to a tricky bug, or an expert could search a thousand other
>> things and only get to the true cause after a long time.
>
>  some "expert"!   ; )
>

Yep. Pick anyone on this list that you believe is an expert, and ask
him/her for a story of a long debug session that ended up finding a
tiny problem. I can pretty much guarantee that every expert programmer
will have multiple such experiences, and it's just a matter of
remembering one with enough detail to share the story.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[Bill]

Chris Angelico wrote:

On Fri, Sep 29, 2017 at 5:45 AM, Bill  wrote:

Paul Moore wrote:

On 27 September 2017 at 17:41, leam hall  wrote:

Hehe...I've been trying to figure out how to phrase a question. Knowing
I'm
not the only one who gets frustrated really helps.

I'm trying to learn to be a programmer. I can look at a book and read
basic
code in a few languages but it would be unfair to hire myself out as a
programmer. I'm just not yet worth what it costs to pay my bills.

You're already ahead of the game in wanting to be useful, rather than
just knowing the jargon :-) However, I've always found that the
biggest asset a programmer can have is the simple willingness to
learn.


I basically agree with what has been posted. I just wanted to mention a
couple things that separates beginners and non-beginners. One is "how long
it takes to identify and fix an error"--even a syntax error. And that is a
skill which is acquired with some practice, maybe more "some" than anyone
likes.

Be careful with this one. For anything other than trivial errors (and
even for some trivial errors), finding the bug is basically searching
through a problem space of all things that could potentially cause
this symptom. A novice could accidentally stumble onto the right
solution to a tricky bug, or an expert could search a thousand other
things and only get to the true cause after a long time.


 some "expert"!   ; )




So while
you're partly correct in saying "how long", you can't just put someone
on the clock and say "if you find the bug in less than five minutes,
you're hired". Ultimately, the only person who can truly evaluate a
programmer's skill is another programmer, usually by watching the
candidate go through this sort of debugging work. But yeah, broadly
speaking, an experienced programmer can usually debug something more
quickly than a novice can. On average.

ChrisA


--
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[Chris Angelico]

On Fri, Sep 29, 2017 at 5:45 AM, Bill  wrote:
> Paul Moore wrote:
>>
>> On 27 September 2017 at 17:41, leam hall  wrote:
>>>
>>> Hehe...I've been trying to figure out how to phrase a question. Knowing
>>> I'm
>>> not the only one who gets frustrated really helps.
>>>
>>> I'm trying to learn to be a programmer. I can look at a book and read
>>> basic
>>> code in a few languages but it would be unfair to hire myself out as a
>>> programmer. I'm just not yet worth what it costs to pay my bills.
>>
>> You're already ahead of the game in wanting to be useful, rather than
>> just knowing the jargon :-) However, I've always found that the
>> biggest asset a programmer can have is the simple willingness to
>> learn.
>
>
> I basically agree with what has been posted. I just wanted to mention a
> couple things that separates beginners and non-beginners. One is "how long
> it takes to identify and fix an error"--even a syntax error. And that is a
> skill which is acquired with some practice, maybe more "some" than anyone
> likes.

Be careful with this one. For anything other than trivial errors (and
even for some trivial errors), finding the bug is basically searching
through a problem space of all things that could potentially cause
this symptom. A novice could accidentally stumble onto the right
solution to a tricky bug, or an expert could search a thousand other
things and only get to the true cause after a long time. So while
you're partly correct in saying "how long", you can't just put someone
on the clock and say "if you find the bug in less than five minutes,
you're hired". Ultimately, the only person who can truly evaluate a
programmer's skill is another programmer, usually by watching the
candidate go through this sort of debugging work. But yeah, broadly
speaking, an experienced programmer can usually debug something more
quickly than a novice can. On average.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[Bill]

Paul Moore wrote:

On 27 September 2017 at 17:41, leam hall  wrote:

Hehe...I've been trying to figure out how to phrase a question. Knowing I'm
not the only one who gets frustrated really helps.

I'm trying to learn to be a programmer. I can look at a book and read basic
code in a few languages but it would be unfair to hire myself out as a
programmer. I'm just not yet worth what it costs to pay my bills.

You're already ahead of the game in wanting to be useful, rather than
just knowing the jargon :-) However, I've always found that the
biggest asset a programmer can have is the simple willingness to
learn.


I basically agree with what has been posted. I just wanted to mention a 
couple things that separates beginners and non-beginners. One is "how 
long it takes to identify and fix an error"--even a syntax error. And 
that is a skill which is acquired with some practice, maybe more "some" 
than anyone likes. Another critical skill is the ability to write good 
documentation--from program requirements, on down. Another is to know 
what is means to "test". Another is to have some familiarity with the 
UML.  Skills in 3 of these 4 area might be assisted by reading about 
software engineering.  So after you have those skills, then, perhaps, 
you can think about "interviewing"--of course a degree will help.  As 
always, your mileage may vary...  It IS True that you don't have to wait 
until you "know everything"--most of use will never get there.

--
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[Leam Hall]

On 09/28/2017 04:15 AM, Paul Moore wrote:

With Python, I'd say that an appreciation of the available libraries
is key - both what's in the stdlib, and what's available from PyPI.
That's not to say you should memorise the standard library, but rather
cultivate an approach of "hmm, I'm pretty sure I remember there being
a library for that" and going to look. The best way of getting this is
to actually work with code - you can start with doing coding projects
of your own (it's *always* a good exercise to have a problem that
interests you, and work on coding it - no matter what it is, you'll
learn more about understanding requirements, testing, bug fixing, and
practical programming by working on a project you care about than
you'll ever get reading books) and/or you can look at existing open
source projects that you're interested in, and offer help (there's
always a bug tracker, and typically some simpler items - and you'll
learn a lot from interacting with a larger project).



When I first started in Unix/Linux there was a group called SAGE. They 
had a list of tasks a system admin was expected to be able to do and 
they sorted the list by "Junior", "Senior", or somesuch. I started at 
the bottom of the list and worked my way up.


One useful thing was to make a sorted list of commands in /usr/bin, 
/bin, /usr/sbin, and /sbin, and then read the first bit of the man page 
that showed what the command did. Fun stuff.


Leam
--
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[Leam Hall]

On 09/28/2017 07:35 AM, Stefan Ram wrote:


   But remember that paid programmers usually do not "code",
   in the sense of "write a program from scratch". Most of the
   work is maintenance programming, where an important part of
   the job is to read and understand a piece of code.
   Coding from scratch also happens, it just less common.

   (So that would be a reasonable interview test: Being able
   to understand a piece of given code and do some requested
   modification to it.)


Another Perl story. I used to love Perl and then got to the point where 
trying to code in it made me physically nauseous. Not sure why.


Guy had written a perl based time tracker for our contractor team. We'd 
enter tasks done and it would give a text based output to send to mgmt. 
Of course the guy hadn't planned on leaving after a few months and his 
program stored data by date but didn't separate by year. So I had to go 
figure out what it was doing since he was using a perl specific data 
archiver. Eventually just wound up blowing away the data store so each 
year was new. Told others how to handle it as I didn't want to do more 
perl and wasn't good enough at anything to replicate it all myself.


Leam
--
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[Leam Hall]

My question has received several helpful responses, thanks!

On 09/28/2017 01:01 PM, Dennis Lee Bieber wrote:

On Wed, 27 Sep 2017 12:41:24 -0400, leam hall 
declaimed the following:
"Programmer"... or "Software Engineer"?

I haven't kept up on "job titles" but for my history, "programmer" is
an entry level position, just a few steps up from "data entry operator"
(aka "keypunch operator" -- to show my age)


"Person who automates routine tasks".

I used to get asked for MAC addresses. I was playing with TCL at the 
time and it had a built in webserver sort of thing. The boxes were 
Solaris. Made a cron job to run Explorer on the servers and another to 
collate them to a node with the TCL webserver. Gave the Network team the 
URL.


I'll show my age; 5 bit ASCII punched tape and actual ferrite core 
memory.   :P



As a "programmer" (in my archaic world): be fluent in the language and
core of the runtime (though perhaps not a master -- I still don't get
Python's decorators and meta-class concepts; my uses haven't needed them).
Be able to read language agnostic requirement/design documentation and
translate to the language in question. At this level, knowledge of the
problem domain is probably not needed. At the higher levels, the language
begins to be irrelevant, but more knowledge of the problem domain becomes
important -- the difference between designing/coding a web-based
store-front (HTTP/HTML, database, security) vs number-crunching image
streams from space probes...

Afraid I've likely just tossed it back to you -- what really is your
goal? 


As an introvert with a speech impediment I live by "Don't call me, I 
won't call you."


Well, okay, yes. I did to Toastmasters and can shine at an interview. 
Still, day to day I prefer to create solutions that solve problems and 
answer questions before they are asked so no one asks me. I know a 
little Networking, Database, Systems Engineering, Project Management, 
Security, large datacenter, and other cool buzzwords to easily find a 
job doing Linux system admin. What I want to move away from is doing now 
what I was doing 10-15 years ago.


A couple years ago I was back into C. A RHEL bug came up and management 
needed to understand the severity of the issue. I was able to read the 
reports, dig through the kernel code, and explain the issues and risks 
to MBA and PM types. I'm not about to represent myself as a C programmer 
but I can follow #include files.


One place brought on Unix people and your first day was split between 
the Eng team lead and the Ops team lead. They would decide which you 
were more suited for. The Eng team lead wrote Perl and asked me to 
explain some of their code. I did and also pointed out a bug. Seems I 
was a better fit for the Ops team.  :P


My short term goals are to use Python to get better at OOP coding and to 
automate in Python stuff that might work in shell/awk but are more fun 
in python. To that end I'm reading Booch, just ordered an old copy of 
the Python Cookbook, and am coding a game/fiction tool to help me keep 
track of characters.


It is often said to learn a language you grab the basics and then join a 
project. I'm happy to contribute to open source projects but the 
learning curve to "useful" has always been steep for me. There's gap 
between reading "Learning {language}" and contributing code.


Python is very useful because all my RHEL boxes have it installed. If I 
build a tool I know it will be able to run. While I enjoy Ruby more, 
it's not on the servers and it ain't going on the servers. I need to be 
useful to keep getting paid. Due to developer count the ability to 
instigate a python project is easier than a non-rails ruby project so I 
can build my "software engineering team" skills as well.


I appreciate your guidance and feedback; keep it coming!

Leam




--
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[Neil Cerutti]

On 2017-09-28, bartc  wrote:
> On 28/09/2017 12:31, Steve D'Aprano wrote:
>> Until now, I thought that people who wrote crappy code did so
>> because they didn't know any better. This is the first time
>> I've seen somebody state publicly that they have no interest
>> in writing clean code.
>
> I meant I have no interest in reading books about it or someone
> else's opinion. I have my own ideas of what is clean code and
> what isn't.

The world contains many programmers with more experience than
one's-self, and some of them are good at explaining what they
know in a comprehensible and entertaining way. I believe you will
benefit from and even enjoy some of the literature. Here's a
recent favorite: "The Pragmatic Programmer", Andrew Hunt and
David Thomas. ISBN-13: 978-0201616224

-- 
Neil Cerutti

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[bartc]

On 28/09/2017 12:31, Steve D'Aprano wrote:

On Thu, 28 Sep 2017 09:12 pm, bartc wrote:


And I have little interest in most of this lot (my eyes glaze over just
reading some of these):

  >  - how to use operating systems


You've never used a system call? Written to a file? Moved the mouse?


Wasn't that more this option:

 - how to program operating systems via system calls

Which was in my first group. Using an OS, I just do the minimum 
necessary and don't get involved in much else.


(In my first phase as a programmer, there were personnel whose job it 
was to do that. In the next phase, with microprocessors, there /was/ no 
operating system! Bliss. That phase didn't last long, but fortunately 
those OSes (MSDOS and the like) didn't do much so didn't get in the way 
either.)





  >  - how to use an editor well (e.g., vim or emacs)


You have no interest in using your editor well?


I use my own editor as much as possible. That doesn't have any elaborate 
features that it is necessary to 'learn'.





  >  - style (e.g. "Clean Code" by Robert Martin, pep 8, ...)


Until now, I thought that people who wrote crappy code did so because they
didn't know any better. This is the first time I've seen somebody state
publicly that they have no interest in writing clean code.


I meant I have no interest in reading books about it or someone else's 
opinion. I have my own ideas of what is clean code and what isn't.





  >  - test (e.g., unit test), TDD


You don't test your code?


I assume this meant formal methods of testing.


I suppose that makes it a lot easier to program. Just mash down on the keyboard
with both hands, and say that the code is done and working correctly, and move
on to the next project.

*wink*


Actually I used to like using random methods (Monte Carlo) to solve 
problems. That doesn't scale well however, at some point you have to 
properly think through a solution.


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[alister via Python-list]

On Wed, 27 Sep 2017 18:18:10 -0700, Larry Hudson wrote:

> On 09/27/2017 09:41 AM, leam hall wrote:
>> On Sat, Sep 23, 2017 at 5:26 PM, Ned Batchelder 
>> wrote:
> [snip]
>> 
>> The question is, what should a person "know" when hiring out as a
>> programmer? What is 'know" and what should be "known"? Specifically
>> with Python.
>> 
>> 
> Hopefully NOT like this person...
> (Source:  http://rinkworks.com/stupid/cs_misc.shtml There is no direct
> link to this item, it's about 2/3 the way down in a long web page...)
> 
> 
> Since I teach nights at a local community college, I get a lot of
> professional programmers in my classes upgrading their education. One
> student, who was one such person, attended every lecture and smiled and
> nodded and took notes. But he only turned in his first assignment. The
> results of his first test were horrid. Out of curiosity, I asked my
> wife, who barely knew how to turn a computer on much less program one,
> to take the test (which was mostly true/false and multiple choice
> questions). My wife scored higher than this guy.
> 
> The semester's end came, and he flubbed his final, too. A few weeks
> later, I got a call from him complaining about his 'F'. I pointed out he
> hadn't turned in any of his assignments, and those counted 75% of the
> grade.
> 
> "Did you hear me say something besides what the other students heard?" I
> asked.
> 
> "Well, I thought my test grades would carry me," he replied.
> 
> It had turned out his company had paid for him to take the course. Since
> he failed, it suddenly came to the attention of his employer that he
> didn't know how to program, and now his job was in jeopardy. As I hung
> up the phone, I mused that his company shouldn't fire him. It was a
> perfect match: a programmer who couldn't program and a company that
> couldn't figure out sooner that he couldn't.
> 

the whole page seems to be full of 
"look how dumb this user is because they do no automatically know things 
that I had to learn"



-- 
  After they got rid of capital punishment, they had to hang twice
  as many people as before.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[Steve D'Aprano]

On Thu, 28 Sep 2017 09:12 pm, bartc wrote:

> And I have little interest in most of this lot (my eyes glaze over just
> reading some of these):
> 
>  >  - how to use operating systems

You've never used a system call? Written to a file? Moved the mouse?


>  >  - how to use an editor well (e.g., vim or emacs)

You have no interest in using your editor well?


>  >  - style (e.g. "Clean Code" by Robert Martin, pep 8, ...)

Until now, I thought that people who wrote crappy code did so because they
didn't know any better. This is the first time I've seen somebody state
publicly that they have no interest in writing clean code.


>  >  - test (e.g., unit test), TDD

You don't test your code?

I suppose that makes it a lot easier to program. Just mash down on the keyboard
with both hands, and say that the code is done and working correctly, and move
on to the next project.

*wink*



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

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[bartc]

On 28/09/2017 03:33, Stefan Ram wrote:

Larry Hudson  writes:

Hopefully NOT like this person...

Since I teach nights at a local community college



a programmer who couldn't program


   It is not clear what »this person« refers to:

   Do you hope one is not like that teacher who
   publicly is shaming one of his students, though
   without actually giving the name of the student.

   Or do you hope one is not like that student who
   did not turn in the assignments?

   The fact that programmers can't program is
   known since the invention of the "FizzBuzz"
   programmer test. But in the case of the student,
   one actually can't know for sure whether he only
   had problems with the /upgrade/ of his education,
   but still can program in his everyday job.

   So, what was the question? Quoted from earlier in
   the same thread:

|The question is, what should a person "know" when hiring out
|as a programmer? What is 'know" and what should be "known"?
|Specifically with Python.

   Some areas of knowledge follow, a programmer should not be
   ignorant in all of them:


I can probably manage the following, even if I hate some of it or some 
might be advanced:



 - writing FizzBuzz
 - writing GUI software [My own]


(Writing a GUI system or using one? I've done both and try and avoid GUI 
completely if possible.)



 - writing software to analyze text files
 - writing software to generate images from data
 - writing software to analyze images
 - how to program operating systems via system calls
 - algorithms and datastructures
 - numerical mathematics
 - how to write a recursive descent parser
 - maths (how to transform to polar coordinates or
   what the use of a fourier transformation is)


And I have little interest in most of this lot (my eyes glaze over just 
reading some of these):


>  - writing GUI software [Other people's]
>  - writing software to analyze data bases
>  - writing user interfaces for data bases
>  - how to use operating systems
>  - how to administer a computer
>  - how to use the command languages of operating systems
>  - how to use an editor well (e.g., vim or emacs)
>  - how to use UN*X tools (grep, uniq, sed, ...)
>  - regular expressions
>  - a source management tool (like git)
>  - design patterns
>  - design by contract
>  - OOA/OOD
>  - the most important libraries for Python (standard and other)
>  - data base design / normalization
>  - style (e.g. "Clean Code" by Robert Martin, pep 8, ...)
>  - refactors
>  - software engineering
>  - being able to read and write EBNF
>  - software-project managemet (e.g. Agile, "Scrum")
>  - computer science (complexity, NP, grammars, ...)
>  - test (e.g., unit test), TDD
>  - programming interviews (there are many books about this topic!)
>  - Using a real Newsreader (not Google Groups)
>  - common algorithms/heuristics for global optimization
>  - common types of statistical analyses and neural networks

It seems the first group is more pure coding (and fun, a lot of it), and 
the second is the usual lot of tools and technologies that programmers 
seems to have to know about these days (and not so much fun).


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[Paul Moore]

On 27 September 2017 at 17:41, leam hall  wrote:
> Hehe...I've been trying to figure out how to phrase a question. Knowing I'm
> not the only one who gets frustrated really helps.
>
> I'm trying to learn to be a programmer. I can look at a book and read basic
> code in a few languages but it would be unfair to hire myself out as a
> programmer. I'm just not yet worth what it costs to pay my bills.

You're already ahead of the game in wanting to be useful, rather than
just knowing the jargon :-) However, I've always found that the
biggest asset a programmer can have is the simple willingness to
learn. "Programming" is far too broad a subject for anyone to know all
about it, so being able (and willing!) to find things out, to look for
and follow good practices, and to keep learning, is far more important
than knowing the specifics of how to code a class definition.

Most programmers work in teams, so you will likely be working with an
existing code base for reference (even if you're not doing actual
maintenance coding), so you'll have examples to work from anyway.

> To move forward takes a plan and time bound goals. At least for us old
> folks; we only have so much time left. I want to avoid retirement and just
> work well until I keel over.
>
> I don't come from a CS background but as a Linux sysadmin. My current push
> is OOP. Grady Booch's book on Analysis and Design is great and I've got the
> GoF for right after that. I've been doing more testing but need to write
> more tests. Writing code and starting to work with others on that code as
> well.

I haven't read Booch, but I've heard good things about it. The GoF is
good, but a lot of the problem's it's addressing aren't really issues
in Python. So be prepared to find that the solutions look a bit
over-engineered from a Python perspective. The ideas are really
useful, though.

Keep in mind that in Python, OOP is just one option of many - it's a
very useful approach for many problems, but it's not as all-embracing
as people with a Java or C# background imply. In particular, Python
uses a lot less subclassing than those languages (because duck typing
is often more flexible).

> The question is, what should a person "know" when hiring out as a
> programmer? What is 'know" and what should be "known"? Specifically with
> Python.

With Python, I'd say that an appreciation of the available libraries
is key - both what's in the stdlib, and what's available from PyPI.
That's not to say you should memorise the standard library, but rather
cultivate an approach of "hmm, I'm pretty sure I remember there being
a library for that" and going to look. The best way of getting this is
to actually work with code - you can start with doing coding projects
of your own (it's *always* a good exercise to have a problem that
interests you, and work on coding it - no matter what it is, you'll
learn more about understanding requirements, testing, bug fixing, and
practical programming by working on a project you care about than
you'll ever get reading books) and/or you can look at existing open
source projects that you're interested in, and offer help (there's
always a bug tracker, and typically some simpler items - and you'll
learn a lot from interacting with a larger project).

Hope this helps,
Paul
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[Dan Sommers]

On Wed, 27 Sep 2017 12:41:24 -0400, leam hall wrote:

> The question is, what should a person "know" when hiring out as a
> programmer? What is 'know" and what should be "known"? Specifically
> with Python.

The longer I claim to be a programmer, the more I discover how wide a
net that is.  Web sites, embedded systems, user interfaces (text and
graphical), databases, communications protocols, applications
programming, systems programming, real time systems, text processing,
scientific computing, simulations, security, etc., etc., etc.  And I
stopped there only because I hope I've made my point and not because
that's an exhaustive list.  Some of it you'll know up front; it's a
pretty boring job on which you learn nothing new.

What must be known is how to produce a program that does what the
customer says they want (note that they likely don't know what they
need, only what they want, but that's a whole other ball of wax).
You'll also have to know enough about the problem domain to converse
with the customer to turn what will be a vague request into something
tangible.  I'm sure you already do this when it comes to automating your
own tasks.

If I'm hiring myself out as a plumber, I should know how to unclog
drains; and install, repair, replace toilets, water heaters, and other
plumbing fixtures (or whatever else a plumber might be called on to do).
Ignore the question of licensing; it doesn't apply to programmers.

It's the same whether you use Python, something else, or some
combination.

Wow, that's a lot more than I intended to write.  I don't mean to be
discouraging, only enlightening.  We all started somewhere, and your
background as a sysadmin puts you way ahead of a lot of future
programmers.

HTH,
Dan

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[Chris Angelico]

On Thu, Sep 28, 2017 at 11:18 AM, Larry Hudson via Python-list
 wrote:
> 
> It had turned out his company had paid for him to take the course. Since he
> failed, it suddenly came to the attention of his employer that he didn't
> know how to program, and now his job was in jeopardy. As I hung up the
> phone, I mused that his company shouldn't fire him. It was a perfect match:
> a programmer who couldn't program and a company that couldn't figure out
> sooner that he couldn't.
> 

I had a coworker like that at my previous job. The boss basically was
paying him to learn to code, and yet (for reasons which to this day I
cannot fathom) let him make a lot of decisions about technology. Thus
we used PHP and MySQL (okay, it could have been worse), with a
multi-threaded daemon in addition to the actual web server (I take
that back, it WAS worse). I had to fight uphill to convince my boss of
the value of git ("why bother, I have daily backups for a week and
then weekly backups for two years"), and even then, this coworker
didn't commit or push until, well, pushed. Eventually he quit the
company (rumour has it he was hoping we'd beg him to stay, since we
were that short-handed), and I had to take over his code... and found
it full of The Daily WTF level abominations. Heard of the "For-Case
paradigm"? Check out this [1] old article if you're not familiar with
it. Well, he gave me this thrilling variant (reconstructed from
memory):

$i=1;
while ($i<3) {
switch($i)
{case 1:
... snip one set of validations
$i=3;
break;
case 3:
... some more validation work
$i=2;
break;
case 2:
... snip another set of validations
$i=4;
break;
}}

I don't remember the exact details, but it was something like this. It
looked like the code just stepped straight through the switch block.
So I stripped out the junk and just did the validations sequentially.

And the code stopped working.

Since I *had* been committing to git frequently, I checked out the
previous version. It worked. I redid the simplification. It broke
again. I stuck in some console output, and found that one of the
blocks of code was actually getting skipped... and due to the
compounding of two or three other bugs, valid input would get rejected
by the validation that wasn't happening.

I have no idea whether he intentionally removed part of the
validation, or if he just never noticed that it wasn't running. It was
a truly impressive piece of work.

ChrisA

[1] https://thedailywtf.com/articles/The_FOR-CASE_paradigm
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[Larry Hudson via Python-list]

On 09/27/2017 09:41 AM, leam hall wrote:

On Sat, Sep 23, 2017 at 5:26 PM, Ned Batchelder 
wrote:

[snip]


The question is, what should a person "know" when hiring out as a
programmer? What is 'know" and what should be "known"? Specifically with
Python.



Hopefully NOT like this person...
(Source:  http://rinkworks.com/stupid/cs_misc.shtml
There is no direct link to this item, it's about 2/3 the way down in a long web 
page...)


Since I teach nights at a local community college, I get a lot of professional programmers in my 
classes upgrading their education. One student, who was one such person, attended every lecture 
and smiled and nodded and took notes. But he only turned in his first assignment. The results of 
his first test were horrid. Out of curiosity, I asked my wife, who barely knew how to turn a 
computer on much less program one, to take the test (which was mostly true/false and multiple 
choice questions). My wife scored higher than this guy.


The semester's end came, and he flubbed his final, too. A few weeks later, I got a call from him 
complaining about his 'F'. I pointed out he hadn't turned in any of his assignments, and those 
counted 75% of the grade.


"Did you hear me say something besides what the other students heard?" I asked.

"Well, I thought my test grades would carry me," he replied.

It had turned out his company had paid for him to take the course. Since he failed, it suddenly 
came to the attention of his employer that he didn't know how to program, and now his job was in 
jeopardy. As I hung up the phone, I mused that his company shouldn't fire him. It was a perfect 
match: a programmer who couldn't program and a company that couldn't figure out sooner that he 
couldn't.



--
 -=- Larry -=-
--
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[Larry Martell]

On Wed, Sep 27, 2017 at 12:41 PM, leam hall  wrote:
> The question is, what should a person "know" when hiring out as a
> programmer? What is 'know" and what should be "known"? Specifically with
> Python.

Fake it till you make it!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[leam hall]

On Sat, Sep 23, 2017 at 5:26 PM, Ned Batchelder 
wrote:

> On 9/23/17 2:52 PM, Leam Hall wrote:
>
>> On 09/23/2017 02:40 PM, Terry Reedy wrote:
>>
>>> https://nedbatchelder.com//blog/201709/beginners_and_experts.html
>>>
>>> Great post.
>>>
>>
>> Yup. Thanks for the link. I often have that "I bet > Fred> doesn't get frustrated." thing going. Nice to know Ned bangs his head
>> now and again.  :P
>>
>>
> "Ow!" --me


Hehe...I've been trying to figure out how to phrase a question. Knowing I'm
not the only one who gets frustrated really helps.

I'm trying to learn to be a programmer. I can look at a book and read basic
code in a few languages but it would be unfair to hire myself out as a
programmer. I'm just not yet worth what it costs to pay my bills.

To move forward takes a plan and time bound goals. At least for us old
folks; we only have so much time left. I want to avoid retirement and just
work well until I keel over.

I don't come from a CS background but as a Linux sysadmin. My current push
is OOP. Grady Booch's book on Analysis and Design is great and I've got the
GoF for right after that. I've been doing more testing but need to write
more tests. Writing code and starting to work with others on that code as
well.

The question is, what should a person "know" when hiring out as a
programmer? What is 'know" and what should be "known"? Specifically with
Python.

Thanks!

Leam
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[Ned Batchelder]

On 9/23/17 2:52 PM, Leam Hall wrote:

On 09/23/2017 02:40 PM, Terry Reedy wrote:

https://nedbatchelder.com//blog/201709/beginners_and_experts.html

Great post.


Yup. Thanks for the link. I often have that "I bet Fred> doesn't get frustrated." thing going. Nice to know Ned bangs his 
head now and again.  :P




"Ow!" --me


--
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[Terry Reedy]

On 9/23/2017 2:52 PM, Leam Hall wrote:

On 09/23/2017 02:40 PM, Terry Reedy wrote:

https://nedbatchelder.com//blog/201709/beginners_and_experts.html

Great post.


Yup. Thanks for the link. I often have that "I bet Fred> doesn't get frustrated." thing going. Nice to know Ned bangs his 
head now and again.  :P


As do I ;-).


--
Terry Jan Reedy


--
https://mail.python.org/mailman/listinfo/python-list

Re: Beginners and experts (Batchelder blog post)

[Leam Hall]

On 09/23/2017 02:40 PM, Terry Reedy wrote:

https://nedbatchelder.com//blog/201709/beginners_and_experts.html

Great post.


Yup. Thanks for the link. I often have that "I bet Fred> doesn't get frustrated." thing going. Nice to know Ned bangs his 
head now and again.  :P


Leam


--
https://mail.python.org/mailman/listinfo/python-list

Beginners and experts (Batchelder blog post)

[Terry Reedy]

https://nedbatchelder.com//blog/201709/beginners_and_experts.html

Great post.
--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list