Programming is terrible – Lessons learned from a life wasted (2013) [video]
youtube.com
youtube.com
Clearly the idea of the 10xer has too big a place in the mythology of our industry. It's oddly masochistic and as far as I know it's unique to us. There are no doctors blogging about "10x doctors" for example.
Anybody who has watched N0tch code on Twitch knows that there are certainly people who are far more productive coders than the average engineer. I have no idea if he's coding 10x faster than I could but it's probably close. And my ego is... healthy sized. But it ignores the truth that few of us work as "programmers." A software engineer has many responsibilities and doing the other things well brings a force multiplier to your work.
I personally subscribe to the belief that we all have a superpower or two, and figuring them out and pressing their advantage is a strong catalyst to success. So figure out what you 10x at and be happy for it.
There are still 10x equivalents though. For instance, a PhD MD that chairs a department at a major hospital, publishes significant research, participates in NIH or similar organisations, and still sees patients is going to be a very different sort of professional than your local GP.
It's the notion that 10x applies only to NCLOC production that needs rethinking, so you're in the ballpark in that respect.
A local GP is what you want for tracking your longitudinal health and being a personal interaction with the health care system for you. Not someone chairing a department & publishing research
Is this true? I've been involved in a number of hires over the years where we quite specifically did not want a "10x programmer". We knew the position didn't pay enough, and had enough tiresome, non-novel work (e.g. building data processes for client data. Not big enough or interesting enough to be big data or technically challenging) that we simply wanted, in effect, a marginally competent chair warmer.
From seeing hiring and employment practices, this seems to be absolutely common across the industry.
Similarly there is another comment that opines that every programmer thinks they're a 10x programmer. Now maybe it's because I have a work history in places like financial firms and banks and insurance and telecom, rather than pure software or Google-esque, but this is absolutely untrue. I found that the vast majority of developers were simply careerists.
I think this is the basis for the 10x developer mythos. Whether there is a great variation or Notch just recorded himself on days when he felt really productive (or the fact of recording himself made him productive) remains debatable.
Then again, I have seen my share of the 1/10x programmers, so it is possible that it is all relative. In either case, like you said, programming a computer is only a part of the job for most people. Gathering requirements, building a product, selling it, supporting it, marketing, all factor in. Otherwise, you might say that all a car mechanic ever does is change the oil.
Do you not think what you wrote is just liberal dogma? I think there probably are people with few things going for them. Possibly removed from you socially due to the various filters that act on our lives.
Sure there are. Unlike programming where most of it is unique, and that stuff that's not is widely dismissed as "crud" (create update delete), with Dr's almost all of their work is routine.
Except when it's not, and when you have difficult cases you most DEFINITELY have 10x Dr's.
Have you never heard stories of patients going from Dr. to Dr. trying to figure out what's wrong with them, until they find that one genius Dr. who finally figures it out?
And regarding blogging, that's what the entire series of columns on NYT called "Think like a Doctor" is!
Part of that is throwing die after die until a six comes up. The die that gives a six need not have _anything_ to do with it.
A junior developer is almost always a net negative on a team of developers as the other developers end up having to fix their code. (one doesn't hire junior devs for their productivity but instead to train them to the point where they're no longer a net negative).
If you extrapolate it further, there are developers that have so much diverse experience and think at a higher level than others that their time brings 10x time to the project than even other experienced developers.
I call this pulling out into helper code function "blowing up" the code, because it usually results in an order of magnitude larger amount of lines of code.
This refactoring technique certainly helps make the core logic of the (usually) over complicated program visibly easier to see / grok from a distance.
From there its just a matter of reducing / refactoring / simplifying things down to more correct (at least I hope) abstractions that don't overcomplicate the solution.
This is most useful when you're given something like a 5k line script that does far too many things for far too many different reasons, all with very little if any documentation. (ie, bottom up refactoring, don't really know what the solution is but you know the current solution isn't the way to go)
That was my point too, you just formulated it in a more positive way. If the developer does not understand the problem completely, then he will do what you describe as bottom up programming.
Experimenting, in addition to taking more time than just spilling out the solution, also produces code that is not used in the final solution. So yes, a library for manipulating a certain kind of data is nice. But when it has functions that are never used, that is lost productivity. And even if the library is there, when a function becomes necessary, it might require different parameters or different application over data. Then making a conversion routine around the library function to fit the new usage also takes time, and potentially leads to inefficiency.
So my principle is that understanding the problem well is still better. That does not exclude experimenting, but its easier to experiment without spending time actually coding up a false solutions, just in ones head, when the problem is well understood.
I often find bottom up coding to be fantastic. I'll start with a general idea of what I want to do, then start writing low-level "helper" functions. Like "save image to blob storage", "perform search against remote API", "normalize search result into our document type", etc.
When I get around to tying it all together, if I've done it well, I find that hey, my "main" function is only 5 lines long as I've built up all the primitives I need.
And sometimes the reverse works, too, where I start off writing main and end up with a 1000 line function with lots of nested bits. Then go back over it and start extracting parts/structuring.
Like many things in software creation, this is one of those "artistic" or "creative" or "intuitive" parts where the developers internal heuristics and experience hopefully guide them to the right approach. Not to say it should be that way, but that seems to be a big difference between good and bad programmers, and I've not seen really hard, structured, learning approaches to teach the difference.
That would explain why we don't see a lot of it in the Java world and therefore why "traditional developers" think it's useless - first, creating DSL may need stronger language than Java to be practical, and second, most of the DSL is already done as parts of Spring or JEE.
I'm curious though, what do you mean that Spring is the DSL? Certainly that's the opposite, being so generic?
- Fewer managers - a group of 10 will probably require a programming lead who spends some fraction of their time not coding.
- One tenth the amount of office space and hardware.
- Only paying for one person's health insurance instead of ten peoples'.
- Vastly reduced communications overhead - a team of 10 people is going to spend a lot of time communicating with each other to insure that everyone is doing what they need to be doing.
So I'm guessing you'll come out ahead even if you do pay ten times more for ten times the productivity. But companies rarely even pay twice as much for a developer who is exceptionally productive.
The downside of having one person doing the work of ten is that it's a disaster when the person decides to quit - it's the equivalent of a whole team of people simultaneously quitting.
My tongue is in my cheek or some other such place right now because I kinda find this 10x business a bit funny, given that we can't even roughly quantify productivity. The thing I do believe in is that some people fit some kinds of work so well that it's silly to consider many other seemingly similarly qualified people as a practical alternative; as in, a hammer is good at hammering and it's not a question of it being 10x better than a shoe or 5x, it's just silly to hammer with a shoe, just don't do it. This is obvious but if phrased as "hammers are 10x shoes", it loses its obviousness and gains ridiculousness.
Suppose the earning/engineer multiplier is 4x: if you make 4x for each 1x engineer, you should make 40x from a 10x engineer.
And, currently the earnings/engineer multiplier in most well known bay area tech companies is enormous.
Do you want a kitchen with 10 chefs and the coordination that demands, or a kitchen with 1 chef that is just as productive as the raw sum of the 10 chefs? Assuming that the productivity of each chef was tested in isolation.
EDIT: grammar
Many times, I don't even write code; I "review" code. We have "grunts" (younger programmers, usually) who pump out code all day. They're are involved in design too, of course. But in a very limited way.
But you know, I think all of this comes with age. If you 22 years old, fresh out of school, you are going to be writing code all day. And that's how it should be, You need to cut-your-teeth.
Also, one last thought, just being a [overly] productive programmer doesn't make you a good programmer. I'd rather someone take there time, be comfortable and get it right.
But I have met that rare bird, who is confortable writing code 18 hours a day.
I'm 22 years old, fresh out of school and I'm as involved in design, recruiting and peer reviews as my older peers. And that's how it should be. Why? Because age has nothing to do with productivity, understanding or ability to come up with simple, elegant and maintainable designs.
You will improve with time. Coding is no different than any skill.
If schools don't teach you that, what's their purpose? (genuine question, I'm from a "special" school in France, and I've definitively been trained with that goal in mind (ie: gathering real world experience))
Every 22 year old thinks they can do everything just as well coming out of school...very rarely are they right, and looking back just 5 years later provides a lot of different perspective.
I would like to watch videos of someone doing something similar, but not well-rehearsed reimplementation. Got any? Thank you..
Definitely not rehearsed, but the first few weeks are stuff he knows well enough that it goes really fast.
After that, though he starts to get into things that he hasn't done (at least in a long time).
http://en.wikipedia.org/wiki/Stakhanovite_movement#History
"The Stakhanovite movement was named after Aleksei Stakhanov, who had mined 102 tons of coal in less than 6 hours (14 times his quota).[1] However, his record would soon be "broken" by his followers.[1] On February 1, 1936, it was reported that Nikita Izotov had mined 607 tons of coal in a single shift.
The Stakhanovite movement, supported and led by the Communist Party, soon spread over other industries of the Soviet Union.[2] "
Basically all this 10x is just a way to make people produce 10x while paying still for 1x. Programmers as a blue colar job also subject to it. White collar jobs like doctors or real engineers are much more resistant to it (as psychologically they are individuals not a member of a crowd what is typical for blue collar jobs)
?
In the conventional business mindset programmers just implement a plan devised by someone else. Consequently we are fungible (easily replaced by cheaper alternatives), and a cost rather than an asset.
However, there are provably good and bad surgeons and provably good and bad programmers. The reality is that you're making a lot of decisions when you cut out a tumor or implement a spec, decisions which take skill and practice to get right. I certainly wouldn't want my surgeon to be a cheaper alternative, nor would I want a programmer working for me to be the same. Not all programmers or surgeons are equivalent, since there is a large element of skill and practice.
Surgeons are briefed on the problem, the diagnosis, the patient's medical history, given all the information they need to know about the project. They are then locked in a small room with all the tools and assistants they need, and given complete and total authority and autonomy over the process and results. Because of that, surgeons are some of the most respected people in their environments.
Programmers are dripfed information on a "need-to-know" basis by managers who have no clue about the process involved (and therefore with no clue about what information is needed). They are then placed in an open area, interrupted regularly, have to justify the cost of any tools, are never given assistants, and have exactly zero authority or autonomy over the process or results. Because of that, programmers are some of the least respected people in their environment.
But we do have a few things in common: if the patient dies it's the surgeon's fault, and if the project fails then it's the programmer's fault.
This stark comparison is exactly why we're blue-collar workers not professionals.
A company can give programmers autonomy, or it can give them bits of information and treat them poorly. It could also do this for its sales team, its lawyers, or its marketing department. This strikes me more as a problem with the company rather than a problem with the nature of programming.
The first few times I did it, it caused a bit of an uproar, but very quickly they came to realize that they got better quality software when the person making it understood why he was making it.
Likewise, if you're in an environment where you're an eyes-down bricklayer (and unhappy about it)... Maybe it's time to put your big-boy pants on.
This is all known stuff, there's endless research and case studies showing that providing creative programmers with autonomy and authority over their environment creates massively better software results.
But the illusion of control is hard for some people to let go, I guess.
A surgeon of that level would be more analogous to a very senior programmer with management responsibilities. Said surgeon only got to that point after years of working very long hours with little autonomy.
And surgeons only get that autonomy for a fraction of their day, every doctor I've ever met complains about hospital and insurance company bureaucracies.
If you want to compare a bunch of 20-40 year old programmers sitting in an office plan at facebook to doctors, you'd do better comparing them to ER residents who definitely don't have the kind of autonomy you're talking about.
There are also plenty of "professional" programmers working as consultants.
But from my understanding of the health industry, the consultants are absolutely the top of the food chain despite their whinges about management. This is not true of even highly-paid consultant programmers (and highly-paid tech consultants are almost never allowed to waste their time actually programming).
There are plenty of niche programming consultants that are highly paid to actually program--firmware reverse engineering, and cryptographic security specialists are 2 of them.
There was a whole thread a few years ago where tptacek argued that $400 an hour is reasonable for certain specialty programmers, which is more than all but the highest paid surgeons make.
And if it isn't actually, then it certainly is in the public consciousness.
He gave 4 example categories: "expert developers with domain expertise in finance" also "cryptographic security specialists", "hardware reverse engineers", and "high-end SEO"
That doesn't describe my job very well. (OK, I don't have an assistant, but I don't think I need one.)
Or are you deliberately making a contrast between "coders" and "software engineers"?
Is this not programming?
Programmers are dripfed information on a "need-to-know" basis by managers who have no clue about the process involved (and therefore with no clue about what information is needed). They are then placed in an open area, interrupted regularly, have to justify the cost of any tools, are never given assistants, and have exactly zero authority or autonomy over the process or results. Because of that, programmers are some of the least respected people in their environment.
That sounds horrifying, how on earth are you ever expected to accomplish anything worthwhile in such an environment, and in the present ultra-competitive market, why would anyone tolerate being treated that way?
I think this analogy is wrong. Like architects, we can and must help requesters understand what's possible. "Architect, please design me a house supported by tiny pillars." "Programmer, please solve the traveling salesman problem for me."
> Consequently we are fungible (easily replaced by cheaper alternatives), and a cost rather than an asset.
The more central to a business their code is, the more this mindset will hurt them.
> The Stakhanovites were responsible for organizing the two-hundreders movement (Russian: двухсотники, or dvukhsotniki; 200% or more of quota in a single shift) and one-thousanders movement (Russian: тысячники, or tysyachniki; 1000% of the norm in a shift)
The idea of "one-thousanders" movement is numerically identical and almost linguistically identical to the "10xer" movement.
Actually, I see it more frequently referenced as reason to pay people more than 1x based on productivity. There are some that deny 10x productivity exists, which is the controversy around it that I am most familiar with. If you are an order of magnitude more productive than your peers, but paid only marginally more, this becomes an incentive to start your own business, or join one where you significant equity, where you will be able to capture more of the value.
... He said and about the profession with surely the highest concentration of arrogant and self-satisfied know-it-alls.
"Illusory superiority" applies to a lot of things. Most people think they are 'good drivers' and that is where it starts.
For most cognitive tasks the people who do them probably did fairly well at school, possibly the top 5 or 10 percent and so assume they are smarter than 19/20 or 9/10 people...
One of them was the VP of Engineering for the startup I was working at. He was and continues to be brilliant. He was online almost every hour of the week/day and he was always working. He singlehandedly kept our site up by himself, and when he left, it literally took 5 engineers to replace the work that he did. His leaving left such an impact that the Engineering team almost disintegrated because of how much work we had to take on, and the lack of any truly great engineers to mentor the other engineers.
The other was a friend of mine who was the most productive coder I'd ever met. He would also work as hard as I've ever seen anyone work, and the code that he produced did things I've never seen people do since then. Tragically, he committed suicide 2 months ago, and it's heartbreaking. Probably the intensity to which he coded reflected on the intensity that he pursued every other thing in his life, and when things didn't work out his way, like his marriage, it probably hit him much harder than it would a regular person, who would be rightfully devastated.
It's a lot easier to be a "10x engineer" when you work 2x-3x the hours everyone else.
I dunno, he sounds more like a 5x engineer to me!
For example, they can select the right approach to concurrency for a particular problem, rather than spending much time later chasing concurrency bugs.
But you are likely aware that this type of 10x engineer is not who the vast majority of corporate managers and "non-technical" start-up founders are thinking of when they describe a 10x engineer. For them, a 10x engineer is simply one who produces code 10x as fast as the other engineers.
In fact, simply writing code 10x as fast as usual is not a difficult task for a competent developer to accomplish. With significant overtime, and reckless abandon, any skilled developer can churn out poorly thought-out code at a rate roughly 10x greater than the rate at which a skilled developer can write well-designed, tested, documented, refactored code.
This is why we have so many "10x" engineers, and so much technical debt.
I think it's really just unique to the Bay Area, and it's wacked out culture it's been cultivating that focuses on the bang-bang-bang go-go-go 100x multiple return on dollars.
I've been an engineer for over a decade, and the first time I heard the term "10x" was 6 months ago when a product manager referred to me a "10x engineer" during a conference call.
It's absurd.
In software development, I think that 10x number is also a lower bound if anything. Bad developers are everywhere, churning out volumes of terrible, pointless, code. In a code review a while back for a client, I made an offhanded comment about a minor thing like "make sure this list is sorted and deduped". The code owner then started "discussing" that and estimated it'd take about 2 hours. I was stunned and added the code ".Distinct().OrderBy(...)" right there in the review. I'm at a loss at how to explain that kind of difference, and that's on a micro-scale.
At the other end, I've seen projects/companies go down colossally wrong paths because they simply couldn't understand basic algorithmic complexity. So, say, I dunno, a week or two to do it right, versus a year spent chasing down fake paths? That doesn't even measure the business impact of floundering around for a year while impacting customers.
Focusing on "coding 10x faster" is simply misleading. Like measuring an author based on how fast they can type.
And are you really saying that inside the US, there are no practitioners with an error of 1/1000 where another one has 10/1000? That seems awfully tight.
Objective Performance in doctors is harder to judge than in developers. Some specialities lose a high percentage of patients no matter how good the doctors are. Sometimes even a difference of "10x" in error rates may require more cases to judge than a particular doctor actually has in a year.
It's a bad myth that "speed" has anything to do with the 10x or 100x programmer. The thing that sets great programmers apart is their ability to instinctively and intuitively design elegant and correct solutions to a given problem while introducing minimal bugs. A great programmer whose code will stand the test of time without needing a total rewrite 6 months later and without a horrendous maintenance and complexity overhead could write their code at 10 words a minute and still be worth their weight in gold.
Personally I think "great" programmers are really just "good" programmers - those that understand the problem domain, have expertise in their tools and know how to minimize complexity - this should not be some white albatross but rather a level we should all aspire too. I think it is more useful to identify bad programmers - those that rage in like a bull in a china shop, adding layers of complexity and abstraction to cover up their lack of knowledge and expertise, who flippantly choose bad designs for a given problem because they believe in some universal "right way" and spend half their time on premature optimizations before their buggy product is even in a testable state.
I have come across numerous bad programmers in my time, and if they were nipped in the bud early before they could leave reams of damage in their wake, I can testify to many man-months in effort rectifying their mistakes.
I don't think this gets nearly enough praise when assessing people. I've worked at a few different software companies with a raft of different programmers and among those who were deemed "superstars" there were certainly a few who I wouldn't want to work with (or inherit code from) given the choice due to the hideously complex nature of their output.
Despite their ability to produce major functionality with incredible speed, which is often what led to them being seen as superstars by management, code that is so complex that it is virtually unmaintainable is a huge ongoing burden. Its great that you rescued a late project when everyone said it could not be done but some poor sucker is going to have to maintain that mess.
The speed you want is rotational, not translational :)
Ultimately a "10x hire" who overcomplicates things can probably be toned down through some mentoring.
I guess the "work smart, not hard" truism can be reworded to "solve smart, not complex" in this case.
> some poor sucker is going to have to maintain that mess.
Although complex is not the same thing as a mess, it merely might as well be.
That is very important. Code that is not written is just as important importat (maybe more important) than code that is written. What I mean is good programmers will find way to solve something using less code. That is very imporant for understandability, maintenance, and long term support.
That is hard to convey to an outsider. Say a manager who has never programed that is in charge of evaluating programmers they are managing. They will usually value more code, more nights spent at the office and more churn fixing bugs vs less code, less nights spent at the office, no churn or "putting out fires". Heck to them it looks like the 10x programmers is a 0.1x programmer compared to others.
It's not about less code, it's about simplicity of code. I have known people who have played code golf with production code, either out of bordom or a desire to generate job security. That's not actually solving the core problem of making it easier for someone to port to a new version of an OS in 5 years time, it only looks that way if you aren't paying attention. Short code can be just as confusing as long code.
Your code should, in all places where it is not necessary to do crazy speed optimisations, be understandable by the average intern. Yes, that means comments, and yes, sometimes it means doing something in one line that is more commonly done in 20 lines and yes, sometimes it means taking 20 lines to do something you could do in one line.
[1] When writing code to solve problems I've encountered frequently in one of the languages I've used long enough to thoroughly memorize all facets of the syntax and most of the available libraries.
[2] Consistently using those 10x powers would quite possibly be the most boring life I could imagine as a software engineer ... give me a hard problem to solve once, then never ask me about that problem again!
Next time something similar arises, you blow the doors off anyone else starting from scratch. I've done it myself, and it has be to quite common.
I disagree with your point [2], though, at least in part. I would get bored, too, if all I ever did was to repeat things I had figured out years earlier, but if I put the effort into figuring out how to do something hard, I want to USE that hard-earned knowledge more than once. I don't want to always be a slow, awkward newbie at everything I do, which is what I am the first time I tackle most new, serious challenges, but I don't want to stop tackling new challenges either. I'd prefer a mix of the two: sometimes a newbie, sometimes an expert.
But, like you, I don't want to be stuck there. I want to experience it often, but I want to have plenty of new days, too.
Faster had nothing to do with it. If anything these guys code slower. 1 line of brilliant code will always beat 10 lines of mediocre code typed very fast though
[1]http://www.computercraft.info/forums2/index.php?/topic/8325-...
see, you are a programmer - you make code. notch is a game developer. he USES code to make THINGS. the things matter, not the code. the game developer ethic is "nothing matters but getting the game running." it's not that notch is a shoddy programmer at all, it's that he has different priorities than you.
Only now, three numbering schemes later (alpha, beta, release), in release version 1.8, does the core game actually have features such as abstracting implementation IDs from object types (EG: now there is minecraft:glass to resolve instead of remembering decimal value 20. Though mods for r1.8 are only just beginning, so that scoping might not yet exist.)
These aren't mutually exclusive. When Carmack, Sweeney et al. built Quake/Unreal, they made something that was both fun and had incredible code quality. Derivatives of the Quake & Unreal engines run today and have been for the last 20 years. I'm doubtful that any code written by Notch for Minecraft will be running anywhere 20 years from now. Likewise, don't NASA engineers "actually make something" while adhering to strict code quality? Doesn't Google "actually make something" while adhering to strict code quality? The choice between "code quality" and "actually delivering" is a false dichotomy invented by people who needed an excuse.
Next, I never implied Notch was a shoddy programmer. Notch is a great programmer by his own merits and I don't think anyone can doubt that - however great programmers can produce shitty code. What I was responding to was OPs assertion that 10x programmers exist. Notch produced some pretty great stuff, and iterated quickly, but that speed didn't come free and surely theres a lot of technical debt that others now have to deal with.
Lastly, I'm not saying this is a bad thing. Sometimes its more important that you can ship first, and fix later. Sometimes being first to market is better than being the best. What I want to point out however this is a normal tradeoff and this doesn't make Notch a "10x engineer" (when I say 10x here I mean a mythical man who has achieved enlightenment that none of us can achieve even if we worked for 1000 years). He's a great developer, but we shouldn't pretend that there weren't tradeoffs to his approach and that his style is anyway mythical (like a unicorn).
the point is that game development is inherently a big job and you have to make massive tradeoffs if you want to get something working in a reasonable amount of time by yourself. of course if you have thousands of people to throw at the problem you can go nuts and adhere to the highest of quality standards.
but i agree that notch isn't a mythical programmer or "10x engineer".
And Tim Sweeney did a lot of development on Unreal 4 on his own[1]. The trade offs of structure & abandon can work at many scales, you don't have to be Google to do it. Likewise Redis[2] has largely been the work of a single developer, and isn't reckless.
Now while Minecraft is a toy and Notch likely didn't start out with the thought to develop it into a business, that doesn't mean the value of its code is worthless. Yes the tradeoffs are there, but we shouldn't get carried away and start to believe you can only write "good" code if you have a thousand engineers.
[1]http://www.tgdaily.com/business-and-law-features/36436-tim-s... [2]https://github.com/antirez/redis/graphs/contributors
There are other problems with original Minecraft, that surfaced when people started to actively disassemble (or deobfuscate) it. But those are mostly unsourced, and I do not feel the authority to speak about it.
[0] http://what.thedailywtf.com/t/optifine-modder-rips-the-minec...
Not all code has to be a platform. It's entirely acceptable to write code that "just works" and does not pretend to be 'future proof' or any nonsense like that.
In YC they tell you the same thing: just write the hell out of it and get it done. You will rewrite everything later anyway when you know more about the business and the customers. Games work a bit different, but the lesson applies.
Yes good engineering is important, and Google is a great example. Do you think the code Larry and Sergey wrote early on was anything close to shippable code at Google today? I guarantee you it was a mess of python scripts and c libraries.
YAGNI. Make your product the edifice, not your code.
It takes 6-8 years of intense training to become a doctor. This is after already doing well in college and passing a tough skills/general intelligence test.
The bottom 70%+ who want to become doctors are simply not able to get through the system. If we got rid of the bottom 70% of developers we wouldn't be having these 10x conversations either.
A doctor who passed with at least 75%, so far as my local [third world] standards go.
Frankly software engineer is fluffy happy world of love and inclusion compared to medicine; a more masochistic profession you will not find.
My experience is second hand through my wife's participation in medicine as a hospital doctor.
N.B. General Practitioners seem to have a far more acceptable work life balance.
A) The person posting simply hasn't had the pleasure of working with such awesomeness.
B) The person is threatened by the possibility of 10X'ers really existing, since that's a threat to their own ego.
I'm a great programmer, and still know many people who leave me in the dust. I'm glad for that.
"The vanity of others offends our taste only when it offends our vanity" -- Nietzsche
As far as N0tch, I think that's a bad person to compare yourself against. While I can respect what he achieved and envy his good luck, he is hardly what many would call a good programmer. My standards may be different than others. He may code fast compared to some people (and slower than others), but code speed/output != productivity. Judging by the state of Minecraft and bug counts of what he's done, one could do the same by shifting emphasis or priorities on getting something usable vs. bug free. It is more correct as you imply that other things are just as valuable or perhaps more. It all depends on context. N0tch might be a great prototype programmer, but a terrible programmer for writing banking software and sending things into space. We still don't have many good ways to judge people, which is why dumb managers look at things like lines of code or total hours.
Indeed we know that many factors influence productivity - familiarity with the task and technologies involved, language choice, library choice, deadlines, environment, external influences, and so on. This sick culture of work will make you free is not a good one. I do believe though that many good developers who can work together in a group (very important) are better than having 100x as many people who are bad coders. It really depends how big or small a team is, how it is managed or not, and so on. Having a team of only the best coders isn't enough and can actually seal the doom of a project.
https://github.com/tef/emfcamp2012/raw/master/programming_is...
Process efficiency is how organised is the process of the development — a.k.a. getting things done. If somebody keeps shipping stuff, they are process efficient. Even if it's the smallest thing ever, just keeping the flow going.
Then there's the output efficiency — how efficient is the thing that was shipped. Is the code high quality? Is the algorithm performing well in the problem's domain? Is the code running "fast"?
I personally think that the best developers optimise their work on these two fields: they keep delivering great output code most of the time. Because what is better: lots of bad code in short time, or good code taking more time?
2) The premise of the 10xers not being around in 50-100 years could be correct. It depends on the amount of money invested in anti-ageing technology.
Coming down on one side or another, in a binary fashion: I think your comment is false.
> Until better than marginal gains are realized, I would say it's premature to hold massive lifespan lengthening out as a realistic possibility since we don't know what road blocks lie ahead. Sure, it's possible in the 'anything is possible' sense, but, IMO, not as a practical consideration.
People are working on the problem of radical live extension today. So even if you consider it impractical, that's certainly not a view held by everyone.
Plus, a gradual improvement is all that's needed. As long as someone can live long enough to reach longevity escape velocity[1], that's the problem solved!
[0] http://www.kurzweilai.net/fullerene-c60-administration-doubl...
The way to deal with overoptimistic programmers is to put them on maintenance programming, fixing bugs in the code of others, for a few months or years.
(wasn't sure if you were trying to be funny by doing so, or if there is something else relevant I've missed in the many posts above and below this that I haven't read)
Once your passion becomes your job it becomes tainted though.
Some references (sorry for the formatting, if this becomes a thing I'll do the wiki and the logo):
Slides:
https://github.com/tef/emfcamp2012/raw/master/programming_is...
Blub Paradox:
http://www.paulgraham.com/avg.html
http://c2.com/cgi/wiki?BlubParadox
Perl and 9/11:
http://www.paulgraham.com/hijack.html
10x:
http://hfs.sagepub.com/content/16/1/70.short
http://www.construx.com/10x_Software_Development/Origins_of_...
http://www.construx.com/10x_Software_Development/Productivit...
Waterfall (same pdf, linking from 2 sources):
http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/wate...
http://leadinganswers.typepad.com/leading_answers/files/orig...
Conway's law:
http://en.wikipedia.org/wiki/Conway%27s_law
Unrelated, Pournelle's Iron Law of Bureaucracy (I just like this law):
http://www.jerrypournelle.com/reports/jerryp/iron.html
X-Y Problem:
http://meta.stackexchange.com/questions/66377/what-is-the-xy...
Atwood, Don't Learn to Code:
http://blog.codinghorror.com/please-dont-learn-to-code/
Wason selection task:
http://en.wikipedia.org/wiki/Wason_selection_task
LMGTFY:
https://www.google.com/search?q=pieget+constructive+learning https://www.google.com/search?q=curry+howard+isomorphism
Amazon Links, no referral:
http://www.amazon.com/Mindstorms-Children-Computers-Powerful... http://www.amazon.com/Peopleware-Productive-Projects-Teams-3... http://www.amazon.com/dp/B00B8USS14/ref=wl_mb_recs_2_title http://www.amazon.com/Design-Essays-Computer-Scientist-ebook...
(Sorry for nitpicking)
> kill yourself now
That's totally inappropriate no matter how funny you think you are.
Strangely, your response bothers me more than the quote. Could you not find anything positive to say?
Source: Men http://www.cdc.gov/men/lcod/2011/LCOD_menallages2011.pdf and women http://www.cdc.gov/women/lcod/2011/WomenAll_2011.pdf
Being unable to joke about it, however, is stifling. The reaction to clamp down on the joke suggests that suicide is something normal people don't do.
I get there is probably some deeper reason behind your views. But I respectfully disagree.
1) http://www.theregister.co.uk/2012/02/29/torvalds_tantrum_ope... 2) https://plus.google.com/+LinusTorvalds/posts/1vyfmNCYpi5