Beginners and experts (Batchelder blog post)

[Paul Moore]

On 27 September 2017 at 17:41, leam hall <leamhall at gmail.com> 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