Not a maker

I recently met with a friend of a friend to offer some ideas on a career change. This guy has a BA in English and has worked in retail management for 26 years. It has worn him out and he is looking for something new. When he heard that I work in software development, he initially didn’t imagine I had much to offer him since the only job he knew of was coding. During our talk, I outlined to him all the different roles involved in software development and sales–not just programming, but QA, tech writing, product management, business analysis, sales, sales engineering, partner management, etc.–and I briefly outlined the desired skills sets of each of these roles.

I would say that his is a typical view of software development: it’s all about the coding. When I read Debbie Chachra’s essay, Why I Am Not a Maker, it immediately struck me that what she describes is exactly what goes on with high tech in general: “As Kate Losse has noted, coders get high salary, prestige, and stock options. The people who do community management—on which the success of many tech companies is based—get none of those.” Substitute any of the job roles I mentioned above (and many others I overlooked) for ‘community management’ in that sentence and you get what I mean.

Debbie Chachra’s essay focuses on the ‘caregiving’ behind making, and in many ways, I don’t think that aspect of her thinking applies to QA and the other roles in software development. On the other hand, it’s usually the job of some non-coding member(s) of the software development team–QA, scrum master, program manager, etc.–to make sure that the processes are followed: bugs get tracked through correctly through their lifecycle, the team board accurately reflects work in progress, etc. You could certainly consider these to be caregiving roles. To cite Debbie’s example, the team members who get those tasks are the mothers who make sure that the housecleaning takes place–if not doing all the housecleaning themselves. Interesting.

Update: There’s a very long and thought-provoking MeFi discussion about this essay. For instance, “[P]rogrammers (I’m one of them) tend to over-estimate how hard their primary skills are and under-estimate skills others learn for their roles, as well, as you note, the half of the population that is “naturally” expected to be better at them (also in that half.)” On the one hand, it’s true that being a programmer typically requires more specialized training than many of the ‘supporting’ roles in software development. On the other hand, programmers overestimating the difficulty of their primary skills is a product of an environment where that work has been given preference over other work since it was dominated by males. It’s a self-reinforcing circle.