Initially, I planned on working through a fast API in each of the software stacks that I had written about in a previous article. Naturally, a Java based solution was near the top of my list going in. There were a number of reasons for that including my familiarity with the language and the availability of cheap help; after all, pretty much every college teaches Java and students are always looking for some part time work.
If you have ever had to manage a project you probably already see the fallacy in my line of thinking. That’s right I blindly assumed that throwing more man hours at the project would lead to more productivity; i.e. I foolish assumed that there was a positive and casual relationship between time spent on the project and progress.
So, I got in touch with an old professor and asked to speak to third and fourth year students that were studying programming. Being from the university’s English department, he quickly introduced me to colleague in the appropriate department who eagerly informed me that a heavy emphasis had been put on practical skills and in particular Java in her department since I had graduated and that she was sure I would quickly find appropriate candidates.
I was happy to hear it. I gave her the go ahead to give my e-mail to her students and began the vetting process. Right off the bat I was seeing some strange things: some students proudly boasted Excel macros as their highest programming skill, many others failed to list a project they had done on their resumes, and still others failed to list any programming or programming related courses or competency. Still, I e-mailed several students and set up phone screens with them.
During the screens I asked all the students if they had ever worked with source control. Most said they had heard of it but had not worked with it. Those who had had only worked with SVN and did not know what a distributed source control system is. To be honest, I wasn’t surprised by this. I assumed that most professors would be focusing on somewhat older and more widely excepted enterprise tools rather than newer alternatives. Still, not knowing what source control is in your last year of a development focused degree is a huge red flag.
Disappointed, I moved on to my second line of questioning: what experience do you have with UNIX-like operating systems. To my surprise, only one of the students had ever really used a UNIX-like operating system (Ubuntu in his case) and he was on the IT support track rather than the software development track. I expected most of them to working on Windows PC’s day to day, but assumed that they would have had some training on a UNIX system beyond a history lesson. Ultimately, knowing how to work on a Mac or Linux box would not be essential to the work I needed done, so I didn’t press the point too hard.
I moved on to asking some technical questions. Most of students were able answer the obligatory: what is the JVM?, what is garbage collection?, what is the difference between a class and an object?, what is inheritance? Thankfully, most of the students were able to answer these questions to my satisfaction.
I finished the call by asking each student to tell me about a project they had worked on in Java or any other programming language. This is the question that made me decide to do the work myself. Not a single student had done any programming during the college career beyond small code snippets for assignments. No Github projects and no Super Mario clones. I was crushed.
At this point I realised that adding any of the students I had spoken with to the project would not only cost whatever I ended up paying them, but would also lead to some scary bugs that would take more time on my end to fix than doing the actual coding myself. Basically, more hours would probably lead to less progress and I just can’t have that. Ultimately, I wrote the professor and explained that I did not feel that any of the students she had sent were qualified for the project and thanked her for her time.