Starting your career in software development

Last December I was asked to give a quick talk to a bunch of programming undergraduates at Kings College, London. Emboldened by Christmas cheer I said “yes”, arranged the date and thought little more about it.

Now that date is almost upon us it transpires that whilst I’m still only giving a quick talk (15 mins), that ‘bunch’ of students turns out to be up to 250, so I’m getting my thoughts together here first rather than winging it and hoping for the best.

Given a free rein to talk about pretty much anything I immediately wanted to talk about my favourite subject: me. Or more specifically my career. I’m currently an engineering manager at OpenTable leading a team of front-end developers, but my career path is no gold standard for how to be an amazing software developer.

However I’ve been around the block enough times to talk a good game so I’ll offer some advice based on what I know now rather than what I actually did.

Getting that first job

Whilst I can still remember the interview for my first job (I’ll talk about The Naked Dwarf later), I have greater insight these days from interviewing developers, and I have personally recruited and managed a number of junior engineers at the beginning of their careers. At OpenTable we have a well practiced hiring process and based on that here’s how you’d get me to give you a job.

The CV

The CV is not as crucial as you might think. Get the basics right – no typos and a neat layout – but don’t cram it full of everything you’ve ever done, just enough to whet my appetite. A single page is usually best (no more than two).

The most important thing for a job as a developer is to show that you love writing code. Nothing conveys this passion better than sites/plugins/projects that you have worked on, particularly outside of your employment. Even better, provide links to repositories, websites, blogs or Q&A sites to show your work and genuine interest.

Dare I say it, but your exams results do not really matter to me. Passion, backed up with examples of work will grab our attention, with that hard-earned first or 2:1 counting only as a tie-breaker.

The Test

If we like your CV we’ll ask you to complete a test in your own time. The coding test will vary from role to role but will need skills that will be required in the job. If you can’t do the test at all then this isn’t the right role for you, but if you can do part of it then give it a go as we may well still like what you submit.

The Interview

If there’s enough quality in your test we’ll invite you for an interview. It is daunting, but we like to talk with you for two to three hours to make sure you’re right for the role and that the role is right for you.

The first half hour will be a code review of your test in which we’ll get you to explain how you completed the exercise and we’ll work with you to refactor or modify the test’s functionality. We’ll be impressed at this stage if you’ve looked again at your code before the interview and can confidently justify your programming decisions. Even if you couldn’t do half the things required in the test, you stand a good chance if you’re knowledgeable about the sections you did complete.

For the next 30-60 minutes we’ll conduct a technical interview. You’ll be interviewed by people whose skills overlap with yours and we’re looking for both a general programming understanding and a couple of subjects in which you can speak more deeply. If you don’t think you’re going to be asked about your favourite subjects try and drop them into the conversation. “Do you work with xxx because I’m really interested in that?” will grab our attention and prompt us to ask more.

The next 40-60 minutes will be a cultural interview in which we want to get to know you as a person, how you like to develop code and your understanding of the software development lifecycle. Even if you’ve never written code professionally try and convey passion and a genuine interest and you’ll impress us. A sense of humour is always welcome.

Finally we’ll ask you to spend some time with the hiring manager, the person to whom you’ll report. This is usually the most relaxed time in the process. If you’re good enough to make us want to meet you you’ll definitely have other companies knocking on your door so we’ll try and convince you that OpenTable is a great place to work and assess whether it is the right place for you. We encourage candidate questions throughout the day but this is the best time to have a genuine chat.

One final word of warning about the interview – be careful what can be discovered about you online. In my first interview my interviewer casually asked me about a site I’d built, The Naked Dwarf. Trust me, you really want avoid having to explain in an interview how your 5’4” friend’s 21st birthday ended with his clothes being stolen and the photographic evidence finding its way online.

The first year or two in the job

Congratulations, you’ve got your first job. What now? Now, you simply carry on learning (and get paid for it).

You won’t know a fraction of what the job involves, but in software development no one can know everything. Not even search engines know it all and this is where you will spend a lot of your time. Vastly experienced developers still have to google the answers to things, but when you start out you’ll be doing this a great deal – and that’s absolutely fine.

If you have the drive to solve problems and know how to look up answers then you’re in the right career. Never be embarrassed to teach yourself as you go. Trial and error will be your default technique and you’ll probably repeat the same mistakes more than once. Software development is constantly changing but if you’re always learning then you’ll be successful.

If you want to try something new in your job don’t ask permission, just give it a go. Unless it could affect the company’s bottom line, most mistakes are forgivable and you’ll learn your lessons. Just don’t be reckless.

Get active in the developer community. There are hundreds of free and inexpensive meet-ups and conferences. Be talkative with the people you meet – you’ll learn from them and get to hear about projects or jobs that could be perfect for you. Don’t be self-conscious, and ask as many questions as you can. You’ll find this much easier earlier in your career before you’re too embarrassed because you feel you should already know.

Things to consider as you progress

You’ll hopefully love the company you work for, but only stay with them if you’re genuinely still learning. Job hunting is hard and it’s easy to pretend your current job is just fine – especially if you like your colleagues – but be honest with yourself about your situation to keep progressing.

Don’t feel like you have to go into management. I have as I like going to meetings and shirking responsibility – but if this isn’t for you then find a company that nurtures individual contributors. You can still become very senior in the industry as a Principle Engineer or Architect, with little or no people management required.

Finally do your best to build a good relationship with your boss. This starts with being reliable and prepared, but take it to the next level by understanding what are your manager’s biggest problems and frustrations, and do what you can to solve them. If you struggle to communicate with your boss identify someone with whom they have a good relationship, analyse why and emulate this. Try to understand the business strategy and identify opportunities and threats.

A proactive, reliable employee who understands their boss will get the most interesting projects and the early promotions.

In summary

  • Start building things straightaway
  • Be passionate in your interview
  • Embrace trial and error, don’t be afraid to make mistakes
  • Get involved in the developer community
  • Don’t stay too long in a job in which you’re not learning
  • Get on the same wavelength as your boss for good, long-term prospects
  • Don’t put naked pictures of your friends online
 

Top five Grunt tasks for front-end development

Since introducing Grunt into my software development last year it’s not an exaggeration to say it has revolutionised many of my processes. At work we use Grunt throughout the SDLC but our first adoption was for our JavaScript and CSS, and after building websites with Grunt for well over a year, it is now integral to the front-end development of several key projects. In fact those projects that don’t use Grunt now seem outdated.

Over time I’ve experimented with many tasks and even written my own and it’s this experience that has enabled me to produce this top five list of our essential front-end Grunt tasks (I’ve cheated a bit with the counting).

1. CSS preprocessor

Take your pick between Sass and Less (or the little brother Stylus) but a CSS preprocessor is de rigueur these days. I often chose Less and use the lessThemes task to automatically compile our files into themed stylesheets.

What this means is I create individual theme files with different values for each variable, e.g. theme-uk.less and theme-com.less where the @font-family variable is Arial for the UK theme and Verdana for COM. The lessThemes task simply outputs two CSS files, one for each theme.

If you don’t use themes grunt-contrib-less will do nicely and will output just the one CSS file.

2. Concat / CSSmin / Uglify

They may not realise it, but your visitor wants to download the smallest (and fewest) assets from your site, so a single compressed stylesheet and a single compressed JS file is what you should give them. But these are the last things you want to have to maintain as a developer so you’ve probably already split your CSS into multiple files, each one likely defining a specific section of the page such as header and footer, or typography or a component such as search-box.

Concat takes a folder of individual stylesheets or JavaScript and merges them into a single file. CSSmin minifies this file, removing white space, uses shorthand and making other space saving changes while the JS equivalent, Uglify obfuscates your JavaScript, removing white space and shortening variable and function names.

3. Imagemin / SVGmin

Again, this is all about page performance – optimizing your images into the smallest viable file size.

Image optimization has been around for a while, but as a manual task it is easy to either forget, or just do once, omitting any new images created subsequently. Adding it to your build process with Grunt is just one less thing to do in your quest to produce the fastest website – but as always with image compression you should manually select the settings that don’t compromise quality for file size.

Imagemin compresses .jpg and .png files, while SVGmin does the same for SVGs.

4. JShint / CSSlint

I’ve heard criticism of linting, and I agree that the tools that blindly enforce all rules aren’t doing their job properly, but they’re very effective when you understand the rules and can pick and choose those with which you agree.

The linting tools we use for CSS and JS (CSSlint and JShint) are easy to automate with Grunt, giving you and error when any of your house conventions are broken – invaluable in a multi-team engineering department. I don’t run these lints every time I change a file, but once before deployment is a handy safety net.

For both grunt-contrib-csslint and grunt-contrib-jshint we define our rules in external .csslintrc and .jshintrc files in the root of the project.

5. Watch

The watch task is invaluable when using a CSS preprocessor – you can’t use Less or Sass and afford to not Watch.

This task simply monitors a file or folder and if any files are modified it runs another task; in our case we watch the Less files and recompile to CSS when any changes are made. Be careful though to exclude generated files else you’ll be stuck in a loop.

If you want to take your productivity to the next level use the livereload option in Watch that reloads your browser when a change is made. All you then need to do is edit a file and boom, the change is in front of you and you’ve not had to hit F5.

 

CSS placeholder cross-browser support

A couple of years ago I wrote a blog and demo page to test what CSS attributes can be used to style the HTML5 placeholder and by which browser. I have tried to keep it up to date since, but times (and browsers) have moved on and the biggest thing missing from the last post is mobile support. So without too much waffle here’s everything you need to know to style the HTML5 placeholders.

Mark-up

<input type="text" placeholder="Enter your name here"  />

CSS

/* Webkit */
::-webkit-input-placeholder { color: #CCC; }

/* Firefox 4-18 */
:-moz-placeholder { color: #CCC; }

/* Firefox 19+ */
::-moz-placeholder { color: #CCC; }

/* IE10+ */
:-ms-input-placeholder { color: #CCC; }

Cross-browser support

View the demo page.

Chrome Firefox Safari Opera IE Dolphin
29 30 30 29 24 24 5 5.1 6 6 7 12 7 7 10 11 10
windows 7 logoOSX logo iOS6 logo iOS7 logo android logo windows 7 logoOSX logo android logo windows xp logoOSX logo windows 7 logo OSX logo iOS6 logo iOS7 logo windows 7 logoOSX logo iOS6 logo iOS7 logo windows 7 logo
windows 8 logo
windows 8 logo android logo
background-color S S S S S S S U S S S U U U S S U
border S S S S U U S U S S S U U U S S U
color S S S S S S S S S S S U U U S S S
font-size S S S S S S S S S S S U U U S S S
font-style S S S S S S S S S S S U U U S S S
font-weight S S S S S S S S S S S U U U S S S
letter-spacing S S S S S S S S S S S U U U S S S
line-height S S S S S S U U S S S U U U S S U
padding top/bottom S S S S U U S U S S S U U U S S U
padding left/right S S S S U U U U S S S U U U S S U
text-align S S S S U U U U S S S U U U S S U
text-decoration S S S S S S S U S S S U U U S S U
text-transform S S S S S S S U S S S U U U S S U

Gotchas

Be aware that these cannot be combined so must be written out individually. I suggest using a mixin with a CSS preprocessor such as Sass or Less to minimise your duplicate code.

Also Chrome (v20-30) implements almost all styles but with a major caveat – the placeholder styles do no resize the input box, so stay clear of things like line-height and padding top or bottom.

 

Printing Jira tickets

Since we moved to Jira in the cloud we’ve lost the SPARTEZ ‘Agile Scrum Cards Print‘ plugin. This has left us to hand write our scrum cards on post-it note or scraps of paper.

Being a front-end dev the aesthetics of my scrum board are important to me and scribbled post-it notes just won’t do. So using the Greasemonkey Firefox extension I written a small script to apply a print stylesheet to Jira tickets which strips out the unnecessary content and prints small neat cards.

The code is on Github – please use and/or improve it.

https://github.com/opentable/greasemonkey-printable-jira

Before

After

 

Styling the HTML5 placeholder

log in boxOne of the exciting new form enhancements in HTML5  – designed to save hundreds of hours of repeated scripting – is the introduction of the placeholder attribute for form input fields.

In most websites this jiggery-pokery is still be done by Javascript, but the HTML5 browsers of the future (and the webkit browsers of today) support this with a simple form attribute, like so:

<input name="demo1" type="text" placeholder="Lorem ipsum" />

… 

 

Easyspace – easy theft

I’m not normally an angry person (well I can be a bit grumpy sometimes), but having to deal with British Internet Service Provider Easyspace has got my goat this week.

It started with a couple of mystery payments on my credit card, which after having rung my credit card and Easyspace turned out to be for a website I built 11 months ago, that had been automatically renewed a month ahead of its due date.

Fair enough you might think. Unusual (not to mention cheeky) I thought, but that’s the way they work.  It was also annoying as it was a site I was going to cancel anyway.  The anger came when I tried to cancel the hosting.

… 

 

Move the refresh button in Firefox and IE9

Here’s my first short post which is about fixing an annoying change that Mozilla revealed in the beta version of Firefox 4.  When I downloaded Beta 9 last week I was horrified to see they’d copied Internet Explorer and moved the refresh button from the top left to the top right…

It’s bad enough in IE, but I only ever use IE for testing so the mouse-up-to-top-left-then-realise-it’s-IE-and-move-across-to-the-right issue is annoying but I don’t lose sleep over it (and F5 is everyone’s friend anyway).

But top-right in Firefox – now that is annoying.

… 

 

Automated CSS testing, or how one CSS coder is now responsible for breaking – and fixing – the build

For the last six months or so the traditional process of releasing the latest version of our company website has been simplified and automated by one particular bright-eyed, talented young developer with a penchant for Ruby.

As the company’s CSS/UI/Front End guy this technical stuff is way out of my remit, but the end product has been hugely useful for the IT team as a whole; my single biggest benefit is being able, with a single click in TeamCity, to publish websites to various test servers.

So whilst the automated wizardry has being going on around me, I haven’t followed how it’s been happening, but I’ve understood why; getting everything automated saves time, right?  So why not get my front-end work in on the act?

…