[nhashem]

"x10 developers" are, in fact, proficient developers, who are experienced with their stack and problem domain.

Well, I'd say this is only true for your typical corporate entity, where their products are basically just web applications that represent a state machine using some sort of database store for persistence (which is... basically everything). By the time the company has achieved some size, there's enough process and bureaucracy and projects mostly consist of what the OP described -- migrating from one framework to another, or some other incremental enhancement that's hardly pushing any sort of business of technology threshold. At previous employers that fit this description, I could have easily been 10x more productive if I didn't have to endure four hour sprint planning meetings or be required by an understaffed QA/DBA/sysadmin team to approve my code before release, all to do completely routine development changes that required no serious problem-solving.

This doesn't mean I'm a 10x developer. It probably means I'm a 1x developer, so a 'true' 10x developer would have been 100x more productive without the aforementioned bureaucratic crap. At these companies that would dogmatically follow Agile and had two week sprints, I might spend four hours, across two days, actually developing -- with the rest of the days filled with various meetings, interviews, waiting for QA/DBA/sysadmins, fucking around, etc. I could easily see how someone could spend only 15 minutes on what took me four hours, and his solutions would likely be more elegant. It doesn't matter -- the limiting factor isn't the development time, or even the development quality. In that environment, there is literally no difference in productive gains between a proficient developer and a 10x developer.

Given a "10x developer" is literally defined by his productivity/quality, if you think they're effectively overhyped/nonexistent, ask yourself this: are you in an environment where a 10x developer could actually demonstrate 10x productivity? At most companies, the answer is no, because a 10x engineer is doing in hours what takes people days, and nobody notices. But in the right environment, the 10x engineer will do in weeks what would take proficient engineers months, or do in months what would take years. They're the people that Steve Yegge calls "Done and Gets Things Smart"[0] or that Rands calls "Free Electrons"[1].

And if you work at a company that can't think in terms of months because it's always concerned about quarterly earnings, then they have no use for 10x developer, and chances are you couldn't even tell if one was even there.

[0] http://steve-yegge.blogspot.com/2008/06/done-and-gets-things...

[1] http://www.randsinrepose.com/archives/2005/03/20/free_electr...

[kamaal]

Agile is the current day water fall model. I mean in spirit on in factual procedures.

>>I could have easily been 10x more productive if I didn't have to endure four hour sprint planning meetings

I completely understand this feeling. The problem is so plain and simple. There are teams that win because of heroics, they achieve something big. Those management types who lack the chops to be heroes simply try to turn heroics in a process.

So what they basically do is, watch a team win. Instead of realizing its the interesting/challenging nature of work combined with things like lesser distractions, strong deadlines and well aligned monetary incentives that count, they rater look into common set of patterns that they would do. The net result is they end with a really boring process.

If you think to be successful you have to do X, Y and Z steps you are doing it wrong. X, Y and Z are catalysts, enablers or at most methods to keep you sane while you pursue a higher purpose.

My latest irritation is manager types getting too obsessed with Unit testing, it reminds of XML and the way it was abused.

[moe]

My latest irritation is manager types getting too obsessed with Unit testing, it reminds of XML and the way it was abused.

It's a bit of a tangent but I've also observed this. So much that I've started calling it the "cucumber-complex".

Once infected the team not only writes excessive unit-tests to validate things like that a method-call to 'foo' does indeed call the method 'foo'. But they also wrap these unit-tests in quite elaborate parsers in order to "express" them in pseudo-english.

The hilarious (cucumber-specific) aspect is how they usually start by writing their tests in plain RSpec or Test::Unit and then go at implementing the parser to make it "tell a story".

[benjaminwootton]

I wouldn't be so quick to write off Cucumber et al.

A few benefits:

- Sometimes business users will contribute and use these scripts (admittedly in only some teams and less often than supporters would claim);

- They help with analysis and design as you are forced to question exactly what behaviour you would like to acheive;

- They keep the developer focused on the feature rather than, for instance, building some big fully featured class or library which wont be used;

- They encourage outside in testing so you get good but pragmatic testing for features at each layer of the application;

- They act as a free living documentation on the system;

- They are more lightweight than they initially appear.

I would rather have lots of BDD style tests than the silly tightly coupled unit tests loaded with expectations that you describe erlier in your post.

[zem]

the most important bit, i think, is that a cucumber test suite is documentation that cannot go out of date, because if it does your test breaks and you have to fix it, thereby updating the documentation aspect of it.

[benjiweber]

> Agile is the current day water fall model. I mean in spirit on in factual procedures.

I think the problem is people sticking to a particular process, thinking it's the definition of "Agile". Rather than responding to change and the individuals in the team.

As our team was growing to the point where planning sessions were taking several hours we switched to just in time planning. A couple of developers could give a lightweight estimate of work at any point. Planning became just a 30min discussion with stakeholders to prioritise work, and we'd dig into implementation details as a team when we actually started working on something.

This would obviously not work for everyone. My point is that we responded to the problem and adapted our process to change in the team and environment. It's the 4th point on the agile manifesto http://agilemanifesto.org/

Retrospectives should give an opportunity for teams to do this if done right.

[joelhooks]

Somebody should let them know that unit tests are for us, not them.

[bastijn]

someone should tell everybody that it is not us or them, but we.

unit test help us but not them? How can that be true if they pay your salary. If tests make you more efficient, so becomes the/their team (we/them as you please). In the end even the customer is influenced by good unit tests, or any other improvement for you. Bottom line: stop thinking us vs them, think we.

p.s. Not a manager, I am a programmer like you.

[_wmlk]

>>Agile is the current day water fall model. I mean in spirit on in factual procedures. >>My latest irritation is manager types getting too obsessed with Unit testing, it reminds of XML and the way it was abused.

Whenever I read opinions like this all I hear is "Wah wah wah. I'm old and I don't like learning new things. What's wrong with the way I've always worked? Wah wah wah, managers."

[edoloughlin]

The problem with unit tests and a certain type of manager is that they see the unit test coverage as something that must be managed to be as close as possible to 100%, when this is arguably a waste of effort.

[dgabriel]

Agile has been around for many, many years. I think the Agile Manifesto is a teenager by now. There are a lot of people well into their careers who have "always worked" the so-called Agile way.

[durzagott]

Sure, but I don't see why an effort to study how successful teams work and distil in a methodology needs to be derided by other programmers.

Most managers I've worked with just wanted some transparency and predictability to the process. Waterfall failed to provide that and now the industry is experimenting with Agile.

I find it distasteful when developers grumble to each other about having to perform basic tasks such as unit testing (TDD, BDD or whatever). I've worked with far too many 1/10x developers to know some kind of process is required to keep them on the straight and narrow.

There is no magic bullet, but I think it's time we stop snorting in derision at the industry's attempts to reduce the unpredictability of building (and maintaining!) complex software.

[clubhi]

" ask yourself this: are you in an environment where a 10x developer could actually demonstrate 10x productivity?"

I'd buy whatever you were selling if you started off with that line.

[lifeisstillgood]

Yeah that struck me too

By extension, that environment is also one where a 1.5x developer is going to repay their salary

[vorg]

> are you in an environment where a 10x developer could actually demonstrate 10x productivity? At most companies, the answer is no, because a 10x engineer is doing in hours what takes people days, and nobody notices.

At most companies a 10x developer will be noticed by other developers. 10 of them will quietly agree to gang up on that 10x developer and backstab away because their own 10 jobs are threatened by that 1 person. Maybe it's just an unspoken agreement between developers all acting in their own interest.

If a 10x or 5x or 2x developer decides not to do things too quickly in a new job so as to "maintain good relations with other staff", they will still know. You won't find too many >1x developers around most businesses because they've all left to do something else, like a PhD program in the OP's case.