Live data from Hacker News

Developer-driven development

schacon.github.com

31–40 of 52 posts

Re: Developer-driven development

#31
post #6

I can't help but think this requires that only 'rock star' programmers be on the team. 1 bad apple would start to throw everything off, and a few could derail it. 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'…

I dunno about 'rock star' (although I'm a pretty amazing drummmer…) but yes, the talk centers around hiring the most driven people possible. I don't think any of us act like we have a stake in the company — we do. 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.

> I'd highly suggest reading Drive by Daniel Pink.

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

Re: Developer-driven development

#32

I can't help but think this requires that only 'rock star' programmers be on the team. 1 bad apple would start to throw everything off, and a few could derail it. 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'…

Using "rockstar" reminds me of awful job advertisements for awful companies.

Re: Developer-driven development

#33
post #12

I was at this talk (given at CodeMash a few days ago). It spurred a lot of discussion/opposition over the fact that it revolves so heavily around only hiring passionate, rock star quality developers that care about the product you're developing. 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 disc…

I'd be curipous to see how the "No vacations" rule plays out.. 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.

Stop tracking what days people are working & what days they aren't and you'll realize you've missed the whole point of "no vacations"

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

Re: Developer-driven development

#34
post #19

Earlier quoted context omitted.

> 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. Does this actually apply to employer-sponsored OSS work?

I meant the model that OSS software gets developed in. That people work on the feature or project they love/want to see succeed/etc rather than what a manager told them to focus on.

It is rarely the case that they'd be paid (by someone outside the project) to work on a particular feature? Companies that sponsor OSS development basically just say "here's a paycheck, go have fun"?

Re: Developer-driven development

#35
This is a cool model, but I worry it only works because software engineers are both the producers and the consumers of the github product.

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.

Re: Developer-driven development

#37
post #30
post #12

I was at this talk (given at CodeMash a few days ago). It spurred a lot of discussion/opposition over the fact that it revolves so heavily around only hiring passionate, rock star quality developers that care about the product you're developing. 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 disc…

As a Dev who worked on finance industry apps, you can get Dev buyin. However, if your motivating them based on selling the company then you should do that otherwise your devs will leave in droves. 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.

I've sometimes told people that I have "shipness syndrome", I start to feel uneasy the longer my code goes undeployed and used.

Re: Developer-driven development

#38

I can't help but think this requires that only 'rock star' programmers be on the team. 1 bad apple would start to throw everything off, and a few could derail it. 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'…

+1 for Driven Developer-Driven Development. This works with small teams where each contributor has a solid track record, or with a group that has worked well together in the past. Open source projects can get by with a few bad apples as long as the core contributors are solid. I think you can use this model within small companies, but only if you are confident in the reliability and talent of each team member.

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.

Re: Developer-driven development

#39
I'll probably write a blog post laying this out a bit more clearly, but responding to a few of the comments here:

* 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.

Re: Developer-driven development

#40
post #39

I'll probably write a blog post laying this out a bit more clearly, but responding to a few of the comments here: * 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…

I suspect that you talk from experience when you make the claim that 'Most programmers got into the game because they love programming.' I currently work in india, and my experience here is that most folks who enter programming do so because of better pay, more glamour, and more international travel. I don't have any studies to back up my observation, just my personal experiences in the last few years.

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.

Post reply on HN