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!

Scaring off users

Node.js is a platform built on Chrome’s JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.

I mean, it all makes sense but gosh, that’s quite buzzwordy. They might as well say “we really don’t want beginners around these parts”. It’s just Javascript and many of those people being put off would do just fine.

No, I don’t have code to show you

Whilst looking for a new job recently a question I’ve been asked by a few companies now is “do you have any projects you could show us, so we can get a taste of what kind of code you produce?”

The problem is I actually don’t. I’ve got quite a few projects from before I started my last full time position, but a year and a half later that code looks stale. Definitely looks like Shane-from-two-years-ago wrote it; you can tell from the mixed coding standards, the lack of tests, the database-as-a-singleton-passed-around-global-but-sometimes-by-reference usage. It’s not something I want to show employers.

This happened because I never carved out enough time to work on my own projects. There was always more actual work to be done – work I was being paid for. So if I was feeling in a programming mood, I’d carry on working on that, staying at work a few hours later than needed. I stopped seeing the value in working on my own projects.

Now that’s coming back to bite me.

It’s fine for employers to ask to see code examples. Why give someone tens of thousands of pounds a year, invest all that time in them, and trust them with your company, when you’re not entirely sure if they’re just bluffing their way through interviews.

Fortunately, I’ve found there’s a number of ways around this issue.

One company asked me to spend a while working on logic problems. They were fun little tasks actually. Mentally challenging enough to keep me interested, whilst actually showing the employer that I can think myself out of a problem. There was no stress in this situation. “I’ll be your compiler,” the interviewer said, handing me a pen and paper, “and this is your IDE.” The point was he wasn’t looking for syntax correctness – anyone can learn that – he was just trying to find out that I know how to think about logical issues.

A second company, asked me to work on a small project for them. I spent eight hours or so on this problem. I’m certain they weren’t even expecting that much. But I did it because it was fun. Again, they were just looking to see how I go about finding a solution to a tricky problem.

So, it’s not incredibly important to have a bursting GitHub profile. But it would have been easier if I had. Who knows how many companies might not bother responding to my CV because of my dull GitHub activity.

Personal blog of Shane Preece. Occasional tech minddump.