blog.nforget.com

Short answer: Decide what you want to make, the rest will fall into place.

From the Hirelite Blog:

When you say “rock star” in your job post, you’re discouraging the best software developers from contacting you.

When you write, “We’re looking for a rock star developer.”
A developer sees, “We want to treat a developer like the RIAA treats rock stars.”

Using “rock star” in your job post may have communicated a trendy vibe at one point, but those times have passed. Now it communicates a desperate attempt to seem cooler than you really are, a sign that you’re too full of yourself, or that you’re just naive. 

Naivety worries developers the most. To developers, “rock star” communicates that you’re not sure what you want. Or rather, you do know what you want, and what you want is a miracle worker. “Rock star” signals that you haven’t thought enough about the role this developer will fill, leaving developers with a feeling that they’ll be receiving ill-defined requirements, not enough time, or not enough resources to do their job (in addition to being overworked and underpaid).

Douglas Rushkoff argues that the United States needs to be teaching programming in grade school.

Amazingly, America - the birthplace of the Internet - is the only developed nation that does not teach programming in its public schools. Sure, some of our schools have elected to offer “computer” classes, but instead of teaching programming, these classes almost invariably teach programs: how to use Microsoft Office, Adobe Photoshop, or any of the other commercial software packages used in the average workplace. We teach our kids how to get jobs in today’s marketplace rather than how to innovate for tomorrow’s.

I particularly liked this part:

When human beings acquired language, we learned not just how to listen but how to speak. When we gained literacy, we learned not just how to read but how to write. And as we move into an increasingly digital reality, we must learn not just how to use programs but how to make them.

Part of my current job involves helping the designers and user experience people design interfaces that will work on a variety of devices, including touch-screens. The number of times “on mouse over” has come up—usually as a compromise solution—is maddening.

I’ve just attended echelon where several of the international visitors were sat in the audiences cradling and poking at their iPads.

When I sat down to a redesign of the Gameplan admin interface I suddenly came to a realisation, :hover doesn’t work. It’s entirely possible I’d skim read this somewhere, but somehow the implications for my design work had passed me by until I saw an iPad in use.

As so eloquently pointed out in this article this lack of hover (along with the technical and performance issues) is one of the reasons making the iPad run flash is not something Apple are keen on.

Jeff Atwood, creator of Stack Overflow and blogger extraordinaire, writes about what it takes to make a remote software development team run smoothly.

When I first chose my own adventure, I didn’t know what working remotely from home was going to be like. I had never done it before. As programmers go, I’m fairly social. Which still means I’m a borderline sociopath by normal standards. All the same, I was worried that I’d go stir-crazy with no division between my work life and my home life.

Well, I haven’t gone stir-crazy yet. I think. But in building Stack Overflow, I have learned a few things about what it means to work remotely — at least when it comes to programming.

From a panel at GDC.

Bettner’s philosophy for his new company, Newtoy, has absorbed the hard-learned lessons from his time at Ensemble. “We don’t crunch,” he vowed. “We just don’t.” It’s a strategy that’s panning out quite well, as Newtoy’s debut project, Words with Friends, is the most successful game on the iPhone. Like, ever.

When I was fourteen, I wrote space-invader games in BASIC on a VIC-20.  If you were interested in computers back in 1982, I bet you did the same.  When I was 18, I wrote multi-user dungeons in C on serial terminals attached to a Sun 3.  When I was 22, I worked deep down in the guts of a text database system — still C, now on a Sun 3/80 of my very own, with one of those HUGE bitmapped screens with a million black-or-white pixels.  I was in touch with my friends from university: we were going to write compilers and operating systems and cool stuff like that — and to some degree, we did.  We sent each other our in-progress code, complained about each other’s programming-language designs, and laughed at how inefficient each others’ completely unnecessary reimplementations of malloc() were.  [I remember a friend’s implementation achieving something like 18% occupancy.]

That was then.

Today, I mostly paste libraries together.  So do you, most likely, if you work in software.

Rands, on knee jerk reactions. Rands usually delivers good management insights—this is no exception.

I want you to think of the last time you were surprised. Good, bad, I don’t care. When was the last time you were really surprised? Got it? Ok, now think about the very first thing that you thought about the surprise. I don’t want to know how you eventually handled it; I want you to think about your instantaneous first reaction.

How do you react when you’re surprised? Is this how you always react when a surprise lands? My guess is yes.