> we strongly encourage people to choose between the MacBook Pro and Air. We’ve had several people originally opt for various flavours of Linux, but they’ve all swapped over to Macs within 12 months.

I'm curious if they've swapped more because of their own personal preference, or the "strong encouragement" from your team, or some combination of both. While I completely get the added value that comes from the homogeneity of equipment in the office, as a Linux guy, I've interviewed in places where they were basically like "Yeah, we're a mac shop, and you need to be too". It was kind of a turn off. I like macs and don't mind using them, but at the end of the day I'm a big believer in going back to the tools you're most comfortable with.

I guess what I'm trying to ask here is, how do you strongly encourage people to go for MB Pro or MB Air, without coming off as overly pushy? Interested to hear how you strike that balance, because I agree 100% that getting most of the team on the same equipment (or roughly so) is a big plus.

A laptop how cute I would expect a decent mac pro if I was going to be using that as my main dev machine and have a couple of pool laptops for when you need to be mobile

And if your not developing a mac application - why would you develop on macs?

You should normaly (ie 99% of the time) develop on identical hardware to that on which production is going to be running - rules out all the risks of differences between dev and live

I generally ask people to all use the same tools so that they can interract on each other's machine, and so that the code is all looking the same (unless someone is trying a new tool, of course). Development is about collaboration and thinking, it's not about typing fast or other time sensitive things. But i explain all this at the interview, so that candidates can determine themselve before accepting a job. Switching to linux would emcompass convincing the whole team.

On the other hand, I see a developer's tools as an extension of his or her mind. Enforcing that everyone uses the same tools seems like a great way to encourage hive mind thinking.

Especially proprietary tools that can not be automated or extended is something you should be wary of pushing onto for example a bash and vim wielding programmer, unless your business has no need for major productivity gains to grow or to sustain itself.

I don't encourage hive mind, by other means. The proprietary tools I recently used where automatable with either apple script system or in java for jetbrain product, but generaly we would do a lot of command line automation because we are more proficient in that. And I try to push products designed for their users instead of designed for their licence or their developers to my product team. But also i leave the freedom to my team to change the tools, every wednesday, we can change some tools, for the whole team.

I currently work at a place that is mostly Macs and I use a Thinkpad. 3 of us are working on the same Android app and one of us uses Eclipse with stock ADT, one of us uses vi and ant to build and I currently use Android Studio (was previously using Sublime Text and ant to build).

I've worked at other places on other types of software in similar situations where each dev may have had a very different setup, and in my experience while this may introduce a bit of one-time hardship at the very beginning of a project, it actually leads to a much better and robust product later because there tend to be issues with the code or overall process that are hidden from you (but can still bite you) in a homogeneous environment that become extremely obvious quickly in a heterogeneous environment.

But to each their own. As long as you're upfront about your one-size-fits-all process I can easily avoid working for you!

> Development is about collaboration...

It some cases development might require or benefit from the collaboration between more than one developer, but I think it's quite a stretch to write "Development is about collaboration."

There does exist successful software and applications written by a single developer.

It's totally true, in those rare cases a team leader would not be there and the whole discussion about hiring developers is completely irrelevant, and nobody is really there to check the tools. But I tend to bend the world around me my way: team work, emphasis on innovation, more or less agile, continuous deployment, don't be afraid of change, try to keeep the code clean etc. By being clear during the interview, I give everybody the opportunity to make their mind about each other. Not everybody is welcomed in my team, and my style is not welcomed everywhere.

We actually didn't encourage people to choose Macs until very recently, and the ones who have previously made the switch had to fight hard for it internally, since it requires significant expenditure - we basically ditched £2,500 of equipment for each person.

They were just fed up with not being able to use many of our standard internal tools, which were largely built for Mac. Having to debug and adapt each one for a new OS gets old pretty quickly.

Yes, I really really really care about Linux, and started working at a "use the tools of your choice" company, but since I was the only one using linux, and no one was caring about compatibility issues, I had to switch to a Mac. And no, I wasn't having fun, it wasn't my choice. It's a Ruby thing, that love of macs, makes me want to never program ruby again.

Really? I find that Ruby works fine on linux. In fact, I doubt anyone is using anything else for their production setup.

Unchecked assumption: the developers most likely to engage with "incendiary" posts about "ditching Responsive Design", or developers that show up at developer conferences, are most likely to be the "top engineers". Why do we think that? How do we validate whether that's true?

On the one hand, I agree that the idea of needing to engage with blogs and conferences in order to succeed as an engineer is way oversold. The whole point of engineering, after all, is to create artifacts that speak for themselves.

On the other hand, I think I might know "why we think that": If hiring is the hardest and most important problem facing most companies, which people keep telling me it is, then it pays to hire with an eye toward further hiring. You might therefore put a premium on hiring people who engage with others via writing and conferences, not because these are necessarily the best widget designers, sprocket debuggers, or gadget platers, but because you expect these people are more likely to go out into the world and be noticed by the great designers, debuggers and platers who you'll want to hire next.

Obviously this can be overdone, and if you feed this process back on itself you'll end up with a one-dimensional clique of a company - in part because blog posts and developer conferences are a very narrow and biased sample of the universe of competent and potentially-competent people. But it shouldn't be surprising that companies think that "always be advertising" is a characteristic of a "top engineer": The problems of hiring are at the top of management's mind, and are probably the only thing at the top of upper management's mind - in my experience, the CEO could not care less about the glitches in the firewall-configuration system, but she interviews half a dozen candidates every day. Every all-hands meeting is filled with exhortations to blog more, shake more hands, hand out more cards, meet more people.

Another question is 'What kind of great developer?'.

The best developers I've seen in terms of producing awesome technology tend to be quiet, methodical people. They are highly disciplined, and have a routine.

This regular, structured way of doing things means that they consistently practice out of hours, commiting regularly to an open source project while mere humans like me flit around playing with new technologies. They develop expertise.

Would you want this kind of developer evangelizing your technology? If you sat them with a client, would they have the soft skills to drive the conversation where it needs to go? Would they enjoy, or avoid these parts of their work?

I think people are people, and people are different. It's worth recognizing this and looking for the sort of person you need.

We think it's true for the same reason many people talk about Hacker News as though it's the only place that attracts talent, and as though talent universally flocks there.

It's $INGROUP bias, and sectionalism. On the one hand it's self-affirming ("I go to conferences, I keep current on Hacker News, these are things good developers do, I'm a good developer"), and on the other hand it's trendy and convenient ("I'm going to post my job ad on Hacker News because that's the trendy place to be for good developers").

I think it's ultimately an echo chamber effect. I'm guilty of associating Hacker News with talented developers, but I'm aware of this bias and it's because I pay attention and follow the posts of people who have more or less proven themselves.

I think it would be very difficult to validate these assumptions.

I've been wondering recently whether having a team of top flight developers in your tiny startup is actually a good idea. Developers need things to do. More developers directly equates to adding features (assuming you have a reasonable team who understand modern deployment, frameworks, testing, etc). It must be possible to have more development resources than you can do user testing for (eg finding out what users want/need).

At what point does available development talent make "featuritis" inevitable?

Clearly, in a startup like GoCardless where they're dealing with banks, financial regulations, etc that's unlikely to be a problem, but if you're making yet-another-photo-sharing-app or it's-just-chat-but-different-this-time-honest-dot-io it should be a small concern.

"...based on a £40k salary..." How sad that it's still considered "normal" in London. So basically toys and noise are cheaper than hard cash. No wonder best devs go to finance.

Well, it seems thinking behind salaries at startups in London is simple - get a cheap workforce (ideally fresh uni graduates) and let them falsely believe that they can get rich by giving them a tiny slice of stock options. Ironically the people who are hiring them would very often badly struggle passing tech interview at another company - especially when sometimes you're interviewed by people who have no background in CS.

I'm always a little bit warry of "developper marketing" like blog and conferences, because when you do that you're not developping, and this shows skills that are quite different than the ones required for software development. Marketing is all about mass media one way communication (broadcast), development is at most two way personal communication.

I think blogging is actually much more a 2-way communication than traditional broadcast media. See this discussion as an example.

If you sit in your office writing fantastic software without telling anyone about it, you're destined for a pretty lonely future.

Participation on the internet is around 1%(edits on wikipedia), that's way more than tradionnal media, and 1% of a one to one conversation. Blogging is still putting on a suit, climbing on a soapbox, reading an edited speech and answering publicly to remarks (ie taking stances, playing roles).

they already have jobs so you have to poach them from where they're working; netflix/facebook/google etc. you do that with money. all this other stuff should be taken for granted. if you're hiring engineers that are failing google interviews then you're not hiring the great ones now are you.

the problem is that most companies don't have the ability to poach great engineers, but they pretend they do so they go and write little posts like this one, but ironically they aren't qualified to be writing these posts in the first place!

People leave big companies for smaller companies for a variety of reasons that don't have to do with money: product, culture, team, technology, or just for the sake of working at a smaller company. And for the record, Google is not a perfect Utopia that has a monopoly on all the good developers with a flawless interviewing system.