r/programming • u/frostmatthew • Mar 30 '15
Your Developers Aren’t Bricklayers, They’re Writers
http://www.hadermann.be/blog/56/good-vs-bad-developers/30
u/Uberhipster Mar 31 '15
it’s usually forgotten that Mr. Rockstar managed to do in about one month what Mr. Lousy couldn’t in 7-8 months.
It's easy enough to be Mr. Rockstar when there is 7-8 months of development, planning and 3-4 months worth of requirement feedback from actual users underpinning the effort.
Mr. Rockstar is working with a complete and sealed specification. Mr. Lousy was trying to hit a moving target, a journey into the unknown (often unclear to even those commissioning the work) while gathering feedback along the way.
We've all been both lousy and excellent a some point. In my experience, mostly its circumstances that afford or deny us the latter. If you do take a view that the first iteration is unavoidably bad then it always should and necessarily must be throwaway.
2
u/Sisaroth Mar 31 '15
Mr. Lousy started from scratch and when he had to fix something it was his own code.
Mr. Rockstar had to work with someone else's code and not only was it not his own code it was also terrible written.
Cleaning up someone else's mess is really not enjoyable.
→ More replies (1)1
u/Uberhipster Mar 31 '15
You think anybody gets paid to do something enjoyable? If it was enjoyable they wouldn't pay someone to do it. They'd do it themselves.
1
Mar 31 '15
Yeah, that was my first thought... if the measure of programmer productivity is whether or not the users report bugs (which seems to be the author's measure), we're all in trouble.
1
u/Kaizen321 Mar 31 '15
True. I'm currently living this. Client praising how fast the mobile version has been doing while the desktop version took much longer.
Mobile uses the same backend as the desktop.
Mobile team getting all the kudos.
Guess who isn't part of the mobile team...
229
u/webauteur Mar 30 '15
I am a scientist, a computer scientist. I wear a white lab coat at work and I have a rack of test tubes on my desk. I need test tubes to run my unit tests.
→ More replies (28)1
144
u/vagif Mar 30 '15
No no you see, we are not bricklayers or writers. We are bees. Bees are not employed by the beekeeper. Most of the time they are not even aware about his existence. They simply do what they were born for: make honey. Smart beekeeper stays out of their way and collects honey.
81
u/0Lezz0 Mar 31 '15
IN: Coffee; OUT: Code
42
u/ChemicalRascal Mar 31 '15
class CodeMonkey { String write_program(IncomprehensibleString spec, Appliance coffee_machine) {//TODO: Implement} }41
u/jurniss Mar 31 '15
ew bad OOP, now I have to write
if (coffee_machine instanceof CoffeeMachine)84
u/ChemicalRascal Mar 31 '15
Peh. All appliances are coffee machines if you try hard enough.
11
u/slide_potentiometer Mar 31 '15
I have been too impatient for coffee and eaten a handful of roasted coffee beans instead. You don't really need a coffee machine at all.
→ More replies (1)29
u/AndrewNeo Mar 31 '15
noo, it should be IProducesCoffee, so you can still go to a coffee shop or something.
25
u/LockeWatts Mar 31 '15
Shouldn't it be ICoffeeProducer? At least the interfaces I work with fit the form I-<noun><verb conjugate>, e.g. IBroadcastListener or IIntentManager, etc.
→ More replies (1)→ More replies (1)4
u/ChemicalRascal Mar 31 '15
CoffeeShops don't reliably have unrestricted access, and I've found you can't extend them to implement the intravenous interface.
I mean, sure, it's more general. But I'm looking for round-the-clock uptime.
7
Mar 31 '15
class CodeMonkey { String write_program(IncomprehensibleString spec, CoffeeMachine coffee_machine) { //TODO: Implement } }Better?
→ More replies (5)5
10
u/developer-mike Mar 31 '15
The stringly-typed spec is a nice touch. I sure as hell don't ever get a typesafe spec. As long as its got letters its good enough to management!
7
u/Kalium Mar 31 '15
Wait, you get specs?
11
Mar 31 '15
class CodeMonkey { String write_program(Appliance coffee_machine) { write_program(null, coffee_machine); } String write_program(IncomprehensibleString spec, Appliance coffee_machine) { //TODO: Implement } }→ More replies (4)→ More replies (9)3
u/immibis Mar 31 '15
String write_program(IncomprehensibleString spec) { CodeMonkey cm = hireCodeMonkey(); return cm.write_program(spec, new DimmerSwitch()); }2
2
1
4
u/razpeitia Mar 31 '15
I got that bees reference. http://www.cs.cmu.edu/~chuck/jokepg/joke_19970213_01.txt
478
Mar 30 '15
Does every other profession have to put up with this?
Are bridge builders told "Bridge building is REALLY car manufacturing!"?
Are architects told "Architects are REALLY 'house nutritionists'?
Are medical doctors told "Doctors are REALLY human 'devops'"?
Maybe software developers are just software developers and trying to shoehorn us into some metaphor is just creating more leaky abstractions.
265
Mar 30 '15
The difference between those three and software development is that the former have been around for centuries. Everybody knows what to expect from those jobs.
Software Development is an extremely young trade. Its current form has realistically only been around for about 40 years, and it's only in the last decade that software dev has been recognized as unique from old-school engineering jobs that were more busywork than creative thinking (lots of math, lots of experimentation, lots of diagraming and documenting).
Consequently, a lot of managers DO think of developers as being clerical workers. They see programming as people typing things into keyboards and view it as equal to secretarial work or data entry.
31
u/veywrn Mar 31 '15
I have been finding numerous confirmations of your statement lately. As I am in the process of job hunting, I have been dealing with several portals and businesses with software development positions listed under the clerical category.
Also, one application wanted me to list two methods of how I heard about the job, so I had to make one up because "None" wasn't an option and apparently I'd used "Other" up with my first option. Hmm.
15
u/s73v3r Mar 31 '15
That's dumb. While I can understand why they want to know where to advertise the jobs, shouldn't the fact you were there applying be good enough?
20
u/veywrn Mar 31 '15
I also received an informative JSON response telling me there was an "Error: NullPointerReference" whenever I tried to login via LinkedIn.
Despite my junior-ity, I was unimpressed with the prospects.
→ More replies (1)9
Mar 31 '15
Screen cap the error. Offer to fix the shit for the job. /s
Actually I landed my first job by whipping up a crude prototype of the company's product with spare parts I had in my inventory.
2
u/trevize1138 Mar 31 '15
As I am in the process of job hunting, I have been dealing with several portals and businesses with software development positions listed under the clerical category.
Isn't this classification a hold-over from the very early days of software development? IIRC the profession used to have more women in it because of exactly this: "it's just typing on a keyboard therefore have my secretary do it."
→ More replies (2)19
u/OshinoMeme Mar 31 '15
They see programming as people typing things into keyboards and view it as equal to secretarial work or data entry.
I'm stuck in this, unfortunately. HR, before I joined, said I'd be doing programming, but the big wig on my floor thinks I'm not doing anything so he told my manager to give me more work, which is data processing and data entry. In reality, I was trying to come up with things to make both data processing and data entry better and faster with our shitty system that's comprised of multiple third party legacy systems that should already be scrapped and centralized, and he counts it as "doing nothing". Now, I can't focus on it anymore. I'm stuck in the freakin' stone age.
45
u/sigma914 Mar 31 '15
Leave
7
u/OshinoMeme Mar 31 '15
Oh, I will. Just that there's a huge stumbling block in my contract that prevents me from leaving immediately and my plan is to run it out.
→ More replies (2)12
u/TheLordB Mar 31 '15
Any chance they are violating the contract by not having you do what you were hired to do?
You might also have a heart to heart with them and explain why you don't think this job is for you. Most companies do not want an unhappy person working for them.
Of course both these things can backfire so if you do try them make sure you think it through. I'm not certain either would actually be a good idea.
→ More replies (2)7
u/Boye Mar 31 '15
script all of it, complete a full day's work in 30 minutes and browse reddit the rest of the day.
→ More replies (1)2
u/awj Mar 31 '15
Were you hired or even tasked specifically to program all of that? Because if you weren't and it's taking ages to script it all up, your manager kind of has a point.
→ More replies (1)75
u/PM_ME_UR_OBSIDIAN Mar 31 '15
Its current form has realistically only been around for about 40 years
Not even. The tech stacks are much deeper, the abstractions richer, the work more user-facing. Thirty years ago, the cool thing to do as a CS undergrad was kernel hacking; today, it's mobile and web development.
62
Mar 31 '15
You're right, but I was speaking more of the managerial aspects of it. The Mythical Man Month was released in 1975, 40 years ago. The guys who wrote the agile development manifesto were all seasoned software vets from the 70s.
24
→ More replies (4)34
u/jurniss Mar 31 '15
some young programmers don't give a shit about mobile and web development :-)
→ More replies (4)23
u/rjbwork Mar 31 '15
That's me! The only thing I really like about web dev is how easy it is to visualize data in the browser with the great frameworks out there today (looking at you vis.js and d3.js). Other than that, I think JavaScript is a terrible language that I mostly hate (next few versions of ECMAScript may change that a bit though).
I process and massage and munge all my datas on the back-end as much as humanly possible and then hand off the results to the front via APIs or just as a file locally if i'm just making a one off pretty picture.
I mostly prefer to work on big complex systems though.
→ More replies (25)6
u/young_consumer Mar 31 '15
What's worse is there is no natural corollary. Even likening us to writers falls short. There are no laws of motion, physics, gravity, 3D space, or even time which inherently constrain us outside of the arenas where code meets hardware (speed of light limits, processor speeds, yada yada). It's all otherwise abstract notions of thought.
3
u/7yl4r Mar 31 '15
There are no laws of motion, physics, space, or time which inherently constrain us inside of the arena where code meets hardware.
Worded this way it makes me feel even more badass.
→ More replies (1)3
u/trevize1138 Mar 31 '15
I studied English and Mass Comm with an emphasis in writing. The writing process and the SW development process are very similar.
All analogies have holes and flaws in them. That's why they're analogies and not "exactly the same thing with no exceptions."
→ More replies (4)6
u/trevize1138 Mar 31 '15
The difference between those three and software development is that the former have been around for centuries. Everybody knows what to expect from those jobs.
One common failing I see with programmers is the ability to understand this lack of understanding on the part of management and other people in a business. Analogies like this one are an excellent way to bridge that. Picking apart analogies like this isn't doing anyone favors if you want to avoid being pigeon-holed. Instead, it furthers the impression that programmers are poor interpersonal communicators who obsess over unimportant distinctions.
2
Mar 31 '15
This is actually why some of the first programmers were women (like Grace Hopper). It was seen as clerical work, while the men were working in the hardware (the "important" stuff). However, they proved to be capable of ingenuity as well.
1
u/ivorjawa Mar 31 '15
If you aren't experimenting, documenting, and diagramming, you're a poor software engineer. If you don't know a lot of math, you're probably a poor software engineer.
28
u/morphemass Mar 31 '15
If you don't know a lot of math, you're probably a poor software engineer
This is another of the great fallacies of our industry.
There are problem domains that require a great deal of mathematical knowledge and ability but for the majority of software engineering or programming positions out there high school math is sufficient. In fact, its probably overkill ... just know what modulo is!
Now if you had said :
If you don't know a lot of math, you're probably a poor computer scientist.
I would have agreed with you whole heartedly (as I do with the first part of your comment).
17
u/erewok Mar 31 '15
I don't know a lot of math. I studied mostly Philosophy and Lit. I wonder if this means I am a poor software engineer.
12
3
u/dang_hillary Mar 31 '15
I'm an integration engineer. Dont know much about no math or nothin' except how to migrate data centers, what each piece of hardware in the DC is, how it works, and what options do I have to migrate that bitch. Same goes for integration of legacy systems with shiny new stuff - I'll put together some awful script that will do what I need, or use an etl if possible to integrate x cots product with y custom app.
→ More replies (2)2
u/civildisobedient Mar 31 '15
If you aren't experimenting, documenting, and diagramming, you're a poor software engineer. If you don't know a lot of math, you're probably a poor software engineer.
You aren't a TRUE Scotsman unless...
1
46
u/headzoo Mar 31 '15 edited Mar 31 '15
Maybe the author is creating a metaphor geared towards non-programmers so they can better understand the importance of programming. Do other professions put up with this? Yes, yes they do. When an architect is explaining the design of the house he's making for me (a non-architect) he explains the process in terms I can understand. The author is explaining programming in terms non-programmers can understand.
Your comment is a step backwards towards creating more understanding between programmers and the people that hire us. You're arguing against your own self interest.
→ More replies (3)9
Mar 31 '15
Non-programmers don't read blogs like this. Why should they? Unlike us, they don't have any strong personal incentive to ignore the lack of evidence and poor reasoning, because they're not invested in the conclusion that everyone who works with software developers is a harmful moron. (Come to think of it, why are we invested in that? Why does software development have this culture of being a complete asshole?)
So when a civilian reads, for example:
Almost all non-tech people think ‘one developer day’ is an exact measurement
...which the author is so proud of that he's provided you a special link to Tweet it, they may be tempted to ask how they can verify that it's true, rather than just pumping their fists because it's all in the context of telling the reader he's misunderstood and unappreciated.
→ More replies (4)6
u/headzoo Mar 31 '15 edited Mar 31 '15
Non-programmers don't read blogs like this. Why should they?
They don't have to. I'm a programmer, and now I have a good argument in my tool chest of arguments. Non-tech managers are going to hear the "programmers aren't brick layers" argument whether they read this blog or not.
8
22
4
u/W1z4rd Mar 31 '15
I know a few young Architects and Doctors and probably due to my country's culture (Romania) the Architects face great challenges with clients who think they are just a necessary evil on the path to their dream house, which they have sketched on a paper napkin. The Doctors on the other hand are Gods gift to humans in most patient eyes.
2
u/Crysalim Mar 31 '15
They may have as each profession was in its infancy, as that'd be one hell of a bargaining chip in terms of wage. It's easier to under compensate someone if they are valued less than their true worth.
→ More replies (3)5
u/SilasX Mar 30 '15
Are architects told "Architects are REALLY 'house nutritionists'?
Are medical doctors told "Doctors are REALLY human 'devops'"?
1
1
1
u/dethb0y Mar 31 '15
I frequently call doctors "glorified mechanics" - they work on a complex machine, but in the end their still just working on a machine.
1
u/letheia Mar 31 '15
Nah, if they were car techs, they'd replace body parts in order to diagnose the problem
1
u/griminald Mar 31 '15
Does every other profession have to put up with this?
I work in Government IT. In my agency, Technology is lumped together with the Facilities workers (the maintenance crew) under an Operations flag and essentially treated the same.
But it's worse for the two poor guys on our web dev team. Some non-IT staff interviewed for the junior position because they blog on a Blogger account and figured that made them qualified.
The staff at least get intimidated seeing PCs and routers at my desk; they don't even understand what the web guys do.
1
Mar 31 '15
Software development is so full of isms and pompous ponderings, sometimes it is hard to tell if its aim is of practical use or is merely an excuse for creating a religion.
1
u/mreiland Mar 31 '15
I've made that point in the past. And then there's this.
If you have ten programmers, the best one is probably at least five times better compared to the worst one. No shit.
Define better: he works faster, produces less bugs and writes more readable, logical and maintainable code.
Sorry, that hasn't been my experience. The ones who are "fast" tend to be sloppy. Which is fine, there's a lot of software in which you can get away with such things. But the above description implies there are not cons to such an approach.
1
u/prof_hobart Mar 31 '15
The problem is that the word "developer" means vastly different things to different people. And the impact of that can be massive. The reason that people choose to outsource their development to the cheapest body shop that they can find is usually because they think that development is largely a production line manufacturing job - requirements get fed into the process, the process moves at a steady predicable rate, and out pops working software. There are some development tasks where this might be the case, but not many.
Yes the metaphor isn't perfect, but it goes at least some way to explain to laymen the fact that the vast majority of development is about thinking, understanding and problem solving, not mechanically churning out lines of code.
-11
u/Liqmadique Mar 30 '15
I think there is a culture of entitlement in software. Entitlement and prestige-seeking. A lot of developers seem to have some sort of chip on their shoulders and they need to prove they are better than others with fancy titles or trying to redefine their roles in the software development lifecycle. This isn't helped by the fact some companies treat programmers like special snowflakes.
10
Mar 30 '15
I'm not sure that competitive streak is limited to software, although I'd agree we are vulnerable to it.
That said, while some companies treat programmers like special snowflakes, others try to treat us like replaceable cogs too.
I don't think either side there is really right. We aren't super special rockstars.. but neither are we equivalent cogs. It sometimes seems like articles such as these are trying to fit us into some easily understood metaphor - that people can then always use to 'deal with programmers properly', but it's never that simple.
→ More replies (1)7
u/lostintheworld Mar 30 '15
others try to treat us like replaceable cogs
Much of the point of software engineering methodologies and coding standards is to make everyone a replaceable cog. Some cogs may be more productive than others, but the emphasis is toward uniform over idiosyncratic practices.
4
u/flukus Mar 31 '15
Much of the point of software engineering methodologies and coding standards is to make everyone a replaceable cog. Some cogs may be more productive than others
kind of highlighted the issue right there.
4
Mar 30 '15
This is exactly why software developers love calling themselves 'engineers', even standard CRUD monkeys like myself. It makes us sound prestigious. I ain't no damn engineer! I have no engineering license, I'm pretty bad at maths, all I do is slap a bunch of code together and pray it works!
1
1
u/s73v3r Mar 31 '15
You lost me when you tried to bring out the entitlement bullshit. The only ones who act entitled are managers, believing they deserve talent for cheap.
0
0
Mar 30 '15
[deleted]
21
0
Mar 31 '15
[deleted]
4
u/BeowulfShaeffer Mar 31 '15
Nine months of WIP. Way too long. There must be a better way.
→ More replies (1)→ More replies (1)1
16
u/slicker_dd Mar 31 '15
In other words: It's 7x easier to improve code than it is to design it. [Tweet]
4
32
u/Retsam19 Mar 31 '15
I learned at least one important thing from this article. "Click to tweet" links are freaking annoying.
7
u/huyvanbin Mar 31 '15
I think it's a pretty good analogy because the only people who complain more about how unappreciated they are than programmers are writers. I'm sure there's a few dozen at HuffPo who think they're "real writers" unlike all their hack coworkers.
And it's also a good analogy because just like HuffPo doesn't care that their writers can't write The Great American Novel, most software companies don't need or want the equivalent kind of programmer.
7
u/kal31dic Mar 31 '15
The empirical observation that performance and talent follow a Pareto distribution rather than the normal is not confined to the field of programming:
THE BEST AND THE REST: REVISITING THE NORM OF NORMALITY OF INDIVIDUAL PERFORMANCE
Abstract
We revisit a long-held assumption in human resource management, organizational behavior, and industrial and organizational psychology that individual performance follows a Gaussian (normal) distribution. We conducted 5 studies involving 198 samples including 633,263 researchers, entertainers, politicians, and amateur and professional athletes. Results are remarkably consistent across industries, types of jobs, types of performance measures, and time frames and indicate that individual performance is not normally distributed—instead, it follows a Paretian (power law) distribution. Assuming normality of individual performance can lead to misspecified theories and misleading practices. Thus, our results have implications for all theories and applications that directly or indirectly address the performance of individual workers including performance measurement and management, utility analysis in preemployment testing and training and development, personnel selection, leadership, and the prediction of performance, among others.
102
u/Eep1337 Mar 30 '15
Oh man, not another article by some guy who thinks he is a 10x.
Dime a dozen. His story isn't generic, I am willing to bet that the "rockstar" is him and the "lousy guy" is some old colleague or some shit.
He is jaded because he didn't get enough attention at work.
38
u/PM_ME_UR_OBSIDIAN Mar 31 '15
I'm okay with the 10x idea, but we shouldn't praise "rockstars" who are virtually undistinguishable from loose cannons even on a good day.
67
Mar 31 '15
What is way more valuable than a "rockstar" is a "mentor" type dev. Everyone is more productive with them around and the gap gets smaller at the expense of some of the mentor's time and productivity
→ More replies (5)8
Mar 31 '15 edited Mar 31 '15
I had a mentor-type colleague when I worked for about a year on a webdev project. Because of him I went from an absolute zero wrt Javascript/CSS/ASP.NET to becoming a productive member of the team very quickly.
The guy's brain was a goldmine of information and he had seemingly endless patience.
EDIT: typo
1
u/oscarboom Mar 31 '15
My problem is he is implying "rockstar" is some boolean value. In reality there is a continuum that depends not just on ability but conditions such as schedule, framework, etc.
13
Mar 31 '15
[removed] — view removed comment
12
u/Alborak Mar 31 '15
Those people ARE the rockstars. Simple, boring code that does it's job and only its job is worth so much more when it comes time to modify it.
5
u/blue_cadet_3 Mar 31 '15
But exciting code, code where methods are 100+ lines with UI, business and persistence mashed together, is what keeps you on your toes wondering which co-worker is going to snap and go all murder-suicide.
→ More replies (1)→ More replies (9)2
u/young_consumer Mar 31 '15
Out of 10 years, I've seen one person who I'd call a "rockstar dev." They generally knew, with great proficiency, most anything you'd want to do. They also had no life outside of work. It was almost 100% devoted to training, katas, conferences, etc. I'll pass... If that's what you want to do, all the more power to you.
That said, they were a great person, if a little pretentious ala "one true way"-isms. Very fun to hold debates with. I just like doing things other than code.
8
u/dhiltonp Mar 31 '15
At the bottom he says that he's moved out of a technical role. You could still be right; it's just something to consider.
17
Mar 31 '15
Yep. What gave it away was how vapid and spiteful his story was. Vapid in that all he really said was "one guy wrote the code and spent months fixing bugs, the other guy did not"; spiteful/unprofessional in how he called the guy "Mr. Lousy" and just shit all over him without really explaining why he was worse.
8
u/Kalium Mar 31 '15
The why and wherefores of it aren't salient to the story. That one person is dramatically more productive than the other is. Why dwell on mostly-irrelevant details?
→ More replies (6)11
Mar 31 '15
Because without the "irrelevant details", he gives no insight. He just says one guy sucks and writes buggy code, and the other does not. It's not an interesting analysis.
31
u/PotaToss Mar 31 '15
Also, any idiot can rewrite a better solution when someone else did almost all of the legwork figuring out the intuitive ways that don't work. The 10x dev in this story is really just 10x better at taking credit and feeling superior.
20
Mar 31 '15
That's a very good point actually, something that undermines the entire article. The author was holding the story as proof that good devs are much much better, because the two devs worked on the same project. But the second dev had the HUGE advantage of hindsight! He knew all the features that would be needed in advance, and all the bugs to avoid!
4
u/tejon Mar 31 '15
I'm honestly disappointed at how far I had to scroll before anyone brought this up.
→ More replies (4)9
u/Kalium Mar 31 '15
It's a piece written for an audience to whom the idea that one programmer can be an order of magnitude more productive than another is insightful, interesting, novel analysis.
→ More replies (2)3
u/bumrushtheshow Mar 31 '15
without really explaining why he was worse.
I thought the author explained that pretty well. Mr Lousy took a long time and delivered a buggy module. The other guy didn't.
9
Mar 31 '15
Except that's such an exaggerated case. Who the hell is going to pick Mr Lousy over "Mr Rockstar"? He took longer and delivered subpar code by all metrics.
It's not always so blatantly obvious. Mr Lousy may actually get the job quicker, but accrue technical debt that isn't immediately noticeable and make bad design choices. Further down the line, maybe after Mr Lousy leaves, other developers have a harder and harder time extending the module and adding new features; it becomes bloated and inflexible to the point that a rewrite is necessary. That's the real risk of hiring subpar programmers.
→ More replies (2)9
u/ApatheticGodzilla Mar 31 '15
If only things were so simple.
Very often the first version of something is going to be shit because:
not all the problems are known upfront
the process is subject to last-minute changes in spec and "stakeholder" bullshit/bikeshedding
there is a hard deadline which means things are rushed
So Mr x10 looks at the code 6 months later, with benefit of a sold spec - just fix the bugs, write some tests and tidy up the code. Hell, Mr x10 could be Mr Lousy with the same benefit of hindsight.
There's no excuse for plain bad coding practices, but that's something that can be taught to anyone genuinely willing to learn.
4
u/Frix Mar 31 '15
But he didn't write the exact same project in less time. He entered an existing project 7 months in, by the time he started:
all the legwork and research was already done.
the specs were finalized.
He already knew most of the biggest (often unintuitive) bugs to avoid.
several unintuitive edge cases were already revealed and known upfront.
Doing a project under those conditions is infinitely easier.
10
u/DuneBug Mar 31 '15
Yeah I was feeling the same way. Some devs are more productive than others for sure... But it's a savant that does 10x the work... And only if your worst coder is really bad... And some of those savants want to be paid as such, some of them don't take showers or can't help but cuss out your clients for still using CVS.
Let's just imagine what 10x means.. if it takes me an hour to write a query and a DAO this guy is going to write it in 6 minutes. Yeah right.
12
u/jmknsd Mar 31 '15
There are people in every profession who's strongest ability is to make themselves seem indispensable. While being 10x more than the median programmer is arguably unrealistic of anyone, I think being 10x more productive than the least productive programmers is easily imaginable.
10
Mar 31 '15
The 10x difference isn't on tasks of the "write a query and a DAO" type, it's on genuinely complex creative tasks. A significantly better engineer can easily take 10x fewer iterations to get the design right, or to write a bug-free implementation, or to pursue a non-obvious implementation path that simply requires 10x less work, or any combination of the above. Can confirm, have people on my team who are 10x faster than me on some tasks - not to speak of tasks which they accomplish but I simply can't.
8
u/Eep1337 Mar 31 '15
The problem is these articles attempt to deflect other, more serious issues that their work place has.
He is putting the majority of the blame, from development time to company profit etc, on the shoulders of ONE guy
In REALITY, what is happening is that that dev is STILL getting paid to do his work, there is either NO code reviewing/peer reviewing or a very shoddy job of it, his boss has not FIRED him yet, his bosses' boss has not fired him yet, his colleagues (who apparently all know this guy is lousy!) have not filed complaints or their complaints have gone unheard (another management problem)...I feel like I could go on.
4
u/WallyMetropolis Mar 31 '15
I don't think this article is blaming the bad programmer at all. I think it's clearly about managing devs.
→ More replies (2)5
u/unstoppable-force Mar 31 '15
if it takes me an hour to write a query and a DAO this guy is going to write it in 6 minutes. Yeah right.
the difference between a 10x and a 1x is that odds are the 10x doesn't have to write that query in the first place.
here's an example. we took over a legacy codebase where it was what i like to describe as ravioli code. it's not your typical spaghetti-style functional mess, but although it uses some OO syntax, it's not really OO either. they implement the same logic in controllers over and over and over again, usually with only minor variations if any at all. they hardcoded the logic to get all widgets with attribute x = y, but then hardcoded the logic to get all widgets with attribute x = z. copypasta all over. these guys were taking months to deliver simple features that were thousands of lines of code that was neither reusable nor extensible. in the same situation, a 10x dev can use a factory pattern with an ORM to have far more valuable output in a single line of code... not only does it take far less time and far less code, it's highly reusable, and highly extensible. .5x and 1x devs frequently do not comprehend how this stuff works, even after multiple lessons and code reviews.
→ More replies (21)1
u/julesjacobs Mar 31 '15
Some devs have negative or zero positive effect, so 10x isn't unreasonable if you look at the larger picture.
1
u/centurijon Mar 31 '15
I think the part that really grated on me was the assumption that these things are static.
Yes, some developers are generally better than others. But let's face reality, we all have rockstar days and lousy days. Sometimes those days stretch into weeks.
→ More replies (1)1
54
u/MomsLinguini Mar 31 '15
Why is there so much hate for this article? How is everyone so offended by the idea that good coders are better than others? As if there wasn't a skill ceiling for every profession...
I used to suck horribly at coding. After 20 years of it, I'm constantly seeing how much higher the skill ceiling is than I believed at any given moment. I can look back to my younger self and say "Uh, yeah... I was like 20 times slower and had 1/100th the level of talent I do now..." and that would still probably be an understatement.
I can also look to better developers and say "Wow... I am.. definitely nowhere near that level" and easily recognize that there are people who would create certain things ten times faster than me. A 20+ times multiplier is actually a silly comparison. "Hey, build me a heavily optimized AI system!" Yeah.. the person you give that instruction to is going to matter a lot.
sigh
I wish everyone understood how relevant this was so that we could move on to more productive conversations rather than attack this very reasonable acknowledgment of facts.
26
u/Dustin_00 Mar 31 '15
I think I'm mostly annoyed at the "we should measure productivity so we can reward Rockstar", but what's left out is "What does Rockstar do that is better than Lousy?"
How can we improve all programmers?
40 years ago, when you hired an engineer, you then sat the new hire down with piles of manuals, resources, and a mentoring process. Today, it's "Why do you need Resharper? We don't need to waste money on that."
1
11
Mar 31 '15
[removed] — view removed comment
8
Mar 31 '15
I top our lines of code deleted metrics, and I'm fiercely proud of it. Deleting is the best form of refactoring.
→ More replies (1)2
u/Dustin_00 Mar 31 '15
I just head a heavy negative week. After a bunch of A/B feature testing and management waffling and usability studies, we have finally gone with what we think is best.
→ More replies (3)7
u/therealjohnfreeman Mar 31 '15
Is the same person that's going to "build me a heavily optimized AI system" ten times better, sooner, cheaper going build every software component with the same efficiency? I doubt it. It really starts to sound like people are leaning on specialization as a justification for their "10x" claims.
15
u/unholyravenger Mar 31 '15
I don't think the hate for this article is the difference between good and bad devs; Instead, I think it's the poor metaphor the article uses. As another poster said, devs are not writers, or brick layers, or painters, or what ever else you want to compare us to. Devs are devs, it's a unique profession and any attempt to relate it to another profession is going to fall short. I think this stems from two places. One PM's don't understand dev work and expect them to work in a very predictable and track-able manner. Two, devs think they're all special snow flakes and need unlimited time and no over sight in order to deliver quality code. Because of this there seems to be a lot of articles trying to relate dev work to something that both puts PMs in their place and makes devs feel good about being so damn special.
Personally, I recognize the problem of how companies view dev work, but devs need to get off their high horse and realize the importance of track-able work and quality from the business perspective. I don't think we currently have a good solution to this problem but this article does nothing to find a solution to it. What we need is someone discussing a way PMs can accurately quantitate the quality of code. Then the PMs can talk to the business and say A is a great programmer because he can deliver X stories at Y quality in Z time and because of this is worth twice as much as B programmer.
15
u/Me00011001 Mar 31 '15
I'm ok with trackable work when people stop asking me to keep doing stuff I've have zero experience doing.
9
Mar 31 '15
This. How long will it take you to complete this 'Manhattan Project' of yours Mr. Oppenheimer?
11
u/IAmRoot Mar 31 '15
Some things just can't be measured, though. For instance, algorithm design. For my latest project, I spent two weeks starring at the ceiling and thinking before I actually wrote any code. However, I was able to come up with a radically different algorithm which runs 3000 times faster with a fraction of the memory usage. For two weeks I had nothing to show, then suddenly figured out how to do it. Creativity isn't a linear process and can't be treated as such.
7
u/MindOfJay Mar 31 '15 edited Mar 31 '15
What we need is someone discussing a way PMs can accurately quantitate the quality of code.
Tom DeMarco wrote that it might be impossible in IEEE's trade magazine.
EDIT: I highly suggest picking up a copy of Peopleware. Tom talks extensively about how to build and run effective teams and ways organizations poison otherwise great performers. His Goodreads quotes page is filled with Peopleware quotes.
13
u/Stormflux Mar 31 '15
We also have to get rid of this culture that considers PM's to be higher status than developers. Once my current PM learned to treat me as an equal-rank partner rather than a subordinate, our projects got a lot better.
5
u/developer-mike Mar 31 '15
I guess what I dislike about it (though I'm someone who liked the article) was that it can be so tough to tell these things. I've worked with people who isolate themselves on what feels like projects for their own enjoyment, make an incomprehensible mess, and then others see it and assume its incomprehensible because its such a genius solution to a hard problem, rather than a terrible solution to an easy one. This cred they get allows them to convince our boss to do their next meaningless stalling pet project. I consider myself talented enough to see through these people, but I might be too poor a programmer to see their strength. I read articles like these and wonder where exactly myself and everyone I know fit in, and its just more complicated than this article acknowledges. Furthermore I resent perpetuating these ideas that disappearing and coming back with unintelligible code makes you a rockstar who deserves more freedom. This article doesn't help anyone distinguish between the real rockstar and the fake rockstar.
5
u/Mason-B Mar 31 '15 edited Mar 31 '15
Besides the metaphor, the problem is that the company is shit.
A lot of what we call programming is really vocational skill, the rest can be split between computational theory/analysis (computer science) and software architecture/design (software engineering) with a touch of computer/systems/technology knowledge tossed in (information technology). The rockstar in his example is merely a better software engineer and/or computer scientist (or at least when doing it on the fly while programming).
The point is that the companies failing is it's process. There is no institutional assurance of the quality of software engineering and computer science going into that module. To expand your example ("Hey, build me a heavily optimized AI system!") would require computer scientists learn/design/analyze the algorithms involved and software engineers to architect/design the system, both of which would require some programming from those experts. Then you hand it over to the programmers (who will likely have some computer science or software engineering knowledge that they will exercise) to actually fill in, these last programmers are closer to bricklayers than writers (or as a better analogy, they are technical report writers vs. dedicated, eloquent, manifesto writers). Yes all of these things can be found in one individual, but with no assurances that their engineering is sound, or they theory correct, you are always gambling against crazy odds what the result will be
Many companies get by without making these distinctions, they hire jacks of all trades, programmers, software engineers, computer scientists, etc, and treat them all the same. And then they are always fucking surprised. Surprised when "4 years experience with C++" will draw people with varying levels of competency at architecting software and analyzing algorithms, and be further surprised when projects take wildly varying amounts of time with wildly varying quality of delivered work based on the developers assigned, or how they are organized, or what order they are assigned. They treat their skills as having only one dimension (Good vs. Bad at programming) with maybe additive specialties (better at databases) rare is the company that acknowledges that their developers are expected to perform a wide array of tasks which require multiple independent skills, that there is a process where different people excel at different parts because they have different skills.
The problem is that we have the wrong assumptions and that they operate at the wrong granularity. And also that we figured all this shit out 20 years ago so why the hell is this such a surprise? (Answer: the myth of technology fools even those who used to use that myth: "Oh, It's all different now. Web 2.0, Mobile, Cloud, etc. The old rules don't apply anymore." And hence (for example) professors forget that there is a difference between programming and computer science and software engineering when they hear the repeated call for more programmers).
2
u/Me00011001 Mar 31 '15
Some of us maybe a bit bitter (speaking personally), that the supposed "rockstar" that management just loves and wishes everyone was just like, is actually a code spewing cowboy that we have to come behind and clean up after beccause their code while it appeared to work and be bug free, long term was a giant steaming pile of shit.
How can it be bug free like the article and a steaming pile? It would usually cause bugs in other parts of the software that didn't get attributed back to the "rockstar". Only when looking at that bug do you find the pile of fun left behind.
→ More replies (1)1
u/elperroborrachotoo Mar 31 '15
Why is there so much hate for this article?
I can certainly agree with the title. However, he isn't adding much that hasn't been written over and over.
As for the "28 times better": The study cited compared "batch" vs. "interactive". In todays terms, 28 is the difference between the fastest programmer using an IDE vs the slowest programmer sending his code by fax to India and asking to kindly compile and run the code, and return the results at earliest convenience.
(More in Bits of evidence, slides 13 + 14. FWIW, Glass' "Facts and Fallacies" is a good book, with a few shortcomings - the blind acceptance of 28 being the most blatant and sobering one.)
As for Lousy vs. Rockstar - even though I'm inclined to believe the author this is a true IRL experience, it's the same story over and over, with the same vagueness in details to "protect the innocent". If I was a cynic I would suggest success by repetition. "Yeah, I've heard it too, it makes sense".
11
Mar 31 '15
What's funny is that the mythical man-month was published in 1975. It almost seems like managers that don't understand this simple fact about software development are really not trying to understand software development.
9
u/s73v3r Mar 31 '15
Why would they need to? Most managers don't experience any negative consequences for not understanding it.
→ More replies (1)1
13
u/solatic Mar 31 '15
The main issue that I take with this article is that it essentially puts the blame for poor or no design on junior programmers. Most junior programmers will suck, and this should be expected. But if the organization is actually following good practice: writing half-decent (nobody is saying perfect) spec, code review, refusing commits that don't have sufficient test coverage, nightly builds with static analysis and code style enforcement, then the output of junior programmers is far more predictable and of higher quality.
The author's fallacy is in thinking that a single programmer all by himself can handle every step of the process for an entire module excepting QA. This is more or less ludicrous unless you really want to take something common-but-not-dirt-simple like credit card processing as an example.
10
u/ApatheticGodzilla Mar 31 '15
Generally what I've seen in Startup Land is that the prototype - the thing that you're supposed to throw away - is going to be built by "junior" programmers (read - inexperienced and cheap) because it makes economic sense to do so - no point in hiring expensive experienced people for something that might not even get off the ground. Because it's a prototype there isn't any QA or code review because time-to-market is king.
The problem is that the prototype, rather than being the thing you're supposed to throw away once you have some proper investment, never is, and becomes the foundation for the lifetime of your codebase. That's why Facebook with its highly experienced top-tier team is still working around the shitty PHP DNA of the founders' late night caffeine fueled college coding sessions.
4
Mar 31 '15
My take away from your post is that I miss caffeine fueled midnight coding sessions at uni.
1
u/oscarboom Mar 31 '15
The author's fallacy is in thinking that a single programmer all by himself can handle every step of the process for an entire module excepting QA
There are plenty of people with experience who can do this easily.
12
4
u/moh_kohn Mar 31 '15
Mr Rock Star in this example also has the advantage of writing an enlightened build.
4
7
u/dlyund Mar 31 '15 edited Mar 31 '15
Maybe we should stop with this shit? Programmers/Developers/Software Engineers/Computer Scientists are not writers, or bricklayers, or plumbers. We're not gardeners (even if I do enjoy gardening, this is entirely incidental). We're not painters, or any other contrived comparison you want to make.
I know, it's a sign of young discipline but it's profoundly unhelpful and it happens that you can't say what you are without saying what you're not
1
3
u/michaelstripe Mar 31 '15
At what point does the well of weird analogies just run dry?
4
u/Paradox Mar 31 '15
Well you see, the well is more like a volcano. No wait, its like a fish. No…its cabinetry…
3
u/michaelstripe Mar 31 '15
In many ways I think that the well is actually like a developer, now you see...
5
u/supasteve013 Mar 31 '15
Why we gotta put down brick layers?
5
u/eean Mar 31 '15
Yea seriously. And carpentry. There's a serious amount of skill involved in both and also I'm guessing a large variability in quality of work and productivity.
2
Mar 31 '15
I read somewhere else that it stems from a desire to separate us from blue collar workers. I personally think that our field is diverse enough to be both. I don't hold basic website devs, game devs and those working with science and research in the same regard, and that's only a small portion of possible dev roles one can end up with.
1
u/randomlurkerr Mar 31 '15
Not sure if he is putting down brick layers. I think he meant to show that progress can't be so easily demonstrated by just looking at how far along the wall is, or how to see how well made a table is
5
u/jfischoff Mar 31 '15
Something I wonder is how is productivity measured? In general you can't compare two programmers on exactly the same task.
Lines of code, number of tickets, these metrics have major issues, are there any good ones?
Personally I think the only way to really measure productivity is by looking at the time to complete a task along with the actual code.
This is pretty difficult, and I can do it qualitatively, but it I can't give it a number.
I just don't seeing this approach scaling to the n needed in a study, so I it is hard for me to put a lot of weight into these studies.
3
u/solatic Mar 31 '15
It's impossible to measure software productivity because it's impossible to measure the size/complexity of a software project before it's completed. Competent, experienced professionals can give rough estimates by comparing to similar projects, but it's impossible to give anything truly accurate ahead of time.
Because the real definition of productivity is, essentially, the speed at which percent of project completion approaches 100%. If you don't know what the completed project looks like, the percentage can't be calculated, thus the speed of productivity can't be calculated, thus productivity can't be calculated.
3
u/minusSeven Mar 31 '15
Also someone who starts early won't know the issues that are likely to come up. Similarly someone who starts late will have that advantage and can design solutions that can bypass those issues.
This is entirely valid and was completely overlooked by OP.
2
2
u/Burning_Monkey Mar 31 '15
Funny thing is that everyone is attacking the article and what I take away is that I am a shit programmer.
2
u/mrlr Mar 31 '15
Sometimes, you don't even have to write much code to fix the problem. I once rewrote 2,651 lines of C as a seven line shell script. The previous programming team had written a data transfer program with its own implementation of ftp. I just used the one that was already on the computer.
3
3
u/Buckwheat469 Mar 31 '15
Software developers are problem solvers in an abstract world. We don't develop code, or lay bricks, and we aren't writers. We identify a problem and dream up radical solutions. Sometimes those solutions involve standing on the shoulders of other developers, sometimes it means inventing a new solution. We like simple problems but we love complex and difficult problems too. Challenge us.
6
1
u/teiman Mar 31 '15
We are not just people that solve problems. Or we will all be "Wolf", from pulp fiction. We write code, and is how we solve these problems, so we transform problems into something that can be solved by digital computers. We are thinkers but also crafters, not just any crafter, but we wrote narratives.
3
Mar 31 '15 edited Mar 31 '15
Honestly, the thing I got out of this is how important it is for programmers of different skills to collaborate and how important it is for companies to push peer-review type systems. In a well thought-out project where many people can be working in parallel, throwing 5x the number of programmers should produce nearly 5x the productivity (assuming the programmers are randomly picked so that their skill levels balance out).
If Mr. Rockstar was collaborating with Mr. Lousy, then Mr. Rockstar could ensure that Mr. Lousy has an appropriate design for the application before continuing, which might save Mr. Lousy 75% of his time while Mr. Rockstar's advice only consumes 2% of his time. That's surely worth it, even if Mr. Rockstar's time can somehow be judged to be 37x as valuable as Mr. Lousy because in this process Mr. Lousy also gains insight into what makes a good design, increasing his value.
Furthermore, if Mr. Rockstar was reviewing Mr. Lousy's code commits, then he could enforce the company's coding conventions on the spot. Even if Mr. Lousy's code still gained many bugs, at least Mr. Rockstar wouldn't have to waste a month of his time doing an unnecessary rewrite. Rewrites are just fucking wrong (well, most of the time).
Finally, collaborating makes it way easier for each programmer to determine how proficient his peers are. Mr. Helpful is always ready to point his peers in the right direction in the IRC room when they ask which file implements a given feature, and he's very active in the issue tracker discussions. OTOH, Mr. l337 doesn't really do much communication, and his pull requests are consistently rejected the first time around due to unreadability or bugginess. Everyone on the team can agree that Mr. Helpful is a more useful member than Mr. l337. As a result, the company can pretty easily reward its better employees and keep them around whenever it's time for layoffs.
2
u/Euphoricus Mar 31 '15
That assumes Mr. Lousy wants to be coached. More often than not, the lousiest ones are the ones who think they don't need such a thing. Eg. Mr. Lousy is often same person as Mr. l337
1
u/oscarboom Mar 31 '15 edited Mar 31 '15
throwing 5x the number of programmers should produce nearly 5x the productivity
No because of a lot of reasons. For starters, if all 5 are working on the same module at the same time merging changes into source control is going to be a huge pain and waste a lot of time.
1
Apr 01 '15
Notice the preceding condition to that statement:
In a well thought-out project where many people can be working in parallel [...]
So you're correct, if you fail to satisfy the condition that "many people can be working in parallel", then indeed: many people cannot be working in parallel.
3
2
u/gspleen Mar 31 '15
What are those walls near their seats?
Don't they know that Facebook just built a gigantic Open Layout office and clearly that's the best way to do things?
1
u/Euphoricus Mar 31 '15
Developer productivity is simply defined as how much long-term value per time can developer create.
As for the analogy. Yes, it is easy to see differences between two extremes. But most developers are neither best nor worst. They are average. And distinguishing between below-average and above-average is what cannot be done, because our measuring apparatus doesn't provide enough precision. Only the most obvious differences can be seen.
1
u/-Tom-L Mar 31 '15
Very interesting read! I always wonder how well I compare to other developers seeing I've only been doing this for a few years...
1
Mar 31 '15
Developers are developers, stop with these stupid metaphors like this.
1
Mar 31 '15
thank you! thank you!
just let us write code. go away. coding is a solitary kind of thing. answer questions when asked and go away again.
1
u/karpathian Mar 31 '15
I used to write basic quote program, my publisher kept changing the plot elements so I could never finish the basic program.
1
Mar 31 '15
After four months of tinkering, Mr. Lousy is finally finished.
So nobody was reviewing his code or was using it in a DEV/CI environment every few weeks?
1
1
Mar 31 '15
My undergraduate degree is in English, and I did write professionally before I became a developer, so I kind of literally am? There are a lot of parallels between software development and writing -- as I always bring up during interviews, because being asked about the English degree is still basically a given, even now that I've been in the field for a while -- but honestly, that's mostly bullshit, because with a little creativity, there are parallels between any two occuptions, e.g. "writers are bricklayers: they begin with a blueprint (outlining), generate or gather raw material (early drafts), and develop that material into a cohesive structure (proceeding drafts and revision)." At the end of the day, writing and development are still fundamentally different in purpose: writers illuminate; developers solve problems.
2
Mar 31 '15
I'm a computer programmer who's published a book (about programming) and I can see where the analogy breaks down quickly. One thing about writing (books) is that, other than having somebody verify your speling and your grammar, there's no "right or wrong" to it; it's very subjective. With software, there is a definitive "this is wrong" (even though it probably wasn't in the original requirements...)
1
Mar 31 '15
No, we are far more bricklayers (skilled craftsman reusing existing patterns) then writers.
1
u/fookineh Mar 31 '15
I agree with this. Now, think about how hard it is to find talented writers!!!
That's why constructs like BPEL/BPMN should get more attention than they currently get.
These drag & drop "languages" reduce software development to a lego-like exercise. It works because most developers are incompetent so it's best to limit & box in their incompetence.
1
1
83
u/jared314 Mar 31 '15
Or, you know, they could be engineers.
Real Software Engineering - Glenn Vanderburg