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
