My favourite parts of Upfront Mini 2015

Yesterday I was lucky to attend Upfront Mini – a smallish (150 person!) one day conference about Front End Web development – the parts that appear in your browser!

I particularly liked this part of the introduction:

First up was Lily Dart talking about how the skills of a good designer: empathising, taking responsibility etc are also the skills of a good leader:

I don’t write front end code. I wish I could, but my role is that well known sweet spot between systems administration, user research and sales, and so like everyone else – I was there to learn. Being able to understand, empathise and mentor customers and colleagues is a really useful skill and I strongly agreed with some of her points.

Her slides are here:


I enjoyed Sam Beckham’s talk about the Polymer library and Web Components.

Most of my front-end experience was gained 5-10 years ago, in xhtml 4.0 where you felt lucky if you avoided a frameset so I find HTML5 (and Web Components in particular) mindtwistingly futuristic – perhaps how the internet must feel to people who group in the era of letters and telephone operators.

By chance I read this great article about web components the night before the conference, and Polymer is a library (a HTML library actually – how about that?!) that makes Web Components easier.

In the most basic, layman’s terms (probably with inaccuracy and missed subtly), Web Components are a way to create snippets of html, and call them back later in a simpler form – perhaps slightly like creating a function in code. Say you want something to create a slider or something, but don’t want to copy all the setup code everytime you want to call it – so you can import the html library that defines it, and then simply reference it with a simple tag. It looks like this is the future.
Unfortunately, currently: Browser support = patchy.


Emma Jane Hogbin Westby’s git talk was interesting (here’s the slides and notes) – and fortunately a few days before, I’d also read this great article on git branching – so I was able to follow along and understand most of what was being said. because I don’t really touch code, and only touch git for hobby projects , I don’t have such a deep understanding of that part of software development. As a result of the talk and the article though, I now know a bit about where you might want to keep all the individual commits that make up a feature and where you might want to squash them into a single object.


Amy Philips’s talk about mobile testing gave me an incredible headsup about how little I know about testing. Basically, testing mobile software is super hard – because there are so many different platforms, software versions, levels of connectivity, accessibility settings that testing becomes super-hard! I now feel extra inspired to go listen to Gem Hill’s Let’s Talk About Tests Podcast and understand more about the subject.


Benjamin Hollway gave a talk about young people and technology – nothing out of the ordinary I thought – just another youngish developer talking about the issues of being young, and trying to get into the technology community. Then after the talk, it came to Q&A, and it was revealed that Benjamin was 17. I was floored. Of course, I should have spotted the clues, but to the organiser’s incredible credit, they hadn’t billed the talk as anything different, they hadn’t said the presenter was young. It was very well executed. The Q&A were lively, with some people clearly inspired to see 17yros doing impressive things, suggesting that perhaps agencies should be recruiting people pre-university. Other people were unconvinced, wondering if pre-university young-people would be able to concentrate through a 9-5 day. They were roundly put down when it was pointed out that most normal developers can’t concentrate through a 9-5 day, not to mention that school/college is basically a 9-5 commitment before that point!

I could empathise with Benjamin a great deal and was psyched to see another YRS alumni going on to fulfill their own dreams and forge their own path. I didn’t go to university, got a job straight out of college, and heard lots of people telling me lots of conflicting information at that time. I always love the conversations that arise when a conference supports a young speaker like that, and I really appreciate that Benjamin and the conference organisers made it happen.


I had a good time catching up with Katrina and talking to Nathan about design processes and how to build things, meeting Goose, working out scary tech halloween costumes with Chris, finally chatting to Nick in real life and Andy about marketing & deals.

As the first event in the upfrontconf/speaktheweb that I’ve attended, I really enjoyed it – the organisers – Simon, Rachel, Katie, Dan & Jack, deserve a high five for putting in all the effort to make such a great event happen. Thank you all!

Pieline.net

What we learnt from building a jobboard

A few months ago we built a jobboard — pieline.net. It was mostly a programming challenge — we wanted to learn more about databases and Node.js, and we thought that this would be useful and straightforward.

There used to be the Geekup Jobboard, run by Andrew Disley, free and for everyone (except recruiters). It was split up by functional areas — business, design, development and others. A few years ago, Andrew focused his efforts on a better solution — NeedHQ and the site received no new jobs.

Pieline.net
Pieline.net

Tim had talked to an Agency owner who was sad that the site had gone and we also knew new developers who weren’t aware of the volume of jobs available, because they didn’t know the names of all the different companies to look at their websites. Other jobboards didn’t have jobs outside of London, didn’t have a clear UX, or were full of recruiter jobs which obscure the name of the comapny you’d be working for.
The idea was to create a simple job board — listing one job from every tech company around Manchester for 30 days. Ideally, people would submit their jobs to us. In practice for the time we ran the site, we manually added ~200 jobs by hand, and never had one submission.

Learnings about companies

Companies are hiring all the time. Even the small ones. Everybody would like another developer or two.

Most companies suck at designing their websites with recruitment in mind. At least half of the sites we visited buried their recruitment page — we often found ourselves trawling sitemaps for a link. Given how competitive it is to recruit developers, we thought that every company would list the main technologies a developer would be using in the job, but all too often we found that ‘Front End developer’ really meant ‘PHP developer’, or there were just no useful details at all. When we looked over recruitment pages, we were struck by a unifying theme — they put no effort in. We rarely had enough information to say whether we could do a job, let alone if we wanted to choose one over the 200 other jobs in Manchester.

When we talked to employers, whilst they were interested in receiving better people, they were totally uninterested in yet-another-jobboard — especially without any candidates already coming in. There are many job boards, and it seemed like putting the jobspec together at all was a labour. They were understandably deeply suspicious of anything that resembled cold calling recruiters (even when we approached via email!).

A very small minority of companies listed clear breakdowns of the job and requirements, with renumeration, perks, and insight into company and engineering culture. We’d probably say AO.com has one of the best hiring pages of the companies we’ve reviewed. If your page is half as good as theirs, you’re above average.

Learnings about technical things

If you don’t know if you’re building the right thing, use duct tape, not superglue

On the technical side, we learnt how you (in a very hacky way) use Node, Express, Bootstrap, CSS, MySQL (especially joins), resolve git conflicts, and Tim learnt some JavaScript. We wanted to use a fairly lean approach, and we had a somewhat functional site live within hours. This was possible because we borrowed a lot of the backend from an open source Node CRUD app.

When we needed to secure the admin area where we could add and review jobs, we didn’t want to learn about authentication in javascript — so instead we created a password protected area via nginx and left it at that. Not rock solid, but good enough.
We never had a staging site — we deployed straight from our git repo. This wasn’t ideal but did force us to test a lot, and fix it if we broke it. When we wanted to move fast and get it out the door — we got it out the door.

Learnings about UX

To figure out how it worked in the hands of users, we went to tech meetups, and asked people if they wanted to see this thing we’d been building, and when they said yes, we asked them to apply for a job on the mobile site. As we watched them use it on their phone, we saw them click on the wrong bits, expecting things to work differently, and instantly gathered feedback about which bits worked and which bits didn’t. Some more experienced developers (I’m thinking Bobby and Martin in particular) were kind enough to critique the UI for us as well, which helped us get some of the common-sense navigation in place. We were reading Lean UX at the time, which gave us some great approaches for iteratively improving the user experience.

Users said many things — often they asked for features we didn’t want to implement in an MVP like search. Almost everyone wanted a clear salary range and we just didn’t have the data.

One of the challenges was that people often didn’t know what jobs they wanted.

People who could be hired into junior or graduate jobs, didn’t know whether they had the qualifications, when all they really needed was enthusiasm, the ability to learn and not being unpleasant to work with.

For more senior people, it often wasn’t really clear what the most useful details were to put in front of them. “Can I actually do the job?” seems like an important question, but understanding what the company is like, why they might want to work there more than where they work now, is also important information, which we couldn’t figure out a way of displaying.

One idea we had was that most job adverts are sparse on details, and so it seemed like the ability to ask each company a question — in an anonymous, ebay-style public Question & Answer might be an appealing feature.

The Q&A feature
The Q&A feature

We still think it’s a good idea — imagine: You read the job advert, you’re happy with the salary, you know where they work, you have the skills, they seem nice enough — however, you have some questions…questions that might be awkward to bring up in an interview. Questions like “do people ever pull all-nighters to finish things for a deadline?” or “will I be able to leave early some days to pick up my kids from school?”. Ultimately, although we tried our upmost to seed the board with questions, and use this feature to add value — we weren’t able to get it moving. We think it’s a neat idea, and perhaps might work really well — unfortunately we didn’t hustle hard enough to see any traction.

We tried adding Optimizely A/B testing to gather data about incremental changes. We might have been better off testing more radical variations but we learnt that with the amount of traffic we had, we were never going to learn much fast with very subtle A/B testing. Ah well.

Learnings about Growth

We never had a growth strategy that was sustainable, real or existant. We tried some paid adverts to get traffic, but since we never received any revenue from the site, this was clearly unsustainable. The idea never had a ‘purple cow’ so there wasn’t much virality potential. The question feature is probably the closest we came to it.

We feel this is an area we would give more thought to next time. Really, we should have tested this part first. ;)

In conclusion

One great outcome is that a several people found jobs because of pieline! This was without doubt the best part of the experience — we’ve heard from a couple of people who found companies on pieline, applied for the jobs listed and got them, which is very satisfying. One of them became a good friend, and we got to hear all her stories of starting her first development job. It was also a great side project for Clara to show off to employers as she was looking for her first coding job at the time.

We learnt a lot from the project — about technical things, about product, about UX. I think the main thing we learned, was that a job board isn’t the best way to solve this problem. We’re not sure what the best solution is, though better company careers pages are clearly somewhere to start.

The site is mostly now offline, though it survives on archive.org, Github and trello. As for us? We’re better prepared for our next adventure.

Pieline was made in the People’s Republic of South Yorkshire with love by @czmj2 & @tdobson.