Attracting great engineers
tomblomfield.com
tomblomfield.com
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.
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.
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.
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!
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.
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
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.
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.
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.
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.
If you sit in your office writing fantastic software without telling anyone about it, you're destined for a pretty lonely future.
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!