Is there more to Googling than you think?

As a developer I Google stuff. Alot. It almost happens automatically:

  1. Working on something.
  2. Unfamiliar error appears.
  3. Google it.
  4. Choose the first StackOverflow link in the results.
  5. Problem solved (usually).

That trivialises the process somewhat. Most decent developers will spend some time considering the error and trying a few things to fix it before resorting to searching. And of course we don’t just seek help when errors occur: looking for best practices during the design phase of a project, finding a more concise way of implementing some logic and learning from the mistakes of others are all common use cases.

So I was surprised when recently I was tutoring at a ‘bootcamp’ style programming course and noticed many of the students struggled to construct useful search queries. They would do things like searching for an error verbatim, including their custom variable names and data. They struggled to abstract and generalize a problem. They also struggled to use the results of a first query to make improvements to subsequent queries.

It turns out being a good Googler is a skill many of us have subconsciously built up over years of work. Is my problem language or framework specific? Do I need to widen or narrow my search? Is this even a problem that the wider developer community would be able to help with or is it an issue specific to my company’s codebase?

Wisdom of the Ancients

 

So, if you’re involved in teaching programming or mentoring junior developers, consider working with them to construct useful searches. You may already know the answer to the problem and could go straight to helping them with it. Teaching them to find the solution themselves may actually be more beneficial.

Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime.

Abstraction

It struck me, sitting in the Eng library, studiously studying (really, I was!) for my upcoming embedded systems exam that our generation has it harder. That probably sounds exactly the sort of pretentious statement you might expect from a college student of today; so allow me to explain a little further.

Computing knowledge and education is dependent on abstraction.  As one of my lecturers likes to say (on repeat), computers are very simple and also very complicated. What he means by this paradox is that any layer of a computing system looked at in isolation can be understood without too much trouble: arrange four MOSFETS correctly and you get a NAND gate, hook up a few ANDs, ORs and XORs and you’ve got a full-adder – easy. Similarly, for any budding programmer writing a script to pull some records from a database and display them to a user might seem a logical enough exercise.

The complexity is in trying to mentally link these two ends of the computing spectrum: the high level and low level. After three years of Computer Engineering courses I’m only just able to go from thinking about some high level bit of functionality and mentally traverse the various layers of abstractions and have some understanding of the machine level functions invoked.

One of the books I was studying from, Mano’s, Computer System Architecture, was published in 1983. It continues to remain relevant and useful in 2012. The topics of RISC architectures, control paths and pipelining have evolved only gradually in the intervening 30 odd years. What has evolved is layer upon layer of high level functionality. We’ve had the OO revolution, with many Computer Science students graduating with their lowest level understanding being how to implement quicksort in C#, Java or Python. There are now countless networking protocols, web frameworks, mobile devices, and embedded systems that are starting to look less and less like embedded systems.

A consequence of all of these extra layers of abstraction is that students can no longer be expected to learn and understand them all! In recognition of this, there has been a proliferation of new, more specific qualifications. Where we once had Electrical Engineering, we now have Computer Science (the first course was taught in 1953 at the University of Cambridge), Computer Engineering (1971), Software Engineering and Information Technology. Is there any other area of professional education that has seen such an expansion?

As a student studying in this new world, I’ve found myself somewhat frustrated that I’m largely expected to learn in detail some narrow area of knowledge. I’ve spent a large amount of my own time trying to understand as much as possible from the other areas of qualification. I’m very aware that to remain current with ever evolving levels of knowledge I will need to continue self-learning throughout my career.

So if my generation has it hard trying to make sense of the layers of computing abstractions, it’s both exciting and ominous to think of the complexity that will be encountered by the next generation of computing students.

XKCD – Abstraction