Graduation time again. Newly minted grads will be taking to the streets looking for a job and many may well have applied or being looking to apply for graduate programs at companies both large and small.
These programs may look to rotate recent grads through the different departments over an 18 month to 2 year period to allow them to find their ideal niche or just be a direct pipeline into a single department. Given the current economy, even a half dozen spaces on a graduate program are going to have several hundred application for each space.
This raises an obvious question for a technology company looking to recruit into their development organisation: how the hell are HR, who we all know lack the understanding of what makes a good technologist, able to winnow this ridiculous volume down to something where developers can get involved? At my current client we would love to be able to interview every candidate. Given that we like to spend at least half a day doing an initial assessment, that just won’t scale. Because of this I was asked to help come up with a solution that could be completed by the candidates and/or the HR folk to generate a way of ranking candidates. So: non-technical people assessing technical people? It’s going to have to be some sort of list.
“There is never any shame in being wrong, only in being too ignorant to learn why you were wrong.”
NoSQL is a hot topic right now; as long as you don’t need ACID guarantees or complex joins you can have a persistence store that is faster, scales better, allows greater schema flexibility and all at a lower comparable cost than a relational database. The number of companies looking to use NoSQL has grown massively and the number of NoSQL solutions looking to feed this grown have blossomed also.
In the eye of this storm are three sets of individuals On one side we have the developers desperate to own the full stack from web app to data store, in the middle are the Ops guys and DBAs used to owning and running the persistence stores and on the other side are the vendors selling their wares. One group focuses on delivering new features as quickly as possible, another ensures that they run smoothly and can be recovered as and when they go bang and the third are deluging these other two groups with an almost impossible amount of information to make sure that their solution is the one being used.
Apologies if I’m stating the bleeding obvious yet again but my previous article, Developers: you are not the sum of your technical skills, raised a bit of comment on reddit. Not a huge amount of comment since the commentary that programmers cannot be insular is fairly obvious but one point that was raised a few times was the section that dealt with being in charge of a team.
“I really, really hate that this is taken as a given. The idea that every successful, productive programmer will eventually lead a team is just… Frustrating.”
“As to being “put in charge of a team”, leaders tend to emerge whether you christen them with a title or not.”
Now there are two points here. Firstly, I completely agree that much of the industry has a mildly insane view of the career track of a developer and secondly there is a massive difference between leadership and management and should encourage qualities of the former from everyone, not just those put in charge of a team.
I’ve been pondering the fact that when I started out on a career in development, I focussed on the technical side of it almost to the exclusion of all else. This was especially true for me since I was coming from a non CompSci background after spending years sticking electrodes in people’s heads and doing biological research. This made me painfully aware that in an industry like programming, if you don’t know your stuff you are useless to your team and your company. Worse, you run the risk of ending up a Net Negative Producing Programmer and reduce your team’s output to less that it would be if you weren’t there.
After a relatively short time it became obvious that this wasn’t enough. Being technically adept is the foundation of our job but certainly not the totality. Even before you get your first job you realise the importance of communication. Not just in communicating your skills to get that first job but then once you’ve got it, then communicating with the rest of your team including the non technical members. This is especially true in an Agile world where you have to be able to tell others what is going on in a way that they will understand.