Overshadowed - Pandora Also Files For IPO - <AUTHOR> http://www.streetinsider.com/IPOs/Pandora+Media+(P)+Sees+IPO+Price+of+$7+-+$9Share/6556472.html

<comment><USER2> This isn't overshadowed, they filed in February and was one of the first of the current crop to file. Today they just set the share price.

</comment><comment><USER3> Smart play: Pandora's launching their IPO before the other big players start moving. With Google Music and Amazon Cloud Player coming into the market, Pandora's trying to get their offering done before competition gets fierce.

Feels like Groupon is doing something similar. With Google and Facebook moving closer into local deals and LivingSocial nipping at its heels, its only a matter of time before Groupon starts feeling the heat.

<comment><USER4> Pretty damn smart considering that they had the foresight of all this, when they filed for IPO in February.

<comment><USER5> Google's $6B offer for Groupon was the catalyst, not some "foresight"... Groupon thought they could get better from an IPO than going with Google.

<comment><USER6> He was referring to Pandora, the ones that filed in February.

</comment></comment></comment></comment><comment><USER7> Tangent: Their ticker will be "P."? Are there any other labels with punctuation in it?

<comment><USER8> The ticker is "P", not "P.". :)

<comment><USER9> The rise of "logical punctuation"?

<comment><USER10> <http://www.catb.org/jargon/html/writing-style.html>

</comment></comment></comment></comment><comment><USER11> I was surprised that they got a single letter ticker symbol, so I looked up the history. It turns out that P used to be for Phillips Oil, which gave up the symbol when they merged with Conoco.

I'm amused by the fact that a tech company is taking an oil company's ticker.

</comment><comment><USER12> I loved Pandora for the brief amount of time that I could use it "legally".

As long as I continue to get this message:

"Dear Pandora Visitor,

We are deeply, deeply sorry to say that due to licensing constraints, we can no longer allow access to Pandora for listeners located outside of the U.S."

Sure, I have my Linode and could use Pandora, if I really wanted, but not everybody in Europe or elsewhere outside US wants to jump through hoops just to use some service.

</comment><comment><USER13> Relevant: <http://ecorner.stanford.edu/authorMaterialInfo.html?mid=2440>

</comment><comment><USER14> When is their stock going on the market? I couldn't find it in the article.

<comment><USER15> They aren't allowed to announce things like that. Although eventually a pundit will piece it together

</comment></comment><comment><USER16> Now, if they were only (officially) available in germany :(

</comment><comment><USER17> I've never been a fan of Pandora. Usually my stations end up sounding like a typical classic rock FM station. The commercials they have on their site for the free service is almost as bad as FM radio commercials.

<comment><USER18> It all depends on what bands you select at the beginning and what songs you favorite.

<comment><USER19> Agreed. You need to remember that all the stations are separate objects. So, on your techno stations, don't favorite soft rock. Oh, and pony up the cash for the paid service; it is worth every penny to not have commercials for business cards.

</comment></comment></comment><comment><USER20> No last.fm IPO?

<comment><USER21> last.fm is part of CBS Interactive. If you like, you can buy stock in CBS right now.

</comment></comment><comment><USER22> This story brought to you by LivingSocial... over and over and over again.</comment>


Veritossed: Cheating Scandal Kills 4 Harvard Quizbowl Championships - <AUTHOR> http://www.insidehighered.com/news/2013/03/22/cheating-scandal-kills-4-harvard-quiz-bowl-championships

<comment><USER2> Have they been sitting on this story? In our hour of triumph! At least they didn't wait until the Crimson beat Arizona.

Seriously though, NAQT might consider not depending on the honor system for access to the questions that are the basis of their entire competition. This ain't Ultimate Frisbee.

<comment><USER3> It wasn't just an honor system. There was a system of actual, albeit clearly flawed and deficient, security in place, which was exploited.

<comment><USER2> Well that's one reading of TFA and the NAQT announcements. It's clear however that the attackers in this case had been given access to the same site, backed by the same database, that contained the data they were attacking. There may have been additional _ad hoc_ countermeasures designed to restrict them to a proper subset of the data, but this is probably OWASP's "Failure to Restrict URL Access" rather than something more easily validated like e.g. TLS setup. I'm not saying that an app _couldn't_ defend against such a threat, but it would be a higher bar to clear, easily obviated by the reasonable policy of maintaining separate sites for the high school and college questions.

A higher-level threat than the dudes they caught (not sure NAQT has such, but whatever) will typically seek privilege escalation before doing anything that betrays its intentions. These dudes just used their own credentials to view the "List of Questions" page a bunch of times in the week before their competitions. Other attackers, who used their site access to attack the credentials or clients of those users with legitimate access to this data, have not been caught.

<comment><USER3> My statement wasn't based on a "reading" of anybody's announcement; I'm pretty familiar with the situation at hand and with the system. There's no optimal way to maintain separate sites for high school and collegiate questions, or any reason to do so, since most writers write questions for both sets. Obviously there are privilege and access problems with the software, and with the way that privileges are implemented across the software's different features, but that can't be solved by walling off the sets of questions (especially since some sets can't even be explicitly categorized as "high school" or "college").</comment></comment></comment></comment>


New Apple Developer Guideline Bans Apps That Promote Other Apps - <AUTHOR> http://techcrunch.com/2012/10/01/how-a-new-apple-developer-guideline-could-be-curtains-for-apps-that-promote-other-apps/

<comment><USER2> "Apps that display Apps other than your own for purchase or promotion _in a manner similar to or confusing with the App Store_ will be rejected." <\- So, sounds like the rather benign goal of keeping developers from impersonating Apple's own payment channel and thereby confusing users into believing they are transacting with Apple and then to send Apple support issues.

<comment><USER3> I actually wish they banned _all_ cross-app promotion, which is the second most annoying thing after the in-app purchase promotions.

<comment><USER4> So you'd ban all the free demo versions of paid apps?

<comment><USER5> No need for having two apps clogging up the store - have just the app, and have the paid version unlocked via IAP.

<comment><USER6> This is actually really painful for both devs and users - the main thing being that recovery of the paid upgrade will be finicky and unreliable. The UI for recovering an in-app purchase is the same as the buying UI, which leads many users to mistakenly believe they are being double-charged.

Who can blame them, the UI blows.

Since devs themselves also do not get any user-specific information when an in-app purchase is sold, it becomes pretty much impossible for your support channels to verify someone actually owns what they say they own.

Until the API improves (not holding my breath, it's been like this for, what, 3 years now?) IAP-driven upgrades will hurt both users and developers.

<comment><USER7> > _"The UI for recovering an in-app purchase is the same as the buying UI, > which leads many users to mistakenly believe they are being double- > charged."_

This makes sense for low-price + IAP apps, but not the free + IAP model mentioned in the thread you're replying to.

Free + IAP seems fine, and it's probably been the most popular PC/Mac software sales method since the 90s.

<comment><USER6> This impacts free + IAP models also. Here's the classic use case:

1\. User gets a shiny new iPhone. 2\. User installs my (free) AwesomeApp on new device. 3\. User is missing premium AwesomeApp features, is now confused about why. 4\. User goes to IAP part of app and tries to recover the IAP/premium features, except Apple's UI here would lead user to believe they are being charged for the IAP again.

This is often followed by:

5\. User contacts support and is very confused. Support _cannot verify_ whether or not user owns the IAP, because the App Store is a black box and we get _no_ information about purchasers.

<comment><USER8> Isn't that what the restoreCompletedTransactions api is for? It's the fault of the app developer for not using it, and forcing the user to go through the purchase flow again.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> We ran into this when I was working on App Map. <http://appmap.mobi> It's just one of the roadblocks against cloning the App Store or just putting a spin on what Apple is doing. It's not a big deal as long as you're doing something different.

</comment><comment><USER10> Ironically, their new Maps app points you to a bunch of apps on the app store when you ask for transit directions.

<comment><USER11> Why is that ironic?

</comment></comment><comment><USER12> Ah, so Zynga will have to remove one of the rows of crap they added to Words With Friends?

<comment><USER13> Wouldn't that be considered their own apps?

</comment></comment><comment><USER14> Hopefully this does not effect AppShopper[1]. It is a great resource and has saved me money.

[1] <http://appshopper.com/>

</comment><comment><USER15> > "The whole point of the review guidelines is that Apple wants consumers to > get the very best apps from the App Store, and they recognize that if it > gets filled with garbage, discovery gets even worse, and that just hurts the > platform," Satok said in an interview.

Both Apple and Google are way too late on that - they're getting proactive now that the cows have escaped and burned down the barn on the way out.

</comment><comment><USER16> Apple should rank apps based on actual usage not downloads.

On the web we call unique users vanity metrics, and monthly active users the real deal. Why not the same for mobile?

<comment><USER17> Because I really don't want Apple tracking every time I open any app.

<comment><USER18> You seem to think they don't already track this. I don't know what Apple does, but it's trivial to hook up Google Analytics to any app you create.

</comment></comment></comment><comment><USER19> Sounds like all app recommendation apps will be going away.

</comment><comment><USER20> If the paranoid reading of this article is valid then this could only mean more entrenchment for big name players.</comment>


ProtonMail is now more secure against sophisticated attacks - <AUTHOR> https://protonmail.com/blog/security-updates-2019/ <comment><AUTHOR> Relevant comment from the ProtonMail team on Reddit: [https://www.reddit.com/r/ProtonMail/comments/d1q7ee/security...](https://www.reddit.com/r/ProtonMail/comments/d1q7ee/security_updates_protonmail_2019_protonmail_blog/ezpmtg9/)</comment>


The Design and Implementation of the FreeBSD Operating System, 2nd ed. - <AUTHOR> http://www.amazon.com/Design-Implementation-FreeBSD-Operating-Edition/dp/0321968972/ref=zg_bs_3756_28 <comment><USER3> I have a very dog eared copy of the first edition and ordered this one. I also bought a copy of the CS class that Kirk taught at UCB on VHS video tape back when I was at NetApp.

I sort of think of three books as being core of a curriculum understanding operating systems, this book, "The Design of the UNIX Operating System"[1] by Bach, and "Operating System Concepts" by Silbershatz. Owning and understanding those three texts will give you everything you need to know about working in the kernel and designing your own OS code.

[1] www.amazon.com/Design-UNIX-Operating-System/dp/0132017997/

[2] www.amazon.com/Operating-System-Concepts-Abraham- Silberschatz/dp/1118063333/

<comment><USER4> It looks like the lecture videos are still available, however, they are somewhat expensive.

[https://www.mckusick.com/courses/index.html](https://www.mckusick.com/courses/index.html)

[https://www.mckusick.com/courses/introorderform.html](https://www.mckusick.com/courses/introorderform.html)

<comment><USER5> That's actually quite cheap as training materials go.

</comment></comment></comment><comment><USER6> A DRM-free ebook is available here:

[http://www.informit.com/store/design-and-implementation- of-t...](http://www.informit.com/store/design-and-implementation-of-the- freebsd-operating-9780321968975)

<comment><USER7> Can anyone with an account please check how much shipping to germany costs? I don't want to set up an account with another site just to check shipping costs. I can get the book from Amazon but the Bok + eBook bundle informit offers looks attractive, but it all depends on the shipping costs.

<comment><USER8> I tried with the shipping address to the German Parliment (taken from [https://www.bundestag.de/htdocs_e/visits/hinweis](https://www.bundestag.de/htdocs_e/visits/hinweis))

Platz der Republik 1 Berlin 11011 Germany

International shipping -- $9.00

<comment><USER7> Thanks.

</comment></comment></comment></comment><comment><USER9> The FreeBSD foundation is one of the charities that smile.amazon.com donates to, so if you're not already using it, consider purchasing the booking through smile.amazon.com so 0.5% of your purchase goes to them.

</comment><comment><USER10> I audited McKusick's kernel class at Berkeley extension. 8 hour sessions every Saturday for a couple of months. I don't have a formal CS background but at the time had 10-12 years of professional experience. It was the most useful class I have ever taken, removing the magic behind the OS.

<comment><USER11> Was that online?

<comment><USER12> You can register here: [https://www.mckusick.com/courses/introinterestform.html](https://www.mckusick.com/courses/introinterestform.html) and if you are not in the Bay Area, you could buy the videos.

</comment></comment></comment><comment><USER13> As a long-time user of FBSD (since 4.x), the book looks like it's quite comprehensive. Keeping up with all the recent changes is difficult, and this detailed reference covers an impressive range of topics (as far as I can determine from the preview), particularly newer and updated features like the Capsicum framework, security features, ZFS, geom among others.

One disappointment is the book doesn't have much to say about UEFI and Secure Boot, which will be important to easily integrate FBSD with other systems on current PC hardware. Understandable though, as they're still in development and the authors not yet ready to discuss it.

For an 800+ page book the price is rather modest. Looks like one that will have to go on my "must get" list.

<comment><USER14> UEFI just went into FreeBSD (it _might_ make 10.1-RELEASE)

In other words: it's too early.

<comment><USER15> UEFI is in 10.1-BETA1, so I think it's safe to assume that it will be in 10.1-RELEASE. ;-)

</comment></comment></comment><comment><USER16> I was never into FreeBSD (I hoped to dive into it more in the past, but never done so sadly), but heard that 1st ed was really good, so the revised version quite likely shouldn't be any worse (hopefully even better). I would order it, but there are still many technical books on my shelf waiting for my attention, thus adding another one will not help in that matter.

One thing is sure, even if you're not into FreeBSD, broadening your perspective is never wrong. So I may eventually order it in the future.

<comment><USER17> FreeBSD combined with this book is great for learning about operating systems in general, regardless of whether you care about FreeBSD specifically. The book goes into a lot of detail about why certain design decisions were made, and how things are implemented in other operating systems.

If you're already studied some other OS in general, you might not need this book, but if you haven't, this is a great place to start.

<comment><USER12> Thanks! Do you think it's useful to get this one even if you have used Linux almost exclusively? Will it make it easier for one to get into Kernel development?

<comment><USER17> Sure. But it's worth having a FreeBSD box (or VM) that you can use to tinker with the kernel.

Recompiling FreeBSD kernel source is super easy, by the way. It comes in /usr/src on your machine and all you need to do to reinstall one with your changes is "make buildkernel && make installkernel" . Actually understanding the sometimes decades-old source code, on the other hand, might be a little more difficult...

<comment><USER12> How'd you compare this with Linux Kernel Development by Robert Love and/or Bovet/Cesati, especially for someone who's a newbie (but curious to learn and work hard)?

</comment></comment></comment></comment></comment><comment><USER18> For those of you who get to use this knowledge in your day to day jobs what kind of things are you working on?

</comment><comment><USER19> My copy arrived yesterday. A real old-school textbook; reminds me of the days of poring over "Modern Operating Systems" in college!

</comment><comment><USER20> Mine arrived yesterday.

The size and heft of the print book is a welcome surprise, it's something that you could toss in a bag and hold to read without support (2.7 lbs, 9.4x6.4x1.4) - relevant for something that will eventually be shelved among stuff like "The Linux Programming Interface" (5 lbs, 9.5x7.2x2.3)

<comment><USER21> TLPI is my favourite book(technical book I own). Sometimes I look over at it and think "Man, what a great book". I'm very tempted to purchase this as well :)

</comment></comment><comment><USER22> These books are pretty much a must read for anyone interested in the internals of Unix-type systems. I keep them right next to my TCP/IP Illustrated volumes, I reckon it's always good to have good reference material handy - <USER2> when it is well written and researched.

<comment><USER23> You sold me. I'm not particularly interested in knowing enough about FreeBSD to diagnose anything non-trivial, but I am interested in learning about design decisions behind operating systems.

</comment></comment><comment><USER24> This book is great, even if you don't use FreeBSD. I remember that I learnt how a TLB/MMU really works by reading this book, and not on an Operating Systems lecture.

</comment><comment><USER25> Would HN-commenters recommend this (based off of experience with either edition) over other OS books for a self-teaching CS Curriculum?

Do you agree that picking one OS to study is the best way to learn about Operating Systems generally?

<comment><USER26> This should also help you: [http://pages.cs.wisc.edu/~remzi/OSTEP/](http://pages.cs.wisc.edu/~remzi/OSTEP/)

<comment><USER25> Wow! Thank you.

</comment></comment></comment><comment><USER27> Is there a comparable, relatively up-to-date book for Linux?

<comment><USER20> Not exactly.

What really sets this book apart, in my opinion, is just how readable it is. I haven't run across anything with quite the same combination of style and depth for Linux.

You could read through something like The Linux Programming Interface [1] or Understanding the Linux Kernel [2] and with effort extract much of the same information, but without the pace/structure/commentary that I think this book does so well.

Thing is, _conceptually_ much of what you'll read in this book will be applicable to Linux just fine and having read it will make it far easier to grok how/where the two differ.

1: [http://www.amazon.com/dp/1593272200](http://www.amazon.com/dp/1593272200) 2: [http://www.amazon.com/dp/0596005652](http://www.amazon.com/dp/0596005652)

</comment></comment><comment><USER28> What are the major changes from the 1st edition? I had bought the old one just a few months back...

</comment><comment><USER29> Has anything important from the first edition been omitted from the second?

</comment><comment><USER30> The first edition is quite good. I'm sure the 2nd is just as good.

</comment><comment><USER31> It seems odd that this book is only about the kernel, given that the BSD camp has always said that an advantage of a BSD over Linux is that a BSD is the whole package, from the GUI and command shell on down, whereas Linux is 'just' the kernel, and relies on distros to be usable.

<comment><USER32> The userland would be harder to write a long lasting book on. It's prone to change between major version numbers.. for instance clang/c++ RT/etc. It would be cool to see a volume on this stuff, but it would probably need a ton of authors and be more like a series of exposes (thinking a book like Architecture of Open Source Applications)

</comment></comment><comment><USER33> Don't forget: [http://www.openbsdfoundation.org/](http://www.openbsdfoundation.org/)

<comment><USER34> Oh man, now you've triggered my OCD and I feel pedantic.

[https://www.freebsdfoundation.org/](https://www.freebsdfoundation.org/)</comment></comment>


Degrowth - <AUTHOR> http://en.wikipedia.org/wiki/Degrowth <comment><USER2> One of the things this comes down to is whether our measures of wealth are sensible.

A country hot enough to require air conditioning will have an increased GDP, but this GDP is really just for bringing it to the norm of another country that doesn't require aircon. And should we count the extra economic activity generated from creating a new demand where there previously was none? [1]

If we optimise for the wrong thing, we end up with bad outcomes.

[1] [http://www.businessweek.com/articles/2012-10-18/convincing-w...](http://www.businessweek.com/articles/2012-10-18/convincing- women-in-china-theyre-too-hairy#r=read)

<comment><USER3> I really dislike GDP as a measure, for this and other reasons.

Ultimately, GDP isn't what matters. We should care about wealth creation, about efficient use of resources (including labor), about happiness and enjoyment.

An inevitable consequence of abandoning GDP as a measure of economic progress (as we will, inevitably do) will be coming to terms with the fact that rampant consumerism and gross inefficiencies do not constitute 'growth'

</comment></comment><comment><USER4> Nothing stops you from doing this yourself.

Just don't expect the rest of us to appreciate being forced to do it.

<comment><USER5> We now theorize that on Easter Island, the societies that presided there destroyed their island's environment to such an extent that they themselves were essentially destroyed.

To prevent that from happening, it would have made no impact if a few individuals would have stopped the harmful actions. They would have had to change the whole culture of consumption, production, even religion. See where I'm going with this?

<comment><USER6> > See where I'm going with this?

Yes, you're constructing a "the end justifies the means" argument.

<comment><USER7> Lobbying for some change that's necessary to avoid a global scale catastrophe implies "the end justifies the means", thus should be rejected?

<comment><USER8> Depends on the nature of "something" and the value of "necessary". If somebody argued that to avoid global overpopulation and Malthusian catastrophe, we are to kill every 10th child born - you would probably reject this, even though the argument would be "it is necessary to avoid a global scale catastrophe".

So far all Malthusian predictions of global scale exhaustion reliably turned false and in most cases, laughably so, in hindsight. This teaches us that such claims should be taken with extreme skepticism and drastic measures proposed under these claims are most probably not justified.

This, of course, does not contradict the usability of technology (or non- technology means) for greater efficiency of energy use, conservation, etc. There's nothing wrong with recycling, reuse and energy saving. It just doesn't need to be turned to extremes under the slogans of future catastrophe that would never happen.

</comment></comment></comment></comment></comment><comment><USER9> I think its interesting how productivity increases have led to increased consumption instead of increased free time. Maybe this is partially because consumption is viewed as nobel in the sense that it's what causes the economy to grow.

Does anyone have any thoughts on a technology tax? If say you're fired because your boss hired a robot to do your job, your boss pays a percentage of his increase in profits as a tax which is redistributed to everyone - much like in Alaska how everyone gets a check for the oil that is pulled from the ground, what if everyone got a check for the technology pulled from our minds? Maybe this would encourage people to value technological growth over consumption growth.

<comment><USER6> > If say you're fired because your boss hired a robot to do your job,

You're not seeing the whole picture: Being replaced by a robot is just the final step in an extremely long sequence of productivity enhancements that being with using a shovel instead of your bare hands. Why should the tax hit robots but not a power drill? Or a fork-lift truck? A washing machine? Or a computer? (don't forget, as programmers, we are parties to one of the largest eradications of jobs in the history of mankind)

What you're really proposing is a tax on increasing efficiency, by a long shot the best and most easily understood kind of growth. Interestingly, with reference to the movement's goals, little frees up more resources for family, art and music than getting the same work done in half the time.

<comment><USER3> > What you're really proposing is a tax on increasing efficiency, by a long > shot the best and most easily understood kind of growth. Interestingly, with > reference to the movement's goals, little frees up more resources for > family, art and music than getting the same work done in half the time.

I think the real gripe with this is that, although automated production may be more efficient, it fosters greater wealth inequality.

As tools become more powerful, and come to replace rather than assist humans, those with existing wealth become yet more powerful. The evil factory owner can now produce their widgets five times faster, at half the cost, and they don't have an unruly workforce to rely on.

</comment></comment></comment><comment><USER10> It is worth repeating the main idea here: "Key to the concept of degrowth is that reducing consumption does not require individual martyring and a decrease in well-being. Rather, 'degrowthists' aim to maximize happiness and well-being through non-consumptive means—sharing work, consuming less, while devoting more time to art, music, family, culture and community."

<comment><USER11> That sounds like something people might say about socialism too.

We need only look at the Soviet Union to see how that turned out.

<comment><USER12> That really doesn't sound like the Soviet Union at all - which was obsessed with growth through centrally controlled 5 year plans.

One of the many reasons the Soviets failed is that they channeled a huge proportion of their national wealth into their military (fearing as they did an attach from NATO) and away from improving the living standards of their citizens.

</comment></comment></comment><comment><USER13> This is impossible because it will stop the investment loop: investment cannot exist in the economy which is contracting and is supposed to contract indefinitely, because average return on investment will be negative. This is why such conditions will never happen.

As for environmental concerns, huge successes by the Germans seems to prove that transition to renewable energy is possible, even with current or slightly better level of technology. This may take some 30-40 years for most developed countries, and about as much after that for the rest, but we seem to have that time given successes in development of shale gas, coalbed methane, and most recently, shale oil.

Germans are good example because if they are outliers given the conditions they have, they are outliers in negative sense: they don't have much of either renewable or non-renewable resources, they are rich and need to consume a lot of the both, and cannot afford having energy too pricey because their economy is based on industrial exports so they need to stay competitive. If they can do it, everyone can do it. Others mostly don't care so far, soon they will have to.

</comment><comment><USER14> I find this fascinating as I am thinking more about how companies acting as Tumors. Growth for the sake of growth is the symptom of cancer. Larger economies do enable human collaborative feats like going to the moon and finding ways to live healthy and longer lives but it's engine itself driven by the fuel (mass consumption) of greed and desire rather than curiosity and joy. All signals seems to indicate that it has gone too far. We have to come up with a sustainable way to create large economies.

<comment><USER4> The difference is that tumours don't have to solve economic calculation problems: companies do. As they reach the limits of that capability they become increasingly inefficient until they are supplanted by smaller, nimbler competitors.

... or propped up by governments. But then the analogy is even more broken.

</comment></comment><comment><USER15> After jacques_chester comment, I wonder (for everyone): what is you country, and is degrowth seen as something positive or negative in general in your country?

<comment><USER6> In Denmark and the UK, the narrative is appealing, not because of its merits but because it provides an alternative to austerity. It seems to be mostly utilized by the same hard-left that has always been more concerned with distributing wealth than creating it. In both countries, the main-stream left has long since realized that there is no alternative to reducing the deficit and bringing back growth.

<comment><USER3> > In both countries, the main-stream left has long since realized that there > is no alternative to reducing the deficit and bringing back growth.

Although behind the scenes this may be the case, the rhetoric remains.

In the UK we still have Labour bleating about the Conservative-Liberal Democrat coalition making spending cuts "too hard, too fast" when they are barely making a dent in the annual deficit.

</comment></comment></comment><comment><USER16> Maybe it's not so much growth vs degrowth as short-term vs long-term? A country like China that's pursuing a very aggressive short-term growth policy is obviously endangering some aspects of their future with pollution, corruption, etc.

I don't have a problem with pursuing growth, so much as focusing on the next few years (or the next election) to the exclusion of anything else.

<comment><USER4> Is long term growth qualitatively different from the integral of short term growth over the same period?

<comment><USER17> I think so.

On a several decades/century scale it's worthwhile to funnel at least a few percent of GDP into basic science research[1]. But, in any given quarter/year, it's almost certainly a net loss. The trick being that every few decades, you'll get nuclear power, the transistor, etc[2].

Or, as a 'local' example: non-trivial number theory had basically no benefit for centuries but humanity kept 'investing' resources into it - which a short term optimizer wouldn't. Then, cryptography came along and it suddenly 'paid' for the entire field a dozen times over.

[1]: Research is sort of like early stage VC - but with funds that pay out over 70 years instead of ~7.

[2]: I would love to write about _many_ more examples in much more depth, but will omit for the sake of brevity. I roughly feel like the newtonian mechanics was directly responsible for the industrial revolution, relativistic physics for the nuclear age, quantum mechanics for the computer age (with similar analogues in the biological sciences).

<comment><USER4> The example Carl Sagan gives is Maxwell's equations. They seemed pretty abstract at the time, but well ... Radio. Television. Fibre optics. Satellite communications.

That said -- these didn't happen all at once. And every technological upheaval, no matter how large it has been _in itself_ , has still appeared in the larger context to be only an incremental improvement.

</comment></comment></comment></comment><comment><USER18> Serious question:

How does a country that embraces 'degrowth' defend itself militarily from a country that is still working on the high production paradigm?

<comment><USER19> The same way France has always defended itself.

<comment><USER18> Not sure if you're being funny?

France has one of the highest rates of productivity per capita [0] and is the 5th highest military spender in the world [1].

[0] [http://en.wikipedia.org/wiki/List_of_countries_by_GDP_%28PPP...](http://en.wikipedia.org/wiki/List_of_countries_by_GDP_%28PPP%29_per_hour_worked) [1] [http://en.wikipedia.org/wiki/List_of_countries_by_military_e...](http://en.wikipedia.org/wiki/List_of_countries_by_military_expenditures)

<comment><USER20> I think it's a joke based on the fact that was a relatively rich county in the 20th Century and had a poor record on self-defence. France was actually considered to have the strongest military in Europe in the late 1930's, but it didn't pan out for them (bad management).

</comment></comment></comment></comment><comment><USER21> The fastest way to degrowth is creation of brain-computer interfaces that have realistic feel like in the matrix. Degrowthers should join the hacker movement in advancing that technology. The way to most quickly advance that technology is through computer vision technologies that allow the running of biotech experiments at an industrial scale. The key to computer vision is the application of machine learning (neural nets and random forests). The key to that is the creation of classifiers on image datasets on cloud computing infrastructure. Therefore, projects like microsoft kinect and google goggles in addition to vision guided industrial robots are the best degrowther strategies.

<comment><USER22> The fastest way to degrowth is [growth] ??

<comment><USER21> Focused growth. Instead of factories churning out designer handbags and pet food, have them churn out biotech experiments for brain-computer interfaces.</comment></comment></comment>


Rules of thumb for a 1x developer - <AUTHOR> https://muldoon.cloud/programming/2020/04/17/programming-rules-thumb.html <comment><USER2> "Rule 11: Which database technology to choose: Choose SQL when you need to do ad hoc queries and/or you need support for ACID and transactions. Otherwise choose no-SQL"

I think it should be the contrary: SQL by default, no-SQL if you have a specific need and know what you are doing.

<comment><USER3> To be completely frank, I'm seeing less and less reason to use traditional sql databases. MongoDB offers the ability to make sql queries and even has Acid transactions. Everything SQL can do, it does without slowing down when dealing with big data. The only thing it doesn't offer an efficient solution for is something SQL can't do either, and that's advanced search engine capabilities like Elasticsearch provides.

Some people will argue that PostGreSQL is better in certain ways, but the argument really always comes down to 2 factors. Are you going to hit the cost efficiency performance limits of traditional SQL servers, and do you require advanced searching capabilities like graph queries or synonym matching. Even if both answers are No, I'd still argue for Mongo because it makes it easier to distribute Acid compliant coppies of the data by region, providing backup redundancy as well as fast responses in multiple regions.

<comment><USER4> Riiiiiiightttttttt, because having well defined data is not useful at all.

<comment><USER5> You can have well defined data and use Mongo. Those two things are not related. I worked at a place that used Postgres and put an object w/ 11k unique paths in a single JSONB column with no schema or documentation whatsoever.

<comment><USER5> ... and this system was responsible for billing, and many other things....

<comment><USER6> and? That's not PGSQL fault, is the DB architect (or lack of) fault. You definitely can drive the safest car in a ditch, no?

<comment><USER5> That was my point right? It has nothing to do with the DB.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> I've been a developer for about 3 years now.

This is probably my own fault, but I feel pressured to be constantly doing _something_ towards programming. I feel like I should either be reading a book or starting a project.

I have 10+ programming books where I just finished reading one of them and I have way more unfinished projects than I could count.

It's reassuring to see the push-back against the 10x developer idea, I'm starting to feel less guilty now when I spend my free time NOT on programming.

Something that has also helped me out is picking a project to do, and ignoring everyone else's projects. I would always get pulled away with what I'm starting to work on because I see someone using a new technology or doing something unique. When I would see that I would change up my project because I felt it wasn't good enough or that it wouldn't make me a 10x developer. Now I'm just trying to focus on what makes me happy and what I find enjoyable to work on.

I want to ask though - the author works at Amazon and considers himself a 1x developer. What does that mean for everyone else who doesn't work at Amazon or a FAANG company? Is a 1x developer at a FAANG company a 10x developer elsewhere?

<comment><USER8> A 1x developer at one of the tier 1 tech companies is...just a 1x developer - doesn't really matter where you're at.

Being a multiplier is not about just being technically proficient. It's about enabling your whole team to be more productive, and help getting to the right decisions, instead of decisions that might cost your team or coworkers huge amounts of extra work long term.

<comment><USER7> > Being a multiplier is not about just being technically proficient. It's > about enabling your whole team to be more productive, and help getting to > the right decisions, instead of decisions that might cost your team or > coworkers huge amounts of extra work long term.

Thank you for this comment! I'll keep this in mind as I progress through my career. It's nice to know that it isn't just about being technical.

</comment></comment></comment><comment><USER9> "To replace out MediaWiki with a Java-based alternative (XWiki) ended up taking a total fo 24 dev-years over 4+ calendar years for the team, not counting the interruptions to pretty much every other team at Amazon as their pages were getting constantly migrated and un-migrated"

I would _love_ to hear more about this. I'm guessing that's a cost of at least $4M? How was this approved? How did they allow it to continue for _four years_?

<comment><USER10> I don't understand why are corporations obsessed with decommissioning wikis. When I was at Red Hat, they tried to decommission local country wiki in favor of their company-wide wiki (Mojo, absolute shit by the way). They tried for about 2 years, then finally somebody said "what the fuck are we doing" and the migration was stopped. I believe the banner "Decommissioning soon" still hangs there.

<comment><USER11> What happens is that different teams build out their own wikis , or come in via acquisition). The company then ends up with a dozen of them, and re-orgs occur and a single team now has two wikis, and people wonder why the information isn't centralized. Everyone agrees it will be great to have a singe company wide wiki and the project is born.

</comment></comment></comment><comment><USER12> > That's all that Agile means to me.

This is the most concise, honest summary of "agile" I've ever come across. Well put.

The amount of person-hours spent bikeshedding about various sundry "agile" procedural details is absolutely breathtaking. A perpetual, real-life Dilbert punchline taken seriously by armies of *Managers.

<comment><USER13> Well that's pretty naive. I've worked with some pretty good teams that wouldn't work any other way. I suspect you've only worked at places that abused agile as described here... [https://ronjeffries.com/articles/language- of-hatred/](https://ronjeffries.com/articles/language-of-hatred/)

<comment><USER12> No, I've worked in places where it works just fine.

The point is that, at the end of the day, it boils down elaborate processes to break things up into two-week chunks of work. That's it. That's the bit I thought was a concise, excellent summary.

Sometimes, for certain flavors of apps and tech and teams, that model works splendidly. Sometimes, it is silly administrative window dressing that is completely disconnected from the reality of what the team is doing. In my experience, it's usually the latter -- and the teams work just fine _in spite_ of the fact that everyone is pretending they are doing "scrum" or "agile".

I'd say what is naive is the belief that such a closely scripted, narrowly defined workflow is a one-sized-fits-all solution to optimizing teams under all circumstances and contexts.

<comment><USER13> "Elaborate processes" and "closely scripted, narrowly defined workflow" aren't adjectives I'd ever use for agile done well. And I've been doing it since we were allowed to call it eXtreme Programming. There's lots of "Dark Scrum" out there. Sounds like those are your experiences. They're not mine.

</comment></comment></comment></comment><comment><USER14> > Rule 20: When somebody says Agile, push for Kanban, not Scrum... ...Scrum > can easily mean that you'll get pressured to work extra hours to complete > something within that arbitary two-week horizon.

This is very true. I've worked for over 12 years in the bay area in different software engineering teams at startups and found that scrum just leads to burnout and developer unhappiness and encourages team members to just do the minimum 'slap it together till it works' solution without thinking long-term on codebase stability, architecture and maintainability. By far the best development process that leads to high developer happiness, engagement, productivity and empowers them to go the extra mile to go above and beyond, and produce work that acts as a force-multiplier across the team, is what the author describes here as 'Kanban', also known as eXtreme programming. Most people from Pivotal Labs or Carbon Five or from a startup that adopted their process would recognize what the author describes as 'Kanban'.

<comment><USER15> To be clear: XP and Kanban are different things. XP has prescribed engineering practices, most forcefully that development should be done via pair programming for continuous code review. Kanban prescribes no engineering practices and could be used in lots of non-engineering contexts (e.g., your marketing team could take all of their tasks, put them in a prioritized backlog, then track the progression of those tasks across Todo/Doing/Done/Blocked and that would still be Kanban). Kanban is great for teams in maintenance mode with a steady in/out of smaller tasks in their backlogs, but it's not great for helping your customers get an idea of when they might see a new product or feature.

I do find it odd that people describe Scrum as "leading to burnout" or a "death march", and I'm guessing most people who do either have not worked in waterfall IT projects that preceded widespread Agile or they're part of "Agile" teams that do waterfall development in two-week chunks with daily standups. (Maybe both.)

Scrum practiced well brings the essence of small-town democracy into the workplace. You have to work a late night the day before sprint release? You were in the room when the team agreed to the body of work that would be committed for delivery in this sprint. You just slapped it together until it works? You'll get to accommodate 0-point bugs in a future sprint, and perhaps you can have a conversation in your team's retrospective about why velocity went down that week. (Speaking of: how many other professions get to have a candid conversation with management about what's going well and not going well on a regular basis? Not many, it's a real privilege!) There are certainly deviations from this, but in my experience Scrum teams' problems are generally of their own making, and many of those problems are refined away over time as teams grow and better define their norms.

<comment><USER16> > You have to work a late night the day before sprint release? You were in the > room when the team agreed to the body of work that would be committed for > delivery in this sprint.

Fuck that. The fact that my estimate does not work out as expected should not be a reason to work late nights just to get it done.

That's exactly the death march that you were saying Scrum is not.

<comment><USER14> +1 A million times on this, you nailed it.

</comment></comment></comment></comment><comment><USER17> > And what I have found is that most – say, 90%, of what I learn at one job is > completely useless for the next one.

Then the problem isn't with what's being learned. The problem is that the author lacks a framework for generalizing and internalizing the lessons learned.

Letting 90% of lessons learned on the job go to waste later in life is going to lead to a very difficult career path.

Later...

> Compounding is a pretty important concept that shows up in compound > interest, in Moore's Law, all over the place. It's about virtuous cycles. > And so in the limited flexible time that I have, I think the rule of thumb > is to focus on things that could trigger a virtuous cycle.

In other words, focus on activities that can capture more value from the 90% of wasted lessons.

Writing, both publicly and privately, is an excellent way to do that. It seems the author may have an inkling but isn't saying it. Given there are only two posts on the blog, this could be the author's attempt to test the idea.

<comment><USER18> > Writing, both publicly and privately, is an excellent way to do that.

Is there a right way to go about this? This is something I need to start doing, personally.

<comment><USER19> There are only wrong ways to go about it, and you will only discover them by doing it.

</comment></comment></comment><comment><USER20> Rules of Thumb for a 1x Developer

During work hours stay away from:

* HN

* Facebook

* Twitter

* Reddit

* Any other thing constantly distracting you and taking away your attention from your job

Congratulations, you are now 3-10x developer.

<comment><USER21> > Congratulations, you are now 3-10x developer.

Congratulations. You are still getting paid the same.

Boosts in productivity need to come with boosts in pay, otherwise the logical thing to do is to scale back your effort to a point where the amount you get done matches the amount you get paid for.

<comment><USER22> I've never heard of a company that will offer to pay you more if you promise to be more productive in the future. What industry are you in?

All of my raises and promotions came from results that exceeded expectations.

<comment><USER21> There is a balance though. The company I work for is stable, but money is always tight. That means raises are few and far between.

Other factors balance that out and make it a reasonable place for me to work, but being aware of the fact that "exceeds expectations" does not lead to more money is important and I'm sure not unique to my situation.

I'm happy to go above and beyond, but I'm also aware that it's unlikely to be rewarded and take that into account in my decisions.

</comment></comment></comment></comment><comment><USER23> With rule #2, (knowledge not transferring), that's always a sign you're not working somewhere good, or you're in a role that will stunt your growth. You really should be able to transfer a lot of what you learn. If you're stuck with a bunch of proprietary gunk that does the same thing as open source, but worse, good engineering management knows to replace that stuff because it will inevitably drive talent away. Or at the very least rotate people through those roles. I know I've left jobs where I've been stuck maintaining legacy systems while the rest of the company moved on to open standards because if you do that for years it's like slow career suicide.

</comment><comment><USER24> Quite surprising take on the languages.

> When to use Python or Ruby

> Python and Ruby seem to me to be pretty similar in that they're scripting > languages and dynamically typed and seemed like the greatest thing in the > 00's. You use them when speed is more important than legibility or > debugging.

I'd say you pick them when productivity and time to market is important. I personally find dynamic languages far more legible (unless you're doing metaprogramming-heavy stuff).

> Haskell or Erlang maybe I would use if I were doing something that required > a very elegant or mathematical functional approach without a lot of business > logic.

I think it's a mistake to throw these two into the same bag. I'd say Haskell is functional and comes from academia. Erlang is concurrent (with functional aspects) and comes from engineering background. You'd want to pick Erlang if you want to build scalable backend systems.

> my guidelines for JS are:

> Try to push as much logic as possible to the server. If the front end > weren't super complex, I would consider something like Phoenix instead which > actually pushes everything to the server.

Phoenix is a web framework for Elixir and Elixir is a Ruby-like syntax on top of the amazing Erlang VM, so this kind of contradicts the suggestion above. Either way, Phoenix LiveView might be a game changer when it's applicable and for people who don't find the whole JS thing very exciting.

<comment><USER25> People overrate the elegance and readability of languages. You can write elegant and inelegant Java. I've seen python code that is totally unmaintainable and python code that's some of the most elegant out there. You can find Rails code that is some of the most indecipherable spaghetti out there despite Ruby being such an elegant language (the project had Fat Controllers, Fat Views and Fat Stored Procedures...yikes). There's a lot of elegant C code out there then there's C code where you don't wanna touch anything because you're not sure what anything does.

I think the general rule of thumb for languages is pick whichever language has the best community, learning resources and packages for your project.

For example R excels at analyzing data because of the wealth of packages from industry and academia for analyzing data and the tutorials dedicated to statistical analysis in R. Python excels at high performance data driven products because of the wealth of packages for ML, scientific computing, etc and the wealth of resources on doing these things in python.

The exception to this is JS and your point about Phoenix LiveView. Potentially it could be better to pick a single language for frontend and backend to limit context switching while developing frontend and backend.

I haven't used Clojure or Haskell yet so I don't know what they excel at. I also haven't dived into Erlang and Go enough to know which situations either is better for scalable backends.

<comment><USER26> > People overrate the elegance and readability of languages.

> The exception to this is JS

JavaScript is beautiful. You're crazy.

<comment><USER25> I think I was unclear. I meant that the exception to picking a language based on community, resources and modules are JS and Phoenix Liveview where there is an additional benefit of using a single language for frontend and backend. In these two examples you might forego using a separate language for frontend and backend (that could have a better community, resources or modules for what you are building) because you can use the same language for both (which offers the unique advantage of having to use and learn less tools for a fullstack app).

</comment></comment></comment></comment><comment><USER27> If you are a 10x developer, you should either angle to get 10x the money or dial it down for your own benefit. Don't let some company get free value out of you!

</comment><comment><USER28> I hate the notion of "10x developer".

It focuses on hiring the best person, rather than firing individuals who undermine the team. The reality is, there are some 1x developers, and some .5x developers. Even worse though are the -1x developers. So many times I see a corporate culture of firing = bad, so lets just try to find someone who is a "10x", when really all you need is to remove the people who cause more work for the organization.

Its our job as managers to accept that we hired someone who is ineffective, damaging the team and that OUR hiring process failed to catch that. Then to deal with them (training, firing) and iterate on the hiring process to prevent the issue going forward.

<comment><USER29> I knew two 10x developers at my previous job. One of them was humble and a great mentor and elevated everyone around him. One was a grump who made everyone around him feel stupid.

Imo toxicity is independent from productivity.

<comment><USER30> Same experience. I learned quite a bit simply by sitting next to an exceptionally good and exceptionally nice developer who was at least a decade older than the rest of the team and enjoyed helping others. He rarely got stressed even in crunch times and that put rest of the team at ease.

<comment><USER31> The simple idea of this being possible, and picturing the scene in my head, gave me a lot of hope. I'm tired of the atmosphere of fear in the office, and I'm tired of how I participate in it.

</comment></comment></comment></comment><comment><USER32> I don't think the author is a 1x programmer. He has learned the first secret of 10x programming. It's not about being a genius programmer. Its about being an efficiency expert and a problem solver. Soft skills play an outsized role here. I have seen immensely talented developers with hard skills for days manage to deliver nothing over long periods of time.

Learning that rules are guidelines not religious artifacts handed to us via burning bush is a big step. I can't tell you how many programmers I've seen hobble their own productivity by having overly aggressive code reviews, strict style guidelines, or requiring more testing than is necessary.

Being an outstanding software engineer is 99% knowing when to tenaciously stand your ground("storing state that way will not allow us to scale horizontally. It will save us a few hours now but in order to achieve our larger objectives will take 1000x the effort to unwind; we have to find another way") and when exerting control isn't helping("You can't put this simple, but incredibly important, time sensitive piece of software into production until it has been reviewed by our 6 committees, is re-written to use the companies globally enforced, yet questionably valuable style guideline, and has 113% code coverage")

<comment><USER33> He's working at amazon so perhaps their talent pool is a little better than the average non-coastal company.

</comment></comment><comment><USER34> This is cynical in a well-written way that matches my prejudices. I like it.

<comment><USER35> Didn't realize that it was already time for the annual HN slogan contest.

<comment><USER36> Almost spit out my coffee.

</comment></comment></comment><comment><USER37> This document provides, especially towards the end, some valuable opinions. The technology-advice is really bland or maybe overfitted to specific use cases.

<comment><USER38> Agreed. The general advice here is really useful. I am not clear on the benefit of the discussion on programming languages and specific tech though, that section seemed like an out of place admission of a lack of knowledge in an article that contained many useful tips.

</comment></comment><comment><USER39> I used to get called a 10x developer, I was also called a rockstar and a ninja and a 100x dev and every other compliment that was hip.

Then I hit 30. That type of talk stopped.

Then I hit 40. Now I will not be considered for any entry level, mid level, or senior level software dev job anywhere in the United States, despite being very desperate and willing to relocate for anything. Doesn't matter. Too old. I'm supposed to be doing something else by now.

Make a backup plan now.

<comment><USER40> I am almost 40, and I fully expect this to be my last software development job. Likewise, I've never had a negative performance review and am usually the top task-killer and bug-destroyer; but when recruiters call and find out I'm married with kids they can't seem to hang up fast enough.

I'm saving as much as I can. The end is nigh.

<comment><USER41> I don't understand why marriage or dependants would come up. If anything these two life changes forced me to take my career and profession a lot more seriously.

<comment><USER40> Any number of ways:

\- What are your hobbies?

\- What drives you?

\- Where do you see yourself in five years?

\- Would you be willing to work long hours often?

\- Can you work in the USA?

And so on.

There's so many questions that are legal to ask but for which an honest answer would reveal private information.

</comment></comment></comment></comment><comment><USER42> I was _very_ surprised to read

> 90%, of what I learn at one job is completely useless for the next one.

That has not been my experience at all (and I've had some pretty major job changes, including lawyer -> software developmer). If I had to put a number on it, I'd say more like 50% of what I've learned at each job is transferable.

How about everyone else? Closer to 10% or 50%?

<comment><USER43> I think there's a point of view component.

If you think of it is "Today I learned how to use $PROPRIETARY_AMAZON_TOOL to set up a new project which will use $PAT to deploy to a $PROPRIETARY_AMAZON_INTERNAL_CLOUD and sets everything up to $PA_MONITORING and $PA_ALERTING in my... etc. etc. etc., you get the idea, then yes, you will feel like what you "learned" is not transferrable.

On the other hand, if you look at it like "Today I learned some best practices for setting up a new industrial-strength projects through the particular manifestation of this tool, learned about setting up monitoring through the particular manifestation of this other tool,", etc. etc., then even though you may have learned via particular local tools, you also learned a lot of stuff that may be useful later.

The question is, let's say you did change jobs and had to learn some new set of tools. Will you learn them faster than you learned the first set of tools? Will you find a new perspective on the issues from learning the new set of tools? The answer should generally be yes. This is broadly speaking why I expect a 5-year veteran to pick things up faster than a fresh grad; OK, sure, you've never "used git", but I expect you've used source control somewhere. You may not "know React", but I expect you to have used something similar enough that you just have to learn React _qua_ React and are not also learning about cookies and the basics of the DOM, etc.

Pretty much the first professional thing I ever did was writing what we would today call a "static site generator" in a tool called Frontier, in its custom programming language, more or less from scratch. On the one hand, completely useless skill, Frontier has been dead for over a decade and was fairly zombie- ish for a good 5-8 years before that. On the other hand... the HTML basics I learned are still mostly good (I think it's fair to say at this point my frameset tricks & skills are not that useful anymore...), and the general skill of knowing how to write a static site generator is almost even low-level _trendy_ right now, even though I would have to write it in some other language, of course.

I dunno what the exact transfer number is. 90% seems high, certainly, but 10% way too low. There's only a small number of tools that are so bad that while working with them, you learn almost nothing about the problem space you are working in because the quirks of the tool completely dominate, and even then I'd submit a lot of it is still attitude.

</comment></comment><comment><USER44> >One great example of this is the debacle of the Amazon internal wiki migration. Back in 2015, the Amazon InfoSec team banned PHP at the company.

Oof. To be fair, Java is probably way easier to code review.

<comment><USER45> Much depends on the Java. Having spent a lot of time on personal projects using the language, it doesn't deserve its reputation -- Java may 'require' an IDE to avoid spending too much time on boilerplate, but modern Java is a good language and the programming experience once you do have that IDE is one of the best, most effective I know.

At the same time, it's absolutely possible for codebases to become "enterprisey" to the point where even the tiniest change takes weeks. Some of the libraries out there use absolutely horrifying patterns.

If you're just coding for yourself, you can avoid those. In a company maybe not so much, and even though the company would be better off avoiding them, maybe they have old code remaining from when such things were considered _good_.

<comment><USER46> People really, really overrate the importance of a language. Java as a language is quite decent, but definitely not great.

What makes it great is everything around it - from second to none JVM, range of state-of-the-art developer tools to the best library ecosystem.

</comment></comment></comment><comment><USER47> > most – say, 90%, of what I learn at one job is completely useless for the > next one

This is the most surprising claim, to me. I would have flipped the ratios. Even the most radically different jobs I've had shared more than 10%.

90% of the _facts_ that my boss tells me are useless for the next job, true, but 90% of what I _learn_ are not the facts which are told to me.

</comment><comment><USER48> My takeaway from this: 1) don't overthink a problem 2) observe norms 3) meet expectations. In other words, simply be reliable.

</comment><comment><USER49> >Internal deadline: This is a target internal to the team that will not affect anybody outside of the team.

Never in my life have I witnessed an internal deadline. If it came out of your mouth and someone heard it, well done, you've got yourself a soft-deadline. If you haven't said it out loud, it's an expected completion date, not a deadline.

</comment><comment><USER50> > I think of Go, Rust, Haskell, Erlang, Clojure, Kotlin, Scala as more > hardcore languages.

I can tell about Scala: it can be insane hardcore if you want, but it can also be just "a much better Java" as easily - the weird parts are easy to avoid and the normal parts work better. Unless you are a Java veteran and also plan to hire more developers, using Scala instead of Java will save you much time and effort.

And Kotlin is, by design, kind of Scala minus the hardcore.

<comment><USER51> The problem with Scala is the same as the problem with Lisp. It's too flexible and it ends up having a bunch of dialects. Sure you can only use a subset, but that doesn't fix the problem that the fragmentation makes it hard to find libraries and code examples that only use the subset of Scala you're comfortable with.

</comment></comment><comment><USER52> > PHP is banned at Amazon due to security reasons, but its successor, Hack, > runs a lot of..

Just to be clear, Hack is not PHP's successor. Hack is a fork of PHP developed by Facebook. Hack will not overtake PHP any time soon.

PHP has had security issues in the past. Sure you can do stupid things with it if you want, but modern PHP is security conscious out of the box. Frameworks like Laravel make great default choices about security concerns.

<comment><USER53> A small question. Is PHP still a preferred platform for any sort of complex web development?

I have never even looked at the php site or docs, but I am curious.

In this day and age, is there a subset of Apps that PHP is suited for?

<comment><USER46> Traditional (non-SPA) web apps is where PHP is quite strong.

Also depends on the team, if you have a PHP team and it's a web project, you probably want to use PHP.

<comment><USER54> That's the problem right? Nobody starts new non-SPA web app projects anymore.

<comment><USER53> There are many new projects that involve Django / Drupal etc.

I myself have spent a lot of time weighing in the pro's and cons of SPA vs. Non-SPA for a recent project.

It's not like _all_ new projects are SPAs.

</comment></comment></comment></comment></comment><comment><USER55> Kudos for the open and honest assessment, I enjoyed reading it. Some feedback for your journey: Drop the focus on languages. Choose one (popular) language and focus on understanding it well. The best thing you can do, is find some open source project with high quality code in that language, and study it. Slowly, how long it takes does not matter. The end result is you will pick up best practices and styles you did not know exist. Concomitantly, study a few frameworks in your chosen language. Ex: If you select python and are doing web development, learn how Django and Flask work. Learn how the requests library or a forms library works. By reading good code, and studying frameworks and libraries that solve peoples real problems, you will build a foundation for how to put together higher quality and longer lasting code. That will not only make you better as a programmer, and better in your chosen language, but you'll start to find that a substantial portion of what you learn will start to transfer.

<comment><USER56> > Drop the focus on languages. Choose one (popular) language and focus on > understanding it well

While I understand this advice, your mileage might vary. I had the exactly opposite approach and did learn a ton of different languages, on the end making it my area of expertise as a compiler developer and language designer. Of course that's niche, but knowing only one language will eventually become a blocking point for every developer, especially in the modern world.

</comment></comment><comment><USER57> Think of this essay as a barbell, in the investment sense of the word. The beginning and the end of it have some really good insights that can be generalized to a lot of technical / development work.

The middle of the essay (Rules 4-16) are useful observations from Mickey's experience. (I don't know him; I am just trying to relate this paragraph of comments to his experience more explicitly.) This is not a bad thing.

If you are a 1x developer yourself who is looking to improve, I think you want to read treatises like this and try to understand your fellow developer's perspective.

Only truly brilliant developers can give generalized language and database platform advice. The other people who give valuable advice at this level are not developers, they are technology evangelists who have a track record of success helping real developers.

</comment><comment><USER58> > #1 Rules are good

Only when combined with "Rules are made to be broken". Nothing is worse than taking an arbitrary set of rules and turning it into a cult religion.

Other than that and some of the programming language rules (such an opinionated topic) a rare, level headed treatment. Bookmarked for future quotation.

</comment><comment><USER59> I'm somewhat perturbed that the entirety of the "DevOps" section is advice to get an SRE on your team because an SRE's job is to "be online after hours".

That's an incredibly dismissive and reductive perspective on the expertise and insight that an SRE (or any ops staff) could bring to a project, and it sounds like this person--or maybe their entire team--is doing a really bad job of owning their own junk.

I'll make a note to be extra wary of looking into any SRE jobs at Amazon if this is how they treat those positions.

<comment><USER60> This is indeed an incredibly dismissive view, only seeing the SRE as the poor soul you offload responsibility of things running well in production, despite the fact he is likely to have far less insight on what might go wrong and means to fix things.

Being basically in this position (but in a large follow-the-sun team, so I'm fortunate enough to not be paged at night), I can only underline the deep frustration such views can generate. Being paged every 10 minutes, being asked to fix things you have no control over, getting answers like "what? the server is overloaded? it's an infrastructure issue, not a bug in our code" and seeing developers cry when they get a ticket a day, when at the same time each SREs in the team is receiving a dozen, it can lead to some resentment.

A saner approach is to have the SRE as the first line to filter bugs/alerts/tickets out, but being able to call a developer if required. The SRE can also be an active team member with more insight on production constrains and pain points and maybe system architecture recommendations for the whole team. Also, in my opinion, developers should be an active part of running things in production, otherwise the whole dev team can lose touch with reality and lose sight on how well or not things are actually running.

</comment></comment><comment><USER61> God must love us 1x-ers because He made so many of us!

</comment><comment><USER62> This article really puts me off working for Amazon.

<comment><USER63> I only read the start. I'm not sure what I make of someone going from zero to Amazon. Is that normal?

<comment><USER62> Amazon recruit huge numbers of graduates, so obviously that's a yes. I think their graduate roles pay quite well too.

But if this article is to be believed, they also do things like using 15 different languages on the tech stack (16 to choose from minus PHP because it's banned) and give you the idea that estimates are worthless. If your workplace is doing things like that it's a _very_ bad sign in my opinion.

<comment><USER64> > they also do things like using 15 different languages on the tech stack

Teams have a lot of flexibility to choose the best tool for the job. It's not surprising that you'd have those options if you're tackling everything from UAV avionics to distributed systems to facial recognition.

<comment><USER62> _It 's not surprising that you'd have those options if you're tackling everything from UAV avionics to distributed systems to facial recognition._

Amazon _as a company_ might use them all, but no Amazon team should be choosing between them all (well, they do in so far as you can immediately rule out lots of unsuitable languages for most projects). This guy has worked on two teams so far and appears to be suggesting he's made choices between _15_ languages already. That either means the teams he's been on have used _wild_ stacks with endless choice (a reason not to work there) or that he's not correct about the extent of choice he had (and if someone has 5 years at a company and they still don't know that's another reason not to work there).

</comment></comment></comment></comment></comment><comment><USER65> > Rule 20: When somebody says Agile, push for Kanban, not Scrum

From my experience, scrum is better. The idea is that you can measure progress and you can learn from mistakes with scrum.

Kanban doesn't help in that regard.

Also, a good scrum master will tell you some things:

\- a successful sprint is one in which not all stories were finished, because the goal was ambitious

\- do not sweat over spill-overs; they happen all the time, it's not the end of the world as long as you work 8h/day really focused and give your best

I know that in the US you got modern slavery with insame working and commuting hours, but life is decent in places like Europe.

</comment><comment><USER66> > Try to push as much logic as possible to the server. If the front end > weren't super complex, I would consider something like Phoenix instead which > actually pushes everything to the server.

Sometimes you don't have or don't want a server, but still want to avoid the issue of wedding business logic to the UI.

With web apps my strategy is to treat business logic as a separate library housed in the same project. I'll have a "SomeBusiness" directory and just import it across the project like I would a third party library.

</comment><comment><USER67> > At first it was pretty simple, but then we got a lot of new frontend > requirements and in no time, managing the front-end state was a total > nightmare

If there's one thing I envy backend developers it's the fact that they don't receive even half the requirement changes the front-end does.

But I would refrain from pushing as much logic to the server as possible - it's never the better experience for most users in comparison to striking a balance between having it all on the server vs the client.

</comment><comment><USER68> Maybe I'm being naive but I'm privately nursing this hope that at least for devops / SRE roles people do want folks with plenty of operational experience? I mean I still expect they'd want to see someone keeping up with tech stacks and facile in a modern language or two so the interviewee can fix issues and contribute enhancements but still is a depth of experience at some point really a hindrance rather than a help?

</comment><comment><USER69> You become more productive by delegating work to the computer.

The better you are at delegating work to the computer, the more productive you will be.

Algorithms are elegant, data is not. If you are not careful, then data will leak into your program and you will end up with special cases for everything.

When this happens, your job becomes a glorified data entry job.

But you can be smarter than that and create abstractions over data that are reusable. And most likely that will involve types too.

</comment><comment><USER70> I'm not sure how I should be reading the article so maybe it's going over my head.

> Rule 10: When to make a microservice

> I would use a microservice when I have a relatively small and simple chunk > of code that needs to run every once in a while.

Isn't this wrong? There's no reason a microservice should just run once in a while. It also creates a lot of complexity for a simple chunk of code.

<comment><USER71> Most of this article could be ripped to shreds based on its accuracy. But that isn't the point - he has developed a set of rules and guidance that work for your average developer just slinging code in an enterprise. And while yes, almost everything he says is "wrong" if we push the details... I can see that they are all "close enough" to build a workable framework for your basic 9-5 1x dev.

<comment><USER72> > almost everything he says is "wrong" if we push the details

Author here. Part of the point was to expose my ignorance and get people to rip it to shreds. So have at it if you want. I've actually learned a good amount so far using this method.

</comment></comment></comment><comment><USER73> Rule 14: When to Write an End-toEnd Test

4\. When your spacecraft needs to get the correct mission elapsed time from the launch vehicle.

[https://arstechnica.com/science/2020/02/boeing- acknowledges-...](https://arstechnica.com/science/2020/02/boeing-acknowledges- gaps-in-its-starliner-software-testing/)

</comment><comment><USER74> Not sure I entirely agree on rule 18. My current team probably cares about estimation more than any previous one I've been on, and it's functioned more to keep engineers aware of prioritization and what is blocking. The team leads have definitely made it a point of emphasis to not put pressure on finishing sprint tickets, though.

</comment><comment><USER75> A slight point on Erlang:

Erlang is good on business logic and not really good on making something "mathematically nice". It is more in the same place than the one you give to Go/Rust. Low latency good performance and great reliability (these things are linked) for web is a classic use of erlang or elixir.

</comment><comment><USER76> Erlang (and elixir) are very unfairly bunched with Haskell since they are both functional languages; in practice they are functional in form and in the large, but they make compromises which really make them "a working person's language", not something to live in the ivory tower.

</comment><comment><USER77> This notion that during non working hours I should still be working on side projects is absurd.

</comment><comment><USER78> >>> To replace out MediaWiki with a Java-based alternative (XWiki) ended up taking a total fo 24 dev-years over 4+ calendar years for the team

He can call himself 1x, but if he can stop just 1 colossal failure like that he can easily become 10x.

</comment><comment><USER79> Heck, writing this post is enough to be at least a 1.1x dev. I don't subscribe to the whole "x developer" thing, but this is an amazing list

</comment><comment><USER80> I think nothing is truer than rule 16.

"If you delegate all your IT security to the InfoSec, they will come up with Draconian rules"

</comment><comment><USER81> > front end [..] consider something like Phoenix

install = install Erlang + install Elixir + install Phoenix

Well.. I'll stick to Node + vanilla JS

<comment><USER82> Installing something is easy, learning how to write Elixir/Phoenix/maybe Erlang is the hard part.

Don't ever let "installation" prevent you from trying something, on Mac it's literally "brew install elixir" followed by a command to install phoenix framework.

<comment><USER81> You are right and that is what I meant.

Sometimes though installation is a real pain. (For ex. OCaml/OPAM on Debian)

</comment></comment></comment><comment><USER83> I enjoyed reading this, although I should note that I agreed with the non- technical advice way more than the technical.

</comment><comment><USER84> I'm only a 3x developer but I'm still _hardcore_.

</comment><comment><USER85> > I would use a microservice when I have a relatively small and simple chunk > of code that needs to run every once in a while.

Is this a joke? Why write such nonsense when you must know you don't know anything about the subject?

</comment><comment><USER86> There is so much that is wrong with this.

Follow this advise only if you are currently employed and your employment is extremely safe because your employer is deemed essential or because they are financial strong in the current economy. For everybody else very carefully consider why an employer should hire you when the current economy is failing, programmers generally are very expensive and add very little value to the employer's revenue, and why you are a better value than the other 1000 developers that were just laid off. The economy is never going to be the same and the common suspicion moving forward is that software hiring/practice will also change to compensate.

The article opens with having kids and so they cannot work more than 8 hours a day in a specified time slot. This is an absence of ambition and nothing else. Work-life balance takes some figuring out, which isn't avoidance. I have two white-collar careers in unrelated industries and kids. I have time for both jobs, coding on the side, spending time with my kids, helping my wife prepare dinner, and so forth. I am not unique with this regard.

The bit about _How to do Javascript_ is really bad advise. This is largely the story of my career in the corporate world as a JavaScript developer. The employer is mostly a Java shop because Java developers are easy to find since they are effectively mass-produced by universities. The Java developers have absolutely no idea what to do with any aspect of web technologies aside from Spring MVC. JavaScript is required by the business, so the Java developer fake it until they make it. They still have no idea what they are doing then give up and require a framework. Epic fail. Any other industry would call that an ethics violation, negligence, and that path would land you in a law suit or possibly in jail depending upon the product/industry.

> So we went with vanilla JQuery.

That makes me cry. The programming section is followed by a section on testing that almost makes me angry. Many of the use cases provided for writing tests explicitly mention low confidence on the part of the developer. Horrible advice. The things to test are features and use cases. The software does all that it promises or it doesn't and there should be enough automation to prove that. How you go about that depends upon the product.

The security speaks like somebody who has absolutely no idea what security is. When you have absolutely no idea what security is or why the company would spend so much money on it I too would think everything about it is draconian and worthless. So many software developers seem to think they are well versed in security despite having no such experience, education, practice, interest, or credibility and I have never understood why.

<comment><USER87> > programmers generally are very expensive and add very little value to the > employer's revenue

Then either they are very bad at their job or working at a very bad company. Software companies have some of the highest revenue per employee numbers, compared to other industries.

> The article opens with having kids and so they cannot work more than 8 hours > a day in a specified time slot. This is an absence of ambition and nothing > else.

Many developers who work 8 hours a day accomplish more than many other developers who work 12 hours a day.

<comment><USER86> Most developers don't work for software companies.

</comment></comment></comment><comment><USER88> As he said: He's a 1x developer.

</comment><comment><USER89> I would like this guy as a colleague.

</comment><comment><USER90> This must be written by a developers with only very little experience.

Generally very shallow advice and poor or no discussion on why.

<comment><USER74> Ironically this comment is quite shallow and lacks any contribution to discussion

</comment></comment><comment><USER91> Rules of thumb for a 1x developer: Stop with the 1x/10x bullshit and quit basing your self-worth on your ability to provide for an employer.

Fuck sake.

<comment><USER27> it's capitalist hypnosis

</comment></comment><comment><USER4> "Rule 5: When to use Python or Ruby Python and Ruby seem to me to be pretty similar in that they're scripting languages and dynamically typed and seemed like the greatest thing in the 00's. You use them when speed is more important than legibility or debugging. And then Python for ML/AI applications."

Eh? Speed? What kind of speed? Developer speed? Code speed?

Why is legibility in Python/Ruby bad? Bad compared to what?

Why is debugging in Python/Ruby bad? Bad compared to what?

Frankly...this feels like a 0.5x article to me

<comment><USER72> OP here. I know that these rules of thumb gloss over some of the details, and it's this kind of ruthless criticism that I wanted to invite with posting this :)

I'm coming from the perspective of a tech giant, where there are thousands (tens of thousands) of services, and it's often a huge challenge to trace the flow of data through any given system or API and pin down the cause of production issues.

The static typing with Java gives us a lot more guarantees about the data flowing through systems, compared to Python. If I want to inspect some code or debug a production issue, static typing gives me a lot of guardrails. I can be sure that data coming in is of a particular shape, that null constraints are met, etc. Whereas (from what I can tell) it takes a lot of extra work (and more possibility of missing something) to do the same with Python or Ruby. But I haven't ever built a Python or Node service or whatever.

That's what I meant by legibility and debugging speed.

If you define legibility as "can understand the purpose of the code," I do think that Python can be way more legible since you've got so much less boilerplate.

</comment></comment><comment><USER92> This is poorly titled. A '1x developer' is by definition an average developer. The page is mostly listing basic knowledge that any developer, even a very junior one, should already have. If you aren't aware of the relative strengths and weaknesses of Java, C, and Python, you aren't a 1x developer, you're a trainee.

Anyone know of any better articles truly targeted at '1x' developers? (This isn't snark, it's an invitation.)

<comment><USER93> The 1x / 10x memes need to die in my opinion.

<comment><USER92> Agreed. _1x_ should be a synonym for _ordinary_ , but as we're seeing here, its meaning had drifted to refer to especially unskilled developers.</comment></comment></comment>


Falcon Heavy Demonstration Mission [pdf] - <AUTHOR> http://www.spacex.com/sites/spacex/files/falconheavypresskit_v1.pdf <comment><USER2> I saw the video animation of the Tesla separating from the second stage. At that point, the car no longer has thrust, so I'm assuming they've calculated the thrust to be just enough to reach Mars and to be able to fall into orbit. To quote the movie Apollo 13, "we've just put Isaac Newton in the driver's seat". I dearly hope that Musk and team have been referring to the "dummy" in the driver's seat of the Tesla as Isaac.

<comment><USER3> They aren't aiming for Mars orbit. As far as I can tell, they aren't even aiming to come close to Mars. Instead (as far as I can tell) they are aiming to come close to the orbit of Mars, i.e. where Mars will be in 4 or 5 months.

<comment><USER4> So basically they're just throwing a car into space.

<comment><USER5> Into deep space. This will be SpaceX's first flight beyond Earth orbit.

<comment><USER6> It will be the first commercial space flight beyond Earth orbit

</comment></comment></comment></comment></comment><comment><USER7> Here's a to-scale graph of the path each core/stage takes:

[https://imgur.com/a/XvPXG](https://imgur.com/a/XvPXG)

</comment><comment><AUTHOR> [http://www.spacex.com/webcast](http://www.spacex.com/webcast)

<comment><USER8> Did it get delayed? YouTube channel now says going live in another 2 hours

<comment><USER9> It's currently delayed until about an hour before the launch window closes, and they are hoping for the winds to die down. looks unlikely that they will launch today.

EDIT: nevermind fuel is being loaded and the "holy mouse click" has happened.

<comment><USER10> When is the next window?

<comment><USER11> Tomorrow, same times (13:30-16:00 EST, I believe, I'm in the UK, so it's 18:30-21:00, that I do know!)

</comment></comment></comment></comment></comment><comment><USER12> This will be a historic flight. It will be interesting regardless the outcome XD

27 engines!

"When Falcon Heavy lifts off in 2018, it will be the most powerful operational rocket in the world by a factor of two"

<comment><USER9> the most powerful operational rocket, but not the most powerful ever. I believe the Saturn V was more powerful.

<comment><USER13> Yes, they say in the same PDF:

> Only the Saturn V moon rocket, last flown in 1973, delivered more payload to > orbit.

</comment></comment></comment><comment><USER14> Just got word from a friend that all SpaceX employee names are etched on the Tesla roadster. So either they will orbit indefinitely around the sun or blow up spectacularly.

</comment><comment><USER6> They have just started fueling the rocket. It seems the launch may happen today...

[https://twitter.com/ChrisG_NSF](https://twitter.com/ChrisG_NSF)

</comment><comment><USER15> What a time to be alive</comment>


The 10x developer is not a myth - <AUTHOR> http://brikis98.blogspot.com/2013/09/the-10x-developer-is-not-myth.html

<comment><USER2> My problem with the notion of the 10x developer is that I've never seen a reasonable study into what a 1x developer is. An order of magnitude gap in productivity between the best and the worst is a massive understatement. I've worked with programmers with net-negative or zero productivity, and being ten times more productive than that is trivial. Thus, the real question is whether or not the people who are a tenth as productive as the very best developers happen to be average, and to answer that we'd first need a much better idea of what the "average" developer is.

</comment><comment><USER3> There's a bit of a difference between science, where you are trying to find insight on unanswered questions, and engineering, where the problem space is usually well understood. In the former a single brilliant individual can have a huge impact, whereas in engineering it is usually teams that do so. My problem with the "rockstar developer" idea is not so much that it is incorrect, it is that it places the emphasis on the individual over the team, which is the real unit of productivity.

</comment><comment><USER4> "Star" athletes are an interesting example. Are they 10x better than the average professional athlete? Well no, probably not. Pick whichever objective statistical measure you like, and you'll probably find that the top five players in the world are maybe 2-3x better than the average pro.

Similarly, it's trivial to find thousands of guitarists on YouTube with enormous technical ability, who will never become famous.

I'd suggest that the top 10-20% of developers are actually quite good, and being obsessed with the top 0.01% isn't very useful.

<comment><AUTHOR> First of all, some star athletes are statistically _far more_ than 10x better than the average. For example, the average NHL player scores less than 50 goals in his career [1] whereas Gretzky scored 894 [2] and Mario Lemieux scored 690 [3]. And that doesn't even count their assists, leadership, defense, name recognition (bringing in fans), etc. And I'm not even comparing these guys to other pro hockey players, such as the minor leagues and leagues outside of the US.

However, not all sports have "points" that scale the same way, so the 10x number is not as easy to apply. For example, Usain Bolt is not literally 10 times faster than the average professional sprinter; his best 100m is 9.58 [4], where as any moderately fit male can easily hit sub 20 seconds, and I believe any professional sprinter will go under 11 seconds. Nevertheless, I'd guess that in the 100m sprint, a difference of 1 or 2 seconds represents an order of magnitude (or two) difference in ability, even if it's only 10-20% of the time. What kind of odds would you give him in a race against an "average professional"? 10:1? 100:1? 1000:1? Usain is roughly as far above other pro sprinters as Gretzky and Lemieux were against other pro hockey players.

I'd also mention that "fame" is a bit of an x-factor. The world is not a perfect meritocracy and there is so much luck and so many external factors that go into being famous that it's not necessarily true that only famous scientists/musicians/writers are the only ones who are 10x. Of course, the famous folks are the only ones I can reasonably use as examples, and fame likely correlates with talent, though that talent may just be at being famous :)

[1] [http://www.quanthockey.com/Distributions/CareerGoals.php](http://www.quanthockey.com/Distributions/CareerGoals.php) [2] [http://www.nhl.com/ice/player.htm?id=8447400](http://www.nhl.com/ice/player.htm?id=8447400) [3] [http://www.nhl.com/ice/player.htm?id=8448782](http://www.nhl.com/ice/player.htm?id=8448782) [4] [http://en.wikipedia.org/wiki/Men's_100_metres_world_record_p...](http://en.wikipedia.org/wiki/Men's_100_metres_world_record_progression)

<comment><USER5> > the average NHL player scores less than 50 goals in his career [1] whereas > Gretzky scored 894 [2] and Mario Lemieux scored 690 [3]

But what are the numbers per season? If Gretzky had a career ending injury at the end of his first season he still would have been better than a mediocre player, even though an average player could play for years and rack up more in a career than the best could in a single season. My point is did players like Gretzky and Lemieux score ten times as many goals per season than the average player?

I'll assume I'm an average engineer (since statistically speaking this is the most likely case), it blows my mind to think there's a large number of people out there who in just a few hours could knock out everything I spent all of last week on. (I'm not saying 10x devs don't exist, I just think they are very few and far between, the NHL afterall has only had one Gretzky in its entire history)

<comment><AUTHOR> Actually, in the case of Gretzky and Lemieux, I believe they did average ~10x more points (and other contributions) per season than the average player. Also, don't forget that the NHL is just the best of the best; there are many hockey players that are "pros" but never make it to the NHL. When you factor them in, players like Gretzky may be several orders of magnitude better than average.

>> it blows my mind to think there's a large number of people out there who in just a few hours could knock out everything I spent all of last week on.

First of all, as I wrote in the post, 10x programmers are rare. There isn't a "large number" of them.

Second, it's not about producing more lines of code per minute or per week. It's about producing the maximum value (for lack of a better word) in a time period by making good decisions.

I'm not a 10x programmer and the results on my own work week are pretty obvious: when I look at it closely, I realize that I spend a lot of time dealing previous mistakes. I lose days because I made a solution that's too tightly coupled and it's hard to adapt the code to a new situation; I didn't add enough tests and waste lots of time fixing regressions; I didn't add enough documentation and can't remember why I made certain decisions; I've created designs that don't scale and need to be replaced entirely; and so on. Since it's harder to read code than to write it[1] and since the cost of fixing defects increases dramatically later in the software process[2], these bad decisions eat up an enormous amount of time.

However, as I learn more, I've noticed that I spend a much higher proportion of my time solving the "real" business problem instead of dealing with previous mistakes. In other words, I'm becoming dramatically more productive than I used to be, not because I'm typing faster, but because I'm avoiding/reducing entire branches of work that used to eat up my time.

These sorts of effects multiply: for the 10x programmer, the gain in productivity can be huge and they will be able to get an order of magnitude more done than the average coder.

* [1] [http://www.joelonsoftware.com/articles/fog0000000069.html](http://www.joelonsoftware.com/articles/fog0000000069.html) * [2] [http://en.wikipedia.org/wiki/Software_testing#Economics](http://en.wikipedia.org/wiki/Software_testing#Economics)

<comment><USER6> That's great and all but Gretzky was a center and so comparing his scoring against "average NHL players" is ludicrous.

This is not to claim that Gretzky is not "The Greatest" but: 1.5x Mark Messier(center) 1.5x Gordie Howe(right wing) 1.5x Ron Francis (center) ...

When we consider p/g Gretzky has a 1.98 (great!) but the 250th on the list has .7 p/g, which is a 2.8x ratio.

10x is imo simply a silly label that doesn't actually apply IRL but is great at ego-stroking.

<comment><AUTHOR> 250th on the list of all time NHLers? That's still a __tiny __percentage of all players that have every played (~1500 /year, obviously with some overlap from year to year). And that's only counting those in the NHL; there are many hockey "pros" who could only dream of making the NHL. Factor them in and the Gretzky performance is even more remarkable.

And you're only looking at points scored. How does a star's leadership affect their team? How did their mere presence affect the other team's entire strategy? How many seats does a star fill in the stadium every time they played? How many jerseys and other merchandise did they sell? Hockey, like software, is a business and I'd be that someone like Gretzky brings in an order of magnitude more money than an "average" hockey pro.

Denying the possibility that there could be someone 10x better than you is the real ego stroking. I _know_ there are developers an order of magnitude better than me. I find that inspiring, as it gives me something to work for every day.

<comment><USER6> Just saying, if 250th of all-time are about half/a third the p/g of Gretzky, I find the 10x label lacking. Comparing him via pts scored to goalies and defense is questionable at best.

<comment><AUTHOR> Re-read my reply above. You're comparing a fraction of Gretzky's contribution to a fraction of all the professional hockey players, even if you only look at forwards. Even then, he ends up 2-3x better than this already elite group.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> As I have pointed out before I have seen on first hand the difference between someone who is great and someone who is filling out the blanks. This is from a few years ago:

The "10x" consultant would delete hundreds of lines of code and keep the functionality. He would rewrite things and make them simpler. And in between he was helping the rest of us, explain architecture and generally make sure we were able to follow.

On the other hand I have seen other consultants, who were definitely smart[1], who would still do things like:

Use tiles (a templating framework for java/struts) to implement authorization. (Cleaning up this fell on me. : )

Add style tags to the body of the page (once the designer found and fixed this it solved all the perceived performance problems we had.)

[1]: If you had seen that code you would have agreed. It was some kind of weird artwork :-/ It worked perfect but every little change took full concentration, a significant amount of time and added to templates spanning hundreds of loc.

</comment><comment><USER8> I'll save everyone the trouble.

"Yeah it is!" "No it isn't!" "Yeah it is!" "No it isn't!"

I do like your other article about converting imperative list processing code into functional style, though. [http://brikis98.blogspot.com/2013/05/10-recipes-for- turning-...](http://brikis98.blogspot.com/2013/05/10-recipes-for-turning- imperative-java.html)

</comment><comment><USER9> One of the skills, I think, of being a 10x developer is picking the right tool for the job--picking a language and level of abstraction that will as cleanly and simply solve the task at hand.

It takes a good amount of experience and knowledge to know when to, for example, prefer assembly to C to C++ to Bash to Ruby to Prolog--not only that experience and knowledge, but the wisdom to see how that choice affects the other people on your team or future people maintaining the code and environment.

(This is an area in which I wish I was further developed.)</comment>