Hiring startup hackers

by Andrew on October 16, 2008

I’ve seen a lot of posts recently about how to go about hiring hackers. Well not just recently, it seems to be common thing people ask, because it’s one of the hardest things to do. You’re using an interview, or even a series of interviews to try your best to determine if the person is going to be up to the task.

The problem is of course, you’re really just determining if the person interviews well, or if they’re the graduates that they’ve got good marks. The real problem is of course neither of the two matter because neither of them have much if any bearing on how good a coder a candidate is going to be.

The problem is exacerbated in a startup because unlike some of the more successful bigger players you really can’t afford to take people on a trial basis for 6 months. What can a startup do?

There are a lot of universities that run placement programs for their students, programs allowing them to get real industry work experience. I’ve also worked in companies that made it a policy to hire students for internships then offer the best jobs once they’ve graduated. It was a great way to get talent.

What if you need to hire to fill a more senior role, or you’re not hiring at the right time of year? Student internships usually start once at the same time every year so unless you’re looking for fill a role then, you’re shit out of luck.

I’ve toyed with the idea of a ‘hacker camp’, getting all the candidates together, and paying them to work as consultants on a project - then hiring the best into permanent positions. All the candidates need to be free to work on the project, and a lot of people would be pretty scared to leave a job to take part and some jobs would prevent them from working on the project, so running it over a weekend might be a good idea, but it limits the scope of your project. You’d also still need to have interviews, to make sure you were getting candidates who were really interested in the job, and also to weed out any candidates you knew were totally unsuitable.

I think it’s important that a ‘hacker camp’ should produce something at the end of the weekend and you should get as much of your existing staff involved as possible. To make the cost easier to swallow you could even go so far as making the deliverable a new feature or part of your existing product but that’s not as important as actually delivering something, because that will be the bottom line when it comes to integrating them into your team.

Reblog this post [with Zemanta]

{ Comments }

What’s with the twitter spam?

by Andrew on October 15, 2008

I’m starting to get lots of messages about people following me, they’ve got one post and it’s a link to “check them out” lots of new pics added.

I’ve been blocking them as they show up, because I only have a few followers. I wonder how the popular people, who must be getting thousands of these cope?

Fucking spam, it’s got to try to ruin every good thing.

{ Comments }

Openness, strength or weakness?

by Andrew on October 15, 2008

As I’ve announced here, we’ve recently taken the difficult decision to put development of Citrus in hold, indefinitely (let’s be realistic, probably forever). I’m now wondering what if anything we should announce about our new project.

Is openness a strength or a weakness? Is there value to the community in publicly documenting our design decisions, and how we’ve come to them? Is it something our competitors could and would use against us? Is there anyway to mitigate the effects?

I like what Jeff Atwood and Joel Spolsky have done with their series of podcasts on the Stack Overflow blog where they’ve released their design meetings as a series of podcasts and given us all an insight into how they’ve come to some of the decisions they’ve taken. But let’s face it I’m neither Jeff or Joel and I don’t get anywhere near their traffic. So the first obvious question I’m asking myself is if it’s even worth the effort of writing posts, let alone recording and releasing podcasts.

Next is the question about maintaining a competitive advantage, given the fact that our team is so small, just the two of us at the moment; I’m only working about half time on the project and Simon, who isn’t a coder is working even less. So giving someone a guide to competing with us could be downright foolish. Then again, nobody is really listening are they? So does it even matter?

The other question, which I think is equally important as the project grows - hopefully into a product is what if any level of openness is appropriate post launch? Will an open discussion of ongoing design decisions as they’re being taken before, or even as they’re released be of any benefit to the community? Communities can be some of the biggest supporters and can be some of your most passionate users - sometimes these passions can work both ways? What level of support ongoing will a public discussion of the decisions you’re taking, before users have all the prototyped interfaces to play with, be required? Is there an ongoing effort you’ll need to make to maintain the level of trust and confidence of the community?

I think I’ve talked myself out of a podcast of our internal discussions, for now - but I’m still keen to use community interaction to help us develop a product that meets the needs of the people who are interested in using it and to drum up support and interest in the project. I’ll no doubt return to this topic in the coming weeks as I develop a clearer idea of how I think we should accomplish that.

If any of the few of you out there listening have any questions or comments, please let me know your thoughts.

Reblog this post [with Zemanta]

{ Comments }

I’m loving Zemanta

by Andrew on October 14, 2008

I added Zemanta to the blog today at lunch time and so far I think it’s great. I’ve gone through and quickly added a links to a few posts, I’m not going to go back and do many but I’m going to use it going forward.

One of the most common pieces of advice you hear about blogging and getting noticed is to link. With Zemanta linking far and wide is a few simple clicks away.

I have no vested interest in Zemanta - I know very little about them. I really just like what it does.

Reblog this post [with Zemanta]

{ Comments }

Location based is the future of mobile

by Andrew on October 14, 2008

First we started to explore, then quickly we needed to figure out where we were and we’ve been building increasing numbers ever more sophisticated maps, guide books and other sources of location based information ever since. The extension of this location based information to mobile Internet enabled devices is the obvious next step and potentially huge market. Just think of all the location based data people pay for:

  • Mapping probably the biggest market segment, and the first which we’ll see device convergence. Look to see the traditional GPS hardware/software become applications for the current and next generation devices.
  • Reviews A common feature of newspapers, local and region
  • Business Directories again, think of the big yellow book of business for every area. It’s one of the most common things to look for in an area.
  • Travel Guides More than just reviews, travel guides also provide us with areas of interest and all of that is very useful in an up to date online service

All of this is pretty obvious and most of it exists now. The problem up to now has been the walled garden approach taken by the mobile phone companies. They had the ability to determine position, but wanted to charge for it. Unfortunately for us consumers, charging for that data has meant that for the most part services would need to turn a profit for every single request, from the start or they’d be very expensive to develop and very quickly.

Mobile data has recently become very cheap and new devices with integrated ability to determine their location is having a profound impact on the mobile landscape. They’re allowing us to build services which instead of answering the question: where is my nearest X, will let us explore the area around us. Mapping the wealth of knowledge on the internet to physical locations and allowing us to actually input data when we’re most likely to want to - when we’re actually there.

From experience, when I’m out there the data I want most is about out there.

Reblog this post [with Zemanta]

{ Comments }

While they’re all standing still…

by Andrew on October 13, 2008

I’ve been a bit lax with the posting again, but I’m trying. Continuing with the theme where I left off last time, starting companies in the downturn (likely to be a recession), the last time we talked the worlds markets were in turmoil, the banks had stopped lending money to us and to each other. Things have continued and are even worse two weeks on.

Now some would say is the time to tighten belts and budgets, for prudence sake. At least that’s what everyone else is doing, and what we’re doing at home to be fair. It’s cheaper shopping, soups and casseroles for the winter. Many businesses are reacting the same, I’ve heard it from them and so have you. Even businesses that have nothing to do with the finacial or property markets are tightening their budgets, and feeling or causing the pinch to be felt.

Is that good news for the nimble small business? Like every other news, yes. Small businesses face unique challenges their larger competitors don’t but they have one major advantage - they can move and react faster.

Don’t get me wrong, I’m not suggesting anyone should go on a spending spree. But neither am I suggesting that now is a time to be completely miserly either. What I am suggesting is that while your larger competitors, or even competitors of similar sizes are worrying about the future and cutting back their development efforts; or cutting back their staff, salaries and benefits. It’s a great time for you to make the leap to the next level, and come out ahead when this is all over- because it will eventually end, one way or another.

Reblog this post [with Zemanta]

{ Comments }

Up in the downturn

by Andrew on October 1, 2008

I think it’s clear now, despite all the best hopes of an easy ride, that the economy has gone to shit. I also think it’s clear that no matter how far you try to bury your head in the sand, it’s affecting tech and other industries now. The knock on effect has a arrived and the inability of some to get operating credit as well as the fear of not being able to get credit if they might need it has lead to some belt tightening already, and there is more of that to come.

Maybe it’s a little cynical of me, but I think that some consumer websites which are lean and well capitalised must be liking the idea that people are going to be out of work. I mean without their boss bothering them to get off facebook and do some work - they can just do that all day, can’t they?

Really though, I think this time around the Internet is probably one of the better placed industries. We’ll feel it less and later than others and we’ll come out of it better off and earlier than some. Big ticket items are going to be the first to go, houses and cars are already down and falling fast. Holidays are out, entertainment and going out is suffering and it’s bound to get worse. That’s going to leave people with more time to waste, at home in front of their TVs and in front of their computers.

When confidence and spending starts to rise again, we’ll start to see people with a little money chasing bargains with time on their hands - isn’t that what internet shopping is all about?

The core fact of the matter is the economy is in the shitter because of banks - there is nothing fundamentally wrong with tech companies today. It’s not anything like the previous bust, it’s not a correction reigning in stupid valuations for companies with no clear path to revenue let alone profit.

Is it a good time to start a company though? That depends on how much if any investment you need. If you can bootstrap, and you should, then it’s a great time. If you’re going to need to find investment to get your idea off the ground, you’ll have a hard time with it. Until we can see the light at the end of the tunnel, and we’re sure it’s the end of tunnel investors are all going to assume it’s just a train.

A bit latter than normal, sorry about that. I’m really trying to maintain the post a day thing and I’ve been scheduling them in advance - I didn’t get a chance to get one scheduled for today so it had to wait till work was out of the way. I’ll endeavour to try harder. ;)

{ Comments }

Interfaces first

by Andrew on September 30, 2008

Don’t write spec documents, throw away any you have near you, they’re next to useless anyway. It might seem like a hearsay to some but it’s true and deep down even the most most anal planner in all of us knows it. Two of the biggest reasons for this are:

  • size and scope: In order to address every aspect of your project a full specification document has to, well address every aspect of your project and it’s going to be huge as a result.
  • lack of vision: For most people relating what’s written on paper to a vision of a design in their heads is difficult if not impossible.

Loose documents don’t work well either, because leaving the obvious unsaid just leads to problems, chiefly not everything is obvious to everyone. The devil is in the details and avoiding them until the end of a project is just going to cause trouble.

“Why haven’t we implemented x, that should have been obvious!”

create the interfaces

Prototype the interfaces and use them as your spec. Working this way has so many benefits, try it once and I promise you’ll be converted. Before you write a single line of backend code, sit down and work out your interfaces. Build each screen, put all the buttons, fields and elements on the page

I normally start with index cards and write a few simple requirements for each screen or page - just a few simple sentences listing what the page is expected to achieve.

My next step is to turn those requirements into interfaces.

in HTML, not photoshop

Photoshop is great, but let’s face it it’s no better for trying to work out a functional interface prototype than some paper and a pencil. It’s very easy to focus on making things look pretty over making them functional and you risk missing something important out.

The best way to avoid both of these traps is to write your interfaces in HTML, mark them up semantically as they will be marked up in the release and use them as your working spec.

I know good design but I’m no designer

Another benefit of coding up your interfaces in HTML before you start writing code is you can hand them off to designers so they can make them look pretty as you’re working on making them work. I have a pretty basic idea of design principals and the tools - but I find it hard work. So with interface first development I don’t have to think about it.

let the testing begin

Another thing which is made infinitely easier with interface first development is functional testing, because your testers don’t have to wait for a release before they can start developing a test suite. You are using an automated test suite aren’t you? By generating interfaces as developers add functionality testers can already have been through the interfaces and written a whole series of failing tests.

updating later

The great thing about using HTML as your design and communication tool is that when it comes to making a change to a page you have the most up to date working copy there ready to modify in the form of your site. Just save the page, add the change to the HTML and you’ve got your interfaces ready for discussion and later implementation. What could be easier, faster or more clear for everyone?

it’s not a panacea

There have been times when I’ve been working with notoriously difficult individuals where nothing was going to satisfy. An exmaple that springs to mind is a multi month project where we produced an interface design early in the project. The design was a set of PDF images not HTML (see above), but the delivered product was a pixel perfect implementation of it. Only once the project was delivered was there any input on the design or functioning of the project - I’m not just talking things that a PDF can’t show you like what clicking a link looks like. I’m taking basic things like colours, layout and the size of elements!

Would a HTML mock up have made any difference, I actually doubt it. I take blame for miscommunication and resulting mistakes when it’s my fault but in this case even after the site was fully developed and deployed to a staging area for testing none of these issues were highlighted. It was only after the site was put into production that these “critical issues” were discovered.

{ Comments }

Is it better?

by Andrew on September 29, 2008

After reading this post what Jamie said hit me as well:

This is when I realized how trained I was in the processes at my former workplaces. This email would have been delayed until it was perfect[...] After fixing this there would be another thing and then another thing. A 2-day project would drag on for a week of redesign, approval, and development[...] It’s one thing to read Getting Real [...] It’s another thing to actually practice the principles. [...] That part is trickier than you think.

I don’t think it’s just Jamie and I don’t think it’s just his former workplaces. We’re all trained to make excuses not to launch, it’s endemic in the culture of most organisations. We endlessly pay lip service to the principals of release early and release often, agreeing in principal
with the principals - but put very little of them into practice.

A manager’s role is to facilitate an organisation’s march towards better - all too often it’s a weak manager that needs constant input on projects and at the root it’s fear of inadequacy on their part that builds a culture of ass covering. It’s obvious that at 37 Signals they don’t suffer from being crippled organisationally when executive decisions need to be made but executives are absent. Their staff are trusted to make decisions and they’re empowered to release better features.

When your last change was ready to deploy, when it was better than what was there, did you release it? If not, how long did it take you to get from that point to actually releasing it and how many people had to give final approval?

Why not empower your staff with a simple test - Is it better than what we have? No flow charts, no organisational hierarchy; just a simple question.

{ Comments }

Location services - must try harder

by Andrew on September 26, 2008

Location based services, another area where there is certainly a case to be made for someone to make it suck less and probably a number of successful application to build on it.

Why it sucks

Location services suck because it’s inherently hard to map the collection of information on the Internet to physical locations.

Most of it just wont map because it’s not about something physical.
It’s obvious, but true - most of the Internet isn’t about a place, or a thing that is likely to stay in one place. This post for example, or this blog’s homepage - neither are about anything specific. My house isn’t

It’s hard to map because language is imprecise, physical location isn’t.
When you’re looking for a nearby restaurant a blog post with a review of a restaurant in London probably won’t give you an address and probably won’t even link to a site that will. It’s become the job of search to try and link the post, a very difficult job - was the post about London, England; London in Ontario or one of the dozens of other Londons around the world. At best the search engine might be able to link the name with another URL that contains an address - but there are no guarantees the name is unique or the address is right.

Sending letters for physical addresses with an activation code is one approach Google has tried, I’m not sure how successful it’s been though - I haven’t noticed locations search has stopped sucking, so I assume it’s not the silver bullet.

Sucking less

How to go about fixing it? If I knew the answer I’d be coding the solution right now and wouldn’t be sitting her writing and thinking about it.

The rise of location aware internet devices
It’s inevitable, the rise of the iPhone, Andriod phones and other location away devices with Internet connections mean people are going to want to consume location based resources. Though they’re not the first phones on the market to do any of this, they’re game changing because they’re the first platforms that make it easy to consume and more importantly produce location based content.

The other key ingredient these platforms offer is a browser, not just a cut down browser - a real browser, with tabs and javascript and all the trimmings!

Like any good problem, this one can be solved with metadata!
We’ve got the consumers with their million plus iPhones, we’ve got the producers who all want to start geo tagging. The problem is how do we link the two and how do we make it easy? We’ve got a few standards for location tagging document, but no clear forerunner.

Suddenly it doesn’t suck anymore

Services for producers and users to announce and tie information to physical locations is going to be the catalyst that really makes local search and local information portals of all kinds take off. It won’t be long until someone comes along with a killer solution.

{ Comments }