(Previous: I Can Has Websiting Job? Learning to Talk Tech)
I recently attended a tech training open house where, in describing the program, one of the engineers got really excited about one aspect in particular: the room where the students do most of their work has WALL TO WALL WHITEBOARDS. Oh yeah.
As a former teacher, I chuckled a little at this statement. I have plenty of experience teaching with whiteboards, smartboards, chalkboards–you name it, I’ve probably found a way to put draw cutesy images on it so my students can guess words and play games. And, having worked in a number of underfunded areas, I’ve also learned how to make do with no whiteboards, by having students learn orally with repetition, songs, games, and interactive lessons.
But this engineer wasn’t talking about whiteboards in the classroom as a way of proving that this was a very funded learning experience (we DO have a whiteboard… in fact, we have not just one, but ten!). And it wouldn’t necessarily be improved by having a wall of smartboards either.
In Engineeringland, having a room filled with whiteboards conveys a bigger idea. The idea that everyone in the room should have physical space to (literally) draw out out their ideas in a way that others have access to them, and that multiple solutions can be seen and accessed and changed all at the same time (because no one’s answer has to get erased to start another answer). It also means that no one can get away with writing bad code, since it’s all there on display to be checked and fixed. A room of whiteboards is about inclusion, interactivity, equality, and reviewing one anothers’ solutions.
Or, to come at the same idea from another angle:
In software engineering interviews, the applicant is expected to be able to “whiteboard” ideas–given a specific problem, the applicant thinks through (out loud) how to solve it while pseudocoding the steps on the whiteboard, then fills in the steps with actual code, all while interacting and clarifying the problem with the interviewer. This is a rite of passage for working developers, who like to grumble about how hard interviewing problems are in a way that conveys the camaraderie of having survived a common ordeal.
But there’s more to this interviewing process than the rite-of-passage difficulty that makes for a good story later.
Coding on a whiteboard, rather than on a computer, allows the interviewer to see how the applicant’s thought process works, point out potential flaws (or new twists, if you’re performing well), and see what the applicant does when presented with new information. When the applicant doesn’t have the crutch of being able to immediately compile the code and see the solution (and fix the code backwards from there), it is easier for an interviewer to assess what the applicant really understands about the code she (or he) is writing.
Interviewing, like real engineering work, is an interactive process, and in that process the interviewer should get an idea of how well you grasp the problem, but also what it would be like to work with you on similarly difficult problems.
So in this scenario, wall-to-wall whiteboards would mean lots of chances to interact, to correct each other, and lots of personal attention to what is (or isn’t) working in your solution.
Which is probably the kind of environment you would want if you wanted to keep growing in your engineering capabilities…