On recruiters not being partularly helpful

As I was looking for a job this time around, I had largely the same experience with recruiters as I did last time around. Although, with a lot more interest.

I posted my CV online on jobsite.co.uk once again, just like last time. But instead of just the ten or fifteen phonecalls the next morning, my phone was ringingly solidly at least the first two days.

This was just before 10:30, and I'd been answering the phone all that morning until then too.
This was just before 10:30, and I’d been answering the phone all that morning until then too.

I can only conclude that the market for web developers has only gotten better when we’re looking for a job.

Once again, I had intreviews line up within hours. One interviewer asked if I was available for an interview “in a couple of hours”. There’s no doubt that you’ll find a job via a recruiter.

On the other hand though, there’s lots of baggage that comes with it. They’ll often get upset and unprofessional if you turn down an offer – “you’re being really irresponsible turning down this opertunity, you won’t get another one like it”, I was told by one recruiter. When they’re not incredibly unprofessional, they’re pushy. These are the times when you realise that the majority of recruiters don’t care about how happy you are – they only care that you find a job.

I should mention that not every recruiter I worked with this year has been awful. Maria from ASG was wonderful at her job, and I really feel like she didn’t feel too pressured into making a sale. I really felt like I had a nice bond with her – she understood what I was looking for. She’s a Symfony specific recruiter.

If you’re going to go with recruiters, definitely go with only one. Don’t publish your CV on a job board and expect anything other than to be treated like high value meat. Find one that your friends have recommended. There are some trustworthy ones out there.

In the end though, much like how I joined MyBuilder, I got my new position by applying directly. I very much recommend this route. Look at who’s sponsoring your local meetups – they’re probably a cool company to be working for. I found my new company – Altmetric – through Siliconmilk Roundabout.

But my point is, the hassle and stress that came with recruiters wasn’t very fruitful ultimately.

On Let’s Code JavaScript

I’m really enjoying Let’s Code Test Driven JavaScript, from James Shore.

His aim is to release videos overtime, showing how he’s developing an arbitrary application. Using JavaScript and Nodejs and driving the development with tests. Not just the code, but the set up as well.

The videos also come with DRM free download links.
The videos also come with DRM free download links.

It’s subscription based, but with a free trial (all access to the content, for seven days). I discovered this whilst in-between jobs and had no income, so in a time where money is heavily budgeted it’s a testament to James’s work that I decided it was worth the money.

In fact, I think it’s so important to the dev space that I’ve linked to LCTDJS in what I usually reserve for ad space on this blog. You guys need to be watching these videos, even if you already know how to write node apps – the test driven component is brilliant and getting to hear some of James’ ideas should make this a really compelling subscription.

The videos are fairly short. I think they’ve been designed that way so they’re commute friendly. I can’t imagine sitting on a train watching these videos, but maybe you can. The shortness is pretty helpful for me since I’ve now got something to watch whilst eating that’s actually productive (instead of endless Youtube). Despite being short, I’ve not yet watched an episode and thought “well, that was a waste of ten minutes”. I’ve always walked away with a new idea to think about. And there’s such a backlog of videos for me to catch up on, if you need more just watch another.

The videos manage to kick off at a really good point – assuming you know how to program. What you’re learning really is the methodology behind programming (the thing that good programmers focus on). Where you should be spending your time. The code is often secondary to how well it’s tested. The best practices talked about in the series really should be sitting along side industry standards set out in Clean Code.

The videos start by adding build automation and linting. Nothing to do with getting the app working, just making it work cleanly. The emphasis on this throughout the series is why I keep watching. I don’t care to watch a guy telling me the problems and features needed in a collaborative painting app. I care about how the code is designed, and how to think about the choices that come up.

The chapter I’m on at the moment is about deploying the code. It’s not something that would have been consider a software developers job in the past, but now people in our job are going to find themselves more often in the command line. Faster deployment means developers are the ones pushing to live, not administrators. So it’s interesting to see how you can wrap tests around deployment. Had you every thought about TDD for things that aren’t strictly code? Because you should be.

My favourite aspect of the series is the warts and all approach. It would have been easy for James to have edited the videos in a way that just shows how to do TDD. But he also leaves in the walls he runs into. My favourite episode so far is episode 31. He starts the episode realising what he’s worked on recently is a waste of time, and then ends it by running straight into a bug. This is exactly how I program. More than likely how you do to. It’s amazing to see that these problems aren’t a reflection on me as a programmer, but they’re just part of the daily trials of every programmer.

After the Ignorant Period

I just finished reading a longform post by Michael Bromley on how he used to feel he was a much better programmer than he actually was.

I followed the example studiously, faithfully implementing all the ingenious and no-doubt cutting-edge techniques – those handy “mysql_” functions for data access; string concatenation for building queries; separating functions into a “functions.php” file; including a “header.php” and a “footer.php” to maintain consistency site-wide; shunning the bulky overhead of the object-oriented approach (whatever that really meant) in favour of lightening-fast procedural code. My skills were increasing exponentially!

This is exactly how I felt – not even that long ago actually. Even at university, I didn’t surround myself with anyone that would say they were brilliant programmers. I was the only one of my close friends that would be very comfortable going in for a weekly “viva” (coding test), and fairly confident I’d do well. And I always did.

I went onto my placement year still in that mindset. I am the best programmer I know. Oh, gosh. I couldn’t have been more offensively wrong. My overestimation of myself grew from my isolation from others who were passionate about software development, and so my story echos the same as Michael’s.

I wrote an abstraction layer over a few mysql functions: database.php. Not that I had any idea of what an abstraction layer was, and I further had no idea how awful that implemenation is. I leave that code up on github not because I’m proud of it, but because it’s a good reminder. Smarter people have written database abstract layers better than you, Shane. Just leave it to them.

My thought process quickly changed from the above, to actually wanting to learn more once I joined MyBuilder. Surrounded by a wonderful team who were smart, and better than that, willing to point me in the right direction and teach me.

That’s when I got into the opposite problem of Michael’s though. Holy shit, everyone’s a much better programmer than me. It’s pretty intimidating to go to talks and see smart people talk about really smart topics. And then you realise they’re only two years older than you or the same age.

I recently realised this feeling of inferiority was just because we never get to see how that Super Respectful Programmer handles their work. In my mind, they have this grand idea, they sit down for half an hour, and bam: an awesome finished product.

When in reality they do exactly the same as I do. They stare at the screen knowing that the bug they’re running into is a really simple one. They do sometimes go down the wrong path, and have to back out half an hour of commites sometimes. This is all hidden though. But these rockstars often aren’t super geniuses – they’re just like you, maybe with a bit more persistance and practise.

Watching the Lets Code: TDD Javascript videos has really put my mind to ease about that. Watching someone “warts and all” has been refreshing. I’ve respected James Shore for a while now, and I had no idea that he hits as many silly mistakes as me. Mistakes that take seconds to fix, but still make me feel stupid. Even with collegues – unless you’re standing over their shoulder watching – you’re not seeing how often they spend a few seconds staring blankly at their screen, unsure what’s going on.

The point I’m making is the same as Michael’s post, but that it can go both ways. Isolation from others leads you to completely misunderstand your capabilities – making you too egotistical, or underestimating yourself.

Response to my CV

My CV has been really well received. I was worried about it just before I started looking for work, but it seems be doing quite well for itself. In this post, I’m just going to brainstorm some reason why I think that was the case.

The biggest risk I was taking with it was the tone I wrote it in: it’s very chatty, and laid back. You can definitely sense the passion behind it, though. Trying your best to show your passion for your work is probably the most important aspect of a CV. It’s easy to keep passionate people motivated, and they’re often in it for the right reasons. This is your first contact with a potential employer – it might be your only opportunity to catch their attention.

At least two interviewers said “I knew I had to get you in as soon as I read your personal statement.” I couldn’t think of what to say about myself there, so I decided to just explain why I love programming. Again, showing passion. But also making it clear what type of job I want. I don’t want to be a heartless code monkey at a bank, I want to be working closely with customers and making sure I can be proud of the product.

I’d suggest trying to specialise early. Most of the companies that reached out to me did so because they saw my Symfony2 experience. A few of these companies were asking for three or more years experience (which I don’t have) but that was overlooked just because of how much time I’ve spent with Symfony. That’s a good area to specialise, there are lots of other niches in web development: get some healthy Rails or WordPress experience. It looks much more interesting when put aside some generic “web developers”.

I did end up adding a section about my life outside of work. I mentioned my interest in (trying) to develop and write ARGs. If nothing else, it made the CV reader curious and more likely to get in touch with me just to find out more about it. I didn’t want to mention extra circular activities just because I thought it added nothing to the CV, so I tried to link them to how they help me be better at my job: inventive uses of technology.

My point is that CVs don’t have to be dry lists, and when you don’t have much experience you can still have an impressive CV. Just explain why you’re excited about your profession. If you can’t do that, maybe you’re in the wrong profession.

Reinstalling Node and grabbing NVM

There was a project I wanted to work on today (after subscribing to Lets Code Javascript), but noticed I’m using version 0.11 of Node. I was caught off guard there because the current version is 0.10. That’s what I’d like to downgrade to.

I can’t find anywhere talking about that being possible, except for using NVM. From what I can tell, that will install versions of node in my home directory, which is fine.

Uninstall Nodejs

First thing for me to do then would be uninstalling the current version of Node I have.

I was hoping this would be as easy as sudo apt-get remove nodejs, but it looks like I didn’t install through apt. Looks like I probably followed the instructions on the github page for installation, which meant I have a ~/node/ directory. From inside there, you should be able to just run sudo make uninstall. From the amount and content of the ‘removing’ feedback it looks like most of Node, and the NPM modules were uninstalled.

That left behind ~/node/, which I just did rm -rf ~/node on.

Check out Isaac’s comment on the Node newsgroup where he goes in depth on how to remove Node.

That’s clean enough for me. Now node complains about not existing.

Installing with NVM

It’s installable by one of those cool pipe-curl-to-bash scripts, which both terrify me and excite me. (I’d always encourage going and reading install.sh before hand. Even if you can’t read bash too well, you can still make sure it’s not sending information out of your server, or downloading anything that could look suspicious.)

It asks you to restart your shell, but that’s silly. Just do source ~/.nvm/nvm.sh. Also, add the bash auto-completion script to your .bashrc or .bash_profile.

Now you can do nvm install 0.10.26, and off you go!

Personal blog of Shane Preece. Occasional tech minddump.