Take Their Brains, Then Their Jobs

Continuing to think about my frosty self-experiment. I mentally went through a number of topics I use at work and that are important for it. I wanted to see how far I would get explaining them on a whiteboard with enough clarity and detail. At first, I felt it's going pretty well. But once I went through a number of topics, a pattern emerged, a pattern my brain was trying to hide in disbelief, we all know it: 'google it'.

What's in My Knowledge Graph?

Aware of that, it became clear to me that if I would represent my knowledge in the form of a graph, a large part of its nodes would be black boxes, whose labels I know, but whose details merely say: 'I can google this'. Mustering my stoicism as defence against running away and stopping the analysis, I figured it actually makes a lot of sense to do this. Remember the wisdom 'don't reinvent the wheel', or the fact that 'two brains are better than one', or simply the common sense of saving your effort for where it makes most impact. The black boxes are just that. In the context of work, which is tied to a business, which thrives on the efficiency of its employees, all these truths compound to a great deal.

Business Efficacy

Why think up a new data structure when data structures have been fully analysed? Why not spend your thinking seeing if you can combine multiple data structures in a way that fits your special problem, while refreshing your mind with the details by reading up on them? Why re-derive the running complexity of a certain search algorithm, let alone implement it, when so many brains (for whom this is a prime interest and a way of life) have already went to great pains to find the optimum? Even though turning each one of those boxes --that were once white, then black-- white again is important for an independent internal knowledge-base and interviews, it is not important for business. One might argue that you will have become too stupid when new and real problems emerge in your business, but that is simply not true, we are not discussing your ability to think. We are saying that the some parts of your knowledge, which includes both data and meta-processes that are common to dealing with that data, are far away from your active memory, and that it takes time, effort, and hints to fish them out of long term memory.

By analogy, we don't test a computer program for adequacy to solve a problem by quizzing it on a little-used code path, and then lament that both the data and the code necessary to handle that code path have been stowed away into tape memory by a least-recently-used algorithm, causing a horrendous cache-miss and a terrible expense of energy to load. In fact, we would conclude that the LRU algorithm is working beautifully.

Over Tuned?

In essence, in your eight or more working hours per day, your brain has tuned itself to what you actually do. Not to the 'fundamentals' of your field that I have seen interviewers adamantly debate 'mean the world', but much more, to the operational aspects of them, and those are quite different. In theory, theory and practice are the same, but not in practice. In your 2000 hours of work per year, you are at a great 'danger' of becoming an 'expert idiot'. Operationally expert, fundamentally idiot. Doing a great job, because you tuned yourself to what the job calls for.

The Programmer's Guild

Of course it is true that you long to fill the gaps, to learn more, to stay up to date, and probably those adamant interviewers will reproach you for not doing this during your own free time, but at that point, this is nothing but a certain kind of 'ism'. It does not matter if you are great at doing your work, which is also the kind of work they interview for. No, what matters is that you share their free-time hobbies. If this is not blind ego-centrism, I don't know what is.

In Practice

Operationally, taking the c++ programming language as an example, here are the right answers for some questions about fundamentals, answers that will possibly get you kicked out of the interview.

• What is a class? The thing that is the hardest to name properly.
• What is a template? A failed attempt at meta-programming, whose syntax gets uglier and more convoluted the more the committee tries to make it a success.
• What is inheritance? Just a tree.
• What is a register? A useless keyword.
• What is volatile? A bullet with butterfly wings.
• What is c++17, also called c++1z? That sounds like the Nissan Z, The committee needs a new car to show.

Don't get me wrong, I love c++ and use (a subset of it) day-in day-out. What I want is show how these white boxes, over time, stop being beautiful and consistent definitions and become what you practically do with them. Some call that experience.

The Fundamentalists

To explain the title picture, here is a slightly surreal conversation:

Interviewer: Greetings, you don't look like a car, where is your chassis (your fundamentals?)

Interviewee: Well, I must've lost it along the way...

Interviewer: And what's with the jet engine?

Interviewee: It was a useful replacement because of the long straight stretches, that's where I'm operating nowadays

Interviewer: Fair enough, but we asked you to prepare didn't we?

Interviewee: I appreciate that highly, but I see that although you yourself do have your chassis on you, it's slightly misplaced... you seem to have simply strung it on top of your own jet engine... it's a bit like a wig... and by the way, it's upside down...

Interviewer: Good eyes you got there, but this is not about me

Interviewee: Oh I see. I am not so sure to be honest. In my company, the cars that display most zeal about chassis have a better chance at being put into the interviewing crew. An honour they will promptly list on their racing curriculum. Personally, I just call them 'the fundamentalists'.

Drill With Your Bare Hands

I have not seen a construction worker drilling with his bare hands in a while. I have not seen a cashier summing your price list mentally. So just maybe, the software engineer should finally be applauded for using his resources optimally, finding the best answer on stackoverflow, looking up that geometric intersection test's derivation on wikipedia. We don't need him for 'mental arithmetic' anymore, even if that's a very romantic image. For that, we have the 'machines' and the 'collective web', who both know better. Instead, we need him for things like the daily exercise of typing code that will get our business running, no matter how trivial. We need him for making sure he types what we can afford to maintain in the timeframe that makes sense for us. We need him to heuristically debug problems, the need for that arising from the fact that our dear 'fundamentals' have yet to solve the theoretical problem of being able to build error-free software, very sadly... (or maybe not so sadly? the provable existence of bugs being the true hidden component of computer science's full employment theorem?)

Take Their Brains, Then Their Jobs

Maybe this way, the engineer has some chance of not being automated away soon. Staying in demand because of the visceral kind of work that makes the nurse's job quite safe in the foreseeable future. If you have become an 'expert idiot', don't worry about it too much. And no, don't stay up to date with the committee's blog in your free-time if it's not your thing. My personal advice would be to study math instead, or work on the fundamentals of error-free software, but that's just my own 'ism', and I won't hold it against you professionally if you are not up for it.