Essential Industry Skills
Allow me to consult the vast oracle of the interwebs on a perplexing problem. (That would be you.) I’ve got a lot of thoughts about on-the-job technical skills needed by industry programmers, each worthy of its own book. I have one chapter in the book I’m working on.
Here’s what I want to accomplish:
Give the newbie programmer a picture of programming topics that seem to come up again and again. I don’t intend to teach the topics, but give a brief discussion of what they are, why they keep coming up, and some good approaches to start on. (See examples below.)
Choose a reasonable subset of topics that apply across a broad cross-section of industry (80/20 rule).
Refer the reader to other resources to find out more.
This chapter is specifically focused on programming chops, not tools or bigger-picture practices. (I’ve got other material about that.) Let me give a few examples to clarify.
It’s shocking how many programmers can’t reason about concurrency. Building blocks like threads, mutexes, and semaphores will get a lot of job applicants tied into knots. My operating systems class in school dealt with these things, but I didn’t truly understand them until writing software on the job. How would I spend a handful of pages discussing concurrency?
For one, I could give real-world applications. Dealing with blocking I/O is tremendously common, and I could illustrate it with code that harvests web pages. Next might be a couple design patterns, for example event-driven vs. threads and locks. Then discuss a few advantages and pitfalls of each.
You can probably see where this is going: how could I possibly spend a five pages on this topic and do it any justice? Yet, how could I write a book for newbie programmers and not give them a heads-up about common concurrency issues?
Neutral Data Formats
Second example, this one more contained. I’ve seen a lot of programmers do this when faced with the need to save some in-memory state to disk:
Get a pointer to an object (or struct).
Open a file.
Splat the object to the file.
This works great for solving their immediate need. Three months go by, they make a change to the structure. Crap, now how do they load the old file into the new program? They start doing all kinds of gymnastics to figure out which version of the structure is in the file, how to de-serialize that into the new object, and so forth. Over the years the code to save/load that object grows into a monstrosity.
(To those of you in your younger years, you may be thinking, “surely nobody actually does that.” I can show you thousands of lines of code in my own company’s code base — not written by me, mind you — dedicated to exactly this class of problem.)
Back to my book: I can spend a couple pages illustrating the design of data formats which age gracefully and make sense for the problem domain. This is a specific issue that most programmers run into early and often. Most students, however, wouldn’t face the problem because their school projects simply don’t have a meaningful lifespan. I could cover the topic with specific examples, pitfalls I’ve observed, and good practices.
Does it make sense to spend precious pages on a topic like this? My gut feel is that it’s a niche thing — a topic that may be relevant, but only one among hundreds. How would I go about picking the best dozen or so topics?
I see my options as this:
Don’t cover these topics at all. How could I do the big ones justice, or cover a broad enough subset of the small ones?
Take a wild stab at it, see what the book reviewers think. Only cost here is time — I’ve tried to write this chapter a few times before and failed miserably.
[Insert your great idea here.]
So, what’s your great idea? If you could sit down with a newbie programmer over coffee, maybe with a laptop handy, and tell them what programming skills you think are essential to them as they enter into industry, what would you say?