* I don't think 'rock star' programmers is important. I think that most programmers got into the game because they love programming, not because it's what they have to do. There are exceptions, but I believe that more programmers love doing it then have to do it. The point is to setup an environment where you as an employer can get the most out of people of a range of talent simply by setting up an environment that motivates in the best way possible - through autonomy, mastery and purpose. I think people that don't seem passionate will become more passionate if given the freedom.

* to be clear, i said every 'developer' makes the same. or, better said, every role makes the same - there are roles that make different amounts, but it's still pretty flat and people are not individually offered different salaries by some subjective determination of their merit, but rather equally by the general role they are hired to do. it so happens that most of our employees are either developers or designers and they're all paid the same out of simplicity. the main point is that salary is less important than environment.

* finally, i'm not saying that the way that github does it is the way that you should do it - we have the difference of the C-suite being open source developers, so it's easier for us. the point is that even this somewhat radical example works surprisingly well, and that if you try to optimize for autonomy and purpose in the lives and working environment of your developers that it will most likely result in a much more productive output.

again, i'll try to do a more comprehensive post on what i specifically was talking about, rather then just the slides out of context, but i wanted to quickly address some of the comments. thanks! also, it was a blast doing the keynote, so thanks to everyone that attended and argued about it after.

I also believe that their training/exposure to CS in college is not uniformly good, and that they are put into an environment where they are already expected to know stuff which they have not been exposed to. Good organizations spend quite some time on training, but many do not.

I personally believe that before a programmer is given autonomy, it is vitally important to have people with good, attitudes who are willing to admit to mistakes and learn constantly, who have some measure of comfort with the fundamentals of programming ( which works across languages ), and who are mentored properly ( by which they have people to turn to whenever they get struck and need to figure out how to proceed further ). Most middle managers have no clue as to what programming is and hide behind a layer of techno-talk and they really are often unable to provide a sense of direction or purpose to the programmer.

While i agree with your role for management in creating a good environment for your emplyees, giving them a lot of autonomy, allowing them to master their tools, and having a sense of shared purpose, i believe that these require a few fundamentals to be met before the above environment is productive.

I admit that these observations are biased and not based on any scientific studies, so take them with a pinch of salt.

Small companies and startups often have a product that you can recruit people who are passionate enough about the idea that stuff like this can work out. The problem for discussion is more based on which (if any) of these ideas can be applied to a large corporation where the developers are working on insurance or financial software etc.

Some things that are lost for those only reading slides:

- His main reasons behind this "DDD" policy is that it's the open source model. Developers work on things they care about, when they feel like working and then every hour they spend "working" is a valuable hour of work. Any policy that forces or even simply guilts people into a set schedule or number of hours causes unproductive time and a loss of developer happiness/autonomy.

- He strongly advocates removing money as a motivator. At github apparently every employee makes the same salary.

- The "no vacations" comment comes from him not believing you should track vacations. Employees should but trusted and able to take the time off they deem appropriate.

- At github, the Google "20% policy" is taken to an extreme. People can work on whatever they want on "company time".

In Australia most employees would deem 4 weeks vacation as appropriate. In France it's probably higher. In the US -- maybe it's 2 or 3 weeks.

We don't have vacations because we judge people by what they do — not how often they're working.

Did you happen to hit Joe Nuxoll's user experience session on Friday? That was probably the high point of the conference for me -- tons of useful info.

The main thing you need to show devs is that people are using their code. Nothing is more depressing for a Dev than code that doesn't ship, followed only by code that people don't use.

Does this actually apply to employer-sponsored OSS work?

It also requires that everyone have the same vision, or you end up with a very fragmented product, see as how you allow each developer to decide what to work on.

Don't get me wrong, I would love to work at a company that is succeeding at this... I just can't imagine how to keep it succeeding.

Seeing as how it requires the developers to act like they have a stake in the company, perhaps a better title would have been: Driven Developer-Driven Development

I'd highly suggest reading Drive by Daniel Pink. The entire book is about how people are motivated. It would definitely answer almost all the points listed.

This video shows Daniel Pink delivering an 18-minute presentation at TED on the same topic: http://www.ted.com/talks/dan_pink_on_motivation.html

"Rock star" developer can mean a lot of things.

What's required here (aside from everything listed in the prerequisite section of the slides) is that developers have a sense of ownership of the product. That's it.

You can foster this by literally giving them percentage shares of ownership. Some developers naturally feel this way about everything they ship. Some developers will never feel this way unless they own a majority interest in the software.

If some percentage of your team is unreliable, requires training, or likes to do their own thing (unavoidable at larger companies) - this can backfire.

If the team has signed up for a goal or deadline, the vision bit is important - it can be difficult to keep a loose team of rock stars on target without some structure.

This perfectly illustrates something I said earlier about the difference between an OS with well defined UI standards, and one where the developers just do whatever the hell they want.

I boldly asserted that in such an environment, the developers will implement the one method of control that makes sense to them, and ignore all the other options, which means the user has to try everything they can think of until they hit on the right combo, which can take a while, leading to frustration.

===

Developer Driven Development. Interesting concept... "dumb ideas are not worked on" wonderful. Nirvana?

What I think is that development works best when the developers understand the problem. No methodology is a substitute for an actual understanding of what you're trying to achieve and why you're trying to achieve it.

Of course, developers understand the issues that effect developers. So of course they will be happiest (most effective?) fixing the problems they are themselves the client for. Also, this removes a layer or two of communication, since you don't need to have the customer talk to the developer, or have a Business Analyst interrogate the customer and then translate it into programmer-ese.

If you understand the problem, you can tell which are the dumb ideas (sometimes you figure this out retroactively). If you don't understand the problem, you're simply not qualified to judge which are the dumb ideas.

this seems to be the uber-rule for everyone who employs a developer. If you can guarantee that one (granted, it's huge) requirement, you should not get into trouble with your engineering workforce. All other things might not automatically fall into place, but once you got your people motivated through their work, a big part is in good care.

If a company allows their workers to choose the features they work on, programmers will automatically take ownership and immerse themselves in the product. Most developers I know are bored out of their mind when working on someone else's idea, although there are a few exceptions.

There's really not much more to be said on this topic imo.

For any HN'ers in the midwest, CodeMash is an awesome polygot conference that takes place January every year in Sandusky, Ohio. I've never been at any other conference where you meet experts in Python, Ruby, Haskel, and other languages in the same session.

The real take-away for me was less their means than how much freedom/less process you can get when the engineers completely understand the goals of your users.

Getting to that point feels like the hard part. Github is lucky to produce a tool central to their developers existing lives.

https://secure.wikimedia.org/wikipedia/en/wiki/Theory_X_and_...

So, while I guess I can imagine this working (and me loving) for products geared toward a highly technical, somewhat forgiving customer base, I don't see this as a workable for anything truly consumer-focused.

The best managers understand that management is mostly a two-step process:

1. Give someone a task. 2. Let them accomplish that task.

Granted, you can't always work that way. But you might be surprised at what proper motivation can do. People will do boring work if it means accomplishing something great.

I'm reacting to slides like: "individuals choose what they want to work on" which is all fine & well, except that sometimes, if we want to ship in time for Christmas, people might have to work on what they wouldn't naturally choose.

I realize this comes across a bit snarky but I honestly couldn't think of a better way to say this. I often find people in project management who have little or no trust in the people who actually do the work and that seems to guide their decisions about how the team should be 'managed' or how the work should be planned.

I also find that while deadlines and backlogs seem like something intuitive, in the end the belief that they really have a tangible effect on outcomes seems to be largely anecdotal. Sure it's often a necessary requirement to work with many organizations, but I rarely see any of those organizations actually backing up their process with measurable results.

Other than that, it sounds like fun.

I think the real question is why do such low quality products get produced by business when building LOB apps to solve "real" customer problems. In my opinion it is too much interference in the communication chain between the customer and the devs designers and that is usually a management problem.

To me this should be the real goal and take-away from this article, not the many nice things this enables, but how to get there for other companies/products.

THAT would be revolutionary.