Ask HN: Sell project? - <AUTHOR>

Hi all,
I guess I am not alone with this kind of situation, let me explain:
So, a couple of years ago I was writing together with some colleagues this php-project - a real estate platform targeting the German market. Its not a small hobby project, but still never made any money - which is the point. Because, after some initial response from the market, we knew we had to put in some extra effort (mainly features the market requested),  but we had no time since (family, other jobs, projects, ...). Now is the time to either take the whole thing down or sell it, because keeping it running is not a real option anymore.
I am neither sure where to look for people who are interested, nor at which price-point. Of course, as some things are not finished the market requests, the whole traction is just missing. The project is now 5 years old, running since then without problems, but was not developed since anymore. It took around 400 man-hours to complete everything. At the end, its very sad, since it was running a lot of time, money and heart into the project, but that doesn't count, I know I know...
Do you think, is something like this sell-able, or should we just take it down? Where would you look for buyers for such a thing?
Thank you for your answers. <comment><AUTHOR> Thanks everyone for the infos, sorry for responding so late, busy as usual :)

Well, the platform would be a good start for anyone who wants to start off with real-estates in any way in Europe. Direct competitors to a real-estate platform: yes, many, as its "only" a platform. Expendable to what the market wants - speaking of more of a real-estate management software.

Doable up to this point in less than 400 hours? Probably not significantly less. A lot of time was running into the details: e.g. Import/export to and from other portals, looking into open formats around in Europe. Legal situation. What software has to be supported, etc... As always, theory and practice are two different things. One would pretty quickly find its boundaries if coming from the US and plan to do anything in the European markets. A clear advantage when doing something here from Austria, right in the heart of the EU. Except someone has millions to invest, then it doesn't matter. Anyways.

So, basically, interesting for people who want to do something with real estates at the European markets. Who plan to extend the functionality and who are lacking the $200k+ seed money. Who do not have the time and the energy for extensive research on those markets.

the userbase: around 1k registered users (mainly estate agents) with around 1.5k active estates currently online. We clearly lacked of marketing, and the endurance to properly market the product. It was a naive idea at the beginning - no question to that - but lack of time, money and motivation let the whole thing fade away.

<comment><USER2> Thanks for the extra information.

With only 1k users and many direct competitors you would probably find it hard to find a buyer. It's not the 400 hours you have invested that is the issue, it's the number of hours required to add the requested functionality. That same effort could be, in principle, applied to any of the competing platforms to increase their functionality.

As learning experiences go, you learnt your lessons very cheaply.

</comment></comment><comment><USER3> Well taking it down does not seem to be a good idea. You should atleast wait a little more and try to sell it. Its worth trying than taking it down right away. You can put banner on your website, letting people know that you are selling the product. Or you can pitch existing similar but low features websites and show them your more powerful feature rich product.

</comment><comment><USER2> You say it (your RE platform) has been running for 5 years. How many people are using it? Why do they use it? Is there anything out there that directly competes with it? Would it be applicable to other countries?

Lastly, but most importantly, do you or any of your colleagues have the time and energy to make the effort to sell the website?

Perhaps if you could answer these questions then HN-folks might be able to make more useful suggestions.

</comment><comment><USER4> It's very doubtful you'll be able to sell a product that doesn't make any money. Especially a very old project with no updates.

The price for small websites is usually a multiple of revenue e.g. 2-5 times yearly revenue. Since your revenue is 0, the price would end up 0.

That being said, the [https://flippa.com/](https://flippa.com/) is a marketplace where people buy & sell websites.

<comment><AUTHOR> Thank, you. I didn't know neither the formula, nor the website.

</comment></comment><comment><USER5> I doubt that you'd be able sell it. Software itself isn't worth much, the traction and user base is what counts. Also, what took 400 man-hours 5 years go may only take 40 hours today due to new technologies/platforms.

Related read: [http://avc.com/2014/07/the-dentist-office-software- story/](http://avc.com/2014/07/the-dentist-office-software-story/)

</comment><comment><USER6> Hellow, There is many ways to sell your project, if you want to. and for your question that if you should sell or take it down? my advice is , it depends on your feelings or what you feel about i, if you want to sell or just take it down?

regards,

Edward</comment>


Coding Horror: Classic Computer Science Puzzles - <AUTHOR> http://www.codinghorror.com/blog/archives/000951.html <comment><USER2> I like the Lisp link:

 _The Volkswagen Lisp is the most configurable and powerful car in automotive history.

The Lisp was invented in 1958 (some say discovered) and the automotive world hasn't been the same since._</comment>


10 Best Practices of Code Commenting & Formatting - <AUTHOR> http://www.dotnetcodegeeks.com/2012/03/10-best-practices-of-code-commenting.html

<comment><USER2> When I worked at Google I was blown away by their attention to readability. It makes sense when they preach that any employee (having passed readability for a given language) can commit code to any project. What surprised me most? Extra spaces. After parens, brackets -- anywhere midline you can. This makes it easier to read any line of code and scan the whole document. Of course, they compile and minimize everything before it runs in production.</comment>


The Hazards of Google+  - <AUTHOR> https://img.skitch.com/20110701-qebn1b6ykcee3nj8tewk2chk3g.png

<comment><USER2> I wonder why Google didn't implement a delete option. Facebook has it.

<comment><USER3> There is a delete option. Similar to Facebook one.

</comment></comment><comment><USER4> This causes lot more embarrassment. It's time for "Google+ Goggles"</comment>


How to hire recruiters - <AUTHOR> http://blog.jaredfriedman.com/2015/08/11/how-to-hire-recruiters

<comment><USER2> I think having a "recruiter" is a problem. When I interview for technical positions, I know that if I am speaking to HR people or a recruiter, that I am unlikely to get any valuable information out of them, and they will almost always try and get my current salary information from me. I would far rather speak with the technical team that I will be working with.</comment>


The European Startup Map - <AUTHOR> http://www.thestartuparena.com/european-startup-map/

<comment> tomh- Many companies on the list are not startups, to name a few: skype, mysql, spil games, unity and rovio.

<comment><AUTHOR> True, I used the term loosely, perhaps I should have said "tech companies founded by Europeans"

<comment><USER2> cool idea, but I can think of plenty of startups not listed

<comment><AUTHOR> I know, you're right, but I thought I'd start with the ones I knew about and then let founders add their own startups to the list.

</comment></comment></comment></comment><comment><USER3> Your signup form doesn't work; asks for the Recaptcha API key.

<comment><AUTHOR> Thanks, I've taken care of this bug.

</comment></comment><comment><USER4> Is there a law against them in France?

<comment><USER5> There's a few near the Belgian border -- but yes, France is, in general, not the startup-friendliest country in the world. Comparing with the UK, it might just be network effects, but I'm not convinced that's all of it.

Additionally (disclaimer, I'm Belgian), I would not start in France because of the fear of _future_ laws. They seem to be pulling a lot of crap -- I don't really know if it's because they're clueless or malicious, but either way I'm not putting up with it.

<comment><USER6> Could also be a self-selection effect. It is far from certain that non- Anglophone startups are just as likely as Anglophone startups to enter themselves on an English website.

Don't get me wrong, this is evidence, but it is fragile and problematic.

</comment></comment></comment><comment><USER7> For a global overview of startup locations you can also take a look at <http://startup-map.datalysed.com>

<comment><AUTHOR> Thanks for the link. Good idea to group the startups by area, this solves the marker overlapping problem. Does it only display the number of startups or can you also list startup details?

</comment></comment><comment><USER8> Interesting. Quite a few venture capital firms nearby (Cologne), but I don't see any actual startups until I zoom our far enough to see the startups in other countries. (and one in Karlsruhe).

Wonder what that means.

<comment><AUTHOR> Yes, it's a problem with the markers overlapping, I'm still looking for a solution to it.

<comment><USER9> See [http://www.appelsiini.net/2008/11/introduction-to-marker- clu...](http://www.appelsiini.net/2008/11/introduction-to-marker-clustering- with-google-maps)

<comment><AUTHOR> Interesting post, thanks for the link.

</comment></comment></comment></comment><comment><USER10> Wow, thanks for this one. Until now, I didn't even know there were any angel investors in my country. Now that I know there are... well, I might just try my luck with this whole startup thing :).

<comment><AUTHOR> What country is that? It's great to know it's useful, there are still a lot of investment funds to be added, so it might be even better than you think. ;) Best of luck with "this whole startup thing" if you decide to try it! :)

</comment></comment><comment><USER11> Polldaddy came from Ireland? Cool, I didn't know that. Surely there are loads more to be added though, right?

<comment><AUTHOR> Oh yes, there are tons, but I thought the YC community is a good place to collect more startup info :)

</comment></comment><comment><USER12> Cool map. But please remember we don't use Euros in Sweden the UK, the Ukraine.

<comment><AUTHOR> Thanks. I know, but the map is not just about the countries using Euro, it's about all countries within Europe's geographical boundaries.</comment></comment>


The Quantum Theory and Reality (1979) [pdf] - <AUTHOR> https://www.scientificamerican.com/media/pdf/197911_0158.pdf <comment><USER3> Wave function collapse is not observed physical phenomenon. Some interpretations of QM require it to exist, but there is no empirical evidence of that happening.

Apparent wave function collapse happens when a wave function in a superposition of several eigenstates appears to reduce to a single eigenstate. The apparent wave function collapse collapse is mathematically equivalent of quantum decoherence where the wave function never really collapses but the states gets entangled with the observer.

If somebody were able to formulate and experience that would show the difference between decoherence and collapse, that would be new physics and we would be able to rule out some interpretations of quantum mechanics. Until that happens, 'shut up and caluclate' seems to be valid course of action.

As far I understand, the philosophical difference between apparent and actual wave function collapse is that in the apparent collapse probabilities of other states get so close to zero that they don't matter, in actual collapse they are exactly zero.

The assumption that human consciousness has something to do with setting all other states to zero is weird one and can't completely understand the assumptions behind it. I guess the idea is that we would not experience the world as we experience it now if there is just continuing decoherenće.

<comment><USER4> The philosophical difference is that without collapse, all of the eigenstates contributing to the intial state will get entangled with their own 'copy' of the environment, which is where the moniker _many worlds interpretation_ comes from.

<comment><USER3> What is unclear to me in the many-worlds hypothesis is the reason whey these 'copies' don't constantly interact with each other and lead to continuous decoherence.

How this is justified?

<comment><USER5> Each of the worlds ends up distinct, e.g. all the air molecules end up in slightly different positions. Worlds that different don't interfere with each other. (This is predicted by the math, the math is the justification.)

</comment></comment></comment></comment><comment><USER6> Ok, I'm going to hijack this thread to get an answer to something I've always struggled with: how does 'observation' cause the wave function to collapse.

It won't happen in a closed box, but what about an open box in a closed room? What about a closed box with a live video camera? What about a live video camera whose display no one is watching?

I'm sure this is a basic question but for the life of me, I've never really understood it. Thanks.

<comment><USER7> The standard story about measurement/observation and quantum collapse is not the only interpretation of the available data.

There are, broadly, three kinds of interpretations of what's 'really' going on behind the scenes:

1\. Collapse - The world exists in an indeterminate state until observation occurs, when the world collapses into one a single determinate state. The probabilities of quantum mechanics map onto the the different parts of the unobserved indeterminate state.

2\. Many Worlds - Quantum phenomena cause the world the branch into multiple worlds. The probabilities of quantum mechanics represent the 'share' of reality that branches in each direction.

3\. Hidden variables - The probabilities of quantum mechanics are artifacts of our inability to know all the relevant variables. Measurement necessarily involves causal contact, and causal contact will always disturb some of the relevant variables in unpredictable ways. It would be cool if we could observe what goes on when measurement occurs, but to do that would require measurement! So we're stuck with hidden variables.

The public tends to hear the collapse interpretation most often. Physicists tend to like the many worlds interpretations. Philosophers of science tend to like the hidden variables interpretation, because the other options require an incoherent metaphysics. (I'm a Philosophy PhD student.)

People say that the hidden variables interpretation is ruled out on experimental grounds, but this is demonstrably false. Experimental data shows that hidden variables, if they exist, violate locality:

Locality - Causal interaction is a local phenomena. No action at a distance.

So long as you're willing to abandon locality, hidden variables can work. Given that the other two interpretations posit equally weird things, abandoning locality won't seem so weird.

For more on this, see Tim Maudlin's excellent paper, "Three Measurement Problems"

[https://www.academia.edu/32885328/Three_measurement_problems](https://www.academia.edu/32885328/Three_measurement_problems)

<comment><USER8> > Physicists tend to like the many worlds interpretations.

According to Sean Carroll, this is because if you 'buy' the mathematics of the wavefunction, even before collapse you _already_ have to accept "many worlds" at the quantum level. "many worlds" for them simply means superposition/linear combinations. After all, if you _already_ accept "superposition" at the level of quantum states, you don't have to invoke anything _new_ to deal with so- called "collapse", if everything simply stays as superpositions i.e. linear combinations.

Or, in other words, if you assume classical behavior _first_ , and you need to get that out of superpositions at the quantum level, you need wavefunction collapse.

but if you _start_ with superpositions at the quantum level, you already have superpositions, and then classical behavior can simply be derived from locating yourself in one of those superpositions.

Explained this way, "many worlds" doesn't seem so shocking, if you have already resigned yourself to quantum level superpositions.

I think of many worlds as kind of a literal interpretation that quantum superpositions are fundamentally real, as opposed to quantum superpositions merely being a very accurate mathematical model. (Most scientists think QM represents something real instead of some lucky equations.)

<comment><USER9> This sounds a lot like someone has fallen for a subtle confusion of map and territory...

<comment><USER10> At some level, if we take scientific theories seriously as descriptions of the world out there, and not merely tools for prediction, then we have to assume some sort of isomorphism between the map (our theory) and the territory (the world), even if they're not the same thing. This isn't only for quantum theory.

<comment><USER7> > we have to assume some sort of isomorphism between the map (our theory) and > the territory (the world)

But a mathematical model != a theoretical model. The very same mathematical model will be compatible with uncountably many theoretical models. (By 'theoretical model' I mean something like 'an interpretation of what the math is representing'.)So you can't read off theoretical structure from mathematical structure. And so you can't read off the structure of the world from mathematical structure.

<comment><USER11> > (By 'theoretical model' I mean something like 'an interpretation of what the > math is representing'.)So you can't read off theoretical structure from > mathematical structure. And so you can't read off the structure of the world > from mathematical structure.

Occam's razor favours a theoretical model that corresponds more closely to the mathematics, rather than one that adds a bunch of epicycles to arrive at a different interpretation. If you follow your logic then you can never reject geocentrism, because it's possible to create a geocentric model that generates the same predictions as a heliocentric one; nevertheless we would generally say that heliocentrism is "more true" and "more physically real" than geocentrism.

<comment><USER12> What Occam's razor favours is irrelvant. It has no predictive power [1]. The more complex answer is just as likely to be the correct one.

[1] [http://scienceblogs.com/developingintelligence/2007/05/14/wh...](http://scienceblogs.com/developingintelligence/2007/05/14/why- the-simplest-theory-is-alm/)

<comment><USER11> Physics tends to be simpler than we originally thought, and Occam's razor correctly predicts this: electricity, magnetism, and light turn out to be facets of the same phenomenon, electricity and the nuclear forces turn out to conform to the same theory, electromagnetism, gravity, and spacetime turn out to behave in the same way. Your link's lazy "11 dimensions! OMG!!!1one" non- argument is in no way an adequate refutation of that history.

<comment><USER12> You're cherry picking. You pick the places where Occam's razor picks the correct answer and ignoring all the places it doesn't. For any _new_ situation we can't predict which of those possibilities the answer will fall. Hence my statement that Occam's razor has no predictive powers.

I just linked to the first article I found that talked about the subject. And it's interesting that you look for something lazy instead of addressing more serious issues like Newton's model vs Einstien's. Very clearly the (much!) more complex answer is more correct than the simple one. Here's [1] another link discussing the issue and gives 2 examples.

[1] [http://neuralnetworksanddeeplearning.com/chap3.html](http://neuralnetworksanddeeplearning.com/chap3.html) Search for "Occam"

<comment><USER11> > I just linked to the first article I found that talked about the subject. > And it's interesting that you look for something lazy instead of addressing > more serious issues like Newton's model vs Einstien's.

You should give links you're willing to stand by. I didn't go looking for something lazy, I went looking for talk about fundamental physics (where Occam's Razor is appropriate, and what we're talking about) and found only the barely even wrong throwaway line about M-theory.

> Very clearly the (much!) more complex answer is more correct than the simple > one.

Newton and Einstein don't make the same predictions. When you include the amount that you'd have to add on to Newton's theory to generate the predictions Einstein gives you about the behaviour of light, Einstein ends up simpler.

> Here's [1] another link discussing the issue and gives 2 examples.

The "new particle" example shows the opposite of what's claimed. Bethe's only reason to dismiss a new particle as an explanation was Occam's razor. The part about Newton/Einstein is just wrong about the history; relativity wasn't developed as an effort to explain the orbit of Mercury, it was developed out of Maxwell and Lorentz's work on electromagnetism. A universe in which the only reason to believe relativity was those deviations in the orbit of Mercury probably would be a universe in which the true theory was Newtonian gravity with small correction terms, not a universe in which relativity was true.

<comment><USER12> >Bethe's only reason to dismiss a new particle as an explanation was Occam's razor.

Thank you for pointing out the other fault of Occam's razor: both sides of most arguments tend to assume the razor is on their side. This aspect was addressed in the second article I linked.

<comment><USER11> It's possible to make a mistake in the application of any principle, particularly when the mistake suggests you've made an important discovery. I think there would have been a clear consensus among third-party physicists that the razor favoured Bethe in that case.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> It's worth mentioning that "quantum theory" has no implications for consciousness, especially given the headline proclaiming the opposite. There are plenty of interpretations that don't involve consciousness at all - <USER2> hopefully my use of the word interpretation clues you in to the fact that this is isn't really a physics question.

Weird philosophy aside, this does look like a good explanation of the Bell inequality.

</comment><comment><USER8> No, you don't need consciousness. Since 1979, the concept of decoherence has replaced consciousness in the understanding of QM.

</comment><comment><USER14> I'm deeply sick of the absurdly drawn-out living death of the Copenhagen interpretation, and its even more absurd "consciousness is made out of magic" descendants. This is bordering on straight-up irresponsible misinformation.

<comment><USER15> What do you mean? What is the death of the Conpenhagen interpretation?

<comment><USER16> The Conpenhagen interpretation is flat out wrong by any reasonable philosophy of science. You can choose many-worlds interpretation, or pilot-wave theory and either one would give you a consistent, simpler explanation of what is going on then some mumbo-jumbo hocus pocus about consciousness and observation of cats in boxes, with fewer assumptions to boot, and no paradoxical conclusions that require religious like mysteries to explain.

Yet for inane reasons the Conpenhagen interpretation is still ALL that is taught to the next generation of physicists, who in turn teach it to their students. Only the weird physics students (like me) who go "wtf?" in class and refuse to believe the teacher go out and learn pilot-wave theory (my preference) or many-worlds interpretation to re-inject some sanity into the world.

<comment><USER17> > The Conpenhagen interpretation is flat out wrong by any reasonable > philosophy of science.

AFAIK, this is an exaggeration to the point of incorrectness.

The Copenhagen interpretation may be a poor interpretation which introduces absurd complicated ideas rather than the simpler ideas of other interpretations, but that doesn't make it "flat out wrong".

<comment><USER16> You ignored the "philosophy of science" part. Philosophy of science is how we decide which of two theories is "correct" when they offer the same experimental predictions. See also my reply to a sibling comment.</comment></comment></comment></comment></comment>


Show HN: TopShots – Your top nine Dribbble shots from 2016 - <AUTHOR> https://topshots.co/ <comment><AUTHOR> I got talked into a NYE hackathon, and we built a way to see a Dribbble users top shots for 2016.

Inspired by the best of nine sites for Intagram, we thought it was be interesting to see what was popular in the design community with a tool like this.</comment>


Police issue warrant for Amazon Echo data to help crack murder case - <AUTHOR> http://mashable.com/2016/12/27/amazon-echo-murder-trial/ <comment><USER2> This is a dupe. This story was posted like 20 times in the last few days. Here are the most popular discussions...

* Police seek Amazon Echo data in murder case | Hacker News || [https://news.ycombinator.com/item?id=13263894](https://news.ycombinator.com/item?id=13263894)

* Amazon refuses to let police access US murder suspect's Echo recordings | Hacker News || [https://news.ycombinator.com/item?id=13269930](https://news.ycombinator.com/item?id=13269930)</comment>


Study: To Beat Loneliness, Visits Must Be Real, Not Virtual - <AUTHOR> http://www.wsj.com/articles/to-beat-the-blues-visits-must-be-real-not-virtual-1464899707 <comment><USER2> As someone who has struggled with this, it is always quite illuminating to me to see the difference between going to a public event by yourself v. with one or two other people. Just one companion/compadre makes an almost binary difference in terms of feeling "like everyone is questioning why you are there by yourself". Two companions are best as conversation can peter off with just one. The point of this is - invite along people to things you might have gone to yourself in the past. The more advanced level is approaching people around you like this is something you do normally. Good luck, I know how easy it is to fall into a social rut - and it just takes one friend to change everything (for going out).

<comment><USER3> > feeling "like everyone is questioning why you are there by yourself"

This sounds like [https://en.wikipedia.org/wiki/Spotlight_effect](https://en.wikipedia.org/wiki/Spotlight_effect) In reality it's likely that nobody noticed you much at all, and almost certainly didn't care to analyze why you're by yourself or even if you really are by yourself.

It can be actually liberating to realize that random strangers you're not interacting with couldn't care less about you short of some kind of medical emergency (and sometimes even then...)

It can be more fun to go to events with people. It can also be more fun to go by yourself. Just realize either way people around you are unlikely to care or even notice either way.

<comment><USER4> Not to sound like too much of an egotist but some of us really are noticed an awful lot and spotlight effect sounds pretty alien to me. I am very tall (over two meters) so that is definitely part of it. I am very outgoing and I tend to go to events alone (because few friends share all my interests and I am fairly antisocial and impatient). All that congeals into many people remembering me and I don't remember them (except interesting stories separated from identities). I don't think most people remember me but many do, they have told me so. It would be quite an experience to just be able to be unnoticed in a crowd but it is one I have never really experienced in larger crowds as there is always some extrovert introduces themselves. I daresay intentional attention seekers and those with some physical quality that greatly distinguishes them from the norm would have a similar experience.

<comment><USER5> Sounds like this might be right up your alley: [https://en.wikipedia.org/wiki/Grandiose_delusions](https://en.wikipedia.org/wiki/Grandiose_delusions)

</comment></comment></comment></comment><comment><USER6> We are physical beings and so I don't think anyone would ever say that meeting in person isn't the optimal.

But you need to look at this from different perspectives.

The very fact that people from around the world can meet so easily virtually today is in itself a value regardless of whether it's better to meet in person.

In other words, being able to meet virtually isn't about replacing actual physical visits it's about allowing you to meet a much larger group of people and perhaps find more likeminded people and at much greater distance.

So I am not sure I buy into the premise of this study.

I also am not so sure that I believe we are getting more lonely. I would need to see harder evidence than the typical qualitative studies that are done to determine this. Would love to see how they are actually getting to that conclusion.

<comment><USER7> > The very fact that people from around the world can meet so easily virtually > today is in itself a value regardless of whether it's better to meet in > person.

So the standard reply to this is because we are fine tuning our meetups we are missing out on serendipity.

Travelers stay in touch with home so much they don't need to meet people.

We are connected on the bus and at a restaurant such that we are not pushed to meet people.

Then when we go to the fine matched event there is too much pressure to make friends.

I would say I'm the same, I'd need harder evidence that we are not getting lonelier.

Without a doubt we are changing, so it is troubling we don't know for sure if it's better or worse, I doubt such a big change is neutral.

<comment><USER6> Serendipity happens online all the time.

<comment><USER8> For example?

<comment><USER6> People meet in World of Warcraft, the tons of online friends I have on Facebook or got from IRC, various forums. Some of them I have met.

</comment></comment></comment></comment></comment><comment><USER9> This is a pretty interesting find, and makes sense.

As someone that struggles greatly with loneliness -- what kinds of systems have people found to address it as an adult? (Presumably there's an interest on this site, since this article is here.)

I've for years found it to be an utterly crippling problem that I just can't really get on top of. I scrape by by having acquaintances at work, and trying to stay in touch with remote friends (which works quite badly). But I haven't been able to find a good balance with it for many years.

Sometimes I think maybe I'm trying to solve the wrong problem, but it seems to be an unnatural state for a person to feel alone.

<comment><USER10> > what kinds of systems have people found to address it as an adult?

Most people find a "permanent friend" aka significant other aka spouse. I realize this is hard for some people, but that is what the majority of humans do.

<comment><USER11> Also, if you have some kids nobody will ever leave you alone again.

</comment></comment></comment><comment><USER12> I find it fascinating that they never once mention instant messaging. As a boy, I found it very difficult to make friends. I was insecure and emotionally guarded. This was only made worse by being bullied by most other kids.

I did have a few very good friends, but was still lonely. This changed drastically when I found a few friends online (via an online game, Dungeon Siege) and we played and chatted every day. I was taken aback by the way I was able to bond with people and how easily they accepted me for who I was, when they didn't see my nervous physical form.

During this period I entered into a long-distance relationship with a girl I'd never met. She helped me overcome a lot of my social awkwardness and issues with self-confidence. We ended up meeting a year later and spent seven years in a long-distance relationship. We spent time together each major holiday, though plane tickets were expensive. In-between these visits we chatted on various IM services. This was great, but I still often felt lonely, being apart.

We're now married and have been living together for six years. Being together for real each day is an incredible improvement. Still, our time together but apart was invaluable. I also recently realised that the majority of my close friends are people I met online.

</comment><comment><USER13> The headline that they had in an earlier version was better - instead of "blues", "loneliness".

I'll cosign all these findings because they correlate exactly to my own experience. It's the tragedy of the 21st century that we happily nuked existing social structures in favor of a "build your own social network" mentality that it turns out doesn't work that well.

<comment><USER14> While you find it tragic, I find it a blessing of sorts.

I've never had the experience of being accepted socially in these so-called social structures. My parents went to church and forced me to go. I've generally worked, and had school and stuff. It is nearly too bad I don't believe in God enough to withstand such things. I might as well been invisible at school, and I only rarely have made any sort of friendship at a workplace that carried over outside of work. Living away from family has been normal, and sometimes would go a few months in between visits due to money issues. I'm the weird one in the family - my brother in law said I was the weirdest person he'd ever met... until he met my spouse.

However, I have met friends online that I have kept for years. I interact with folks that aren't turned off by my weirdness. Met my spouse over the internet, and talking to him, though overseas, eased loneliness. The same lack of extensive social network at home allowed me to more easily move overseas when we married. Oddly, being an immigrant has made my weirdness easier and people tend to be a bit more accepting (minus the anti-immigrant folks).

<comment><USER15> I'd still venture a guess that you are fairly (within a few standard deviations of) normal. I miss the days of the Internet when it wasn't just a virtual extension of one's life. The same social memes are now embedded digitally, which makes loneliness even more prevalent because you can't escape from it like you used to be able to.

</comment></comment></comment><comment><USER16> I'd imagine people are not purposefully replacing real contact with virtual, as much as they have trouble finding real contact, so they go for the virtual?

<comment><USER17> Definitely the case for me. Most avenues of pursuing "real" contact readily available in my area and age group involve social situations that I have a great deal of difficulty navigating (which I increasingly think is some kind of neurological condition) and/or "common interests" that I lack interest in. Usually both.

</comment></comment><comment><USER18> Been there. I just got done spending 5 years at the end of the earth surrounded by very few people of my own age. Sometime in between 3-4 years is when I realized that the internet and all of the people on it can't substitute for someone you like coming over to hang out.

<comment><USER19> What was the context/reason behind spending 5 years at the end of the earth? Curious.

</comment></comment><comment><USER20> If I had both the time and the money to commission a similar study, I would design is so the "virtual" option uses virtual reality instead of say, a webcam. Ideally there would be some kind of haptic vest put around each participant so that an analog to physical contact could be approximated (e.g. a hug, a poke, etc). My experience so far building games in VR has surprised me in the sense that small amounts of haptic feedback within the Vive controllers can create a surprising amount of physicality if it is timed well with what the user sees. The brain seems to just fill in the gaps.

</comment><comment><USER21> Interesting that "virtual" in this case means your smartphone. That is not really virtual. Anyone that has had a good conversation with someone on VRchat or Alt Space VR realizes there is a very "real" face-to-face communication going on, and this is just the beginning. Once we get facial gestures and full-body motion into it, I think true virtual visits WILL beat loneliness.

</comment><comment><USER22> IMO it's totally possible for virtual experiences to help with loneliness, but not all experiences are equal. The differences between the status quo of social networking and real life interaction ought to be examined more closely.

</comment><comment><USER23> This has to be linked with what you grew up with.

I've spent my teens and beyond on text/voice chat with friends and it feels exactly the same as being with them in person. Maybe slightly less with text.

Or could it be because we play games instead of just talking?

</comment><comment><USER24> What about video calls, do those make the cut?

<comment><USER25> I was just going to ask this too because I remember reading an article about how people felt that video calls did much to alleviate the loneliness from remote work, whereas texting and even calling didn't quite work

<comment><USER26> My two cents: I'm a remote worker. Video calls make all the difference! It's something about the facial expressions, stuff happening in the background you can comment on, people walking by and joining the conversation. That helps.

Dedicated IM channels for small talk and sharing internet-nonsense are pretty good too. Can't really do that on the company-IMs, it just clutters serious discussion, but you get to know co-workers on a different level. That's usually just on all day. Not sure how much chat reduces overall loneliness levels, but it's fun.

Phone calls are neither here nor there for me. It's just business. It's hard to have casual conversations over the phone. "so, now that we got these expense reports sorted out, how's Timmy doing, still playing soccer?"

I do need to make an effort to step out and do some social things during the work-day (coffee-&-lunch, sports, ...). These people are not colleagues, but we're all full time telecommuters. For me personally, these can't be evening dates, the atmosphere is just wrong, it needs to be somewhat business-like. It took a while to get a routine schedule with that. Took a lot of "cold calling" people, like, `hey, we met at this Meetup about BuzzyMcBuzzword.io, you want to hangout?` (luckily, getting the cold shoulder from some bearded JS-ninja is not as bad as from that cute med-student at happy hour, but dang, it gets old after a while).

In my experience so far, remote workers I see doing well seem to fall into two camps. Either very reserved and just not social, and doesn't really mind being alone, but with strong work-ethic, they're often abrasive too. Or pretty easy- going and pleasant company, so the channels of communication are kept open on both sides. If you're sort of in-between, it can be a hard slog. You need to ensure colleagues keep reaching out, which requires you to be pro-active and upbeat, and you can't tire of that either, that energy needs to come from the remote worker first, because at the other end, it's easy for colleagues to just kind of check out on that.

Biggest thing about remote work and loneliness in my experience, isn't necessarily about being physically alone for a large part of the day, or about what communication medium is best to substitute for real life interaction. A big factor seems to be how the work is going, and how the team as a whole communicates about it. Sometimes, projects just take a bad turn, and it's much more difficult to not have that be a millstone, when you have other people to commiserate with, through whatever medium. But it takes buy-in from all sides. If colleagues bitch&moan in the break-room, but don't take it to IM, you're missing out on that. So you kind of have to get people in the habit to bitch&moan on chat too. That's the hard part, getting remote-working etiquette (rule 1, there's no such thing as using too many emoticons) be shared by the non-remote workers. Because when challenges arise, you need to be part of how the team is dealing with it. If you're left out, it opens the door for loneliness to creep up on you.

</comment></comment></comment><comment><USER27> I have to say: People older than me or the IRC-protocol are often not very good at online friendships.

</comment><comment><USER28> Technology and modernity are definitely factors that have led to increased loneliness, but I hope it'll help lead us out too. My company, Krewe ([https://www.gokrewe.com](https://www.gokrewe.com)) is making it easy for people to make a new group of friends in their neighborhood and actually have an active, real world social life.

<comment><USER29> That's pretty amazing. This was something i just discussed in a Psychology class that I was in about lonliness and visits/interaction where someone is physically present bridges the gap and decrease lonliness. There have been many studies that I've read also show that the people who are lonley and online also have increase microagressionns and lack social interaction skills.

<comment><USER30> The part i don't get in all this discussion is that being alone is a physical thing, but being lonely is a choice, a perception that can be changed subjectively.

If you are feeling lonely, and don't like. Stop. On the other hand if you are enjoying feeling bad, which happens more frequently than most people seem to realize, then don't complain.

<comment><USER31> Do you tell clinically depressed people that they "just need to cheer up," too?

</comment></comment></comment></comment><comment><USER32> "Winston Churchill called his own bouts of depression "my black dog,""

What a man. Next to him everybody looks like a wuss.

<comment><USER32> I don't understand why this statement attracted angst.

I am merely saying that Winston Churchill is a forthright character and a particularly resilient one at that.

<comment><USER33> No, you weren't "merely" saying that - you added on a general criticism of everyone else. Don't be disingenuous.</comment></comment></comment>


A personal story about 10× development - <AUTHOR> http://nibblestew.blogspot.com/2019/07/a-personal-story-about-10-development.html <comment><USER4> Let me tell you about one of my personal stories.

The project I got transferred to was the thing of nightmares.

Not deterred, I hacked into it a shitty solution and shipped it very fast. I shipped it so fast that suddenly I had everyone's attention. And I shipped another thing super fast and got more attention. One day, I said "this needs to go", and everybody listened, architects and directors alike. 6 months later, most of the code was replaced by my code or something originating from it. Every projects and features delivered on time with great appreciation of the clients.

You have to make it like software development is not a problem at all in the eye of your client and never never go behind the line where this is not true. The day software development is a problem, you lose. You must deliver software like you're delivering a book from amazon, _no matter what_. Because then, you got credit to make things better, which creates a positive loop. In that particular instance, I used some rushed victories to get more credits to make things clean later on. The guys who say they can make things clean but never ship and never win any battle against a deadline are just funny anyway.

To be honest, I took some fights in my career. I was fighting some dudes in every project. But don't fool yourself: if you're not really capable of making things better, then fighting is useless, just improve. You win the fights because the managers are on your side and you get them on your side by making software development not a problem at all.

 _edited_

<comment><USER5> > Not deterred, I hacked into it a shitty solution and shipped it very fast.

And moved the burden of maintenance to someone else? If so, this is one of the things people are complaining about 10x dev on twitter. You may look good, but the team / dept / company is worse off, and someone else has to clean up.

<comment><USER6> Well, that depends. You haven't actually seen the product so the assumption that it sucked and needed cleaning up may be a faulty one. I've seen the 10x phenomenon first hand a couple of times and some of those people really are that much better that their 'quickly hacked out solution' still beats your 'carefully considered product of 12 individuals'. In fact some of these simply work better _because_ they are the work of a single talented individual, no meetings, no distractions, no comms overhead or having to explain stuff. Design by committee is rarely better than design by a good craftsman or woman.

<comment><USER7> So tell us, how is a shitty solution better than a well designed testable solution? Literally every book on project management is about the development cost vs maintenance cost and how the latter beats the former. But yeah, keep dreaming.

<comment><USER8> Because what a "10x developer" (i would just call them pragmatic, personally) might call a shitty solution is still better than what you may call a well designed testable solution?

Not everything needs 90% test coverage and more comments than code to be good. And not everything with 90% test coverage and more comments than code is any good at all.

<comment><USER7> Pragmatism based on shittyism? Or how shall we imagine this? Is there a motto for this? "We excel in shitty code or something?"

<comment><USER8> I think you are missing the point. That someone calls their own solution "shitty" doesn't mean that it's shitty by your standards, its shitty by theirs. The reality is that people have different standards. I don't understand the hate you seem to be exuding for productive people.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> In my personal opinion, the fact that in discussions about 10x engineers, many of the anecdotes and ideas try hard to discredit/disprove the concept¹ rather than presenting real-world examples of very productive engineers, indicates the fundamental will not to _recognize_ them, simply because of pride.

So I'll give a short and sweet argument: read John Carmack's biography and code (both in detail), then feel free to argue that he's _not_ a 1000x engineer, and/or that he's the only one in the engineering world with such capacity.

¹: I agree, though, that "10x" is a profoundly misguided label

<comment><USER10> The 10x label, especially as described by the tweet that started the tweetstorm is the situation which you may encounter when someone who designed the system understands it yet its not comprehensible to anyone else, because either:

* their design is poor

* they didn't take the time to document it

* they don't take the time to explain, mentor and in general communicate with others

This is a way more common situation than the one you're describing (John Carmack)

<comment><USER11> > This is a way more common situation than the one you're describing (John > Carmack)

FWIW i remember reading that Carmack didn't really document nor explain his code and all people who bought id's engines got was a single day to ask questions about it to him and that was it.

On the other hand for the vast majority of its life, id was a very small studio (IIRC the entire team who made Doom 3 was just 21 people - <USER2> includes programmers, artists, designers, etc) so chances are if someone wanted something they'd just ask him directly. I also remember a comment about programmers at id not having meetings and decisions were taken in informal discussions.

<comment><USER10> Yeah I've often wondered if many of the heroes we celebrate might be heroes by means of being at least a bit selfish and less of an ideal team player :) Its interesting to read that that might be the case even with J.C.

An amazing engineer who is also an extremely strong team player is less likely to be that noticeable because the contrast between them and the people around them tends to disappear in those situations.

</comment></comment></comment></comment><comment><USER12> _The project I got transferred to was the thing of nightmares. It was a C++ project and all the bad things that have ever been said about C++ were true about that code base. There was not much code but it was utterly incomprehensible. There were massively deep inheritance hierarchies, compilation speed was measured in minutes for even the most trivial changes, and so on. It was managed by an architecture astronaut that, as one is wont to do, rewrote existing mature libraries as header only template libraries that were buggy and untested (one could even say untestable)._

Oh no, it seems like a hyper-modern-C++ developer lead the project and transformed the code into template-metaprogramming madness... (inferred by the absurdly long compile times) Deep condolences to all the people who worked on the project.

<comment><USER13> I have done this when I was younger, after reading Modern C++ Design and the Template Metaprogramming book. I am sorry.

Please not I'm not saying those books are bad, just blindly apply stuff because you think it is cool and fancy is probably not good leadership.

<comment><USER14> How do you know how to use the new shiny things without real practice? My friend, we have all done this. (after about the 10th time the 'new technique' turns to a mess, you become very conservative about 'new things').

<comment><USER15> Ideally, I prefer to practice radical new approaches on hobby projects, or single person explorations, rather than team projects.

</comment></comment></comment></comment><comment><USER16> I'm a definite believer in 10x developers because I've seen these mythical beasts with my own eyes.

For instance, dev teams of 20+ where one person is the absolute backbone of the team and churning out features faster than the rest of the team put together.

I've seen maybe 5 instances of this across hundreds of teams I've worked with (I was a developer turned consultant so have a lot of data). They are rare beasts but 10x devs absolutely exist.

<comment><USER5> I am not saying you are wrong, but could it also be:

1\. the person had been there the longest, and had the most context on the code base.

2\. There was very little docs on the code base, so new people had to go to them.

3\. This person would just do the feature instead of helping the other person implement the feature, and ensure their position as "top feature churner"

If these are true, they may be 10x of the others on the team, but they are holding the team back by not dropping themselves to 4x and lifting up the other team members to 2x.

<comment><USER17> It's so weird to see so many people argue so hard that the Usain Bolt's of the programming world simply cannot / should not exist.

<comment><USER5> Sprinting - individual sport.

Development - team sport. You could put Messi on my company's 5 a side lunch time team, and we still wouldn't win the champions league, and the skill of the others on the team would atrophy, and they would become over reliant on a single person. Not a great thing for a _team_.

A true "10x" engineer raises up the team by 10x by doing the things a lot of devs hate doing - docs, mentoring, guidance (without taking over someone's feature), and knowledge sharing. Not shipping :all-the-things: on their own.

<comment><USER18> > Messi

One of my assertions is that Messi hasn't proven himself to be a GOAT until he's been great _somewhere else_. It's easy* to perform at a high level when the entire team is built around you as at Barcelona. In non-Messi-specific environments (ie Argentina national team), he just doesn't perform as well.

Whereas Ronaldo, on the other hand, has done it in several distinct environments _and_ elevated the teams he's been in (which I guess makes him a "true" 10x player?)

<comment><USER19> But still is the same thing. If Ronaldo, the best player in the world, would be considered a 10x player, it would mean that him and just a goal keeper would be able to compete with other professional teams, which we all know is bullocks.

The original 10x term was about productivity (and namely, lines of code that is pretty much bunk).

For me is always about what is a 1x developer. If we consider them a professional developer that does their tasks (somewhat) on time, documented, and with minimal bugs, which I would consider the baseline for what I would call a _professional_ developer, I have a strong opinion you won't find 10x developers compared to this.

On the other hand, if a 1x developer is a person that can't create a simple algorithm(fizzbuzz), copy pasts code from every possible source, including his own code from file A to file B, etc etc, then sure, 10x developers are there, but this is because we set the bar too low.

</comment></comment></comment></comment></comment></comment><comment><USER20> Lots of conceited sounding comments here from devs who either have an inflated sense of communication skills or stopped reading the article quite quickly.

In my personal experience, the author's anecdote rings very true. At my first and last corporate job, I was handed a thick af HP laptop that could barely be used anywhere but in the cube, a hideous screen, 30 min build times, and a java stack that made testing/understanding the existing YUI (JS) codebase a brutal activity. It took almost my entire first 6 month contract to just get minimally productive, and that's without accounting for meeting interruptions. Another frontend fella was hired on shortly after me, and we worked together to test and get productive with this codebase which was great, until a month later the manager who popped his head in every so often to check that things were running to his measure, decided to shake things up and dismantle all the teams, re-positioning them on different projects for no apparent reason. My colleague and I were split up, me on the new project that he had been prepping for through requirements gathering and UX stuff. Starting from square one, on a team whose members had barely met, in a different part of the codebase that I'd never touched, and with a 2 month arbitrary deadline, all while everyone was moving from SVN to git, and the feedback loop on a frontend change (locally) being 5 - 10 minutes. Shocker, the project failed, I was fired, and much like the author, I wanted to get the fuck out of the industry.

Edit: I think it's important to note sometimes the nature of what you're working on or the company you're doing it for can be extremely constrained. That in and of itself isn't unsurmountable. But when the expectations, compensation, budget, and measure of output aren't balanced, or if the constraint is poor management that don't understand or care about the people they're managing, then it's just a tire fire.

<comment><USER21> Is this a communication issue?

When you realized the codebase was a mess and that it would take you forever to reach productivity, did you reach out to the manager and explain the situation? Did you push back on splitting up the teams, and explain why splitting the teams would be a bad idea? Etc.

Unless a manager is truly incompetent, in my experience they usually listen to technical people when they speak up on these kinds of topics.

<comment><USER22> Competence is a spectrum. I've worked with managers who would listen, and nod along to problems I was pointing out, and after the meeting nothing would change.

</comment></comment></comment><comment><USER23> I'm sorry but the author misunderstood the situation:

\- He explained to the manager that a simple Hello World took a lot of time bla bla bla. The manager already knew this, that was his "achievement". He also took it personally as most people do, because when you tell him that something was bad, indirectly, you criticized his work (and so him) in the last years maybe.

\- The author tried to explain rationally the situation. The manager didn't want to hear it because he was already desperate. The manager knew that the end was close. A desperate man does not think rationally. All you can say is that you will fix it and then proceed as normal. They just want to hear that everything will be good even if you know it will not be. You are his psychologist/priest now.

\- The project had to failed. When you as a developer are in a situation when management is bad you should not do your best to save the project. The badly managed projects and companies must fail in order for the sane ones to survive. If you save a bad project/company you are the reason why there are some many bad jobs everywhere. Also this is the reason there is so much burnout in this industry.

<comment><USER24> Yep, exactly. One thing I've learned over my 30-year career as a programmer is: never argue. It's a waste of not only your time, but your credibility. If they say it has to be done in a week, and it's impossible to get it done in a week (like, actually impossible), you have two choices: disappoint them in a week, or argue, make them hate you, lose the arguments and disappoint them in a week anyway.

<comment><USER23> More stuff needs to be written to teach well behaved people how to deal with all kind of toxic persons in the workplace.

</comment></comment></comment><comment><USER25> What are the common "safe" traits of a 10x developer?

So far everyone I have met with traits like \- produces working feature/code faster than anyone else \- delivers stable massive projects on time \- can carry a whole team through fire and hell \- praised to produce masterpiece*

Are the same people everytime who are just \- good at playing office politics \- are excellent at cutting major corners \- knows when their project will fall apart and leaves before \- are in league with upper management, so can't callout

I have yet to met a real developer who when left team/project/job didn't leave a massive trail of destruction but up until they were present everything was a-ok-top.

May be someday I aspire to meet one, but so far, most pseudo 10x are just people knowing how to play right politics and hide the skeletons really well :(

<comment><USER26> This is a complete guess just based off my experience, but I know a couple of devs I'd bet on to 10x the worst of the devs I've worked with (over a long sample period), and the one thing they have in common is that they keep their code simple moreso than the average dev does.

One part of that is they all seem to err on the side of less code (including dependencies) over quicker implementations. The other part is a few times I've shot them a piece of code and they've come back with something simpler that I've overlooked. I.e they seem to have good fundamentals, good algorithm knowledge, good understanding of the language etc.

It makes sense to me, because I think this is the _only_ vector you can 10x somebody in. You can't generally 10x somebody early in a greenfield project because everyone is smashing out work. You can't 10x somebody in a hellish project like in the OP because everyone is struggling with the same cruft. The only way you can really 10x somebody over a big sample size is by keeping every project you work on simpler for longer.

So that's what I look for when I'm looking for 10x devs. I might be completely wrong but it's the best indicator I've found yet.

<comment><USER27> You can absolutely beat people in greenfield projects with experience; choosing and designing business data structures optimally so that not a lot has to be refactored.

I don't really buy into the idea of attributing "x speed" to a developer, the idea is trying to oversimplify what is really a function of experience in- and the complexity of current task

</comment></comment></comment><comment><USER28> Some times ago I was working in one company. We were building some platform and have the big task to integrate with another technology. I was involved in an absolutely different field and only participated in some meetings during the planing phase. The discussion lasts for a few months and when I completed my other project team already spent some sprints on development. When I have joined I wasn't familiar with underlying libraries and spent almost the whole week to improve my knowledge. When I have started to coding I found that whole project size is only 3-5 days of productive coding including tests for one person. My firsts thought was "I don't understand something", but when I ask some other guy to do pair coding during a day he barely did one class during 6 hours without tests and other things. And it was their normal pace for the whole team. But they get their bonuses and endless meetings.

Definitely, I feel myself as a 10x developer that days working with my normal 1x speed.

<comment><USER29> I think there are more < 1x teams out there than people think

</comment></comment><comment><USER30> A lot of this rings true for me. A few years back I worked for a company that seemed hell bent on utterly demoralising its engineering organization. Think endless rules (even down to which HTTP verbs you were allowed to use), a Macbook Air for development work, releases that very literally required manager signoff coupled with a company culture that was very partial towards throwing engineers under the bus. Of course they were crippled by technical debt, outdated development practices and regularly plagued by production fires. They did make a lot of bad hiring decisions - helped largely by not conducting technical interviews. But even those of us who were competent felt like 0.1xers.

<comment><USER31> "which HTTP verbs you were allowed to use"

I hope they only allowed GET?

<comment><USER32> Nah, only DELETE

<comment><USER33> If this was the case the poster wouldn't be complaining about the limitation, but celebrating!

</comment></comment></comment></comment><comment><USER34> "Wanted: Spaghetti-Wizard"

There are indeed a lot of factors involved and a good environment/stack/management can result in a lot of productivity from the team or at least multiple individuals. There are probably a handful of people in your city who could even do good work with spaghetti stacks and chaotic management.

But if your software requires a Spaghetti-Wizard, you're in deep doo-doo when he/she leaves because Spaghetti-Wizards are rare and hard to identify up front. It's a safer bet to clean up your organization and processes by listening to multiple people and not getting caught up in hype. Non-friends give you the most useful advice. If you gravitate toward people who only tell you what you want to hear, you'll have a biased perspective.

Another thing, sometimes a given stack or org is just not a good fit for you. People think in different ways. The author perhaps should have looked around and if other devs were doing fine with the odd stack, just say, "for some reason I find this particular stack confusing and difficult." Be honest and don't bash the architect if it's only you struggling.

<comment><USER35> I started my career on a 1.5 million LOC project that only had 5 developers working on it. It really influenced my development methodology, and I've always thought working on messy code bases was fun and challenging.

So when I started my consulting company I thought about marketing it as something like "Spaghetti-Wizard". Similar to the "we buy ugly houses" but "we work on ugly code. never surrender. never rewrite.". Couldn't think of proper way to find clients though, so with one exception mostly been working on greenfield projects or as an expert on Oil and Gas IOT systems.

<comment><USER34> There is certainly a need for "spaghetti decoders". Being able to study and figure out messy systems is a fairly rare gift.

</comment></comment></comment><comment><USER36> I've worked with people who are the "10x developer" people are talking about. I hope I can explain the confusion.

First: let's just replace that with "much more productive than average" developer. 10x is a silly statement, a bit like saying someone is a 10x footballer etc.

It's correct to say these people get a lot more done than others. They often have admirable traits, such as great focus or enthusiasm for their job. They're dedicated and will work long hours to get things done. Great for a CEO or investor to have. On solo projects, they're exactly the man for the job. And startups usually begin as solo projects.

The reason there's such a backlash on Twitter is that there is a huge cost to the rest of a software engineering team when working with such a colleague. Every instance I've seen of this situation has a common factor: as others joined the team, the MPTA developer monopolised the codebase. They won't delegate, and preferred to spend time coding rather than helping others do their job.

And here's the thing: __The productivity gap is mostly a function of this dynamic __

Try to take ownership of something, and the MPTA dev will use the time in the evening to rewrite your code in their style. They are extremely opinionated (though often correct) and unwilling to delegate and bring in ideas from others. Make a mistake (inevitably as you pick up the codebase) and the MPTA will roll their eyes at the CEO and replace your code. Working in a team is not about who writes more code, it's about how to work together to move the company forward. And a happy team building a large product will always outperform a MPTA developer by long-term measures.

With no documentation, strong communication, team ethic, and delegation, employing a MPTA is unsustainable in the long term. If you're a VC or early stage startup you probably don't care about that. But most developers are in teams in bigger companies, and perpetuating the 10x myth makes their lives worse, and makes them look bad.

Moving on from the idea that a 10x developer is good for a sustainable development effort is a significant step in the maturation of software engineering as a field. They have their place and can be an incredible asset, but great software engineering is about teamwork and communication.

</comment><comment><USER37> This is a nice anecdote, but it misses the mark a little bit.

A 10x developer is 10x compared to his peers under the same conditions. Comparing across project conditions like this is talking about a different concept.

<comment><USER38> New programmers on a team eventually affect the quality of the code as they work, and thus the project conditions. Project conditions can also include how easy it is to work with others on your team, which depends both on the new dev and the existing team. So that definition misses a lot.

<comment><USER37> Everything you said is true, but I didn't make up the definition :) This term was coined many years ago to highlight one simple idea.

That you can hire someone tomorrow that would have 10x the output of the average hire. Basically that such people exist.

Cross team productivity, and inter team dynamics are very interesting topics, perhaps more interesting, but this label for this topic is pretty clearly defined.

<comment><USER39> The meaning of 10x has blurred considerably - when coined, as far as I can tell, it seemed to mean that sometimes the _most_ productive developer on a team is 10x more product than the _least_ productive developer, not the "average hire" - which is a very different claim.

</comment></comment></comment></comment><comment><USER40> This story also raises an interesting point for development managers; When you transfer a dev to a new project, it's a lot like getting a new job - you ( probably ) won't have the domain knowledge, knowledge of the tools in use, will have to prove yourself to the other developers on that project before anyone takes anything you say seriously - etc; with one key difference - <USER3> you get a new job, you would usually expect a pay rise. I think this is a massive problem in larger orgs where developers may be seen as an interchangeable resource, and can be a major contributor to staff turnover, and loss of critical knowledge. Soon all your developers will be 0.1x.

</comment><comment><USER41> If the definition of a 10x developer is 10x more productive than the least productive member of the team, then I'm at least a 10x engineer.

We had a story to build a relatively simple go web server and deploy it to kubernetes one of my teammates got it, and basically got no where with it for a couple of days so I thought I'd get it started for him.

I got a basic hello world server set up and deployed along with a 'ko' setup so he could do hot rebuilds and deploys with a keypress.

I sent him the git repo and instructions for how to get it working.

While I was waiting for him to get it working, I was kind of in a groove so I kept adding features from the story.

By the time he got it compiled (with me coming over and just walking him through everything because he couldn't follow the same docs I used to get started), it was already 90% finished.

If I had waited for him, he'd still be working on it for another 2 weeks at least.

It's not that I'm a genius or he's an idiot, he's just fairly new on the team and I built our whole stack from scratch more or less and know it like the back of my hand.

<comment><USER42> You could have been a 10x developer if you taught him how to do it. A single developer can only scale so much, a true 10x developer is one that scales the output of those around as well.

<comment><USER43> Yep. And if you're a 10x developer who becomes a manager or team lead, your best bet to maintaining your 10x effect (or increasing it to 100x) is to grow and support your team. You might not say that they are each and all 10x, but if you can grow them from 0.01x-2x range up to the 1x-10x range, then multiple by n team members and you get the net effect of a 100x-1000x dev.

</comment></comment></comment><comment><USER44> What about the infinity X developer. I've seen time and time again situations where a developer simply didn't have the skills to complete a task. You could give that developer infinity time and it would never be completed.

And then you hand it to someone else, and it gets done.

There are some problems that are just really hard, and some folks just aren't cut out for those problems.

<comment><USER43> Infinity X developer? If true, I'd say that team has a professional development and growth mindset problem, one symptom of which is a productivity problem.

<comment><USER45> Having expectations that any person should be able to teach what they can do to the rest of the team in a timely manner is unreasonable.

Problems like "Make X take less than Y time to run" or "Reduce binary size to Z" or "Design a fault tolerant system accomplishing Q" etc are often impossible for most to solve since they simple don't have enough foundations and intuition to solve them. You'd have to spend years drilling fundamentals to get people to that level if they are even capable of gaining the same intuition, most developers never gain those skills no matter how many years of experience they get.

<comment><USER43> Who says you have to be the one to do it? What conferences exist? What books? Online courses? You don't have to be the professor, but you do need to be their advisor and point them in the right direction to learn, grow, and thrive.

<comment><USER44> Sometimes there aren't conferences, books, or courses. There are lots of problems out there without solutions you can take courses for. Board bring up, performance, and lots of problems that fall into the bucket of "machine learning" require knowledge, cleverness, and lots of persistence.

There's also the set of problems that are best learned at universities. Normally, one doesn't have time for a developer to catch up on their missing compilers or cryptography class (this is particularly a problem since perhaps a quarter of programmers have CS degrees, and a quarter of them went to a decent program). If I were asked to debug a clock skew problem on a particular VHDL design, it would take me a long time to learn enough to even approach the problem.

</comment></comment></comment></comment></comment><comment><USER46> Also,if one is a kind of mediocre developer but gets thrown into the team,where standards are high, the productivity of such a person would be higher than in a kingdom of spaghetti code..

</comment><comment><USER47> I think the author raises a very good point. Developer productivity does not lie in a vacuum, this is overlooked a lot mostly because for small teams most developers manage their environment and toolings and for big teams there usually are standards to follow but there is a huge gap in the middle where if a developer is not vocal enough or has sway in a toxic team a good developer could spiral downwards in productivity.

As to a solution to what the author asked: "What could have been done". I think the way to handle that situation is to approach the manager with a solution. Tell them, if you give me A, B and C I will be productive, I do not have these now and they are causing me pain. To do this one has to have self- awareness and experience in what they need for a productive environment. one also has to be vocal and willing to fight for it.

</comment><comment><USER48> I think the 10x developers are a myth if you compare the whole output versus another developer whole output.

But it is very common that a developer can fix a problem or build something 10x or even 100 times faster than others. Simply because they know the project, the language, understand the problem already, have experienced that problem before.

I have many anecdotes where I was stuck on something for hours and a colleague solved it in 10 minutes. But I have also counter anecdotes where 2 colleagues were stuck a whole day trying to solve a problem while I was out of the office and the next day I solved it in less than 5 minutes. The multiplication factor of that is insane, but it really happened.

<comment><USER49> I don't think it is a myth. If you look at coding challenges and live coding, there are developers who can churn out correct and well-documented C or C++ code while speed typing and without making any substantial mistakes. Not every developer can do that, no matter how experienced he or she might be with the language. I'm not one of them, but to give an example, I find some of Bisqwit's live programming on Youtube pretty impressive - and he works as a bus driver during daytime!

<comment> GuB-42 Doing coding challenges is a special skill. To be fast you need to:

\- Have all the boilerplate code almost memorized. By that I mean things like parsing a simple file, opening a display, etc..

\- Know the relevant techniques, and train. For example, if you are doing a coding competition, dynamic programming algorithms are a classic. If pretty pictures are your goal, fractals and raytracing are a good start. Neither is likely to be of much use for you in the real world.

What coding challenges don't require is the ability to think long term. That code is likely to be thrown away after the challenge is completed. Managing complexity is maybe the most important part of real world programming, and for technical reasons you have very little of it in coding challenges.

As for Bisqwit's videos, they are awesome, and he certainly is very talented. I actually learned a lot from him. However, all his videos are about toy projects, not building complex applications. BTW, I think this is the reason he is a bus driver. He doesn't enjoy coding in a professional setting, because it is a different kind of work.

</comment></comment></comment><comment><USER50> On a lighter note, iIf you don't see any 10x developers around, maybe you're the one :D

</comment><comment><USER51> It looks like the real 10x debate is not so much "do these people exist" (yes) or "is it context dependent" (yes), but the more subtle questions of how to identify one by any other means than working with them for weeks, and what a 10x developer (or salesperson!) is allowed to get away with in terms of not following the rules.

There is also the Stakhanov question about how to attribute the work of supporting and being supported by others, and how this can be used for propaganda.

</comment><comment><USER52> I think it's not unreasonable to suggest that there are very productive people out there. They pick things up easier and they generally have an aptitude for the work and the environment. However, the original tweet that set this whole thing off listed out a number of attributes that 10x engineers are supposed to have. Things like having dark mode in their IDE, using the command line and never needing to read documentation. Which is nonsense of the highest order.

</comment><comment><USER53> I deal with this type of situation on a daily basis. It turns your team into firefighters instead of being able to focus on building more value.

When I hire new people, I hammer clean code and TDD. I am not dogmatic about it, I just know from experience that maintainable code makes for a more enjoyable experience for everyone on the team.

</comment><comment><USER54> I prefer the term Batman developer

He doesn't play well with others and usually he'll just do stuff his own way without telling anyone.

He's usually right and he's usually more effective than his sidekicks.

Some villains need Batman, but after a while he can work on more pressing issues and the sidekicks can handle the weaker villains.

<comment><USER55> Sounds like the same destructive behaviour that is commonly referenced as the bad 10x developer.

<comment><USER56> Yeah, the obvious point is that Batman is a billionaire businessman who could pay his taxes and get Gotham to hire some decent police but instead of actually focusing on the structural problems that cause crime in Gotham, he runs around banging models and beating up street criminals.

The Batman comparison is a great example, because the criticisms of the 10x developer match exactly the problems with batman.

</comment></comment></comment><comment><USER57> It's easy to be a 10x developer if you don't write tests, no documentation and don't design anything, don't do any code review...

<comment><USER58> So like most companies then? They say they do or plan to do but when you go and check there is nothing. Most projects I encounter when doing integration have nothing (well, perhaps some minimal docs for the integration) while they process millions-billions $ via these systems.

My latest encounter was an insurer who spend a lot of money on building a system by a hip team who started with node/mongo/react and a few months ago insisted on switching the frontend to Svelte because 'React is not current tech' (I am not joking here). No tests, bare minimal docs, bad design (every change takes forever and some changes are deemed impossible) but it works, makes money, client is happy. It took however over 2 years (not cheap guys either; Dutch, 120+euro/hr people) to finish while my beer napkin estimate is 6 months and that would include tests and docs. Easier because there already is a system so that is not fair but the idea that companies are living in some HN nirvana where they pay programmers to implement non business stuff (tests, docs etc) is just not realistic. And the people who do it are not '10x' even then.

If I would say 6 months to rewrite (if that was on the table) inc tests and docs, the client will say; how much without those then?

<comment><USER59> >> inc tests and docs

Why should the client have to worry about tests or developer documentation? I would not be trying to get it as a line item on the invoice.

Keeping the code base in a state that makes it fast and cheap to add future features is just a professional duty. Decide how to best achieve that on a project by project basis and bake it into your estimates.

Some projects the client just wants the absolute cheapest implementation though and i am completely fine ripping out the need for continual re- factoring or keeping the test suites in good shape IF i've explained the down side to the client first.

<comment><USER58> You are right, my point is that this is the HN echo chamber; I see almost no- one and no company doing this in real life. At least not in the countries and companies I have ever worked with and that's quite diverse. Naming and shaming makes no sense here, but I know many Silicon Valley, Berlin, London, HK, Shanghai, Barcelona startups saying that they 'will' do these things (and some of them shouting on Reddit & HN it's bad if you do not) but not doing them _at all_ and many fortune 1000 companies not doing it either. Not even the basic stuff.

So yes, it's my professional duty, but my 'competition' doesn't do it and is therefor cheaper. I don't do much of that work anymore as I now do a lot more own products with my company where I can do it, but if I 'bake it into the estimates' we will come out most expensive. So for us it's line items, and if you, after we explain everything, do not want that, we will remove or not take the contract (depending on the terms).

</comment></comment></comment></comment><comment><USER60> I have maybe seen two people I would characterise as what other people might call a 10x developer.

One of those 10x was truly someone who was worth 10 developers (at least!) given that not only was he capable of holding the entire business in his head, but he could also mentor and bring people together. At crunchtime he could also shield the rest of the team by churning out features at triple speed while still keeping them in a mostly maintainable fashion. He brought the best out in everyone.

The other 10x was a silo of knowledge, was terrible at mentoring and wrote code which was neither readable nor high quality. That said, he was unmatched in his ability to ship and solve problems in distal regions of the codebase. In my evaluation of him, although he was 10x more productive than everyone else, I can't help but wonder how much less productive everyone was around him (and the team was larger than 10!).

So tl;dr YMMV. They definitely exist, when they work right then probably can set up systems/organizations that can scale around them and generate tonnes of value. When they're egotistical/insecure vampires, their global value will be questionable but they will definitely look good relative to everyone else!

I think moral of the story is don't hire assholes...

</comment><comment><USER61> I inherited a similarly Kafkaesque codebase where I work now and yes, iteration on features went down dramatically from previous workplace.

It's just so difficult to do anything without something completely unrelated breaking.

Enough that I have considered simply leaving.

</comment><comment><USER62> Rather sureal to see so many blog post about a "10x" controversy, without anyone actually referring to controversy - therefore making it impossible to understand if people are even talking about the same thing.

Without any snarkiness implied, I suspect _not_ being on twitter anymore lately has spared me a few hours in this case.

Maybe 10x programmers (I'm not one) don't have time to talk about 10x programmers.

</comment><comment><USER63> I'd like to highlight this part:

"But even more important than technical issues are things that promote healthy team dynamics. These include things like blameless postmortems, openness to ideas from everyone, permission to try new things even if they may fail, stern weeding out of jerk behaviour and, ultimately, trust."

It's just so important.

</comment><comment><USER64> I have personally witnessed 10x developers. The trick is making everyone else look like 0.1x developers.

</comment><comment><USER65> I am getting so tired of the term "10x" due to the past week. Some people use it as a synonym for "socially maladjusted" or "toxic," while others use it like "amazing developer." Just...stop.

Some people are more productive than others; it happens. Some people are toxic and destroy entire teams. It doesn't make sense to lump all different kinds of "developers we don't like" into the category of "10x" because _that 's not what that is_. There's another comment in this thread suggesting a change to "more productive than average," which is a term I could get behind. You can't measure productivity to multiply it by any number, so please just stop.

</comment><comment><USER66> This is a great story as it illustrates how to make a 0.1x (or 0.01x) developer. The 10x version of that is one who created a codebase that's missing all the ineffectiveness of this one as well as adding sprinkles if well defined boundaries to work on parts indepently without complication. Setting up this sort of multiplier environment of code structure is how you achieve Nx output for onself or others. Most of the time you shouldn't even see the 10x'ers work because it's invisible what's _not_ there is the magic.

</comment><comment><USER67> Can't speak to what makes a 10x dev. But a 10x dev team is much easier. Where each member can carry their own weight, most of the time.

\--

I have been involved in seemingly simple projects that never seemed to end (and a lot did not or shipped with significant debt) and on other complex/novel projects (with many unknowns) which went really really smoothly and shipped on time.

Successes are oft attributed to a 10x developer or a high performing individuals contributors. But, then I've seen the same 10x devs go to 0.1x and 0.1x to 10x and back.

My anecdotal observations on what sets successes apart from the fails are:

\- A well defined problem: Well defined to the extent that this intends to solve X. It can easily solve y,z,a and b, but it will not and is out of scope/not expected to be delivered.

\- PMs with domain knowledge: An external aide who can step in and guide when asked, or if the visibility reduces. But understands the problem and technologies involved (task masters need not apply). No PM is often better too. Also the PM here is more like a sponsor, only steps in when asked, to recover failure.

\- Smaller teams: Structured like a cross-functional pod. For complex projects a senior dev, a not as senior a dev and a designer work well. A lone wolf + a designer works. A junior dev with high degree of domain expertise on the problem + a part time designer works too. No designer necessary if there isn't a front end.

\- Hard code reviews: Starts with a good convention that's documented, a style guide for programmers. Some languages have this baked in. This happens at the very end in the testing/cleanup phase.

\- Let the teams write out the task, then group these in to scopes. A PM or person with more knowledge outside the pod might be tapped in to help sub- divide scopes.

\- Let the team on their authority cut down on scope if it helps ship on time, with fewer unknowns, without changing what we were trying to solve.

\- No extensions: The project is done or its done.

\- Finished early? Free time to NOT write code. Usable as the team sees fit.

A few other nuances, one could argue that this makes for good and consistent 1x dev. It definitely makes for a 10x team.

aside: read a great book that summarized a lot of the successes as a plan they use in there team. Its an easy 60-80 minute read (I'm a slow reader). Highly recommend it if any of this resonates, high recommend if it doesn't and you want more ammo for a flame war. [https://basecamp.com/shapeup](https://basecamp.com/shapeup)

</comment><comment><USER68> "10x developers" are about as well defined as the word "startup". Similarly they are often used by VCs (or similar stakeholders) to attribute causation to a highly complex system, which is basically a fool's errand. The description the original VC uses for a 10x developer (where the tweetstorm originated) is akin to a supply chain that just spits out masses of widgets to a nascent widget market. VCs love this because it means a quicker ROI on their investment.

</comment><comment><USER69> The 10x comparison makes only sense if you compare developers on the same project. If there are colleagues that perform much better, try to learn from them

</comment><comment><USER70> One serious side effect of these kind of discussions is that people tries to be a "10x" developer, and start producing like hell but it's just garbage. Also it creates a culture of "I deliver, ergo it's good". And then you are in knee deep crap, and the guy moves, leaving everyone else with the shit.

</comment><comment><USER71> Don't forget "competent managers". The manager blamed him even though the codebase was the problem.

Or do competent managers even exist? Or we just assume that they usually aren't and we will have to work around them?

</comment><comment><USER72> I always thought the 10x developer was simply someone who sees the cleverer, simpler way to do it. Like in trick maths problems: software is the thing in the world that is most like math.

</comment><comment><USER73> This story is basically about a 10x coder and architect which acheives his 10x by belittling others by means of architecture astronauting and personal job security.

</comment><comment><USER74> The worst thing about 10x devs is that some of them work in places where the process or general dread reduces them to 0.1x to 1x developers.

</comment><comment><USER75> I imagine most 10x developers just have their life together as a whole and that's what allows them to be so productive.

So many developers I see are overweight, drink alcohol often, play video games until 2AM and then sleep 5 hours, no exercise at all, bad diet, porn addiction.

By having such a bad lifestyle they are really low energy and tend to go into "autopilot" which of course translates to worse output at the job.

<comment><USER27> I don't see a causation here, those things aren't specific to tech, and are in fact fairly common in other areas of work as well.

<comment><USER75> Yes, and I bet there are 10x employees in all other areas of work as well.

</comment></comment></comment><comment><USER76> Here are my brief incomplete thoughts on becoming a 10x developer writing JavaScript. In summary, become comfortable with how the technology actually works. Hoping something else will solve your problems for you makes you less productive (I've heard all the excuses).

* Understand that super productive people likely do things that aren't the popular way of doing things. If the super productive way of doing things were the most popular way of doing things then everybody would be more productive. Be critical about why a productive person intentionally does something in defiance of popularity.

* Become comfortable reading code. Frameworks, unit tests, processes, and tools are not there to make sense of the code for you. You cannot be a 10x developer if you are intimidated by reading code or expect something else to do it for you.

* Learn to organize to the scope model before adopting any other convention. This will reduce the amount of code in a given application. In many cases it will also greatly increase code performance. In JavaScript OOP concepts and inheritance are conventions that can be avoided, but not scope. Scope is always present and not hidden behind a code convention that can be avoided. Don't be afraid to nest functions and try to declare references as locally as possible and share where necessary as this greatly increases maintenance speed.

* Write original code. In JavaScript _invented here syndrome_ is exceedingly common. In many cases it is faster to write original code for a given problem and in many cases that original code will execute orders of magnitude faster than misunderstood dependencies downloaded from NPM. If writing code is intimidating you will always be less productive. If you want to write clean maintainable code solve a given problem as directly as possible and then later, after clearing your mind, refactor the code to achieve simplicity. Simplicity almost always takes extra effort, but reduces maintenance time down the road.

* Master the DOM. The DOM is still the ultimate backbone that glues all things together in the browser. The DOM is not some strange React fiction. It is a language agnostic standard. Learn the standard DOM methods and node relationships. The DOM methods execute thousands of times faster than query selectors and faster to maintain for code where sections of the page are in flux. [https://dom.spec.whatwg.org/](https://dom.spec.whatwg.org/)

* Become comfortable with callbacks. Node is callback driven. If you cannot figure out callbacks or passing by reference your code will be a struggle to write and look like spaghetti.

* Learn to write your own tools. It is nice to increase your own performance because you have learned to automate part of your daily tasks or parts of your job away. This isn't something that comes naturally and it does take practice to become efficient write quick tools on the fly that doesn't burn up all your time.

* Take ownership of test automation. Some developers want to test everything because people have told them testing is somehow important but have never learned what is important about testing. Tests are a form of debt that. Test what your application claims to do opposed to what it literally says. Test features, options, and output. Test that collisions of features do not produce unexpected results. If you are confused about what to test ask for guidance from your QA team. Ensure your tests automation executes as quickly as possible so that it isn't a swamp holding back the productivity of your team. Slow test automation is worse than unnecessary unit tests.

* Most importantly accept that you are fallible and that you are probably wrong more than you are right. Learn to appreciate negative feedback and criticism as gifts of guidance. If you drink your own Cool-Aid believe you are too good for improvement you aren't improving. The soft-skills are perhaps the most important part of becoming more productive.

</comment><comment><USER77> Do 2x developers exist? And what about 5x developers?

<comment><USER27> It's a matter of speech, not a concrete measurement. I'd liken the speed to a "compiled" version of the problem in your mind; if you've done it before, it's easier to apply it now, rather than to start from the beginning to understand the problem.

</comment></comment><comment><USER78> you fools still believe it's an innate characteristic that only a few can possess; it's something anyone of us can achieve as a form of transcendence

<comment><USER79> Just wondering. Can we all be J. R. R. Tolkien?

Other industries have people who are clearly Superstars. Why would they not hold true for development?

<comment><USER80> Nah, I expect not. But we can probably all be Jim Butcher or Robert Jordan.

<comment><USER78> You're still trying to be anything but yourself, why not start at first principles?

</comment></comment></comment></comment><comment><USER81> Well, but C++ does take a lot of time to compile. The whole meta language implementation is relatively dumb for a lack of another word. So should every C++ product now be scraped and rewritten either in rust, ocaml, or C? Or is it upon the Developer to see these problems and find a workaround?

<comment><USER56> Large codebases can take a long time to compile, but if, as the article claimed a simple new Hello-World example is taking minutes that's because your build system is unnecessarily rebuilding everything every time.

<comment><USER82> I know not all things should be attributed to technical causes.

But I'm a consultant and I often have to deal with - to me - new MLOC piles of C++ code. These code bases are of course almost always non-trivial and my first approach is most of the time - If I am permitted - to analyze the include structure and to optimize it. Removing headers, pimpl, basic things. Only then would I even begin, to explore particular problems. Side effect is an intermediate 500 feet view, that develops along the way.

Many developers are too hasty, taking too narrow an approach.</comment></comment></comment>


Show HN: Mock your API - <AUTHOR> https://www.owllang.com <comment><AUTHOR> Hi everyone. I created this website because I want to solve some of the problem that I have when mocking an API. 1\. I need a mock that uses the same function as the real API. 2\. The mock API must have the same path as the actual API so that integrations and switching between dev and prod is easier. 3\. Delay so I can test loading time.</comment>