The Happy Demise of the 10X Engineer - <AUTHOR> http://a16z.com/2014/07/30/the-happy-demise-of-the-10x-engineer/ <comment><USER4> This article is wildly off base, _particularly_ when you look at the examples the article cites.

WhatsApp was able to scale to so many users while keeping the engineering team small precisely because they hired _great_ engineers who wrote an extremely efficient system in Erlang. (Does he think commodity coders know Erlang? Really!?) They heavily tuned their architecture and built efficient paradigms which kept developer productivity & performance from degrading as their user base grew. [1] Commodity engineers don't write that sort of code.

Yes, we increasingly have tools which allow mediocre coders to get stuff done. (For example, Ruby on Rails.) But the inevitable byproduct of letting mediocre coders loose on a stack they only partially understand is a mess of spaghetti code which takes even more developers to maintain. This is already what you see with non-tech corporations who employ dozens/hundreds of developers to maintain Drupal/RoR/Java apps which are significantly simpler in scale & complexity than WhatsApp or Instagram. If you want to use tools well, you need to hire people who understand the tools.

Yes, the tooling has improved dramatically. A 10x engineer of yesteryear might actually be a 100x engineer today. But if you give a bad engineer modern tools, it just allows them to fail faster.

I might be able to build a house with legos, but I expect to be spending a lot more time repairing it than if I'd just hired a carpenter in the first place.

[1] [http://highscalability.com/blog/2014/2/26/the-whatsapp- archi...](http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture- facebook-bought-for-19-billion.html)

<comment><USER5> > _WhatsApp was able to scale to so many users while keeping the engineering > team small precisely because they hired great engineers who wrote an > extremely efficient system in Erlang. They heavily tuned their architecture > and build efficient paradigms which kept developer productivity & > performance from degrading as their user base grew. [1] Commodity engineers > don't write that sort of code._

The problem is they did it with only a few (16?) "great engineers". That's the premise of the article -- our world today might need 100,000 great engineers to solve great problems. Tomorrow 1000 might be enough.

As for the "near great" they would too be less needed, and commodity engineers would be the equivalent of burger flipers.

> _Yes, the tooling has improved dramatically. A 10x engineer of yesteryear > might actually be a 100x engineer today. But if you give a bad engineer > modern tools, it just allow._

The first yes, the second not really. A bad engineer can get enormously more done with modern tools than he could 10 or 30 years ago. Essentially a bad engineer today can build stuff that took high level senior engineers to build -- and do it in less time too. It might be a little crude, but it will work.

E.g a bad engineer can automate a workflow that would have taken expert engineers, custom software and several man-years to do 20 years ago, and can do it in a day.

And because it's so abstracted, building something like that needs little influence from his skills, so his "badness" doesn't show up much.

<comment><USER4> > The problem is they did it with only a few (16?) "great engineers". That's > the premise of the article -- our world today might need 100,000 great > engineers to solve great problems. Tomorrow 1000 might be enough.

The premise of the article seems to be that we no longer need great engineers at all. Or that they only need to work at infrastructure companies (not application companies like WhatsApp). The very example he chose shows that's empirically untrue.

The fact that a small team of amazing engineers can accomplish huge things (given some ops support) is not new. The original Macintosh team was also tiny.

There's no evidence that we will ever stop needing great engineers, particularly as more and more applications require huge scale while maintaining agility.

<comment><USER5> > _The premise of the article seems to be that we no longer need great > engineers at all._

Well, not really, because somebody will have to build all those elaborate abstraction layers people will use.

The core idea is that we'll need much fewer great engineers -- which is another way of saying we won't need "great engineers" at all. Read "not need them at all" liberally (very few), not literally (nobody).

After all if job demand goes from 1,000,000 people to 1000 people (arbitrary numbers), it's like it's the end of that job, even if technically people are still employed (there are after all horse cabbies and film lab technicians and letterpress printers employed still today).

<comment><USER6> This is absurd. How many people where creating their own languages 20 years ago? Everyone and their grand ma is building new languages on top of javascript. The expertise level of software engineers is going up! 20 years ago, how many people could build a VM from the ground up? Have you visited github lately? Sure, an average engineer can do much more today, and the reason is because of these great engineers, and they are not fewer by any means.

<comment><USER5> What you said actually corroborates what I wrote.

> _How many people where creating their own languages 20 years ago?_

20 years ago? Far less. That means writing a language is getting more commoditized -- and we work in a higher, easier, level of abstraction. That's what TFA says about other spheres of development and deployment too.

> _Sure, an average engineer can do much more today, and the reason is because > of these great engineers, and they are not fewer by any means._

Neither I, nor the article, said there are fewer great engineers. Only that fewer great engineers are (and fewer still will be) needed. Both as a percentage of all great engineers, and in absolute numbers.

<comment><USER7> I can't substantiate it, but there were in fact a lot of languages being created through the 60's to 90's. One could argue the language implementors of old were quiet daring, push boundaries much more than today (see APL and ICON as examples). sed and awk arose in an era of language explosion, make, sql, the list goes on.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> > As software becomes a high-impact, low-skill trade, we decouple the > technical ability and experience needed to write tricky software from the > ability to solve problems for people.

It's one thing to know that capital secretly delights over the commoditization of labor. It's quite another to watch a16z gush so openly about a future where we can be tossed aside.

<comment><USER9> Alternatively, a creator can now build a product with fewer people and doesn't need to raise capital. This trend is extremely empowering of labor.

<comment><USER10> In theory, yes. In practice, most people aren't entrepreneurs. Try convincing someone living in the Bay Area to walk from their 200K/yr plus stock units from FB/Google/etc. and you'll find out the reality: what really separates capital from labor is risk tolerance.

Labor = show up, do your job, get paid. Capital = put money at risk without any guarantee of getting anything back, let alone earning a profit. Capital makes the rules because half of America is two paychecks away from bankruptcy (I read this somewhere credible) and can't/won't take any risk.

</comment></comment></comment><comment><USER11> I'm failing to follow the logic here. The initial point is that "The potential impact of the lone software engineer is soaring". However, the author then takes that to mean that engineers will be _less_ valuable in the future?

This analogy seems apt to me, and I think it makes the logical leap more obvious:

Fifty years ago, if you wanted to design a new model of car, you had to get plywood and clay, and work hundreds of hours of to get even the most basic model completed. Now, you can open up a CAD program and begin making real decisions immediately. What previously took a large team to build, a single designer can now do. ( _The analogous logical leap to what the OP seems to be saying is_ ) Soon, we won't need designers at all! A company will come out with a new car model simply by snapping design-legos together.

In reality, removing inefficiency made designers _more_ valuable. If you were the best car designer 50 years ago, you had to spend a significant amount of time molding clay. Today, you spend almost all of your time _creatively finding solutions to problems._ I see the value of individual engineers increasing significantly as we remove cruft in the creation process.

<comment><USER12> Replace "software engineer" with "person building a product" in that first quote.

The value of engineering skills as they are defined today is falling, but the value of a single person with an idea and the drive to implement it is soaring.

<comment><USER10> I think the change is purely additive.

Great engineering is no less valuable than it once was, but pure "idea guys" can do stuff now that they couldn't do before.

<comment><USER13> If they do stuff, by definition then they aren't "idea guys" :)

You might mean "nontechnical people can do a functioning MVP" which they couldn't before :)

</comment></comment></comment></comment><comment><USER14> This article is grossly oversimplifying and conflating things. All the examples cited are skewing the results to fit the agenda the author wants to promote. Specifically, the functionality, audience, and valuation are creating insane $$$-to-engineer ratios, that the author then tries to claim is the future of the industry.

Functionally, imgur is not very complex. Its an order or 2 of magnitude less complex than say, another "software is eating the world" business like a web- based CRM app. That's not to discredit imgur or Instragram. They are great achievements and successful apps. But it doesn't and shouldn't take dozens and dozens of engineers to make those.

The potential audiences for the examples are, essentially, the world. These apps can gain use very rapidly, and it can disappear just as fast. 1 person can make Flappy birds and the entire world can use it. The people to audience ratio here is huge compared to say, a SaaS invoicing product.

Imgur doesn't have a monetization strategy like, say, a SaaS product like a web CRM, or even something as simple as a WordPress backup SaaS product. Instragram had no business model. How much is it worth? This is where the crazy audience ratio comes in and messed up the results some more by effecting valuation. These valuations are not based on real revenue numbers. They are based on the wish and dream of extracting value from eyeballs. I'm sure they are worth something, but taking a Series A or Series B valuation and extrapolating is murky.

So, low functionality apps, with a huge potential audience, and a completely made up valuation number. Of course you are going to get $10B to 10 engineers ratios. That doesn't mean this is a trend in the industry, let alone business/enterprise software.

</comment><comment><USER15> The article suggests that, as super-human programmers build ever-better platforms/languages/tools, those building apps/whatever on top of those will be less differentiated in terms of programming ability, because it will be so easy to develop stuff anyway.

I'm not sure this is true. Are 10x programmers really 10x because they can grapple with technology stacks, or because they're really smart and experienced at problem solving? Programming will always be about problem solving, no matter how easy you make the final implementation of the design.

<comment><USER16> I agree.

Specific skills (e.g. working with a certain framework) will go in and out of style, but problem solving will always be in demand.

Also, maybe I'm naive, but I just don't see the software-as-legos future as feasible. There will always be the need for customization and ever-more- advanced functionality.

<comment><USER10> I don't agree.

If you spend a few years at university (I have two degrees), you learn things like sorts, automata, proofs, and calculus.

On the other hand, most of the junk I deal with day-to-day as a working software developer turns more on my knowledge of tools like Chef/IntelliJ, software libraries (the stdlib of various languages, the Java/.NET BCLs), build systems, git/github, and how to do a proper code review.

For most stuff today, I would _highly_ prefer the person with more tools experience. Granted, there are some problems people who aren't "10x developers" could never solve (e.g. writing linux) but for most stuff industrial software devs today are doing, it just doesn't matter. You just need to write the code, it needs to be maintainable, and it needs to be done as quickly as possible.

<comment><USER17> You compare two people who have different skills. Presumably either one could learn the skills of the other. Why choose the one with the easiest skills to learn?

<comment><USER10> Because learning skills takes time, and in tech, time is everything.

</comment></comment></comment></comment></comment><comment><USER18> This post is making the completely wrong conclusion.

The reason companies like Instagram, Imgur, etc are able to service large #s of users with 7 engineers is mainly because computers and tools are a lot CHEAPER than they used to be, not simpler.

Cheaper. Less expensive. This allows small teams to build really huge things because generally small teams don't have much money (because if they did, they'd have a bigger team!), and the fact that stuff is cheap allows them to build it in the first place. Open source = free. Computers, bandwidth = a lot cheaper than they were 5/10 years ago.

Snapchat couldn't have existed 10 years ago because it would have cost 100x what it costs today. In fact, things are so cheap these companies can overspend and run their service on AWS or Heroku because the price of computing doesn't matter as much [1].

Programming is just as complicated as it was before. In fact, anything where you have a team of 5+ people working on the same thing for years is going to be complicated whether it is software, legos, or plumbing. As tools get simpler, the product will compensate by becoming more complicated (which is why we are seeing more awesome software these days), and thus the level of complexity will be roughy the same.

Today I could build a product as a one-person team that would have been competitive 5/10 years ago, but today the bar is much higher, and of course it will continue to get higher as we software and the trade of building software improves.

1: Though companies like StackOverflow still build their own metal and because of that run their sites _incredibly_ efficiently on a cost basis

<comment><USER19> I think the tools are not simpler as being simplist, but easier to use, maybe by having clearer objectives and design than it's predecessor. Also, it was not long ago that put a web system was hardm with lot's of workaround or using not specialized tools for the job. Today is clearer what one need to create and support such system online.

</comment></comment><comment><USER20> The article makes the error of assuming that a 10x engineer is 10x because he has arcane knowledge about the intricacies of low level programming. This may be true for some layers of development. In my experience, for application programming, this isn't the "10x skill".

10x engineers are the guys that can grasp the complexities of large systems, enabling them to change them with minimal effort. When prompted with the need to implement a new use case, they understand the whole system or most of the system and thus they can plot the minimal change path to achieve the new functionality. They don't code faster. They code less, leveraging work that is already done.

If you have fewer engineers working on a system, because of better abstraction layers, then you only need the 10x guys. These are the ones that can drive the powerful machines.

What we are witnessing isn't the demise of the 10x engineer. It's the demise of the code monkey.

</comment><comment><USER21> This doesn't pass the sniff test. The demand for _high-quality_ software continues to outstrip supply. Bad software is an imperfect-but-better-than- nothing substitute for good software, which is why so much of it gets written.

The problem here is that there's a sort of Gresham's law effect - bad software drives out good software by infection. Your technology stack is only as good as the worst component, and if you're operating at the level of indirection that Sam Gerstenzang suggests, that's a _lot_ of software that you need to depend on, and your software can only be better than the software it depends at the cost of a lot of effort. Some component in your stack doesn't work the way you need it to? Well, suddenly you're either three layers down the stack trying to fix it, or you're writing a non-trivial piece of software higher up the stack to make up for the deficiencies of the lower level.

I'd also dispute Gerstenzang's basic premise that modern engineers need to know less than yesteryear's. 20 years ago, you could write an entire app in Visual Basic. It could integrate with a database, had a drag-and-drop GUI builder, was scriptable using a language that, for all of its many idiosyncrasies, was fairly easy to learn (and you could write plug-in components in C++ if you wanted to). A statically-compiled binary could be put in a floppy disk and would work on any computer running Windows, where it would look basically the same.

Modern _front-end web code_ needs to navigate a Rube Goldberg machine of preprocessors and build pipelines that would have embarrassed a C developer from 1988, and incompatibilities with particular browsers, operating systems or form factors frequently cause simple tasks to take longer than expected. Because nearly every modern application is a distributed application in some sense, you need to understand concurrency and network protocols, and if you want to work on both the client and server components of your application, you _probably_ need to know more than one programming language, or the subtle differences in the runtimes that your language has on client and server. And that's just fairly simple web applications!

WhatsApp was created by a small team, but that team needed to include skills in everything from Erlang to J2ME. That breadth of knowledge was what gave WhatsApp the key competitive advantage of being able to support almost _every_ mobile device on the market, not just the latest generation of smartphones. You might be able to get a startup off the ground without engineering, but you won't be able to grow it much.

</comment><comment><USER10> This has always been the case. Software people in the 70s and 80s already had the distinction between "systems" and "application" programmers -- the former understood to be concerned with making the pipes and plumbing, vs. the applications guys concerned with the end users. Applications have always been like legos.

I work as a systems developer but often do consulting projects as an application developer, and it's a totally different mindset. Writing software for end users, I rarely even remotely think about CS, algorithms, pointers, recursion, numerical stability, memory allocators, etc, whereas I _do_ care intimately about the tools I'm using, much like I suspect a carpenter cares about what drill he's got. On the other end of the spectrum, I can hardly go a day writing traditional "systems" software without considering things like what data structure MongoDB/Postgres uses to hold indices, and gigantic, complex consensus problems (distributed systems, e.g. how DNS behaves).

I hope we start to treat these two endeavors differently because they require totally different mindsets and education. A typical app developer need know no more about how OSes work, than a plumber needs to understand the metallurgy used to make pipes.

<comment><USER22> I see the overall point you're making, but it's not true programming applications is always (or even often) like building with Lego pieces. It's just that many of us have to write mindless web apps which mostly consist of CRUDs. _Those_ definitely are like working with Lego.

CS, algorithms, pointers, recursion, numerical stability, etc, etc, are all alive and well in the world of applications programming. Just not in the world of run-of-the-mill CRUDs.

<comment><USER10> Sure. And to be clear, I in no way think applications is easier. In fact, applications, as they're closer to end-users, have to deal with all kinds of socially-imposed whimsy like people with four names, tax rules, interest rate calculations, and 100 other things that make my head hurt to consider.

</comment></comment></comment><comment><USER23> Gerstenzang is watching the latest complexification of small shops into huge industries and projecting it onto the entire field. This is very silly reasoning and it ignores history.

Transported back in time, he could say the same thing watching the small, passionate computer shops of the 1970s becoming huge organizations as customer money and investment capital flow in, as more engineers are hired, as efficiencies and industry-wide standardization set in. He could say that the emergence of low-skill labor in the mature industry was the end of engineering, that there was nothing more to do.

But there will always be a new layer to this game. Once the previous layer has walked its arc from hobbyist to small shops to huge industries and maturity, there emerges a ragtag group that takes advantage of the new environment.

Gerstenzang does identify and appreciate this crucial factor, he just seems to view it as an endpoint and not a beginning.

Of course, an AI that can do real, human-level engineering might throw my own entire line of reasoning out of the window.

</comment><comment><USER24> It's already happening. There's an incredible difference (in personality, tooling, skills) between your typical full-stack web developer and kernel programmer, as there is between the kernel programmer and chip designer. They're each difficult in their own way, but one definitely has a lower barrier of entry.

</comment><comment><USER25> The arguments are flawed and taken very lightly.

One could argue the exact opposite: Engineers are needed now more than ever. A skilled engineer (what does this even mean in a context so wide?!) can run a website like PinBoard, serving millions of users, from the a jungle in Thailand, on a crappy 56k using a 250 USD ChromeBook.

Of course it's _possible_ but how many people do _actually_ manage to do it successfully?

And while having AWS, Github and you-name-it makes this possible (scaling was the big issue apparently), AWS and Github can not be run by a lonely engineer, you need an army of them.

</comment><comment><USER26> I have two problems with this:

1) Even if we are able to remove all of the inessential complexity of the problem (ceremony and routine drudgery,) we cannot automate the essential complexity. For crud apps, the essential complexity is very low. However, for many apps there is intrinsic complexity to the problem and how it relates to the domain. You might argue that what this leads to is a vast array of cheap specialty modules that can be plugged together. Well, the complexity is then in understanding the impacts of the modules and their interrelationships. The 10x engineers aren't 10x because they can set up logging or automated deployment, they are 10x because they can instantly cut through multiple layers of abstraction to see how their interactions lead to an emergent behavior that is different from the spec (for example.)

2.) Unfortunately, machines (and _networks_ ) are not fast enough to compensate for an unconsidered approach to information retrieval and propagation and this is not going to be helped by a "legos" approach to building software. This _might_ be helped by a different set of tools (view- first rendering driving parallel backend requests..) but that brings up its own set of challenges.

</comment><comment><USER27> This article fails to mention that our expectations for software have increased. We expect more from apps than ever before. This has lead to new specialities such as Front End Engineers and UX staff. Surely we can build more with less with current technologies as compared to the past but we also expect more. If our expectations outpace technological improvements this could lead to spending more time/money on developing apps.

<comment><USER28> Consider Bootstrap and the uniformity it offers in GUIs with little effort.

<comment><USER21> Uniformity isn't so great for people who want to differentiate their products. (Not saying that they _should_ want to differentiate their products visually, but they almost certainly _do_ want this).

</comment></comment></comment><comment><USER29> This seems to be pretty specious reasoning which has at its heart the principle that acquisitions are the final goal, not a functioning enterprise. I think the acquiring companies would tend to disagree.

</comment><comment><USER30> Teams are not getting smaller. The original Macintosh team was not much larger than the teams he mentions and probably had much more technological impact.

The web has been around for a quarter century now and still rather trivial websites that mostly could be replaced by tools sell for some $50k. Because even those basic tools we had 25 years to build are not there yet.

Software engineering is actually becoming proper engineering, at least in Europe where much of it is focused more on industry. Crashes are mostly unacceptable now. Embedded software is sometimes formally proved.

Finally, as everyone who actually develops software knows, we need to cut many needed features to ship in time. Think how incredibly long it still takes to implement what you can imagine: It takes many months. This is a good indication of how far we are actually from combining things in a lego-like fashion, from making dreams come true quickly because it is so easy.

</comment><comment><USER31> The author makes some good observations but I feel he is undervaluing post- foundation engineering skills.

Sometimes the reason why certain companies end up with so many engineers due to the _lack_ of those so-called "10x engineers" \-- specifically, those who know how to build robust, scalable systems while coordinating with the needs of product development.

I know some of the engineers who have worked for those lean, highly scaled shops and I know for a fact that they know their shit extremely well - <USER2> they've poured hundreds of hours into carefully scaling their infrastructure. They could not be replaced by your average full-stack engineer off the street as they'd immediately be in over their head and would have to spend the next few years learning all the hard-won knowledge of the more experienced engineer.

</comment><comment><USER32> Let's compare writing software to writing English. (Writing is kinda an individual sport) Almost everyone can write a short story in English, but the 10x writers really really stand out. Writing isn't a perfect analogy - <USER3> generally think of programming as a skill (right and wrong, boolean, either you can or can't) and writing as an art (shades of gray, non-boolean skill).

The assumption is that more people being able to make things with code would make the 10x engineer less valuable - but I think it makes them more valuable. In a noisy world - only the truly great can stand out. And to really make our future great, we are going to need a lot more than CRUD web apps.

I could be wrong - but I don't think this is as cut and dry as the author claims.

</comment><comment><USER33> The implications of this are pretty interesting. People will only use software that solves actual problems they have. Software development is now more accessible to more people because of all these frameworks and tools. It only follows that the people most familiar with actual problems will be able to create the most used software, and those people aren't necessarily going to be software engineers by trade. The question "How long before we have a billion- dollar acquisition offer for a one-engineer startup?" is crazy, but likely not too far in the future, but even more interestingly, "How long before we have a billion-dollar acquisition offer for a zero-engineer startup?" might not be that far off either.

</comment><comment><USER19> This article is confusing two different things: engineer and the tools used by the engineers. It's not like the tools will ever substitute an engineer or exist one tool to rule all other tools or even one tool that do everything. What we have now better tools than before, which makes possible for few engineers to produce more than before. Examples from other jobs, graphic designers were not substituted by tools like Photoshop and InDesign, will they ever be? I don't think so - and that's by design, the tool is to easier the job, let the person concentrate where it makes more money, and not to substitute the person.

</comment><comment><USER34> Part me wants to agree the picture painted here, but bits like the one below make the whole thing out to be an veiled appeal for more naive investment targets without the myriad complications of engineers.

Basically, they'd like a lazy Susan of people who've done a bunch of leg work on a 'lego' app or website and are ready to accept $50K for 60%, Shark Tank style.

 _> 'As software becomes a high-impact, low-skill trade, we decouple the technical ability and experience needed to write tricky software from the ability to solve problems for people.'_

Not exactly.

In keeping with the analogies to traditional infrastructure and trades.

This sort of commoditization of labor allows a certain class of problems to be solved - repeatable, fairly well-understood ones for which there are ready instructions and appropriate 'legos' available.

Providers of these services race to the bottom and have to be kept in check with codes and consumer paid inspections to ensure that their snap-together builds meet barest minimums of safety and sensible design.

In this race to the bottom, implementers don't care and won't pay for better components, just cheaper ones that meet the minimum spec.

There's good reason people loathe calling a plumber or HVAC repairman as much as they love certain tech companies known for their design and engineering.

This is probably fine for money men, but neutral to bad for nearly everybody else.

</comment><comment><USER35> Looks like I'm riding the wrong train, screw learning C++/Scala, Big Data and NoSQL database, looks like engineering is gonna be commoditized.

Not this time, I'm gonna get on the new train early this time! I'm gonna pivot to learn SEO, A/B testing, social media marketing and lean startup principles on how to manage coders to build startup's on the backs of free open source software hosted on Github donated by hobbyists!

</comment><comment><USER36> A billion dollars for a one engineer social media company? Certainly possible, but then you'd have to ask yourself what you are paying for. Perhaps it's not just (or even mostly) the engineering; in which case I'd say the author slightly misses the mark here.

This is certainly not to say that I believe more engineers/engineering == better product or more value, far from it. Only that devaluation of skill and experience suggests that the problem being addressed might not be primarily focused on engineering tasks. And that perhaps the gargantuan sums we see being paid for some small collection of companies are calculated somewhat differently than we might be used to.

Even if I'm wrong about that, heralding the death of the highly skilled engineer is more than a little premature either way. I tend to think that problems will continue to present themselves to challenge our best tools, regardless of how much engineer quality of life improves. If that's not happening in social media (which I highly, highly doubt), then that can probably be considered a separate issue entirely.

</comment><comment><USER37> Well, yes, if we restrict our domain to the set of application types for which development can be commoditized, then development becomes a commodity.

Not all development is webapp and mobile app development, though, and some things, like actual engineering, just aren't things that can be commoditized (beyond a certain point).

</comment><comment><USER38> I happen to think that because the leverage is greater, the reward for hiring highly skilled & talented engineers is much greater than it ever was.

All the products mentioned were functionally simple and I like billyhoffman's explanation of why the low functionality/large audience products don't represent the majority of the industry - [https://news.ycombinator.com/item?id=8109434](https://news.ycombinator.com/item?id=8109434)

I'm trying to understand how Sam Gerstenzang becomes a partner at Andreessen Horowitz and I can't figure it out.

[http://www.crunchbase.com/person/sam- gerstenzang](http://www.crunchbase.com/person/sam-gerstenzang)

I don't want to ad hominem, I'm just a bit puzzled. It seems like he was an engineer for about 12 months. Anyone here know him?

</comment><comment><USER39> When I was in college in the mid-late 90s, my Software Engineer professor said that "In 5 years, programmers won't exist. With the revolution of Object Oriented Programming, creating software will be a matter of plugging blocks together".

Right.

</comment><comment><USER40> The Lego approach has been the holy grail of software development at least back into the 80's with OOP. Yet it still requires programmers who know about data structures, algorithms, etc. to write software. Even if they're just cobbling together libraries, there is still a lot of additional functionality required--not just 'glue' code.

All we have now are improvements in efficiency (great, mind you), with operational improvements like IaaS and development improvements with the great OSS that we have now. It will require a sea change in the field of comp sci. to achieve Lego-like orders of magnitude improvements.

</comment><comment><USER41> I would like to think there will always be a frontier, and there will always be people driven by their curiosity to seek the frontier out. Some of them will be called 10x engineers, some visionaries, some pioneers.

</comment><comment><USER42> This article sets up a a few interesting points, but stops at only one. Yes, the ever-increasing level of abstraction available in information technology enables less technically-specialized people to creatively utilize the tools available to them, and that's pretty amazing.

But the plumber analogy fails to capture the breadth of the tech world. What I would call equally exciting to the empowerment of less-technical developers is what highly technical "10x engineers," or whatever you want to call them, are enabled to do in a world of next-level abstractions.

</comment><comment><USER43> > The same software foundation (open source software, development tools like > Github, infrastructure as a service provided by the likes of Digital Ocean, > and more) that allowed Whatsapp and Imgur to scale, means that experience > and skill writing software become less important.

The author focuses a lot on ease of scaling, but the bigger challenge has _always_ been building applications (experiences) that need scale. If you build it, they will not come.

</comment><comment><USER44> I love how all the top comments here are all devs in denial about this, but it's an inevitability that programming "becomes legos". Don't become the old men guys!

As said in the article and below, many products will still require very high- level engineers building without "legos", but the basic webapp kind of stuff probably will be full commodity able to be built by anyone with the motivation to see it through.

<comment><USER11> It's not about being in denial. It's that this argument has been brought up with every advance in the last 40 years.

In the early '70s it was "Programming in C will allow anyone to program and commoditize the industry!".

In the later '70s it was "Object-oriented programming allows modules to be created that snap together like legos, commoditizing the industry!".

In the '80s-90s it was "Scripting languages like ruby and python are so simple, it's almost like writing real english! It's so simple you won't even need a programmer."

In the early '00s it was "Scratch and other visual programming languages will create a platform that everyone can understand! You can learn it yourself, you don't need a developer."

Now, it's "Libraries and tooling are getting so great, what used to take 100 engineers now takes 5. In a few years, it will take zero!"

\--

That obviously isn't proof that this time is the same as the others. However, this article gives no evidence that I can see why this simplification and removal of inefficiencies is any different than the others.

<comment><USER44> Yea...and it has gotten easier. I'd bet the average level of software dev (writ large) today is lower than 20 years ago because it's getting easier. (Though I'd bet there's probably more great devs today ever because the pool of devs itself is growing and becoming more accessible)

Sure, having MS Word doesn't make you a novelist, but Wordpress + plug-ins can let you make your own pretty high-quality news site with very little technical knowledge - that's real improvement.

I'd say to just give it time.

My company is doing this to another set of engineers in the mechanical / manufacturing space, so I hear these types of complaints all the time.

<comment><USER17> Most Wordpress themes are highly inefficient in regards to load time and bandwidth. There are some great plugins but most are sub par quality in terms of performance and security. All large scale Wordpress deployments are tuned either by in-house engineering staff or [http://vip.wordpress.com/](http://vip.wordpress.com/)

</comment></comment></comment></comment><comment><USER45> Less overhead, more productive, yet still the same pay...

</comment><comment><USER46> > Software engineering is not yet plumbing — or Legos — because our standards > are incomplete, our libraries incompatible, scaling is still not free and > our software still buggy.

I think it's more that plumbing has been with us for thousands of years. Imagine if we had computers 5000 years ago - software surely would have been plug-and-play by now as Sam writes about.

</comment><comment><USER47> 10X engineers won't disappear, but they will do other things, and that's great! [http://make.bubble.is/post/93505282266/conversion-10x-engine...](http://make.bubble.is/post/93505282266/conversion-10x-engineer)

</comment><comment><USER48> Its funny I've always thought that Twitter could really be run by 100 folks (heck I've said 40) and be hugely profitable and it a lot of ways more efficient. Instead they've got 2300 employees to allow folks stream 140 character tweets.

<comment><USER49> That's a bit optimistic. Their sales team alone is bigger than that. Companies aren't just engineers.

</comment></comment><comment><USER50> You can't scale without well crafted solutions - scaling your rails app on digital ocean would have a higher burn rate than hiring a few good engineers to build scalable code that needs fewer machines. AWS is pricey!!

</comment><comment><USER51> This seems to be ignoring entire classes of software. I can't imagine the enterprise development world will be taken over with easy to snap together software packages any time soon.

<comment><USER9> Why do you think enterprise development is different?

<comment><USER51> Because enterprises are infinitely complex and diverse and there will never be a single piece of software that can run all the businesses in the world with a couple configuration setting tweaks.

</comment></comment></comment><comment><USER52> I had this vision 5 years ago, for sort of an operating system for social apps. Where a regular user could build their own app by just installing some plugins, dropping a chatroom and some other components on a page, paying a developer to wire them up, and paying a designer to design the theme. And there would be a marketplace of components built by more experienced developers.

So 5 years ago I started my first open source platform, [http://phponpie.com](http://phponpie.com)

Since then it's come a long way, and it turned into a real platform: [http://platform.qbix.com](http://platform.qbix.com)

Like mobile apps, social apps require an operating system that solves common problems in a standard way:

      * User signup and secure auth, login
      * Should work with emails, mobile #, facebook
      * Accessible from desktop, tablets, mobile
      * Contacts integration / friendlists
      * Real time collaboration from any device
      * Offline notifications via fb, sms, app notifications etc.
      * Access control and privacy - as expressive as possible
      * Native apps on iPhone and iOS via Cordova
      * Invitations and one-click account creation
      * Encourage best practices for scaling, web standards etc.
      * Installer to upgrade apps and plugin versions cleanly

etc etc.

All that stuff should have standard solutions which you can override. The apps and plugins should all interoperate.

And finally, since I really care about decentralization, it would be cool if this whole operating system could be as decentralized as Wordpress is for blogs, as opposed to say facebook. That would also solve all the scaling problems that facebook and other centralized social networks have.

That last part - decentralizing the social network - took the most effort, as I had to solve problems of security, identity, privacy, as well as app and plugin versioning and signing across a distributed network. Just like iOS is for mobile apps, and Bitcoin is for distributed contract apps, the Q Platform is if you want a social layer for your app, from user accounts to everything else, without having to write it from scratch.

Yeah, so that's what I built. Link to the open source: [http://github.com/EGreg/Q](http://github.com/EGreg/Q)

<comment><USER52> How come every time I post about the platform I've spent 3 years building someone here decides to vote it down? I'm just curious. Is it really something you don't want to be spoken about?

<comment><USER10> I think this got downvoted due to the way you describe it.

My experience with HN is that it's a very hard-edged, no-shit crowd. People here expect things to be described with simple, crisp language, no jargon (especially not computer/science/technology terms with precise meanings), and a minimum of hand-waving. It's a bit hard on the ego, but it'll make you a better communicator.

In the first sentence of your post, you described your thing as a "social operating system" or something like this -- this immediately sets off my bullshit alarm. "Operating system" is a very specific thing to software people, but for whatever reason, non-technical people love using this term to talk about something perceived to be big and complicated.

In general, try to cut the fat. If it's a library of software components you're making, say that. If it's a Ruby gem, or an app, or some kind of a specification, just describe it for what it is. You don't gain much here trying to hype it up.

Other things I notice:

\- You say you can "override" \-- how? Using what?

\- What is a "social app", anyway? Aren't all apps "social" today? This descriptor (social) adds very little value. Github, facebook, twitter, instagram, linkedin, could all be considered "social" apps.

\- "Social" is a very overused buzzword in SF. Everyone here is building bullshit "social" companies and all the devs here get like 10 job ads/day for some dumb social network for cats.

\- Again, "interoperate". How? Via a REST API? Server-side includes? Be specific.

\- Don't say "it's come a long way". Stop telling. Show.

\- "Decentralized". Again, what does this mean? It can be hosted anywhere? The software is widely distributed? What is a "distributed network"? Aren't all networks "distributed"?

<comment><USER52> I did show. All your questions can be answered immediately in that link - [http://platform.qbix.com](http://platform.qbix.com)

</comment></comment></comment></comment><comment><USER53> The software equivalent to doing your own plumbing has been here since the mid-90s: build your homepage with Geocities.

</comment><comment><USER54> Mathematically,is he saying that because the limit of a function tends to zero,it will actually be equal to zero?

</comment><comment><USER55> Get ready for the next wave of "business bootcamps"

</comment><comment><USER56> Wouldn't that mean The Happy Demise of the VC as well?</comment>


L++ Language - <AUTHOR> https://bitbucket.org/ktg/l <comment><USER2> In principle, it is very similar to the design of Chicken Scheme, a transpiler from Scheme to C: [http://en.wikipedia.org/wiki/Chicken_Scheme](http://en.wikipedia.org/wiki/Chicken_Scheme).

The L++ source also looks very much like this lovely write-up on how to write a Scheme x86 compiler: [http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf](http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf)

<comment><USER3> There's also ECL, but I don't know if it uses the same continuation style as Chicken though.

<comment><USER4> It does not. Nearly all of the common-lisp to C transpilers are decedents of Kyoto Common Lisp. One notable exception is mocl, which I believe to be a decendent of CLiCC ([http://www.informatik.uni- kiel.de/~wg/clicc.html](http://www.informatik.uni-kiel.de/~wg/clicc.html))

</comment></comment></comment><comment><USER5> Usually I love looking through new programming languages, but the docs here don't give me any motivation for the language, or even any reasonably non- trivial examples. Is it just supposed to be C++ with Lots of Irritating Silly Parens?

<comment><USER6> Silly Parens are easier to parse. Automated manipulation of programs might be fairly easy to accomplish.

If there were Lisp-style Macros available, that would beat the pants off the C Preprocessor for boilerplate.

<comment><USER7> > _Silly Parens are easier to parse._

I thought silly parentheses are just as easy to parse as in an imperative language like C. Are you referring to the Polish prefix form being easy to parse?

<comment><USER8> It's more like, the text is easier to turn into an AST, and it's easier to manipulate that AST. It's not so much the parens, but the nested structure (and that all of the code is in that structure)

<comment><USER7> > _It 's not so much the parens, but the nested structure (and that all of the > code is in that structure)_

I should have explained myself more clearly, I thought that the operator appearing at the beginning of the list means that operator precedence is no longer relevant. With infix operators the precedence is important.

<comment><USER9> Yes, this is also correct. In most (if not all) Lisps the generic structure is "(operator [arg1] [arg2] [...] [argn])".

</comment></comment></comment></comment></comment></comment><comment><USER10> the source, in its entirety:

[https://bitbucket.org/ktg/l/src/cb93b589c03ec1e39007c1907deb...](https://bitbucket.org/ktg/l/src/cb93b589c03ec1e39007c1907deb03d0787f9f17/l%2B%2B.rkt?at=master)

</comment><comment><USER11> Not his first "parenthesis", see [https://bitbucket.org/ktg](https://bitbucket.org/ktg)

<comment><USER12> Heh, guy loves creating lisps..

<comment><USER11> Who could blame him.

</comment></comment></comment><comment><USER13> Racket is so much fun. A single rkt file to C++ transpiler? Awesome stuff.

Anyone who has done things like this before: is it peformant? The Racket documentation mentions against compiling out C/C++ sources it can emit, because it misses the JIT and other optimizations. Would the emitted C++ code be worthwhile?

Ironically, this seems to be exactly what Naught Dog was doing for the infamous Racket on PS3 talk, even though it was not actually running on the PS3 (it was MzScheme that transpiled to C++ code that could be compiled to patch together game demos).

<comment><USER14> I'm curious, why infamous talk?

<comment><USER13> I meant in the sense few watch it and no Racket is not running on the PS3.

</comment></comment></comment><comment><USER4> For those interested in C++ and lisp, there is someone who has a nearly complete common-lisp implementation written in C++, with a strong focus on easy calling to C++ (Which is a serious weakness of the FFI for most languages, Lisp included). I don't know if there is an ETA for it being released yet though.

</comment><comment><USER15> If you've ever wondered what it'd be like if Lisp and Python got drunk at a party and 9 months later gave birth to a beautiful 800 lb C++ application.

</comment><comment><USER16> Ah, Clojure changed its name.

</comment><comment><USER7> To whoever down voted my earlier comment, linked here [0], thank you for responding to my query, I'm guessing that you consider bit-bucket not to be superior to git-hub.

It could have been easier if you just replied to the comment, then I wouldn't have to extrapolate an answer.

[0] [https://news.ycombinator.com/item?id=7712428](https://news.ycombinator.com/item?id=7712428)

<comment><USER17> I didn't downvote you, but I suspect the reason you were downvoted was because it was off topic - we are talking about a new dialect of Lisp here, not github and bitbucket.

<comment><USER18> But it wasn't hugely distracting. There are a lot of down votes in this thread for ultimately ignoreable comments.

</comment></comment></comment><comment><USER7> Quick query - is bitbucket better than github?

<comment><USER19> Unlimited private repositories for free, yes.

<comment><USER7> Thank you.</comment></comment></comment>


Theranos founder Elizabeth Holmes to stand trial in 2020 - <AUTHOR> https://techcrunch.com/2019/06/28/theranos-founder-elizabeth-holmes-to-stand-trial-in-2020/ <comment><USER2> Wait so the defense's case centers around the idea that Carreyrou had too much influence over regulators by providing extensive evidence, witness testimony, and analysis by objective third party specialists? Is this for real? By "eager to break a story" do they mean a kind of eagerness that results in a painstaking effort to build a thorough case that has been scrutinized by the public and media alike? This, like Theranos' tech, can't possibly be viable.

<comment><USER3> "And I would have gotten away with it, too, if not for that meddling reporter and his stupid newspaper".

</comment></comment><comment><USER4> The best defense they can offer is that Carreyrou was too good of a journalist. I hope to god the jury is not lenient here in the face of overwhelmingly damning evidence. This was a matter of defrauding not just investors, but putting lives at risk and ruining careers in the process.

<comment><USER5> Ruining careers? Not always. Mona Ramamurthy, former head of Theranos HR and Sunny Balwani's right hand woman, was one of the most egregious offenders and later got a job as senior HR at google. Google was probably most impressed by her treatment of the H1Bs at Theranos, since they have the same needs.

</comment></comment><comment><USER6> Good, we need to set the record straight in SV that this kind of blind bullshitting and manipulation will not be tolerated.

Has info been released as to whether or not all of Holme's finances will be frozen prior to trial?

</comment><comment><USER7> Does anyone have the d hn threads about her? Got banned for sexism back in the day for calling her our for being a fraud and not being civil.

Hi Doug.

<comment><USER8> I'd be interested to see how you phrased it.

<comment><USER7> Can't remember but probably called her a fraud and the people supporting her useful idiots at best and doing more to discredit women in the workplace than the worst misogynist in the inbred backwoods of North Virginia ever could.</comment></comment></comment>


How an 'ugly,' unwanted weapon became the most popular rifle in America - <AUTHOR> https://edition.cnn.com/2017/12/14/health/ar15-rifle-history-trnd/index.html <comment><USER2> Apparently does everything, from hunting to sport shooting. And if you're into guns, why not also have an automatic rifle?

<comment><USER3> _Semi_ -automatic rifle. Automatic rifles manufactured after 1986 are illegal for private citizens to own.</comment></comment>


Ask HN: What is your sleep schedule? - <AUTHOR> And how consistent are you on keeping it over long periods of time and over weekdays/weekends? <comment><USER2> 4-6am to ~1pm. Whenever some unforeseen external factor forces me to change it (usually an unwelcome social obligation in the morning), I quickly gravitate back to it.

</comment><comment><USER3> 4am-7am - 11am-2pm, all week, very consistent, extremely stable against perturbations

</comment><comment><USER4> Sun-Thurs: I try to go to bed by 9pm, read/watch some show and hopefully fall asleep around 10pm, wake up at 5:45am.

Fri/Sat varies.

</comment><comment><USER5> 00:00 to 06:30 but I wish I could sleep an extra hour. Zero dream recall these days.

</comment><comment><USER6> 12ish midnight to 6:30ish am

</comment><comment><USER7> 1am to 5am</comment>


We tried NPM and found Yarn to be better - <AUTHOR> http://www.blog.distelli.com/single-post/2016/12/14/Why-we-switched-from-NPM-to-Yarn <comment><AUTHOR> tl:dr

NPM downloads and installs dependencies in a manner that can be inconsistent. Yarn is better about handling dependencies and is also faster.</comment>


The Sound of the Big Bang (Planck Version) - <AUTHOR> http://faculty.washington.edu/jcramer/BBSound_2013.html

<comment><USER2> You would think it would be louder.

P.S. I fully admit this is a stupid joke but it makes me laugh so there ya go.

</comment><comment><USER3> Could somebody explain what I'm listening to?

<comment><USER4> From the WMAP edition at: <http://faculty.washington.edu/jcramer/BBSound_2003.html>

>Q: How can you represent it as a sound? Sound is supposed to be a wave that travels through air, and there was no air in the early stages of the Big Bang?

>A: The Big Bang Sound in the simulation is derived from the sound propagating as compression waves through the plasma/hydrogen medium of the early universe some 100 to 700 thousand years after the initial Big Bang. The density of this medium was changing as the universe expanded, but should have been considerably more dense than air on our little planet. One does NOT need air to have sound, only some medium in which compression/rarefaction waves can propagate. The sound waves were very low in frequency and had wavelengths comparable to some fraction of the size of the universe. For the convenience of humans, who could not hear such low frequencies, I have increased them to the audio range of the human ear.

Or... One could simply say it's a rendering of J.R.R. Tolkien's _Ainulindalë_. ;)

"The Music of The Ainur", strange and beautiful.

</comment></comment><comment><USER5> Interesting speculation in light of the article I read earlier that the universe may have started out with one time and one space dimension. No "sound" then ... and no gravity.

[http://www.space.com/11470-universe-birth-1-dimension- physic...](http://www.space.com/11470-universe-birth-1-dimension-physics- theory.html)

[http://news.discovery.com/space/once-upon-a-time-the- univers...](http://news.discovery.com/space/once-upon-a-time-the-universe-was- really-weird-110321.htm)

<comment><USER6> Isn't one spatial and one temporal dimension enough for sound to exist?

</comment></comment><comment><USER7> It sounds oddly mechanical, like an overhead helicopter at times. Can anyone give a not-too-technical explanation for that?

<comment><USER8> I haven't looked at his source yet, but my guess is that the power spectrum was inverted directly back to real space/"time" domain, without randomizing the phase.

Keep a grain of salt at the ready as you analyze the problem. It's a tricky thing to do "right", and even when you're done, it's not clear that "right" will be well-defined in this case.

Edit: Since the code is a *.nb form, I can't read it directly (insufficient space/desire to install the Mathematica Reader), but from what I can glean reading it as ASCII text, the sound is synthesized from in-phase cosines. Each signal at every frequency starts together, leading to a spike in amplitude. You can see each pop very clearly if you look at the wav file over a short duration in the time domain.

The relative phases of the spectra, following the analysis that Cramer's used (inverting the angular power spectrum into sound) actually are in the raw WMAP/Planck data, and may be in print. If you have the raw temperature map and are comfortable computing the angular power spectrum, you'll have access to the phase too.

I can't find a perfect reference at the moment, but to emphasize the importance of the phase in reconstructing real-space data, check out the pictures in [1].

[1] [http://homepages.inf.ed.ac.uk/rbf/CVonline/LOCAL_COPIES/OWEN...](http://homepages.inf.ed.ac.uk/rbf/CVonline/LOCAL_COPIES/OWENS/LECT4/node2.html)</comment></comment>


Ask HN: What podcasts would you recommend? - <AUTHOR> I have a good number of hours each week when I'm commuting and I have found podcasts to be a good use of that time.  I'm sure many others on here have found the same.  I'm on the look out for some more science and tech podcasts.  What podcasts would you recommend to other HN readers? <comment><USER2> I have been binging on Darknet Diaries ([https://darknetdiaries.com/](https://darknetdiaries.com/)) Each episode deals with various aspects of infosec. The description given on the website is:

"This is a podcast about hackers, breaches, APTs, hacktivism, cybercrime, and all the things that dwell on the hidden parts of the network."

</comment><comment><AUTHOR> The Skeptics' Guide to the Universe - [https://www.theskepticsguide.org/podcasts](https://www.theskepticsguide.org/podcasts) \- Fun science and critical thinking podcast. Has been around for over 10 years. Worth it just for the Science or Fiction game each week.

Escape Pod - [http://escapepod.org/category/podcasts/](http://escapepod.org/category/podcasts/) \- Weekly science fiction podcast magazine. The quality and variety of the stories is amazing. I have found lots of new authors via the stories from this podcast. (Also has Pseudopod for horror fiction, PodCastle for fantasy, and Cast of Wonders for YA fiction)

The Infinite Monkey Cage - [https://www.bbc.co.uk/programmes/b00snr0w/episodes/downloads](https://www.bbc.co.uk/programmes/b00snr0w/episodes/downloads) \- Witty, irreverent look at the world through scientists' eyes. From the BBC with Brian Cox and Robin Ince.

Daniel and Jorge Explain the Universe - [https://www.iheart.com/podcast/105-daniel-and-jorge- explain-...](https://www.iheart.com/podcast/105-daniel-and-jorge- explain-t-29862087/) \- A fun-filled discussion of the big, mind-blowing, unanswered questions about the Universe. By a CERN Physicist (Daniel) and the author of PhD Comics (Jorge).

LRC Presents: All the President's Lawyers - [https://www.kcrw.com/news/shows/lrc-presents-all-the- preside...](https://www.kcrw.com/news/shows/lrc-presents-all-the-presidents- lawyers) \- An in-depth and often humorous look at President Trump's Legal issues. I know, not quite the normal HN sort of content, but worth it.

FiveThirtyEight Politics - [https://fivethirtyeight.com/tag/politics- podcast/](https://fivethirtyeight.com/tag/politics-podcast/) \- A geeky look at (mostly US) politics and polling.

Talk Nerdy with Cara Santa Maria - [https://www.carasantamaria.com/podcast](https://www.carasantamaria.com/podcast) \- "conversations with interesting people about interesting topics". Cara is an great science communicator and is well worth listening to on this and the The Skeptics' Guide to the Universe podcast.</comment>


MySpace, R.I.P. - <AUTHOR> http://gigaom.com/2010/02/10/myspace-r-i-p/

<comment><USER2> _The web doesn't hold much attraction for Rupert Murdoch who is now enamored with e-readers and tablets.

Tablets, according to those in the know, are being viewed as saviors for News Corp.'s core business: news and information. He thinks that since devices are not that useful without his content; he eventually wins because he will get people to win. "Content is not just king, it is the emperor of all things electronic!" he recently said._

I think he's missing the point here.

a) Newscorp has flourished as a business because up until recently media has been an industry with a high barrier to entry. To paraphrase Warren Buffett, if you own the only newspaper in town it's a bit like owning a local monopoly. The same applies for television channels, etc. which have high upfront costs.

b) The problem facing Newscorp now is that the internet has lowered the barrier to entry dramatically, so that its size and financial clout is no longer a major advantage. For instance, would you rather read an article in a Newscorp paper or one of PGs essays? In the past it'd be hard for PG to get his essays out there, now it's much easier. This means a much higher level of competition, and competition destroys margins.

c) e-Readers/Tablets don't make the barrier to entry much higher. (You can publish stuff on the Kindle for free, for instance: <https://dtp.amazon.com/mn/signin>). Hence it's hard to see how he can compete in the tablet/e-Reader space any better than he could compete online.

<comment><USER3> "This means a much higher level of competition, and competition destroys margins."

This has wider implications on the ability to profit over the long run in a capitalist society. In open markets margins should tend to zero. It seems the only way to profit would be to have some edge in terms protected market (monopoly) or slight protected technical advantage for a short period. But once the protected advantages are gone margins should tend to zero. Therefore, this isn't just a problem of old media but of all markets.

<comment><USER4> I am not sure that "margins tending to zero" applies at all to any market where the marginal cost of producing is non-zero.

<comment><USER5> Yeah it does. The margin that tends to zero is the profit margin, not the marginal cost of production. That's why the commodities business is so tough: If you make $10 profit pr. ton of CommodityFoo, someone's gonna come along and underbid you $5, unless you bring some value to the game that the new guy can't.

And that's exactly what's happened to the news business: The internet ate the newspapers USP, classifieds, and effectively turned them into commodities. Take away the classifieds and the agency-dispatches, and the rest barely fills an interesting blog.

<comment><USER4> "unless you bring some value to the game that the new guy can't." yes, like the supply of a scarce resource. This little get out clause renders your argument meaningless.

If there are only 100 tons of gold available per week, (the marginal cost of producing the 101st item is infinite, i.e. non-zero) it does not matter how many competitors there are in the market. If demand is for more than 100 tons, profit margins will not "tend to zero". This scenario illustrates that even in a commodities market a situation may arise where a large number of competitors will not cause margins to tend to zero.

Let alone situations where branding is involved etc. - all factors that we can assume are permissable under the stated condition of an "open market", and all in the category of "some value to the game that the new guy can't". So in other words your comment amounts to "yes it does, except where it doesn't"

<comment><USER5> You're confusing profit from speculation and profit from value added sales.

 _Especially_ in the gold-market, profits come from speculation, not value added sales.

<comment><USER4> No, I contend that it is you who is confused. There is only one type of profit, and I am correct that profit may be derived from demand exceeding supply irrespective of the number of suppliers. This has nothing to do with speculation, it is a basic concept of market economics that holds true in an "open market" as defined by the original commenter.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> I don't have quick access to user numbers, but Google search trends is interesting (especially when you consider the readwriteweb example today of people typing 'facebook login' into google).

Here's the comparison of Facebook, Myspace, and Orkut - [http://www.google.com/trends?q=facebook%2C+myspace%2C+orkut&...](http://www.google.com/trends?q=facebook%2C+myspace%2C+orkut&ctab=0&geo=all&date=all&sort=1)

Nothing surprising, except that there are some areas (USA? Tijuana??) where Myspace still out searches Facebook.

</comment><comment><USER7> It's hard for me to understand why people still use MySpace. I've never had an account there, but from all the user profile pages (not sure if that's what they're called) I've visited, none have been easy on the eye. Facebook seems to be the much better option to me. The Facebook fan pages can be used by most bands to build their brand and market themselves (I've only ever seen Bands using MySpace - nobody I know uses it) - maybe they should create some way for people to migrate their MySpace accounts to Facebook - that'll probably speed up MySpace's demise.

<comment><USER8> Myspace is good as a home page for musicians, due to the high availability of bandwidth for sample tracks. Virtually every musical artist who is anything at all, has a home page there.

Facebook is a poor replacement as _you must be logged in to be able to see a Facebook page_.

I don't like being spied on, so I don't have a Facebook account, and never will.

As a pure social networking site for ordinary people, MySpace's days are long over.

<comment><USER9> You don't need to be logged in to see a fan page.

</comment></comment></comment><comment><USER10> I think Myspace still has the band/musician space, largely because what Myspace allows and Facebook doesn't (restyling the page, embedded music player) are pretty necessary to artists asserting their brand identity. Which is really the main reason for them to have a presence.

<comment><USER11> Take a look at Bandcamp, it's the last nail in MySpace's coffin.

Main page, <http://www.bandcamp.com/>

Random couple of artist pages for an indication of the customization available, never mind the billing and music serving back end.

<http://redfang.bandcamp.com/> <http://danielaspector.bandcamp.com/>

<comment><USER12> The problem I see with Bandcamp is that there's no discovery portion of it. If you already know of an artist, it's great, but you can't stumble across some new artist like you can on MySpace.

<comment><USER11> Not to be sarcastic, but there is the whole internet full of tools to point people at your Bandcamp or MySpace page, in fact that's what people are doing for their MySpace music pages, promoting them on Facebook and in some cases writing their address on bathroom walls.

Also, there is something to be said for doing a single thing and doing it well. Managed hosting of musicians websites and nothing else.

If anything this is the year of overshoot, Google wants to be Facebook, Facebook wants to be Twitter (still), the Sixty One decided to be more like a glossy magazine.

Everyone wants to be your single source, conveniently forgetting that this is the internet we are talking about and not the cable or phone company.

</comment></comment></comment></comment><comment><USER13> MySpace Music is hopeless: the interface, the way content is presented, the way search results are inaccurate and incomplete. The search field isn't even selected by default.

If I were Murdoch I would be focusing on an awesome API for anyone to access any and all of News Corp's material. A content warehouse, by which large users can be charged. Uncooperating with Google is one thing, but it should be balanced with this one.

Otherwise, News could run a public talent search for hackers, like The Apprentice or Rockstar INXS, to find CEOs.</comment>


Show HN: Pocketsquare – portfolios for developers - <AUTHOR> https://pocketsquare.io <comment><AUTHOR> Hey guys, thanks for checking out Pocketsquare. I built this to give devs a better way to showcase their work. For me, my public Github page isn't always the best representation of the stuff I like to work on, and LinkedIn isn't optimized to show dev work.

So, Pocketsquare focuses on just showing your skills, projects (may or may not correspond to a git repo) and code snippets. You can also show work experience or education. I tried to make it simple and straightforward for non-technical visitors yet also visually appealing so it's something you want to show people.

Thanks again and I appreciate any feedback you guys have.

Edit: I didn't have time to put social links on the landing page, so for anyone who wants to stay up to date as I make pocketsquare more awesome, you can follow the Twitter account here: [https://twitter.com/getpocketsquare](https://twitter.com/getpocketsquare) or add your email to this list and I'll let you know when new features roll out: [http://bit.ly/1RvGHIn](http://bit.ly/1RvGHIn)

Thanks!

<comment><USER2> Cool idea.

> Oh, also: it's free.

Your target users, developers, have the "I'm a product" meme at the front of brain. It certainly immediately came to mind when I read that.

I'm not saying you _are_ selling me, but some treatment of that concern might make the paranoid wing (proud member) more comfortable.

And if you are selling me, well, nothing wrong with that, but be up front about it.

<comment><AUTHOR> Good point - I should probably spend more time working out the text on the landing page, as I could see how that could come off wrong. To be honest right now I'm just focused on making users happy with a product that's useful for them so I haven't given too much thought as to what's next. Thanks for pointing that out though - I'll definitely think about it.

<comment><USER3> And that's perfectly fine, but then you end up on the other side of the coin which is:

"How do I know you don't plan to sell me out down the line or that you'll disappear in a few months once I've invested time and energy into setting things up?"

So really you need to make sure both are addressed ;)

Congrats on shipping!

</comment></comment></comment></comment><comment><USER4> _Code repos are also hard to digest for non-technical folks_

And that's _exactly_ what the gh-pages branch in a repo that generates a Github Pages/Jekyll site addresses - [https://pages.github.com/](https://pages.github.com/)

This is an admirable effort but I feel it's going about the problem the wrong way. The presentation is very rarely the problem with developer websites. It's the content that's the problem. No amount of fancy bootstrap veneer is going to fix someone failing to write documentation for their project or themselves, especially when Github makes it _very_ easy.

<comment><AUTHOR> Thanks for the feedback. I'm a fan of Github pages and Jekyll and have used them for several projects. Github pages are great for explaining individual repositories but I think they serve a different purpose than Pocketsquare.

Pocketsquare is more of an overview of what you do, letting you showcase multiple projects in one place and talk about different skills, language and frameworks you know, as well as highlight your experience and education background if you'd like.

</comment></comment><comment><USER5> 15-20 language/framework icons don't tell me much, despite telling me too much. what's the estimated level of expertise? I don't believe someone who shows that many different things is a master at any of them (whether they are or not, I don't believe it). grouping those icons - data, web, language, etc - might help as well.

</comment><comment><USER6> I don't see how the snippets bring value to the portfolio, can't imagine a use case.

Anyway good initiative!

<comment><USER7> Snippets provide a way to showcase concise bits of code or programs. I think of it as a place to centralize jsfiddles that emphasize specific interactions or examples of some particular software concept or architecture.

<comment><USER6> Yep, and that's very nice/useful for a blog post, but it feels weird in a portfolio. It's like "hey, I'm XX, those are my strong skills, and check this neat piece of code".

<comment><AUTHOR> I do see your point, and I'll just have to see if it's something users want and are using, or not.

</comment></comment></comment></comment><comment><USER8> Needs a sign-up/sign-in with Github button

<comment><USER9> I would also add portfolio integration with github. Having to manually replicate code over to a new site will turn some people away.

</comment></comment><comment><USER10> Yeah, you need to add more languages and frameworks, and not just the things that are out and popular now. I'd want to include projects from awhile back, personally, and that includes projects made from Flash. I know its unfashionable now (and I no longer use it), but it's how a lot of devs got started.

If you want game developers to find this useful, you might want to consider adding:

C++, C, Unity, Unreal SDK, Cocos2D, Lua, Flash, Havok, Direct X, OpenGL, VR. Maybe show a list of consoles to show specific console dev experience.

<comment><AUTHOR> Thanks for the tip on gaming languages. And I agree on Flash - I actually started as an AS3 dev so should've known. More languages/skills are coming soon.

<comment><USER11> You should also think about catering to data scientists. It's not an option in the "specialty" dropdown and you don't have languages like Scala, R, Julia, or MATLAB.

<comment><AUTHOR> Yeah I had that same thought actually. Data scientists are becoming more common lately.

</comment></comment></comment></comment><comment><USER12> Just a suggestion...

If you are going to have a big list of icons the first thing that comes to mind is "Click on one". Analysis of programming language(s) used isn't hard given its built into the GitHub api:

[https://developer.github.com/v3/repos/#list- languages](https://developer.github.com/v3/repos/#list-languages)

So if you allowed an "import Github Repo option" then linked those icons to the "examples/repositories/snippets" in those languages that would help.

You already seem to be able to designate icons-per-project/snippet so you shouldn't need to add much beyond a hyperlink on the icon that scrolls to the first appropriate projects and/or allows the user to designate the project to scroll to.

I'd say have a page listing the relevant projects as well by technology [e.g. A "Would you like to know more...?"] but I'm not sure that should be the default behavior.

Similarly, I'd encourage/enforce linking to test suite(s) and/or documentation as a requirement to list anything larger than a snippet. That might be a bit too opinionated but I think it encourages "new" developers to get into the right practice of having some sort of documentation [even if it is just a test suite].

</comment><comment><USER13> You're making use of the deferred anti-pattern [0] on your own profile page [1].

[0] [https://github.com/petkaantonov/bluebird/wiki/Promise- anti-p...](https://github.com/petkaantonov/bluebird/wiki/Promise-anti- patterns#the-deferred-anti-pattern) [1] [https://pocketsquare.io/alanfriedman](https://pocketsquare.io/alanfriedman)

<comment><AUTHOR> Because "request" returns a promise? I created the deferred object because I'm waiting on multiple async operations (get gravatar url, download gravatar locally and upload to s3). Or am I missing something?

<comment><USER14> The trick is learning how to compose promises out of one another. For instance, then() on a promise doesn't just support a callback, but another promise or a function that returns another promise. Often you can build multiple async operations as chains and flows of promises. Additionally there are "higher level" compositions of promises such as Q.whenAll(promise1, promise2, ...).then(), making it easier to deal with things like parallel promises.

Also, it's often cleaner to use something like Q.nfcall to turn a callback accepting function (like request in your example) itself into a promise that can be chained. (I just noticed that this is contrary to Q's own documentation which surprisingly is pro-deferred.)

</comment></comment></comment><comment><USER15> You need a better differentiation between skills - this is very web orientated at the moment. If I'm a native mobile developer is that full stack? Backend?

There also needs to be a bigger range of languages. Alternative contact details would be nice, or, links to other profiles and the option not to show the email address.

<comment><AUTHOR> Yeah, one of the most common requests I've gotten is adding more languages/frameworks, and I'm working on getting that out as soon as possible. It is very front-end dev focused at the moment, so I'll be broadening the options to give all developers what they're looking for. Thanks for checking it out!

<comment><USER16> I think the request was to add other options besides Front/Back/Full.

</comment></comment></comment><comment><USER17> I see a few great suggestions from people here, but I want to add — I see the grand vision here. This is a great "First-step" in this direction. I feel it's great because it does away with the shitty "sign-in-with-github-and-youre- done" thing. Comprehensive, yet minimal. I like it.

<comment><AUTHOR> Thanks!

</comment></comment><comment><USER18> Good work so far. Just a few things:

\- I graduate from university in 2016, but I can only choose up to 2015 for the end date

\- This is in Chrome 45, Windows 8.1: [http://i.imgur.com/u5xMXob.png](http://i.imgur.com/u5xMXob.png)

<comment><AUTHOR> Thanks - I'll think about how to incorporate future dates. And wow those scrollbars look terrible. Sorry about that! I think I can fix it pretty easily with CSS overflow.

<comment><USER12> I'd suggest to do this year +10 and set the input to the current year. That should cover pretty much anyone.

</comment></comment></comment><comment><USER19> It's a fine line between "minimal and designery" and "understyled". I think this falls slightly to the wrong side.

Also, the icon thing encourages people to check the most number of boxes, even if they're not skilled there. This is reasonable and something lots of devs do, but it will hurt your appearance to people who hire. Everyone I've ever talked to about hiring developers has an opinion somewhere in the realm of "I'd rather see resumes with one or two languages that they're strong with, than have to spend time fishing out which of 20 languages they actually write every day"

<comment><AUTHOR> Fair points. As for the design, it can always be tweaked, but I have gotten positive feedback around the simplicity and minimalist look so would have to think it through.

As for the icons, my theory is that devs are free to add whatever skills they want to their own portfolio or resumé anyway, but they're going to ultimately be responsible for demonstrating that knowledge to employers, clients, etc, so it probably wouldn't be beneficial to them to exaggerate their skills. I do see your point though.

</comment></comment><comment><USER20> Looks great! I recently revamped my freelancing homepage and something like this would have made the process much quicker.

By the way, I noticed your site returns a server error for pages that aren't found instead of a 404 e.g. [https://pocketsquare.io/notfound](https://pocketsquare.io/notfound)

<comment><USER21> If you're interested NeedProgrammer also offers simple dev profiles for freelancers: [https://needprogrammer.com/#/profiles/developer/zach-van- nes...](https://needprogrammer.com/#/profiles/developer/zach-van-ness)

</comment></comment><comment><USER22> I'm sorry but I feel like you have to do more than whack some icons on a bootstrap page for something like this. That level of simplicity requires exceptional presentation for it to be valuable.

<comment><AUTHOR> Thanks for the feedback. What kinds of features would make it more appealing for you?

</comment></comment><comment><USER23> What/where is your privacy policy?

<comment><AUTHOR> I plan on adding it today and will send it to any users who signed up before it was posted. I know how important it is so it's my top priority to finish by end of day.

</comment></comment><comment><USER24> Nice work man, I am working on something similar - would be cool to chat? PM me on twitter @desicochrane

</comment><comment><USER25> I... can't change my password. Nice and clean look though!

<comment><AUTHOR> Sorry about that - it's at the top of my list!

</comment></comment><comment><USER26> As I said on reddit yesterday, I like it, keep up the good work

<comment><AUTHOR> Thanks!

</comment></comment><comment><USER27> issue: Can't reorder experience items and they are not sorted by date.

<comment><AUTHOR> Yeah, this is on my list for sure. Projects, experience and education will all be sorted by date until there's an option to manually sort. I'm working on it!

</comment></comment><comment><USER28> Any custom domain love?

<comment><AUTHOR> Absolutely - it's on the roadmap.</comment></comment>


How to Build a CI/CD System with GitHub Action in Nebula Graph - jamie-vesoft https://nebula-graph.io/en/posts/automate-workflows-with-github-action/ <comment> jamie-vesoft Thanks for your feedback and sorry for the user experience. Is there an element that you feel specifically hard to read? For example, code snippet?

Are you reading on mobile? As to "the share hover", do you mean the popup?

</comment><comment><AUTHOR> UI makes it hard to read + the share hover

[https://outline.com/2MqJcX](https://outline.com/2MqJcX)</comment>


Swandive: create an EC2-based VPN for your iPhone (uses IPSec/L2TP) - <AUTHOR> https://github.com/iandennismiller/swandive

<comment><AUTHOR> I wrote Swandive because I really needed a VPN for the road. Even though OpenVPN is so easy to set up, it's not compatible with iOS devices, making it a non-starter. IPsec/L2TP are the standards-based way to do it, but it's much harder to set up... all the more so because IPsec relies on some non-standard IP packet types, and my home router isn't capable of handling it. I wanted to run my VPN in EC2 because those machine instances are essentially disposable, but EC2 presents all sorts of new problems...

In the end of the day, it was really non-trivial to get this set up, so I decided to package the process for everyone.</comment>


How do you measure motivation of your startup team? - <AUTHOR>

[maybe to many question marks here... but I've been dealing with this questions for some time]
I believe my team is happy and motivated. But: - Can I prove it?
- Can I improve it?
- Can I measure this improvement?
in a realistic and easy way? <comment><USER2> There are only two ways I know of.

One is just having social skills. You should be able to tell when someone isn't happy; you should notice when someone doesn't fully engage in a debate in which they should; and when they don't meet your eye about something.

The other way is to look at the details of how they behave. This is how I notice when I myself am not motivated about something. I notice that sometimes I still "feel" motivated and cheerful, but I start turning up a little late. And there's always a good reason for it -- but looking at the pattern from the outside, there's a hint something is wrong.

</comment><comment><USER3> You have to look into the eyes:))) Eyes are not lying. Plus everyone wants more... so you can't make them happy anyway.</comment>


Show HN: Minimum Viable Technology (MVT) – Move Fast and Keep Shipping - <AUTHOR> https://www.linkedin.com/pulse/minimum-viable-technology-mvt-move-fast-keepshipping-ajay-shrivastava?published=t <comment><USER2> Great article, most startups miss the deadlines and it's a major reason

<comment><USER3> Totally agree

</comment></comment><comment><USER3> An awesome article

</comment><comment><USER4> Insightful..</comment>


Intern at the Free Software Foundation - <AUTHOR> http://www.fsf.org/volunteer/internships <comment><USER2> Why work on administrative trivia for no money for the FSF when Google will pay you to actually write free software?

<comment><USER3> Well, my hat is off to the talented individual who, despite having lucrative opportunities elsewhere, recognizes the importance of what free software means to the world.

<comment><USER2> Sitting in FSF's office has very little to do with free software. Actually _writing it_ and _improving it_ is what the world needs.

<comment><USER4> I disagree, the FSF offices are responsible for ftp.gnu.org which is a free high bandwidth mirror, and savannah.gnu.org which is a free project hosting site. Both of those are things developers and the world need.

Also in the FSF office they spend time educating people on open source licenses so that the free software that is written is not abused. Again, something we still need.</comment></comment></comment></comment>


Linus: What's Wrong With The Whole DRM Crowd? - <AUTHOR> http://www.phoronix.com/scan.php?page=news_item&px=ODgwMQ <comment><USER2> This is in reference to the direct video hardware access module in Linux, not _digital rights management_. But it is mostly about the polite use of git in Linux kernel development.</comment>


Ask HN: Would you guys like to have a Wikipedia for book summaries?  - <AUTHOR>

Hey guys! Currently brainstorming on the next thing to work on (previous project: www.onecentmovement.org where we were turning everyday transactions into opportunities to give to charity through a round-up logic).
I've been going through our idea list and need some feedback/help here. One of the top ideas in our minds now is a Wikipedia for book summaries.
Problem: Are there books that you would just like to not read but know the summaries?
Solution: A place where users can submit their summaries and dig the good ones right up to the top.
Would you use it? <comment><USER2> Gnus,

I think something like that would be really useful. I've been messing around with summarizing public domain books for (<http://summary.io>) summary.io.

If you want to do something together, let me know!

</comment><comment><USER3> Sure. And there are plenty of people who miss the rush of getting an "A" on their English papers who would happily write the content for you.

</comment><comment><AUTHOR> BTW, here are some great book summaries by Derek Sivers himself!

<http://sivers.org/book></comment>


Beta launching Professional Analytics for Linkedin, check it out  - <AUTHOR> http://predikt.co/

<comment><USER2> Looks interesting, but how does this compare to services like Klout, Peerreach, Peerindex, Kred etc.? At first sight it looks like a sort of reputation score like the other services.

<comment><AUTHOR> Thanks. It predicts your professional expertise in specific domains for specific roles based on data from user's profile as well as similar other profiles. Sample representation: "Score of 67 in Data Science domain for Data Scientist Role". Multiple factors such as education, work etc. go into algorithm (much more being added). Klout, Kred etc measure social influence based on how much you engage and interact on the web.</comment></comment>