Within the unversity, I do think you should be taught the basic use of fundamental tools/techniques such as the debugger. I’m pretty sure I came into university knowing what a debugger is and how to use it, but not everyone might have that. I think it’s only fair to make sure that everyone starts out with a minimum level. I think there could be more room at the more advanced levels to teach or maybe share higher level programming strategies. At lot of the ‘art’ of programming I think really could be shared and disseminated more effectively. Now that I’m out in industry, I do see more coding styles, but as student, there isn’t as much exposure. As for specific tool use though…

Unlike other disciplines, in CS, the risk-to-reward for tinkering with tools is particularly low. The odds of you destroying something is practically nil (backup and/or recompile); the most you risk losing is your time. In addition, throughout your career, the number of tools you will encounter, especially when multiplied with the number of operating environments, is huge.

I think to survive in this discipline it is imperative that you tinker (or at least google), and put some time into learning the new because it’s impossible to expect to be taught how to use every tool/environment combination you will encounter. I personally don’t think that universities should teach tool use beyond the fundamental basics because the likelihood that you will be using a particular tool again is pretty small. I would much rather that the time be spent learning something with more general applicabillity.

Speaking personally, I think I’m less of a tinkerer, and more of a googler. I don’t really see a reason why I should waste time exploring hidden menu options when I can typically find the answer with a few keystrokes.

When reviewed potential hires, I wanted people who would go and explore the solution space and who would keep themselves informed of the possibilities in our fast moving field. Tinkering and ongoing research were two of the markers I used to determine if they were sufficiently motivated. Obviously I also wanted people who would actually do the assigned tasks…but I didn’t want wage slaves either. It’s a balancing act and part of what makes hiring so much of a pain.

Teaching tinkering could be a good idea, but it may just be the equivalent of claiming you’ve warmed up a room by putting a hot water bottle on the thermostat. I think the admonitions that not expanding your knowledge and competence is risky might help a bit, but could backfire as naturally risk-taking people might pay attention.

I am a reluctant tinkerer. I need theory, I hate just wacking around and seeing what falls out. With knitting the theory is easy (interlock loops, different methods result in different patterns) so it was easy for me to plan experiments (yarn under the bottom, needles over here, and tug; yarn threaded from behind, needles still here, and pull…) to see the interaction of variables and impact on end results.

…I was going to go somewhere different with that paragraph, but it took me to a simple conclusion: blind tinkering isn’t systematic. Introductory science and engineering training programs are designed to relentlessly pound in a methodical, systematic to approaching problems; laboratory courses emphasize that equipment is both expensive and dangerous so don’t screw with anything without instruction. (Even my departmental stapler has a warning to seek instruction or risk injury & paying for damages.) I call Mixed Messages on scenarios demanding students adhere to strict discipline in all scientific endeavors and condemning tinkering, yet require that same mucking about for software (and even penalizing its lack).

I am a reluctant tinkerer. I need theory, I hate just wacking around and seeing what falls out. With knitting the theory is easy (interlock loops, different methods result in different patterns) so it was easy for me to plan experiments (yarn under the bottom, needles over here, and tug; yarn threaded from behind, needles still here, and pull…) to see the interaction of variables and impact on end results.

…I was going to go somewhere different with that paragraph, but it took me to a simple conclusion: blind tinkering isn’t systematic. Introductory science and engineering training programs are designed to relentlessly pound in a methodical, systematic to approaching problems; laboratory courses emphasize that equipment is both expensive and dangerous so don’t screw with anything without instruction. (Even my departmental stapler has a warning to seek instruction or risk injury & paying for damages.) I call Mixed Messages on scenarios demanding students adhere to strict discipline in all scientific endeavors and meeting tinkering with heavy penalty, yet require that same mucking about for software (and even penalizing its lack).

My hypothesis – as a teacher at a girls school that teaches both programming and engineering – is that tinkering can be taught. And that tinkering is inherently a rewarding experience, so people who are enticed (or forced) to try it will develop it as a habit.

The reality is that I agree with both you AND your peers. I think we should “teach” tinkering – or at least explicitly encourage all kids to do it. I think it develops regions in the brain that are important. Tinkering leads to a kind of experimental mindset that is important in disciplines like engineering. I also think we should teach the tools we want students to use. Why in the universe would we ask them to waste their time futzing around? All other scientific disciplines teach how to use the tools – remember your chemistry and physics labs? They didn’t just give you a triple beam balance and tell you to play around with it. They taught you what to do with it. Why don’t we do that? There isn’t any value to playing around with a triple beam balance until you finally figure it out, unless it’s to act as a gatekeeper to people who can’t figure out the triple beam balance. We need the doors open wider, not closed off with stupid, irrelevant barriers.

It’s extremely hard to discuss values and stay neutral, and I smiled to myself when I thought I caught you out in this article, namely regarding the survival rates of startups related to the gender mix in the startup. Survival isn’t necessarily the end-all, be-all for startups. How about degree of success? A risk lover could counter your story like this: Yes, some testosterone fueled startups bet big and fail, but some testosterone overdosing startups bet big and make all the founders millionaires, whereas hormone-balanced startups bet low and (only) give all the founders steady jobs and the ability to pay off their car and their one bedroom apartments.

As in so many other culture / value discussions, I think it’s a matter of fitting in. What level of risk aversion is required for the developer? Depends on their environment, i.e. their product, their customers, etc. Banking software and gaming engines might be on opposite ends of that scale(?)

As for the startups, what level of risk aversion does the business environment expect? A couple of extremes: In Denmark (one of the safest societies in the world in almost any way imaginable) having failed with a business is a stigma. I visited Silicon Valley in 1998 and got the impression that if the founders of a new startup hadn’t been involved in one or two startup business failures, then investors would think they were sissies and they’d be reluctant to take a chance on the new startup.