Do you really need to know the first principles to...

... become an engineer? Before today I was 100% sure that you do need the base knowledge of the engineering field you specializing in. You have to understand some basics of electronics for example to be able to design electronic systems. Or you need some basic knowledge of mechanics to produce robots. And in both cases you most likely will use computers and therefore you need to know computer basics too.

So what happened today?

A few hours ago (on a very short notice) I helped to setup an Arduino based class for schoolchildren visiting the Uni for a field trip. Some PhD students were organizing and helping with technical side: connect Arduino based robots, copy libraries onto computers, setup login and workspace for the school students to practice.

The first problem occured when the PhD's tried to install a particular Arduino library onto the computer's harddrive. I usually frown upon anything that gets installed on top of the base image, especially if this requires admin rights. Well, I am probably too lazy to type the admin password into 20+ computers, but I also know that this should not be necessary in order to use that library. It can be done by simply coping the library to desktop and using an absolute path in the program source code. So the students - intelligent Mechatronics PHD's in their early 20's! - copied the files from a network drive onto local Desktop and asked if this is enough to do it once so the file will (magically?) appear on the rest of computers.

They were surprised when I told them they will have to manually copy the files on all computers. And no, I did not want to automate the process - why to make their life easier, especially when they were not prepared in the first place?

Another problem was with specifying the local path for #include statement. I would expect them to know that #inlcude takes a file name as an argument, not the directory name. But no! The student's did not realize that library (in Arduino sense) is just a bunch of source files, with the .H file as its base. I wonder what will happen when they meet real uC development toolchain?

Once again, these were intelligent (and some are quite actually bright) people who did not understand fully the basics of 1) Desktop computing; 2) Arduino programming; 3) File structure. I am pretty sure they are quite successful at what they do despite these knowledge gaps - thanks to several layers of abstraction imposed by software developers.

Then what is the problem?

The problem lies in their core ability to create something non-mainstream, something that will require advanced skills. What looks to me as a very basic and necessary information for them will become an intimidating and alien concept. They will spend too much time to get through the wrongly understood principles and improperly learned skills

Or they will just hire someone who will do all the dirty work for them

The curse of education industry

This is not the first time I get hit by the (quite common) stereotypes about the Education industry. And I can't say I was not warned - quite the opposite, just before I got the job at the Uni I was told that it does not count towards commercial experience. But at that time I was quite sick of the corporate environment - a lot of rudeness, shallow jokes, tasteless parties, etc. I was hoping to find a better medium at the academic circles (and better pay, of course). At first it actually was so.

Now, having spent over 15 years at the Uni, I am sick of bureaucracy and fake smiles, budget cuts and wasteful spending. It's time to get the new job and I have prepared the CVs and cover letters, and am ready to dive in to the sea of unknown.

I tried this (not very thoroughly) earlier last year. I did not succeed despite receiving invitations for an interview on both occasions I applied. This year I was hoping for the similar result. Surprise: nothing, not even a click on my blog I started for this occasion. Looks like the myths about educational industry still prevail the minds of my potential employees.

Myth 1 - deadlines are not met and standards are low at Uni

Funny enough, there are thousands of students come through the University each year, and every time in the beginning of semester it's a mad house: last minute orders to install software on dozens of computers. Last minute rearrangement of lab layout. Unprovoked network port block by the central ITS. And so on. Guess who should fix all of the above before the first lab? So I do. And I succeed. It's true that many times the decisions are made quite late and there is physically not enough time to implement most of them. But it is also true that the students come next day to the fully functional computers and equipment. So the myth is not quite right about the people who actually do the work.

Myth 2 - Uni people are not skilled enough and their products are of low quality

Imagine an Uni tech, working on huge variety of subjects, from AV integration to CNC programming. The tasks change daily, there are always a new skill to learn - not to the perfection, but enough to make things running. In complex systems - and University is one of those - it is much more important to maintain the stable operational flow than to fine tune individual processes. At some stage after dealing enough with certain issue the skill level gets relatively high and the quality improves accordingly. So it is quite untrue that University means low quality experience. Rather it means broad skill set and ability to learn on the fly.

Myth 3 - Uni people tend to do everything perfect and thus it takes forever to do anything

The opposite to the previous point (and sometimes mindlessly quoted one after another) also does not bear the truth. While every one should thrive for perfection, in real world common sense rules that "good plan today is better then the perfect one tomorrow". Considering how many times I had to streamline some jobs due to late notice/urgent requests, the question of slowness is rather theoretical and based on stereotypes.