On 27 September 2017 at 17:41, leam hall <leamh...@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 -- https://mail.python.org/mailman/listinfo/python-list
