neiljohnson

Yeah, I'd never really thought about quitting before that point, it was a spur of the moment thing. Once you make the decision though, going back on it starts to feel a bit scary, 'I can give up any time I like, just not today...'. So I stuck with it.

Warren Buffet is an unlikely person to quote in a discussion about agile, but .....

"First come the innovators, who see opportunities that others don’t. Then come the imitators, who copy what the innovators have done. And then come the idiots, whose avarice undoes the very innovations they are trying to use to get rich."

Without more specifics it's hard to give practical advice. Daniel Pink's book 'Drive' and the video that has been doing the rounds in response http://www.youtube.com/watch?v=u6XAPnuFjJc make an awful lot of sense.

Essentially to get the best from people you need to give them * Autonomy * Mastery * Purpose

I suspect from your question that you are most interested in focusing on Mastery, specifically how to help them make progress towards it.

I found Pragmatic Programer to be a pretty good general resource. http://www.pragprog.com/the-pragmatic-programmer

Outside of that I'd second the other comment here taking about Design Patterns - I think that the Head First book http://oreilly.com/catalog/9780596007126 is a great introduction

Day to day, finding ways to give to really quick feedback is important, code review and general collaboration with the others will really help.

I thought this was pretty cool http://noteandpoint.com/documents/pdf/jap.pdf

Not just focussed on games, more what games can teach us about motivation in general.

London Open Market (formerly MX Telecom)

Mobile messaging and payments, might be your cup of tea....

http://www.mxtelecom.com/uk/careers/roles/softdev

MX Telecom are looking for developers in London. Mobile messaging and applications for folk like 118118/KGB_ BBC and Twitter We like great software and the colour blue http://www.mxtelecom.com/uk/careers/roles/softdev

MX Telecom are looking for devs in London. Mobile messaging and applications for folk like 118118/KGB_ BBC and Twitter

http://www.mxtelecom.com/uk/careers/roles/softdev

"What if it's both high-priority and hard? Like you find out that a fundamental part of how your product works causes data to be miscalculated in a certain scenario, and rewriting it while maintaining backward compatibility is a multi-week task? During which you will get more high-priority bugs..."

Perhaps it's a matter of terminology, if something is going to take a significant block of time and have multiple people working on it then you need some way of planning and tracking progress, your bug tracker may support project planning as well (JIRA perhaps), but used a pure bug tracker will not be as effective in fixing the problem.

"That said, if it works for your team, go for it. Never throw in more process than you need, but don't assume that what works for small teams scales."

I fully agree with this sentiment, in this case we're talking about a dev team of 6 working in a broader team of 50 developers. So I wouldn't describe it as small, though there again if we were 250 developers then certainly, we'd need more process.

No remote working, sorry.

MX Telecom are looking for devs in London. Mobile messaging and applications for folk like 118118/KGB_ BBC and Twitter

We like great software, Frisbee and the colour blue

http://www.mxtelecom.com/uk/careers/roles/softdev

I found Amit Rathore's essay 'Against all Oddities' to be very helpful in bridging the gap.

http://epistemologic.files.wordpress.com/2007/01/againstoddi...

I found this post by Steve Yegge to be really helpful, it's aimed at phone screening but you can easily extend it to a face to face interview

http://steve.yegge.googlepages.com/five-essential-phone-scre...

Guys, thanks for the feedback, based on the discussion I've decided to stick with the British approach even with titles, and have submitted the article here.

http://news.ycombinator.com/item?id=1173473

Thanks

Neil

Anne, thanks for the feedback. Actually I'm still proof reading the post, so it's not quite ready yet (suddenly realised a few bits needed turning upside down). For the typo I meant 'Defence' vs 'Defense', by Scrumbut I mean 'We do Scrum but..' as in http://bitsnwidgets.com/2008/04/19/DontBeASCRUMBUT.aspx N

TPS led to Lean thinking in general (http://www.lean.org/whatslean/principles.cfm) and the principles can be applied to manufacturing as well as it can product development or indeed software.

I would agree that the implementation as applied to manufacturing is poorly suited to one-off projects, but would consider work in the fields of product dev and software (sometimes called Kanban) to be highly appropriate.

In the case of Kanban there are those that would argue that incremental and iterative approaches are not well suited to large scale projects, though I think that this due these processes still be relatively new to organisations capable of pulling off huge projects, rather than a deficiency in the methodology itself.

The Toyota Production system that led into Lean manufacturing and more recently Lean thinking in software provides a strong counter example.

http://en.wikipedia.org/wiki/Toyota_Production_System

We're hiring java devs in London, we're working on Mobile payments, SMS, MMS and VoIP

http://www.mxtelecom.com/uk/careers/roles/softdev

We're hiring devs (paid, full time) at graduate level in London we're working on Mobile payments, SMS, MMS VoIP

http://www.mxtelecom.com/uk/careers/roles/softdev

Depending on your product, have you considered taking payment from the purchaser's mobile phone (even if it's just an alternative payment route), that way people without Paypal can still make a payment without having to leave your site while they sign up.

http://www.mxtelecom.com/uk/payforit#about http://www.mxtelecom.com/uk/tech/cta/webpfi

Just a thought, I work for these guys, so I can't claim to be impartial.