The Promise and Realities of Technical Education: Computer Science

Previously published in Industrial Automation:

Being able to program computers effectively, and understanding the computer science and industry details necessary to do this well, is an extremely valuable and important skill. But it is not a skill that comes easily to most people. In a similar way to the leaps in capability necessary for an advanced artist, lawyer, or doctor, engineers, and software engineers in particular, must transform their minds in ways that are difficult to describe. It is difficult to explain the need for this because it is usually difficult for a proficient practitioner to remember the transition, especially as highly experienced engineers likely made that leap so long ago. Competent software developers must be able to simulate software in their minds, to remember many details and understand, in detail, how that will affect a program. They must learn to solve problems with an ever expanding and changing set of tools, vocabulary and concepts. The number and complexity of concepts is ever growing, with much of what’s published becoming gradually or suddenly obsolete all the time, without much clear guidance of that to anyone not deeply involved. Problem solving using appropriate techniques is a difficult skill to master, both at the meta level of breaking down goals and assembling conceptual and concrete solutions, as also in the details of tools, components and other details and their relative usefulness for certain situations. Additionally, a programmer must be an expert detective to understand and resolve bugs: In complex systems, especially when working with code from other people, it can be very challenging to understand and fix bugs.

This combination of lots of evolving details at various conceptual levels, ability to simulate how a computer will work with particular software in a complex environment, flexible creative problem solving often using just learned concepts, and debugging detective skills, along with communication and management skills required to work in a team, requires gradual, persistent, and substantial growth in mental capabilities and concentration stamina. The great thing about software is that, learned in a healthy way, each success inspires and empowers more effort and excitement. While frequently challenging, if you are doing anything interesting, it is addictive fun: Opportunities for work are a worthy opponent to your creative problem solving skills, work that might have a positive impact on millions of people. London cabbies are required to learn important information about every street in London to be licensed. A few years ago, a study was done of the brains of these students: An MRI was taken before and after the intense 6 month process. In every successful student, there was a measurable increase in size of the hippocampus, known to play a key role in memory. The path to becoming a competent programmer can be thought of as changing your brain: You must grow new conceptual mechanisms, capabilities such as a large working memory, a feel for what solutions fit what problems, and a range of other skills. You must learn to hyper focus for long periods of time. And you learn to communicate in a whole new language, communicating complex solutions concisely. This process takes time and some degree of just trying and failing many, many times until both programs and your process of creating programs just works. There are various paths to get that point, and various backgrounds, from a range of play as a child to solving math problems (not required, but similar enough to be helpful) to process based work, may all help one get over the initial barriers.

To become a competent software developer, persistence, grit, is most important: Can you keep making slow, painful progress, withstanding the discomfort of pushing yourself to adapt and grow to have these new capabilities? Just like math, art, and other areas, no one does this without difficulty, although most don’t remember that difficulty. Although continuous growth requires that you often visit this discomfort at your boundaries, the growing range of things that are now easy and powerful makes this much better than when starting.

There is a lot of talk about a gap in computer science training. What is this gap? There is an old saying in project management that every customer wants three things: cheap, fast, and good; you usually have to choose two. Computer science training is often limited in this way. Peter Norvig wrote about how to become a programmer in this famous online essay “Teach Yourself Programming in 10 Years”. He started with the observation that there were a lot of “Teach Yourself X in Y Time” style books out there that promised people success in learning a programming language or actual programming in two weeks, 30 days, etc. It’s always a critically low time frame. Why is this? When most people ask you the question: “How do I become good at X”, they actually are asking, how do I speed up my learning. Everyone is always looking for that silver bullet which propels a skill they are interested in from novice to pro in the shortest amount of time.

Is there a short cut in learning any complex skill? Usually not: if you go for fast there will be some trade off. If the choice is between becoming good or getting there at a low cost — we all know what the average person chooses if they are not Wim Hoff — the “ice man” and don’t take ice cold showers every day.

How do you become good fast? Peter Norvig’s essay points to the often repeated “10,000 hours rule”. Some research indicates that mastery of difficult professional skillsets takes about 10,000 hours. Unlike other domains, there are seldom people who learn a musical instrument and ask whether they’ll be able to play concerts on the piano in front of an audience within two weeks. Even more modest goals can’t be achieved instantly: There is a well-known comedy video called “Learn the Guitar to Get Laid”. The basic joke is that the character in the video basically just learns to play the intro of “Wonderwall” by Oasis. When the people around him start singing he only continues by knocking on the body of the guitar to lay down a beat for the now formed chorus.

Many in computer science careers are aware of the value of actual experience coding. While in higher education, students often realize they are not yet fully ready for professional positions that require coding. Often, they must then building software development experience, working on their 10,000 hours. On computer science CVs this usually amounts to years as a developer and lines of code written. Computer science education usually seems like an interim phase gathering “book knowledge” toward being able to tick two boxes: “I studied hard and achieved good grades and now I have all this experience.” However, right after college it can be difficult to get a job due to lack of experience. Then, if one wants to return to school (e.g., for a master’s) one is told that the coding itself doesn’t constitute knowledge — at least not in computer science.

Computer science programs often mainly measure knowledge of certain concepts, along with some degree of basic competence designing solutions and implementing them. What counts in actual software development work is high competence in design, implementation, debugging, and communication. You are expected to be competent in computer science knowledge, but very often you are looking things up to verify, using libraries, finding and learning new algorithms, concepts, and systems. And, in some types of work, creating new algorithms, solutions, and even discovering new methods. A key thing to understand is that, for the most part, the actual difficult transition from non-programmer to programmer, in various senses and degrees, happens alone sitting at the keyboard trying to solve problems. A ‘Teach yourself X in Y days’ book assumes that you already have a solid baseline of software development capability that you are just going to extend.

Coding interview requirements may surprise new graduates: There is often an element of live implementation, such as a classic algorithm from computer science. It isn’t just the algorithm you are asked to implement and explain, but also how you handle bugs. That “now what” moment is much more illustrative of what you can actually do than fast and flawless solution. How does one prepare for a moment like that? Deliberate practice: Challenging yourself until you master the skill. Want to double your success? Triple your failure. Measuring progress, bug fixes, and lines of code is a great way to quantify. Ask yourself how many bugs you may have fixed along the way, how quickly, and how this reflects your skill level.

In future articles, we will explore approaches for gaining this knowledge most efficiently.

Sascha Griffiths, PhD, CTO of Ortelio Ltd, University of Hamburg, cofounder Blue Scholar Foundation — AI & robotic research, academic & industry.

Stephen D Williams, CTO of Yebo Technologies, founder VolksDroid, cofounder Blue Scholar Foundation — System architect & developer, inventor, entrepreneur, author.

Missed Points

You’re missing the point. Let me explain…

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store