Uber lays off 435 people - <AUTHOR> https://techcrunch.com/2019/09/10/uber-lays-off-435-people-across-engineering-and-product-teams/ <comment><USER3> Hello Uber Engineer here!

Obviously everything I say is personal experience and opinion. I think the layoffs were long overdue and should've happened sooner. There was a general understanding between my coworkers and I that Uber definitely over hired in 2016. Thanks to that a lot of engineers ran out of things to do which led to political infighting over roadmap, ridiculous redundant resourcing - <USER2> single team had mobile/web, severe shortage on infra teams since head count was already taken by main Uber teams. We even started building and maintaining our own chat app. I disagree that all the cool eng project that we put out and share here is a waste of time or resources. Those project was initiated by real needs on Uber and only the best make it out into the rest of the world. Engineers that shipped those projects are still here and we would've done it regardless of whether the 435 people that were hired in the first spot. I fully realize that it's an insensitive thing to say but I think it's important that it's expressed somewhere.

I think the lesson here is to grow responsibily, and it's real people's lives that are being affected. Don't hire people to alleviate your current engineer's burnout and stress. Learn to plan better and to prioritize aggressively instead of just hiring and getting everything done.

<comment><USER4> > We even started building and maintaining our own chat app

God I love the Not Invented Here disease. Somebody, somewhere, thought "hey, slack is way to expensive, we don't want to get 'locked in', and 'mumble mumble privacy cloud evil stallman' so lets write our own chat application.... how hard can it be?"

Boom, now the company is straddled by a shitty, homebrew chat application that is maintained by nobody because the original author left for greener pastures. Nobody dares replace it though because that would be sacrilege. That chat app is part of the company, after all!

Arg.... I hate, hate, hate when engineers with a bad understanding of business and too much time on their hands lock their organisations into homebrew crap that has nothing to do with the value delivered by the business.

/rant

<comment><USER5> "Enterprise" slack is $15 per head per month. This would equate to an recurring annual expenditure of nearly $4.86million for Uber's 27000 employees.

Given that Slack can be seen as IRC with some pretty decoration glued up to an Elasticsearch instance, and that Uber already has a highly trained tech org in place, if it wants to make a Slack "clone" for less than, say, $25million (cost of Slack to Uber for 5 years), it could actually be a pretty sensible decision- especially when you take into account the tax and stock-price benefits of capital expenditure.

<comment><USER6> Unless NIH/buy are truly the only options. `docker run whereverthatactuallyis/mattermost` looks like a cheaper option that doesn't require building from scratch.

<comment><USER7> Funnily enough, mattermost seems to list Uber as their client on their home page. [https://mattermost.com](https://mattermost.com)

Maybe they realised it was a superior solution to building their own app.

<comment><USER8> > _Maybe they realised it was a superior solution to building their own app._

Uber's internal chat tool is built on top of Mattermost.

<comment><USER9> That's unfortunate - they could have made Mattermost on par with Slack instead.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> Probably some reality shaking out. Uber's engineering team puts out some impressive stuff, often as OSS. Their engineering blogs are regularly on HN. I've been genuinely surprised that they churn out some of these things and release them for free given their relatively extreme financial situation.

In contrast to companies like Google, Apple, Microsoft, Amazon etc. that have mountains of their own money to burn (rather than investors') on research and OSS side-projects, it always seemed to me that Uber was trying to play the same game, but far too early. Paying lavish SF engineer salaries to generate cool, but not revenue generating, software is probably excellent for morale, culture and recruiting, but a dubious use of resources when you are losing money seemingly faster than it would be logistically possible to literally burn it.

Saying they're ~ "culling the low performers" can be entirely true, but it is also a Silicon Valley, meritocracy-culture-friendly way of saying "we're losing far too much money to pay bloated growth-stage poaching-game salaries to engineers, so if you're not working on something that generates revenue, glhf"

<comment><USER11> > that have mountains of their own money to burn (rather than investors')

I totally agree with everything you're saying. But I'm going to quibble with your phrasing. Apple's cash reserves belong to the shareholders just as much as Uber's funding rounds.

Too many CEOs operate under the mistaken belief that retained earnings is "play money" in the way that paid-in-capital is not. For investors, retained earnings are subject to the same opportunity cost of capital as funds raised by equity or debt.

Its management's responsibility to deliver returns exceeding the firm's weighted-average cost of capital. If they can't do that, then they should return capital to the shareholders, who can then use it an alternative higher- returning venture.

<comment><USER12> I get that this is the normal ideological description of firms post-70s neoliberal whatever, but if that's true, like why not just say firms suck, we need communism? Like your description makes Pikkety look like an optimist. "The purpose of a firm is to help rich people get money faster than other rich people" logically implies that eventually a small group of rich people will have all the wealth. That's feudalism. If that's the goal, let's start a revolution instead.

<comment><USER13> share holders longer term don't have to be rich

<comment><USER12> I agree, but the theory "firms exist to maximize shareholder value" ensures that they will be.

Put it this way: gravity turns space dust into supernovas. Dust is just ever so slightly attracted to other dust, so it accumulates and accumulates, and eventually it becomes so massive that it forms a star.

The theory that firms should beat the market makes money gravitational. A shareholder who beats the market will get more money than other shareholders. Now they have more money that they can use to invest in other market beating schemes, etc. If whether a firm beats the market is random, then some investors will win and some will lose but it all balances out. But if beating the market is not random (and how could it be totally random?) then those with the most money can invest in the best firms faster and more easily than smaller investors and crowd them out. Remember that companies only have a finite number of shares, so not everyone can invest in a winner. If there's even a slight bias towards having more money making it easier to beat the market, then eventually you will get a supernova.

We all understand this on some level. Why is insider trading illegal? Because it makes it trivial to beat the market!

</comment></comment></comment></comment></comment><comment><USER14> Scaling back on the engineering and product teams was a smart move to cut costs. The promotions in engineering have been based on rollout of new features. No one was willing to be a grown up and require the engineering team to fix actual problems with the core product, the app. That is on the VPs. Sure, fixing bugs is not as much fun as building new features but Uber needs to make its core product better. Uber also had the opportunity to use a mapping system like google maps or Tom Tom the way that Lyft has. Instead, they built their own proprietary system at huge expense, refused to scrap it after it became clear it would be advantageous to do so, and have yet to work out the bugs with turn by turn navigation. There are some brilliant people at Uber doing amazing things, there are also a lot of ridiculous side projects with engineering teams devoted to them like the flying car team. It's unfortunate that Uber laid off so many people. Maybe if upper management had made smarter choices about how they measure and reward success internally prior to this they would not be in the situation they are in.

</comment><comment><USER15> Related, but Uber is said to be hiring 2,00 for it's new Chicago office next year [1]. A mix of engineering and operations. My understanding this would be under their freight team, which according to this Techcrunch article, was unaffected by this layoff.

[1]: [https://www.chicagotribune.com/business/ct-biz-uber- hiring-o...](https://www.chicagotribune.com/business/ct-biz-uber-hiring-old- post-office-20190909-va4mtjmgkfh7bnlrub736fbw5q-story.html)

<comment><USER16> They also recently announced plans to hire 3,000+ in Dallas [1] at a brand new massive office. I'm sure the hiring and layoffs are from different business units, but it does seem strange that there's been multiple several-hundred- people-layoff stories form Uber recently at the same time they're announcing otherwise massive hiring expansion. I would at least figure that they would prefer to transfer engineers between units rather than to layoff and hire anew.

1: [https://www.nbcdfw.com/news/local/Dallas-Leaders-Approve- Abo...](https://www.nbcdfw.com/news/local/Dallas-Leaders-Approve- About-93-Million-in-Incentives-for-Potential-Uber-Expansion-542866411.html)

<comment><USER17> Does Uber have different pay scales depending on location?

<comment><USER18> I can't possibly imagine they're paying 3000 Dallas employees a bay area salary.

</comment></comment></comment></comment><comment><USER19> I don't know the details of this situation and Uber is far from a healthy company, but I don't like that layoffs are always a sign of a company in peril in Silicon Valley.

1) This is a public company with shareholders. If they think they can cut costs without hurting their revenue outlook that's not a bad idea!

2) We all know that interviews for engineers in SV suck ... So why can't you fire someone if you make a mistake?

3) I work at a company (Google) where the prevailing assumption is that if a team is not getting enough done it should ask for more engineers. That almost never helps. It adds communication overhead and doesn't address the problem of why the team wasn't getting to where it thought it would. Just smothers the issues. The most effective teams I've ever worked with were 3-10 people who were motivated and working in their area of expertise.

4) We all know that one bad teammate can undo the work of two good ones.

I could go on. Yes I truly have sympathy for anyone who loses their job suddenly. It sucks for them and those who depend on them. It's probably good for Uber though.

<comment><USER20> > I work at a company (Google) where the prevailing assumption is that if a > team is not getting enough done it should ask for more engineers.

What I'm finding at Google is that whenever a team takes longer than 2 quarters to do pretty much anything, that's considered some kind of "problem" that needs to be "fixed." Sometimes the problem is that the technical challenge really needs more than 2 quarters to be adequately addressed. And yes, the first instinct is to ask for more headcount. But often times the problem is also with the headcount you have, not the headcount you don't have.

What is usually needed is to get rid of the TLM who got into a management position through the IC track because of the collective delusion that someone who has worked their way up to Senior or Staff SWE by writing dank design docs and uber code (often in vast quantities) has also acquired senior engineering management competency.

Once you've hired somebody who has significant education and/or experience with engineering management is managing the team, the next thing for that person to do is figure out how to increase the health and effectiveness of the team they have. You might even need to reorg to get the team size down to 7-10. In the process you need to give the team a couple more quarters to cut their MVP down to the bone and deliver on it.

Then, and only then, should you think about throwing more headcount in the team's general direction. And it needs to be done with the goal of adding a layer of management hierarchy, making sure than no more than 7-10 people are in the daily standups.

</comment></comment><comment><USER21> Uber was actively poaching from our team when I was at Edmunds.com a few years ago; hope my ex-teammates that jumped ship are doing alright.

Uber is in a precarious position and I can't help but wonder what would be different if Travis Kalanick were still in charge. I know it might be an unpopular opinion, but I think his leadership and vision were really instrumental to Uber's early success.

<comment><USER22> I mean resistance to his ideals and methods are based on his relative carelessness towards anything but his and the company's goals.

Incredible leader, amazing CEO with the raw ability to move mountains for the company's growth.

Remarkably bad at human and helping humankind.

If burning the Amazon rainforest helped Uber's goals he would have it torched in the most efficient and rapid method possible by morning light. Perfect CEO for the shareholders and maybe for keeping the lights on, not so much for the rest of us.

<comment><USER23> > Remarkably bad at human and helping humankind.

I would say that the way how Uber aggressively expanded throughout the world has massively helped humankind. Because of Uber, many countries have changed their taxi laws, and many local competitors have sprouted up. More efficient taxi and ride-sharing services help save the environment and make cities nicer. Of course this is quite theoretical but I believe Uber was the needed company to push the mass transit development forward.

<comment><USER22> Was making more taxis on the road with more downtime and increasing congestion really an improvement in cities? A Recent study found that 50% of all cars in lower manhattan were rideshares. Is that really a better world? Ridesharing in cities has been absolutely proven to increase pollution rather than reduce while carpooling in rural areas helps reduce pollution. The problem with rideshares is that they are jobs based on time rather than efficiency. You drop someone off and then you are available to pick someone up, so you drive to them, drive them where they need to go and drive to the next person, the points between passengers are reductions in efficiency vs single cars and add to congestion in high congestion areas. In any case mass transit is much better in cities.

<comment><USER24> There is surplus value to the customer that you aren't accounting for. Mass transit is a far worse experience than Uber.

<comment><USER25> In most of the US, probably. It's not so clear cut in London. The tube is usually faster and more pleasant. (London's air quality is pretty bad, and many Uber drivers have an annoying habit of driving through heavy traffic with the windows open.)

<comment><USER24> Sure, but London has always had taxis, too, because sometimes they're the better tool. It's not like some people are taxi-takers and others are subway- takers. You use whatever's best at the time. When I lived in Boston I took the T every day -- but on some occasions, a taxi was the better choice.

<comment><USER25> I was responding to the claim that mass transit was "far worse" than Uber.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER26> I wonder about Uber, they have spent lots of money branding and getting everything in place, that they overshot the whole making money aspect and now playing catchup. Problem is, will they reach that balance before they bleed beyond the point that they become vulture targets for another large company to step in, cherry pick what they want and discard the rest.

With all that said, I wonder if maybe Amazon or some self driving car startup steps in and buys them up for a lot less than it would to build that penetration. Can imagine your Amazon owned Uber driver bus picking you up, with half a dozen stops on the way, some people, some packages, doing the rounds. Things change, how will Uber adapt and more so, all those drivers on zero hour contracts, are just as easily laid off and much cheaper as well. Self driving cars are a case of when, not if as so much being done in the field, progress has become a hot competition and slowly getting there.

<comment><USER27> Uber was very profitable when they just had Uber Black. The problem is they were disrupted themselves by Lyft and had to launch UberX (give Travis credit for launching this _before_ Lyft even though it was their idea).

<comment><USER28> Are you sure? In the recent book about Uber written by Mike Isaac,the author stated that Lyft was the first to launch a low cost ride service with non professional drivers and Uber rushed to copy them.

<comment><USER27> I read the book last weekend and am going with my memory (I've since lent it out). In the book Travis found out about Lyft's planned rideshare service and raced to launch UberX first.

Alas google has become useless for finding useful information so I hope somebody who still has the book can confirm.

<comment><USER29> That was referring to Pool / Lyft Line.

As others said, Sidecar was technically the first to the "ridesharing" model

<comment><USER27> Thanks for the correction!

</comment></comment></comment></comment></comment></comment><comment><USER30> Uber is also planning to open an office for 3k employees in Dallas.

"...create 3,000 full-time jobs and pay employees an average salary of at least $100,000..."

Considering the lower cost to operate in TX it would make sense to move IT roles to that area.

[https://www.dallasnews.com/business/technology/2019/08/09/ub...](https://www.dallasnews.com/business/technology/2019/08/09/uber- s-dallas-office-could-bring-3000-jobs-downtown-be-company-s-biggest-hub- outside-san-francisco/)

<comment><USER31> The Dallas office is an administrative office and will not have eng roles. Also, these are all "promises", we really have to see how it plays out. Promises are cheap. Remember how Foxcon was going to hire 10k people in Wisconsin

<comment><USER16> That isn't what the article in the parent comment says:

>The office would include engineers, finance executives, salespeople and other roles across Uber's business.

<comment><USER31> Here [https://www.businessinsider.com/uber-new-offices-chicago- dal...](https://www.businessinsider.com/uber-new-offices-chicago-dallas-will- dwarf-san-francisco-hq-2019-8)

This directly quoted an Uber exec saying that it will be focused on HR, sales, and ops

</comment></comment></comment></comment><comment><USER32> This is a bold move for sure. It sounds like they might have hired the wrong people so instead of "redeploying" them they just cut pretty deeply. Definitely unfortunate for the employees but also impressive that Uber had the guts to do this. I've seen companies let dead weight hang on for too long. The fact that they are still hiring makes me think that this was not a panic move to address Wall Street.

</comment><comment><USER33> There's definitely a tightening of capital happening right now. Investors are pulling back as fear of recession grows.

EDIT: Did I say I believe there's a recession coming? No. I said (accurately) that there are growing FEARS of one. There's definitely tightening of investments and capital happening.

<comment><USER34> I mean there's also the fact that California has pending legislation that seems ready to pass that will kick Uber (and others in the gig economy space) right in the wallet. Next 2 years should be interesting as we see what effect that has on things.

<comment><USER35> What's funny is that if they were employees then uber would be a lot harder to compete with. As it is now uber drivers will use several apps and often recommend competitors to customers, which they're entitled to do as private contractors.

<comment><USER34> If they were employees, Uber(and the others) would just be another taxi company and wouldn't have the same market share/investment levels they do.

</comment></comment></comment></comment><comment><USER36> Kinda interesting that they chose to do the layoffs during the Apple event. I wish companies would just own what's going on instead of trying to bury it.

<comment><USER37> Some tech company always tries to bury their garbage during Apple keynotes, unfortunately... Glad this made it to the top here anyway.

</comment></comment><comment><USER38> Uber's core business is a taxi app and I get that there are some clever algorithms involved, but I still don't really understand how they justify the size of their engineering team.

I read that they had 2,000 engineers out of 6,000 employees in 2016, though I don't know the numbers now. That seems gigantic.

<comment><USER39> There is Uber Eats, Freight, and JUMP bikes in addition to their ride-hailing product. I believe they share some technical similarities but still each of the four(I know of) are startups ideas imho.(See Lime, Lyft, Sennder, Delivery Hero, Takeaway.com, door dash etc.)

</comment></comment><comment><USER40> Google is pretty well-known for maintaining a very deep bench-- if an engineer isn't effective in some role, they'll just move them to some other team. Heck, a lot of hires (especially 3rd/last attempt) go directly to the bench. This strategy pays off well when a new competitor (like Facebook or Uber) comes along and snatches up people in the lead roles, or if the company feels the need to pivot to something really fast (e.g. Google+, which drew from many teams across the entire company).

Moreover, hiring a long-term employee today versus tomorrow might save money for a place like Google, assuming we expect competition and wages to continue to increase.

It strikes me that if Uber is laying off software engineers, their company outlook must be very, very dire. A layoff is perhaps better strategy than firing the bottom 5%, which would likely preclude the departed from re-joining at a better time. But probably the wrong message to send to a cohort like software engineers-- a layoff is a legal confirmation that the company made a big mistake.

<comment><USER41> This strategy works very well if you have a gigantic money printing machine, which Google does. Uber has a gigantic money _incinerating_ machine. They don't have the ability to just have engineers spinning their wheels on non- business critical projects like Google does.

<comment><USER42> Or in the case of Amazon you have both, printing money with an awful culture of churning through employees. They even structured their stock vesting around it.

<comment><USER43> What is Amazon's vesting structure?

<comment><USER39> Seems it vests over 4 years with 5%, 15%, 40% and 40%

<comment><USER43> That's pretty awful.

</comment></comment></comment></comment></comment></comment><comment><USER44> They are in a race: Be the first with self-driving taxis and go for the monopoly, or run out of cash. I don't want to sound pessimistic, but my bet is on the latter. It's just such a hard problem, especially in cities.

I just hope there won't be a kind of AI winter when some of these startups run out of money.

<comment><USER45> > Be the first with self-driving taxis

This is thrown out all the time. How exactly does this save them?

Are they going to spend billions to purchase and maintain a fleet of their own taxis? Are they going to be paying people to "borrow" their self-driving cabs? Something else?

I just don't see how this suddenly changes the equation in a meaningful way. People aren't going to spend more for a self-driving ride and the costs can only go down so much.

<comment><USER46> Because self driving cars, while expensive, are still significantly cheaper that employing drivers. Furthermore, it could be argued that you need less self driving cars than cars with drivers, as they never need to take breaks, and can work all hours of the day. It would also drastically decrease ubers cost of entering new cities - previously they relied on driver incentives, this flattens the variation in cost greatly.

<comment><USER47> > Because self driving cars, while expensive, are still significantly cheaper > that employing drivers.

Are they? How much does a self driving car go for in today's market? And does your calculation include the fact that a driver comes with free car, maintenance, fuel, etc.

Even if the numbers do add up, SDVs aren't about to roll out next week. Remember how close we were to VR for about 30 years?

</comment></comment></comment></comment><comment><USER48> How does this work with layoffs + hiring? Can you layoff and then hire in the same department? I assume companies agree to pay at least unemployment and possible severance too in the case of layoffs. Can a company say "These 80 employees are under preforming" and justify a reduction in force that way? (I guess in at-will employment you don't need to justify it at all, so long as you meet legal unemployment requirements?)

Are they getting rid of under performers and getting new blood or are they cutting people from certain departments (in which case, they could apply to be rehired in another division?)

<comment><USER49> Like another poster mentioned, up until 2 years ago (?) Uber was handing out very fat compensation packages even to entry level engineers. It's possible these are employees who've been at Uber for 2+ years and are frankly overpaid even if there were no serious performance issues.

</comment></comment><comment><USER50> Is this the same as the 400 from a month ago, or a new batch?

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

Edit: Guess not, that initial group was just marketing. From the article:

>These layoffs come shortly after Uber laid off 400 people from its marketing team.

</comment><comment><USER51> I've always wondered if uber were to abandon their ongoing development efforts and focus on support and maintenance, would they would actually be profitable? It seems to me they would need a fraction of the tech workers they currently support.

<comment><USER52> No. Their quarterly losses are more than double their entire R&D spend.

<comment><USER53> Fact check: R&D spend for three months ending June 2019 was $3.06B. Reported loss for three months ending June 2019 was $5.24B. So, already false.

Now take away the one-time IPO expense of $3.9B, and we're not even close to being true. Further take away the $300M "IPO driver appreciation award" and you end up with a $1B loss for three months ending June 2019. In other words, the quarterly R&D spend is over three times the size of the quarterly loss.

[https://investor.uber.com/news-events/news/press-release- det...](https://investor.uber.com/news-events/news/press-release- details/2019/Uber-Reports-Second-Quarter-2019-Results/default.aspx)

<comment><USER54> But that IPO stock-comp expense is largely attributable to R&D, so if you want to subtract that from the losses to look at a more cash-focused analysis you have to substract that cost from the R&D side as well.

Of the $3.95B total stock expense, $2.56B was from R&D, which suggests cash cost that quarter was more like $910m (still a lot!)

<comment><USER53> To my mind this quarter shouldn't be used at all in this kind of discussion since its so messy. e.g.: I take your point, but that $2.56B is the culmination of over ten years of R&D compensation. It's not at all representative of the company's broader financials.

OP's inference that Uber's quarterly loss is more than double Uber's quarterly R&D costs _in general_ shouldn't be propped up by a moment in time observation.

</comment></comment></comment></comment></comment><comment><USER55> I suspect when the economy takes a downturn luxury purchases like this will be the first to go. If I think I might be laid off do I spend 10 dollars to Uber home or walk the 5 blocks and have one less drink? I would personally have one less drink and walk, or take the train/bus... Those 7 dollars Starbucks venti iced white chocolate mochas with 5 shots will slow also.

<comment><USER56> One drink determines whether you can walk 5 blocks or not?

<comment><USER57> It was difficult to follow, but I think the point was to exchange the cost of the uber for a drink (same cost) but walk home.

</comment></comment></comment><comment><USER58> Is it any coincidence this happens the week that CA is debating a bill that can drastically change how they compensate drivers? It appears like they are trying to gain leverage from an outsider's perspective.

<comment><USER59> Uber is at a worrying place with or without bill.

</comment></comment><comment><USER60> Any idea roughly how many SF engineers just got laid off? Trying to get a sense of how this will hit the local labor market in the next few weeks.

Articles says 265 engineers.. 85% in the U.S. So up to ~200 will be looking for SF jobs? How many are remote or in other US offices?

</comment><comment><USER61> This is an unsustainable business model. If you draw a Gaussian surface around it, the end result is that Uber/Lyft will destroy the taxi industry (which was execrable, but put a fair amount of kids through college) and replace it with pauperized "contractors" too naive to calculate depreciation. And at the same ultimate fares, but with less share for the drivers.

Enjoy it while you can, I guess.

</comment><comment><USER62> My uber alg:

1) open the Uber app.

2) X - price of ride with uber.

3) open the Lyft app.

4) Y = price of Lyft.

IF Y < X -> Choose Lyft. Else : Choose Uber.

Currently, Uber is around 20% more expensive. Not good.

The rest is irrelevant to 99% of the customers.

</comment><comment><USER63> Anyone know what divisions the layoffs were in?

</comment><comment><USER64> "Of those laid off, more than 85% are based in the U.S., 10% in the Asia- Pacific and 5% in Europe, the Middle East and Africa, according to the source."

Interesting. This hit seems to be mostly localized to the US. During their last mass layoff in July, employees from all over the world were affected.

[1] [https://www.reddit.com/r/dataisbeautiful/comments/cwutan/oc_...](https://www.reddit.com/r/dataisbeautiful/comments/cwutan/oc_locations_of_the_400_uber_employees_laid_off/)

</comment><comment><USER65> Dang, I wonder if this makes my job search here in SF much harder now :).

<comment><USER66> More startups than people here with multiple black holes sucking up talent dont worry from this news

Recruiters salivating though

</comment></comment><comment><USER67> I predict this situation to get worse over the next couple of years and will culminate in Uber shutting down the self driving project and partnering with Waymo.

</comment><comment><USER68> "exceptionally high-performing teams"

12h sort of performance.

</comment><comment><USER69> Maybe Uber should focus on fixing their main app first. Driver can't get rides even after being online for hours sometimes. Card payments are being delayed and now I know why they are decreasing bonuses day by day, due to over hiring, because they have to pay over hired engineers a shit amount of money thus decreasing drivers bonuses!

</comment><comment><USER70> ...and the internal demoralization just started. Once this Pandora box is opened, it cannot be closed.

</comment><comment><USER71> I think the logic is simple:

while(true) { getHired(); work(); quitOrGetFired(); }

There's no logical explanation for any of these steps. Every company that is being funded is not funded for being responsible, but for showcasing a hockey stick growth and making investors go $$$$$$$. If you're lucky, there's a chance your company will be an unicorn, and if you are luckier, your stock will mean something, and if you are one of the luckiest, you can actually sell it and do something else with your life than work. Anecdotal evidence shows that you need to be really lucky than be meritorious to make money. It also shows that even with low luck, periods of employment basically give you that money stream.

Leave the analysis for someone else and get going! I've already done the good deed of referring the Uber engineers in my network.

IMO, about the open source thing - Now that you've left Uber, you still have the neat tools you need to build something better, faster, bigger and someone else already paid for the caveman to science work.

</comment><comment><USER72> Serious question: what does Uber need 27k employees for?

1k people to run the show in the main headquarters + some small-ish ~50-100 people regional offices should be enough to keep the company running.

<comment><USER73> Uber is in 85 countries and each one needs ops, legal, marketing, driver interaction teams and etc. There are only 4000 engineers.

<comment><USER74> Perhaps the next question is, what do 4000 engineers do? Not aimed as a troll-y question: an informed idea of what the breakdown of that many engineers do would be enlightening. For example, there were about 200 iOS engineers the last I heard. Assuming similar levels for Android, that leaves 3,500-3,600 engineers.

<comment><USER53> +1 Appreciate you avoiding the usual "it's just a little smartphone app"

I'm not going to try and give an exhaustive list, but as a rough explanation: things get really, really hard when you're operating at Uber scale (hundreds of thousands of riders on trip at any one time, each demanding low latency and reliability):

\- Product: native clients for each side of the marketplace in each vertical (rides, eats, freight, atg, et al), maps, localization for every country with a presence (not just language, but tax, legal, hundreds of region-specific modes e.g.: tuk tuks)

\- Infrastructure: hardware teams to build on-prem DCs (cloud can get very expensive at scale), software networking to deal with said low-latency traffic, storage to optimize for reliability/latency/cost, observability (metrics, logging, alerting, tracing), security, et al

\- Data: insights, operational support, routing, et al

\- ATG

Hope that gives a better idea.

<comment><USER68> Datacenters are not cheap either, at escale go for the Cloud as it makes some operations more efficient which is what they want.

VMware for example, assuming they don't use ProxMox lol, is super expensive, hardware maintenance, network, power, building, etc.

</comment></comment></comment></comment></comment><comment><USER75> This is probably good news for "City Storage Solutions," Kalanick's new startup, given the volume of recruiting emails I've seen going around from them.

</comment><comment><USER76> Sounds like an awesome opportunity for hiring managers. At my last company, I'd be all over this, and indeed may be all over this when I start my new position.

</comment><comment><USER77> Curious to know how many of the engineers who were laid-off were specifically iOS. Relevant to me since I'm pigeon-holed and in the Bay Area :)

</comment><comment><USER78> Hi newly ex-Uber engineers! If you're an iOS developer And live in Southern California please reach out.

</comment><comment><USER79> Maybe they can be independent contractors, what with the gig economy being no big problem and such.

<comment><USER80> Oh yeah

</comment></comment><comment><USER81> Does anyone know yet how this will affect their open source work, such as react-vis and deck.gl?

<comment><USER82> If they heavily rely on their own tools, odds are good maintenance will continue.

</comment></comment><comment><USER83> This is positive, they need to adapt to the expectations of the public markets.

</comment><comment><USER84> My question is, do they forfeit the RSUs given to the laid-off workers?

</comment><comment><USER85> Hey! Maybe there should be unions in tech! Just a thought!

</comment><comment><USER86> This news comes hours after a massive Uber outage. Huh.

</comment><comment><USER87> I can't belive that such simple and hugely profitable idea needs such huge staff, which can only screw things up. No wonder these idiots are losing big money!

</comment><comment><USER88> well hope their balance sheet looks better now

</comment><comment><USER89> Dropbox is next.

</comment><comment><USER90> Ohh we want come back. Uber xl. To Turkey again

</comment><comment><USER91> I believe the actual term is "deactivated".

</comment><comment><USER92> This is just unaccetable

</comment><comment><USER93> Great news

<comment><USER69> great? how?

</comment></comment><comment><USER94> I think like @fpoijasw

</comment><comment><USER95> I wonder how long a nonprofitable company can sustain...

<comment><USER96> As long as the Fed keeps lowering interest rates

</comment></comment><comment><USER97> 435 of their real employees or fake employees?

</comment><comment><USER98> Given what we know of Travis Kalanick and Saudi Arabia, burn baby burn!

Good riddance.

</comment><comment><USER99> > we have over 27,000 full-time employees in cities around the world

Wow

</comment><comment><USER100> It all comes down to management. ASSHOLE IN === ASSHOLE OUT

¯\\_(ツ)_/¯

</comment><comment><USER101> I'd like the see HN consider layoffs in other verticals as well. Particularly manufacturing.

<comment><USER102> Why?

<comment><USER101> It seems like technology plays a role in these paradigm shifts, perhaps awareness might inspire folks to leverage the workforce in new ways, maybe with technology.</comment></comment></comment>


Visual simulation of the 6502 CPU - <AUTHOR> http://www.visual6502.org/JSSim/expert.html

<comment><USER2> Any folks on here know of good resources that might help someone begin to understand what they're looking at here?

More generally, learning about the physical operation of microprocessors? I'm particularly iffy when it gets to where the wires and the assembler meet, if you will.

<comment><USER3> Yeah, check out "Feynman Lectures on Computation": [https://rapidshare.com/files/2100994846/Feynman_Lectures_on_...](https://rapidshare.com/files/2100994846/Feynman_Lectures_on_Computation__1996_.pdf)

It's fantastic. Feynman dives all the way down to the very fundamentals of how a computer could be built.

Much of the information is likely dated; nonetheless, it's still viable.

<comment><USER4> Or, if you happen to prefer getting still-in-print books legally rather than pirating them, <http://isbn.nu/0738202967> .

</comment></comment></comment><comment><USER5> That's an impressively detailed simulation. This is tangentially related, but I made an html5 Apple ][+ emulator which, of course, includes a 6502 component. Mine doesn't simulate gates or anything that cool (and isn't even 100% correct yet) but it boots and runs a lot of different software (at full speed): <http://porkrind.org/a2/>

</comment><comment><USER6> Previous discussion: <http://news.ycombinator.com/item?id=1702200>

</comment><comment><USER7> I have no idea what is going on here, but it looks really neat.

<comment><USER8> IIRC, it's a JS simulation based on the physical transistors of the original processor.

Neat, indeed.

</comment></comment><comment><USER9> Video on the background <http://www.youtube.com/watch?v=K5miMbqYB4E>

</comment><comment><AUTHOR> and 6800: <http://www.visual6502.org/JSSim/expert-6800.html>

</comment><comment><USER10> Appears to not work in Chrome (at least for me). Safari did the trick though.

<comment><USER11> Works in Chrome for me. (Windows 7, 64 bit, no extensions installed.)

</comment></comment><comment> mck- Fancy. But what's it for?

<comment><USER12> For writing DCPU-16 emulators, of course!

</comment></comment><comment><USER13> Wow this is really cool.

</comment><comment><USER14> My eye hurts.</comment>


Neighbors Clash in Silicon Valley; Job growth far outstrips housing - <AUTHOR> http://www.wsj.com/articles/neighbors-clash-in-silicon-valley-1465291802 <comment><USER2> > Housing has lagged behind commercial projects in part because it is less > lucrative for municipalities. Land that goes to residential uses tends to > bring in less tax revenue—and requires more services like schools and parks. > San Jose last year estimated that for every 1,000 square feet of single- > family housing, the city budget takes a net loss of $255 a year, compared > with a gain of $1,064 for the same size commercial space.

The taxes are too damn low!</comment>


Congress introduces bill to block government encryption backdoors - <AUTHOR> https://www.cnet.com/news/congress-introduces-bill-to-block-government-encryption-backdoors/ <comment><USER2> Its a nice thought, but If the NSA is part of the Executive Branch, good luck getting them to police themselves in a transparent matter.</comment>


Ora.pm – new task management, just got better - <AUTHOR> Ora.pm gets a huge update! - https://ora.pm/ - Task Relationships<p>- Recurring tasks<p>- Full Keyboard Support<p>- Move Cards to other projects<p>- GitHub Issues Import<p>- Set/remove attached image as cover<p>- Star public projects <comment><AUTHOR> Ora.pm - [https://ora.pm/](https://ora.pm/)

Update Blog Post - [https://ora.pm/blog/august- update-2017](https://ora.pm/blog/august-update-2017)</comment>


Design Documentaries - <AUTHOR> https://rrrepo.co/repo/designDocumentaries <comment><USER2> Can't find this on the list, but I loved this video of Aaron Draplin working through a new logo design:

[http://vimeo.com/113751583](http://vimeo.com/113751583)

<comment><AUTHOR> If you sign up, you can submit it directly and get the credit for it :) If you don't want to, let me know and I'll just add it myself :)

</comment></comment><comment><USER3> Also check out [http://designers.watch](http://designers.watch) \- very nice, curated collection of design-related documentaries.

</comment><comment><USER4> _51_ Design Documentaries

It's an excellent list. Most designers will have seen many of these already.

<comment><AUTHOR> You actually counted, I'm impressed!

<comment><USER4> I counted the ones that I had seen. Then counted the ones I hadn't.

</comment></comment></comment><comment><USER5> Great list! I would add the Clouds Documentary: [http://cloudsdocumentary.com](http://cloudsdocumentary.com)

<comment><AUTHOR> If you sign up, you can submit it directly and get the credit for it :)

If you don't want to, let me know and I'll just add it myself :)

</comment></comment><comment><USER6> That looks like a great list of documentaries. I might watch few of them this weekend. The website could use ngCloak though as the angular expressions flash for a sec or two before the actual data loads.

<comment><AUTHOR> Thanks for the feedback. I'll pass it on to the backend dev. I agree, the flash annoys me.

</comment></comment><comment><USER7> Great resource! The scrolling is weird on mobile safari. May be missing some -webkit-overflow: touch to the scrolling element.

</comment><comment><USER8> @mildrenben - I see its your site so just a heads-up that the font rendering on rrrepo is _really_ poor on Win7 Firefox.

<comment><AUTHOR> I am aware of that, and I have tried everything I can to fix it, but nothing works.

We're looking into other fonts now to make Firefox a better experience, as right now it isn't that great.

There are other things we need to fix on Firefox too, which we will be fixing over the next couple weeks.

</comment></comment><comment><USER9> I really appreciate the intuitive UX here, that (almost) every title links to a streaming copy of the film.

</comment><comment><USER10> Scrolling this page is frustrating in iOS Safari, as inertial scrolling seems to be disabled or broken.

</comment><comment><USER11> @mildrenben Great work. Solid collection and love the other rrrepos as well. :)

</comment><comment><USER12> Snark Attack! I think this title should have been: "50 Design Documentaries"

<comment><USER13> Doesn't HN have a rule about no numbers of things in the title? So the most appropriate submission would just be "Design Documentaries"

<comment><USER13> ...and now that's the title! Way to go team tomelders+jchendy.</comment></comment></comment>


Where is the casual programming? - <AUTHOR> http://iamsamy.blogspot.com/2012/04/where-is-casual-programming.html <comment><USER4> There is one statically typed language with a nice toolchain that allows interactive (REPL) programming and scripting: F#.

Try the steps here[1]. They're old, but still work, and work pretty well. It's fast; there's no need to create a project or solution. You can type your code all you want, use IntelliSense and all that, then select and Alt-Enter to execute it.

If you don't want to load VS, you can just run "fsi" for the interactive shell alone. You'll lose the full IntelliSense and colour highlighting, but you still get tab-completion. Plus, F#'s syntax is much lighter than C# or Java, so it's nicer for quick scripts.

Quite frankly, for any level of programming, I find having a REPL available is such a massive productivity boost. I shouldn't have to give up static type checking and a slick IDE to get it.

[http://blogs.msdn.com/b/jomo_fisher/archive/2008/08/25/f-scr...](http://blogs.msdn.com/b/jomo_fisher/archive/2008/08/25/f-scripts- zero-to-execute-in-ten-seconds.aspx)

<comment><USER5> And F# is not the only statically typed language with a (built-in or out of the box) REPL: ML, Haskell, OCaml, and Scala all have REPLs.

Some of these predate Java and C#, but I don't know what it is about those languages and the cultures around them that has ignored the value of a REPL. I guess part of it is just inertia at this point, but it's definitely one of the biggest things I miss when working in Java on Android.

<comment><USER6> The problem is F# has arguably the best tool chain out of all of the languages you listed. Hell, I still have problems getting Scala to work with Netbeans 7.1 and I'm not sure of any IDE (for windows at least) for ML, Haskell or OCaml.

<comment><USER5> You may be right, but on the other hand F#'s toolchain isn't that hot on OS X and Linux (being facetious, but I'm half-serious). Anyway I was really only talking about the presence of a "first-class" REPL.

</comment></comment></comment></comment><comment><USER7> Casual programming happens in Excel every day.

<comment><USER8> Indeed -- as long as the problem domain is "strings and numbers", and doesn't require any I/O. That's a pretty small fraction of the things I actually need to do. What would his 7-line shell script look like in Excel?

The great thing about functional languages is they have no side-effects. The lousy thing about functional languages is they have no side-effects. :-)

<comment><USER9> Thats true, but people use other worksheets as kind of declarative IO areas (that they print). And Google Docs is a big improvement as your spreadsheets get URLs and so enter into the outside world.

</comment></comment></comment><comment><USER10> As a direct answer to the question and based on the problems the author raises, OS X's "Automator" is just that. It's casual yet still pretty powerful automation/programming. It loads fast, it has a visual IDE of sorts, and it can do a lot of jobs you'd otherwise use shell scripts for.

<comment><AUTHOR> (author here) I'm not a Mac user, but took a look at Automator now. It seems a _big_ step in that direction. Still, I'm not sure it makes the casual programming problem solved. Maybe I misrepresented the problem; let me give some more examples on casual programs that could be made easier...

* Quickly testing small game ideas or demos (programming as self-expression).

* Solving an ACM problem or one of those programming job puzzles without too much setup.

* Writing the blog tagger example in the blog post, and other "do my web tasks for me" code.

I think a good casual IDE could be written for various types of needs, not just automating the OS or Apps..which are certainly an important part of the problem.

<comment><USER10> Yeah, Automator is essentially a sort of group of visual DSLs for some very defined domains. Your examples here are definitely more in the realm of general programming languages.

It's definitely not as easy as the environment you speculate, but Xcode and iOS development have been making big inroads lately, even with total beginners. Certainly, it could be made a lot easier, but efforts to do this in the past have tended to fall flat as people think that the skills they learn won't be useful in "real" environments later on.. which turns it into quite the chicken and egg problem :-)

I wonder, however, if JavaScript and Web oriented development environments will ultimately fill the gap you're identifying. The browser is an ideal environment for the tasks you outline, and JavaScript is a fine 'base' language for DSLs to fall on top of while still giving access to the full language.

<comment><AUTHOR> Yes, I do feel that JavaScript could be a very possible way towards achieving those goals :)

</comment></comment></comment></comment><comment><USER11> I can't think of anything more casual than a shell script. Once you grok the syntax of the shell's control structures it becomes pretty easy to rig up just about any behavior one can imagine. I suppose some might consider the command line excluded from the category of casual by default but most of those people would be surprised at how insanely simple the command line actually is.

<comment><USER12> For us, but not for people who don't program otherwise, yet would like to casually do more with their computers than what the installed apps do. Thinking of what you want to do is the more important part of doing something; it seems like, in the spirit of the OP's post, you shouldn't have to make such a large leap from what you want to how to do it.

It is what it is today, merely because it is what it is.

<comment><USER11> _Thinking of what you want to do is the more important part of doing something;_

Agreed, and those who don't program otherwise are at the cognitive mercy of the metaphors defined by a "user-friendly" abstraction. Of course, there is always a balancing act; we all rely on abstractions, but at some level a user has to understand how a system works in order to adequately conceptualize the task they want to execute.

This isn't to say that we should expect anyone who wants to get more out of their machine to learn shell scripting or that we can't make things easier for non-programmers, but just like playing an instrument or writing a book, hobbyists should readily expect that they won't be able to do much unless they take the time to learn the system and the tools.

</comment></comment></comment><comment><USER13> It's a red herring to bring up the static vs dynamic typing issue, because both can readily support interactive autocompletion & documentation.

Even something as Spartan as the Javascript REPL in Chrome will do autocompletion of method names, despite being in a completely dynamically typed environment.

<comment><USER14> > var n = 42; n.[[TAB]]

No auto-complete. It's severely limited to only live objects. Which may be an argument for REPL, but it's not an argument for "dynamic languages can have autocomplete".

<comment><USER15> I have intelligent object method/property auto-completion in Python in Emacs.

The argument for "dynamic languages can have autocomplete" is that they already do in a variety of modern editors (like Emacs) and IDEs (like PyCharm et al).

You're not only ignorant, but proudly so.

<comment><USER16> You're right that autocomplete does exist, but in my experience it's very limited in dynamic languages.

For example, the following code does not give me any auto-completion suggestions in eclipse or in vim:

      str = "hello"
      test(str)

      def test(val):
        val.[TAB]

</comment></comment></comment></comment><comment><USER17> I forget everything all the time.

I have found a great solution for this, but it is not an IDE(!)

It is the bpython CLI. (I hear ipython is good too)

When I forget some string method's name, I just type "str." and a dialog box appears with all the options. If I am learning a new module I use "help(<function>)" or "<function>.__doc__"

oh yeah, and there is auto-complete. and syntax highlighting.

</comment><comment><USER18> Where is the casual carpentry? Why can't I make my own tables and chairs? How do I know which tools to buy? Why so many different types of screw heads with no clear indication in the box as to which kind should I use? Tapered shank what? How do rivets even work?! And it's not like it's a new thing either we have had wood manufacture for millennia!

IMHO some things will never get past the hobbist-accessible stage.

<comment><USER19> I agree. If the OP was talking about mechanics, he could be saying: _"I want to build a hotrod from scratch, but oh look so many little parts!"_.

I think that what many people fail to realize is that although the intended purpose _seems_ simple enough, the tools to do it are sitting atop so many levels of abstractions that without prior knowledge you just have no way to figure where to start assembling the parts. The only way for a hobbist to manage that, would be with the right tools pre-assembled for some finite set of purposes that could guide most of the work.

<comment><USER20> ... or to learn what the abstractions are, why they are used, and break through them to learn the basic steps.

What you describe is a very common problem on electronics forums. Consumer electronics are cheap, sophisticated and ubiquitous, so the newcomer to electronics DIY thinks that a cell phone as a first project should be easy and then gets angry when everyone tells him how hard it is to actually design & build one and that he should start by learning how to make an Arduino blink an LED instead.

When I consider all the problems that had to be solved to make a disposable $20 phone, it's absolutely mindblowing that we could ever have reached this point in technology.

</comment></comment></comment><comment><USER21> I'm a little disappointed that none of the posts here actually discuss how these (pretty pertinent) issues might be solved in the future in any way different to how they are at present.

The issue of having to choose a combination of 1000 overlapping libraries and languages, for instance, is one that affects us all, and is actually pretty recent. Whats the best solution for the future? Surely its not just 'google them all'....

Languages and libraries are, after all, supposed to make the leap between the conception of a simple idea and its implementation easy. If they fail to do this something will change.

</comment><comment><USER22> It's not as if Python or Ruby have set out to be deliberately difficult. They've grown difficulty because they're used to solve real problems, and real problems are hard.

Implied inside your question is the idea that we can, in advance, choose the right level of abstraction. That we have a library / language / set of verbs that is neither too high level (like Automator) nor too low-level (like your bash script example) to solve the problem. While I think we can improve a little bit on the set of abstractions that we have, I think a broad solution is naive.

As a point example, I used to be frustrated that so-called 3D engines tended to grow until they included the kitchen sink. Why do I need a menu system as part of my 3D engine? Why do I need a sound engine? Can't I just use system libraries like a sane person? etc. All I want is a set of primitives that let me render models to the screen. How hard can it be?

It turns out that the problem of rendering graphics to a screen quickly is so hard that it actually infects the hardness of other problems. Doing elastic collisions is a trivial thing that any first-year physics student can do. Until, that is, your game loop skips six frames because it's busy rendering graphics code, at which time you need to retroactively handle collisions that have occurred _in the past_. Now we're doing rocket science, and so your graphics library needs its own physics system, because you're not going to derive that stuff. And that, basically, is the story of every feature added to every serious game engine that exists today.

You see this problem everywhere you look, for example, at one point people thought POSIX and C were reasonable building blocks that everyone would use, and at another point people thought that about Java. At first, BSD sockets was the primitive, now we're starting to think about HTTP connections as the primitive, maybe we should work to make REST requests in Python not suck so damn much? But at this point SPDY looks like it might be turning into a thing, so maybe we should just build primitives for that instead? If you look at this staggering tower of abstractions you start to see things that seem crazy, like SPDY including its own flow control even though TCP already has it, because TCP has some bad assumptions that should be really be fixed at the network level, but will never be fixed there as a practical matter. I hope you followed Inception, because if not you're gonna have a bad time.

I'm doing a bad job of explaining this, but I had this insight first after reading an article by Kamp, the author of Varnish: <https://www.varnish- cache.org/trac/wiki/ArchitectNotes>. He makes the argument with a specific example that as we have moved to higher-level primitives, we've built an overly simplistic mental model of how the lower-level ones like OS and hardware work. As a result, we implement our own caching code, because we've forgotten that OSes were designed to do that for us. So in a sense we have more power because we have this nice set of high-level primitives, but in practice we've forgotten all the things that those primitives wrap, we've started to believe that they are simple because they _look_ simple. And so, we muddy up our application code with all this stuff that has already been solved.

I doubt very much that there is any software program that people actually use that is not either undergoing a big refactor right now or has one scheduled, either to make things "simpler" (less abstraction) or "more powerful" (more abstraction). Just thumbing through the projects that I work on, I am adding features to a mental backlog for a future refactor for every single one of them. This seems to be like a fundamental problem that all software projects have, and creating a new set of primitives and saying "no seriously, that should do the trick" is at best going to yield a nice little language like Python or Ruby that somebody will post articles about on HN saying why it's so hard for casual use.

<comment><USER12> "It's not as if Python or Ruby have set out to be deliberately difficult. They've grown difficulty because they're used to solve real problems, and real problems are hard."

The problem of getting from the East coast to the West coast has not changed in 100 years (move body until done), yet when was the last time you had to set the spark and choke and hand-crank a car? Cars solve real problems, and today's cars are sophisticated enough that essentially anyone can use one. To solve real problems.

Certainly the problems solved by a car are in a more narrow domain than programming languages. But cars themselves are in a narrower domain than internal combustion engines.

Edit: stealth.

<comment><USER23> I'm sorry, but this analogy is awful. Getting from coast to coast certainly HAS changed in the last 100 years. 100 years ago, you had railroads or mostly dirt roads. A crap ton of infrastructure has been put into it (interstates and the intensely complex logistics of maintaining them). A pile of services exists around this problem (airlines, and the even more complex logistics of keeping them running safely and profitably). Going broader, you are ignoring all types of "get between coasts" that apply to stuff rather than "me" - <USER2> is the best way to get a pile of widgets from LA to NYC? Airplane? Train? Some trucks? -- the answer is "well that depends on $logistical_considerations". Going narrower, choosing the right car for you is a pretty complicated process, trading off features, options, gas mileage, capacity and so on - <USER3> like any set of programing options, only internalized by the culture".

Further, a car is simple to use out of the box, but customization beyond do- dads and bling? Nope, not really easier than it ever was. Different tools? sure. Different base skills? not really. Anyone can do it? Not so much.

And before I go into tech equivalencies here, if you think cars are pretty much the same and can be abstracted to "the car" for the purposes of this discussion, go buy a van or pick up truck. Watch your social graph get all buzzy and see the request pour in for help, turns out your form of tradeoff in "car" are very very useful to people, and suddenly a car isn't just a car.

Further, I would argue that we have done wonders for the tech equivalent of "car". We have amazing computation devices in our pocket that just do what people never knew they wanted to do in the form of "phone". We have awesome abilities to have web presence unthinkable (outside of internet famous blog machines) 10 years ago, in the form "social graph". These are great and just work for most people, until they need something different...

In the infrastructure department: the ability to do semi-custom stuff has grown in ways unimaginable in the car world. Need a website to do your magic? Here are a bunch of platforms like app engine or heroku, all you need to do is get your custom stuff in place, don't worry about the machinery to feed it. Up and down the customization level there are more entry points as well. Going back to the car world, how easy is it really to get a ricer put together? How easy is it to put in crazy hydrolics or a good thumping stereo system? Need to rip off the doors, reshape the body and put in a different engine? Good luck getting a doctor to just do that without serious learning curve.

Basically, my point here is that hard stuff is hard. If it isn't your specific field, it is easy to just blow off the stuff that caters to the masses as "they made it easy", and at the same time, it is easy to blow off the stuff in your field which caters to the masses as "not done well".

Final thought: a lot of people look at cars and computers the same way, as soon as the littlest thing goes wrong, they freak. or they take it to the mechanic who asks "why haven't you changed the oil in 7 years? (c.f. our IT guys who ask why they don't have anti-virus installed).

<comment><USER12> "Further, a car is simple to use out of the box"

Exactly my point. They didn't use to be simple. Crank, choke, throttle, water in the battery, where's the next fuel repository, where are my goggles, where is the rug for my legs, etc. Now they are, and you just think of moving your body from here to there, and almost not at all about how to make your car help you do that. Now people use a car _casually_.

It's that kind of change, only much more profound and difficult to achieve, that will be needed before people can "program" (if we still call it that) computers casually.

<comment><USER24> The difference is that it was easier _in the past_ for people to program casually; it hasn't gotten easier. Consider the microcomputers of the 80's: it was very difficult to own one without knowing at least a bit of some BASIC dialect. Consider microcomputers now: most people get away without ever knowing what it's like to write a program. People who actually _want_ to learn how to program must go out of their way to do so (and that's _if_ they even realize programming is a possibility).

So, perhaps computers themselves have progressed much like cars. It is now possibly to use a computer casually. But programming _per se_ is significantly less casual than it once was.

<comment><USER12> You used to have to type in 1s and 0s on a keyboard, or cut little square holes in a piece of cardboard with an Exacto knife. You had to learn what opcodes were represented by those 1s and 0s, in which contexts, and reverently hand your stack of cards full of holes to the Keeper of the Card Reader. You had to really, really want to program, with books open on the desk and your lap, and a grilled cheese sandwich holding open the one on your lap. I don't know if that's _formal_ , but it sure doesn't sound like a casual drive around the block to me.

I wouldn't know an opcode from a gerund, and I don't want to know.

Now I can Write a Program for Dummies, or I can write Python the Hard Way, or I can <script>alert('hello world')</script>, all as close as [https://encrypted.google.com/search?hl=en&q=how%20do%20I...](https://encrypted.google.com/search?hl=en&q=how%20do%20I%20program%20a%20computer) while holding a sandwich in one hand. That's not as casual as the OP would like, but it's pretty darn casual compared to The Day.

Edit: vocabulary.

<comment><USER24> Just because it's not difficult doesn't mean it's casual. There's a higher barrier to entry now than there was in the 80s, and that makes programming much less accessible to the casual computer user. The average user perceives coding as a feat attainable by only wicked smart, socially inept nerds.

<comment><USER20> Are you serious? The barrier to entry for learning programming has never been lower than it is now.

I remember what it was like beginning programming in the 80's and trust me, it was much harder then.

Back then BASIC was the _only_ language I could get for free. In order to learn C I had to (1) buy an upgraded version of my computer (CoCo 3) that had more memory to run an OS, (2) buy the OS-9 operating system (3) buy a C compiler for said OS (4) buy the K&R book. In total, I think that cost around $400, which explains why I didn't learn C until after I graduated (EE, not CS) and had a job to pay for that stuff.

Last year, to learn Javascript I opened my browser, got a free download of Notepad++, searched a Javascript tutorial and began programming. If I wanted to learn C from scratch today, it would be as simple as downloading gcc. Not to mention that expert help if I get stuck is all over the net.

Getting started in technology, at _any_ level I can think of, is _much_ easier today than at any time in the past.

<comment><USER24> Good points. I suppose I'm just being nostalgic about instant-on computers with a welcoming BASIC prompt. My Timex Sinclair 1000 even came with a couple of BASIC manuals!

My point was that you now have to go out of your way to learn to program. There are a lot of options, and casual programming involves a lot of libraries (which usually themselves depend on libraries). Those microcomputers were very inviting in that regard.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER25> with ipython you do get some of that auto completion for python. It'll autocomplete the module name for you, but you do have to figure out you want that module first, so you'd need to google and realize you want shutil for dealing with files. I use it a lot when I'm interacting with new APIs or even just for writing the code as I go.

      In [1]: import sh
      sha     shelve  shlex   shutil
      In [1]: import shutil
      In [2]: shutil.
      ...
      shutil.copy  shutil.errno  shutil.move
      In [2]: help(shutil.move)

To do other more powerful automation kind of stuff, this is pretty nifty: <http://sikuli.org/>

<comment><USER26> check out path.py

<https://github.com/dottedmag/path.py>

it's awesome for dealing with paths instead of having to do stuff like

        os.path.abspath(os.path.join(os.path.join(x,y),z))

everytime, it gives you nice abstractions like

        path('/home/me').files('*.jpg')

<comment><USER27> Os.path.join can take more than two arguments. So it's not as bad as that example.

</comment></comment></comment><comment><USER28> Lisp people don't remember the various functions or their arguments, they use SLIME which autocompletes and allows for looking up in the hyperspec.

</comment><comment><USER29> It seems like you literally are describing Processing. I'm not sure if you've heard of it: <http://processing.org>

It is designed for non programmers – artists and designers, so do a lot of things you are asking for.

</comment><comment><USER30> It sounds more like you just want the machine to read your mind.

edit: not saying that's a bad thing, IBM says 5 years to go <http://mashable.com/2011/12/19/ibm-mind-reading/>

</comment><comment><USER31> Like anything else, things worth doing well take time to learn.

There are great tutorials out there to teach you the very basics of programming in a few hours. There are also great tutorials out there that teach you to play a basic song on the guitar in a few hours.

After that, its up to you. If it were easy, everyone would do it. I've been programming for close two two decades, and I still feel like I'm scratching the surface of programming. As various iterations of the saying go: The more I learn about programming, the more amazed I am that computers even boot up and function.

</comment><comment><USER32> >feels too much like piecing together jigsaw puzzles where you first have to know which pieces actually exist.

Well... that describes programming in many ways. That's not to say that shell scripting is the perfect casual programming environment - in fact, it certainly isn't! - but that anyone dabbling in things will certainly come to feel that problem. When I hacked in BASIC thirty years ago, then moved to Pascal, and then to C, that's largely how I felt the whole time.

</comment><comment><USER33> I do not understand his first reason for understanding programming AT ALL.

He writes: >To have an aid for thinking and expressing ideas. What Steve Jobs called "A bicycle for the mind".

But if he can't express any ideas due to trying to be "casual", how has he reached his goal in any way?

English is not my first language, yet I had to get a pretty firm grip on it in order to being able to express my ideas in English: there is no "casual English-learning", you either learn it or you don't.

</comment><comment><USER34> The question is, do people at large even want to do casual programming?

Stepping back, what does "casual programming" mean anyway? Automate certain repetitive tasks? Do some complicated calculation? Write a two-player tic-tac- toe? Make a Sudoku solver?

For the most part, "casual programming" for people who are not into the abstraction layer have been mostly done in Excel/VBA. Most people just don't realize that _IS_ a valid form of "programming" (albeit a very limited subset of it). It's like people who play Angry Birds/Farmville (or Minesweeper in the '90s) obsessively don't consider themselves as gamers, even though they might have spent more time "gaming" than most Counter Strike "gamers".

On the other hand, if you want to dig more into programming, tools like Lego Mindstorm or Scratch teach the concepts rather beautifully. It makes moving onto an actual general purpose programming language much easier.

</comment><comment><USER35> It seems like one of the big things he is talking about is good documentation which includes usable example code.

Bash Shell scripting would be a lot simpler to use if each man page for a program or shell function had 10 or so examples with the most common command uses which were easy to paste into an editor.

Course my real preference would be the inverse. Search how to do something, return code in the specified language/shell to do it. Right now that's done by Google and other search engines, though rather poorly. Also google doesn't compare and contrast implentations.

The faster we can find a way to implement our goal, the greater our efficiency. That is something abstraction does of course , but we should remember that documentation also serves programmers.

</comment><comment><USER36> I started programming with PHP, and I was easily able to apply all that knowledge of (rather basic) web-dev to the CLI. If I need a quick script my first instinct (besides bash) would be to fire up TextMate and write some PHP. As a beginner, whenever I needed to do something Google _always_ had the right answer (e.g. "php check if string contains string"). This helped because I never felt like I was reading tons of documentation, and always gave me a quick answer. Once you use the same function a few times you generally remember it.

</comment><comment><USER37> My teammember's remark when I mentioned this made front page: "Still reindexing."

</comment><comment><USER38> F# 3.0?

[http://msdn.microsoft.com/en- us/library/hh156509(v=vs.110).a...](http://msdn.microsoft.com/en- us/library/hh156509\(v=vs.110\).aspx)

</comment><comment><USER39> He sounds like's he's described VBA

<comment><USER12> Maybe, sorta.

Why don't people use VBA more for casual programming? Is it because it's Office-centric-ish?

Or, why don't more people _do_ casual programming of any kind? Certainly lack of tools is one. Another is probably that most people don't exist in a culture where people do casual programming.

The biggest problem is that the things above the level of raw bits, the objects like documents and blog posts and check registers, are not themselves built to be manipulated in a casual environment. They're not built as part of a casually programmable environment. They're bits.

If you had a stack of books in English and Arabic and wanted to categorize them, you'd grab them and put them in their piles without thinking about it.

A blog post is nothing but bits. The only reason it's an English or Arabic post is that every program that touches it is required to, and agrees to, sniff it at a very low level and pretend that it's a blog post. The inside of a blog post looks exactly the same as the inside of a check register, and it's a huge leap from the bits that they are to the pseudo-objects that all relevant programs agree to pretend that they are. There is no casual middle ground, and so there's nothing that can be casually picked up and manipulated. You're a wizard, or an ardent apprentice, or you're nothing.

I think a real casual programming environment would look much less like app- centric VBA, or Excel (mentioned elsewhere), and more like Squeak (mentioned elsewhere). But it would work best if all the things on the system, at least the things that aren't dangerous to expose, are fundamentally casual objects. The browser window should be casual, as well as the post plugged into it.

<comment><USER40> _why don't more people do casual programming of any kind?_

I'm not sure I understood what the author meant by casual programming, but the first thing I thought of as I read your comment was HyperCard.

</comment></comment></comment><comment><USER41> Try writing python with Pyscripter and see if you can't code something useful in an hr

</comment><comment><USER42> Writing a shell script after some trial+error+googling sounds pretty casual to me.

</comment><comment><USER43> matlab has a lot of these features, and so did genera for lisp machines. Proprietary development stacks win when it comes to solid documentation.</comment>


Learned Multi-dimensional Indexes – Result with big impact for key/value stores? - <AUTHOR> https://arxiv.org/abs/1912.01668 <comment><AUTHOR> This could have huge implications for key/value stores and cloud storage systems as it provides a mechanism to access data by more than one key. The numbers to Amazon's z-order encoding also look very interesting. Of course, updates/inserts might still be a problem, but many of the other techniques (e.g, Amazon) are also static.</comment>


San Francisco Real Estate Exuberance Index for 2013 - <AUTHOR> http://priceonomics.com/san-francisco-real-estate-exuberance-index-for/

<comment><AUTHOR> IMO, it's interesting to see this the day after yesterday's discussion about how low average founder salaries are ([https://news.ycombinator.com/item?id=7058840](https://news.ycombinator.com/item?id=7058840)). The report in yesterday's article mentioned that 2/3 of founders in Silicon Valley earn <50k, and it's hard to reconcile that with the median price of a 2-bedroom condo in SF being almost a million dollars.</comment>


Ubuntu to Abandon Unity 8, Switch Back to Gnome - <AUTHOR> http://phoronix.com/scan.php?page=news_item&px=Ubuntu-Dropping-Unity <comment><USER2> Better url for this story: [https://insights.ubuntu.com/2017/04/05/growing- ubuntu-for-cl...](https://insights.ubuntu.com/2017/04/05/growing-ubuntu-for- cloud-and-iot-rather-than-phone-and-convergence/)

<comment><USER2> Which would be a duplicate of [https://news.ycombinator.com/item?id=14043631](https://news.ycombinator.com/item?id=14043631)

</comment></comment><comment><USER3> Dang or other moderator, could we merge this with [https://news.ycombinator.com/item?id=14043631](https://news.ycombinator.com/item?id=14043631) please? It was submitted earlier and points to the source.

<comment><USER4> Thanks! We've moved most of the comments there.

<comment><USER5> I don't care whether you move comments about, but if this story ("Ubuntu to Abandon Unity 8, Switch Back to Gnome") had been marked as a dupe a little earlier, then I would probably have passed over a story titled "Growing Ubuntu for Cloud and IoT, Rather Than Phone and Convergence" even though I consider Ubuntu's abandonment of Unity to be big news.

</comment></comment></comment><comment><USER6> A wise and decisive decision. Unity did not revolutionize Linux desktop usability, and the phone business was never within reach. Stop trying to make happen what you can't make happen.</comment>


The next major leap in software development needs mental model visualisation - <AUTHOR> I worked for a startup back in about 1990 and the visionary guy who ran that startup said something that made me think for many years afterwards.  He said "there will be a revolution in software".
At the time I didn't know what he meant.  Probably he didn't either.  But soon the web came and along with it several revolutions in software development including new languages, better languages, better processes, better information for programmers via the web and collaboration for programmers on problems via StackOverflow.
But it is still incredibly hard to learn new software technologies.
The main reason is because it is so hard to form a mental model of the technology that you are working with.
Consider reactjs.  You'll only really start to work with it effectively when you understand the mental model of it - that there are components, and components have a lifecycle, and data flows through them in one direction.  When you've studied it and programmed it for a certain amount of time then a mental model forms in your head and that's when you really can get going driving that technology effectively. And that's true not just for ReactJS but any development technology.
And until that mental model fully forms, you're digging around in the dark, puzzled, wasting time, trying to understand why things don't work in the way you expect, doing it wrong and being very frustrated.
So the question is, "is there a better way to convey the mental model of a software system?".
I feel like some sort of visualisation system is needed that can effectively convey the mental model of a given piece of software.
When we get such a thing, and when it works really well, software developers will be able to much more rapidly come up to speed by examining the visualisation and seeing how the parts hold together, instead of the current way of forming a mental model which is reading lots of documentation and going through a long and painful learning process. <comment><USER2> Like a DFD?

Data flow diagrams were proposed by Larry Constantine, the original developer of structured design, based on Martin and Estrin's "Data Flow Graph" model of computation. Starting in the 1970s, data flow diagrams (DFD) became a popular way to visualize the major steps and data involved in software system processes. DFDs were usually used to show data flows in a computer system, although they could in theory be applied to business process modeling. DFD were useful to document the major data flows or to explore a new high-level design in terms of data flow. (copy/pasted from wikipedia)

<comment><AUTHOR> I guess a DFD is one form of visualisation.

For me, the outcome of learning a software technology is almost like a 3d image in space of the software and how it works. It's not as clear as a real 3d image of course but in a vague way that is what it is.

Imagine if you asked 1,000 programmers to "draw a picture of the mental model of X software system", you would find a small handful of really good visual/spatial conceptualisations of what that software is and how it works. The question is, can that process of drawing a good mental model visualisation be brought into the real world as some sort of definable process?

I would find it dramatically easier to learn new technologies if the start point was a really good 3d visualisation.

It's hard to explain exactly what I have in mind because it's not a solved problem.

<comment><USER2> I like the way you think.

The problem here is probably that if you asked 1000 programmers to draw something -- they'd all be limited to the two dimensions they can commit to paper (or whiteboard).

Even a photograph is a projection of a 3d scene down to 2d.

 _My_ mental model of react is a cascading DFD.

But if that doesn't work for you -- imo you should definitely come up with your own notation. After all, all models are wrong in some way but many are useful.

<comment><AUTHOR> Turns out the web is really good at getting 1,000 people to do something.

Maybe some enterprising entrepreneur will find a way to make this new revolution happen by harnessing the power of everyone to create great mental models for software.

</comment></comment></comment></comment><comment><USER3> I read about this 'visualization' ability that people are said to have during my senior year of high school. It's sort of like dreaming, in that you can 'see' pictures in a 'mind's eye'. I remembered having two dreams from growing up, so I kind of knew what this 'visualization' was supposed to be like. It's supposed to be a natural human ability, but for me it was not easy (some people are auditory, others kinesthetic, etc etc, but all the usual techniques didn't seem to help.)

Figuring out how to relax my body was 8/10ths of the journey.

</comment><comment><USER4> To me, the closest to a mental model would be a combination of

\+ domain model diagrams (illustrates domain objects and cardinality relationships)

\+ sequence diagrams (expressing flow in between systems)

\+ state diagrams

But what I found in the real world is not many people use these UML diagrams except in really large companies.

I totally agree that the current ways of forming mental models (through watching tutorials, reading docs, writing code, and taking notes) is super painful.

</comment><comment><USER5> >is there a better way to convey the mental model of a software system?

There is UML but that's mainly to explain stuff to non-engineers and turned out to be a total waste of time in 90% of cases. Documentation becomes rapidly outdated and costs money to maintain. Do you want someone updating stupid arrows and boxes in a visio file for $200 an hour? Engineers develop an intuition of why things don't work the way you expect just as a mechanic develops an intuition about why your car doesn't run the way you expect.</comment>


Running Empty - <AUTHOR> http://www.outsideonline.com/1986361/running-empty

<comment><USER2> I cycle commute to work about 38km each way, currently about a 90 minute effort. I ride at for me, "threshold" (above 90% of max heart rate) for 45 minutes of that and remainder at "tempo". No where near "ultra" but I think I'm near my biological maximum.

I too have hit a period where I was feverish for several weeks. Foolishly kept cycling and became ill / fatigued to the point where it was a struggle to get out of bed. The physician I visited didn't find anything conclusive and I was on variants of ibuprofen to control the fever and for pain relief. When I was finally feeling better, I cycle commuted once and that knocked me back into bed for another week.

Likely I was going too hard for the conditions. This occurred when temps during the commute was hovering around 0dC. Low temps make it a challenge body temperature and may have stressed my body too much.

Strava provides a metric to guess how fatigued one is from cycling. I noticed that the point when I fell ill was the same time it was reporting record fatigue levels. I now keep an eye on it but I'm feeling a touch of that "fatigue" these days. Likely to due to $dayjob and cycling...

I wish there was a way to measure all my activities to guide when I should be backing off. I've found my breaking point and crossing the that point means weeks of recovery.

For what it's worth, I'm faster then I ever was... but something is going to break.

<comment><USER3> A number of the heartrate monitors have "recovery indicators" that are based off of how steady your heartrate is I think. In other words a very solid 41.2bpm +-0.05bpm would be indicative of full recovery and 42bpm +-2bpm means that you're still fatigued.

I don't know if you've looked into that at all but I messed around with it a little some years ago and saw some correlation between low recovery scores and feeling like a ride was harder than it should have been. I say this as someone who was a competitive amateur cyclist in college during a time in grad school when I could really ride.

I would also caution you against doing nothing but threshold and tempo if that's all you're doing. Morning and evening base training would be really useful and would definitely make recovery easier. I read The Cyclist's Training Bible and found that slowing down when I was supposed to go slow actually meant I went faster when I was supposed to go fast.

</comment></comment><comment><USER4> OTS is almost certainly the same as chronic fatigue syndrome. The only difference is that in OTS the stressors are usually mostly physical, where in CFS they are (usually) mostly mental. In many cases there is also an apparent flu-like illness at onset, although it isn't clear whether this is an actual illness or just a symptom of the immune system going haywire.

It seems that at some point after prolonged, chronic stress the brain just says "that's enough", and further stressors result in a reduced stress response from the brain, rather than the usual increase in stress response (cortisol, etc.) Essentially it's a form of burnout.</comment>


Ask HN: Poland vs. Ukraine for choosing a dev shop? - <AUTHOR> For our company, I constantly get linkedin requests from either Poland or Ukraine based companies for outsourcing dev work to them. Would love to hear any stories/anecdotes from HN on working with these types of dev shops in Ukraine or Poland. Are they worth it in terms of cost vs benefit ? Compared to US developers, how competitive are the salaries/cost for a mid level developer there ? <comment><USER3> If you have the technical/management chops to know what work can be offshored successfully, package up the work, evaluate the shop, ask very specifically for what you want, assess the quality of what comes back and push back when it needs to be fixed, they can be a great option.

Don't know specific salaries but in my experience work is 30-50% cheaper to have done offshore on a project scale (imagine savings are better if you are paying salaries for full-time engineers). Those savings quickly evaporate if something goes wrong or takes longer than expected ( _very_ common due to communication issues), then rapidly become multiples of the original cost if you need to throw it away and have it re-written. This isn't necessarily because the offshore developers are bad, but because communicating software requirements is hard enough even without cultural/language/time barriers.

Offshore shops are a tool in a toolbox, one with a more specific use than most people think, that when deployed can be incredibly powerful but when deployed wrong can be catastrophic to a project.

As with all service relationships, building a partnership over time is the best way to get good work from vendors regardless of their physical location.

Never start with a large, mission critical project - give a small piece of work to a vendor and see how they do, and ramp up from there. Even consider giving the same small project to 1-3 vendors and see who does well - <USER2> redundancy is a sunk cost but a small price to pay for long term success.

<comment><USER4> As the owner of an offshore shop, I think you are right on the nose!

</comment></comment><comment><USER4> I run an offshore dev shop (web/mobile) with over 15 developers based out of my Ukraine office.

I don't think the base country will make too much difference. The biggest issues I had (that would not have occurred in the US) were with cultural barriers.

No matter the country, language can mostly be addressed with the right process and managers, but the attention and service that US customers expect is not something culturally that exists in many other places.

Getting that right, so that my team leads and PMs meet customer expectations was the hard part. I think that is where many offshore projects fail.

If your team is committed to delivering quality, and you, as the end client know how to communicate your needs and check the deliverables, things usually progress very well.

If your offshore team doesn't understand or care about this (many just don't get it, because customer service is NOT a thing in most countries outside of North America and Western Europe) then you will have frustration no matter where you go.

My clients are about 75% US based and I would be happy to talk with you directly if you have more questions or want to discuss a project. Reach out to me here: ethan [at] abovebits [dotcom]

<comment><AUTHOR> Sure I will reach out for more questions. One important question for now: do you provide dedicated developers to a client or you prefer allocating 1 developer to multiple clients for risk purposes ?

<comment><USER4> Great, would love to hear from you.

In regards to full time, we do both. Typically we start small and build up to ensure we are both happy with the initial work and can work well together. Once a client is ready to commit to one more more full time developers, we go month to month and the only issue would be scheduling the start time. If a developer was shared with another client/project part time, we would want him/her to finish up that commitment before pulling them off.

</comment></comment></comment><comment><USER5> What I've encountered - Poland teams are usually way bigger than they are required, not sure why though; e.g. a project that would require a scrum team of 6-7 people, will usually be done by 10-12 people. But Poland pricing is quite good, there are a lot of people, only downside that I encountered is the English language, it still seems that people are not that interested in it :). Ukraine on the other hand, seems more pricy; maybe due to multiple big USA corporations being opened there.. But it seems people are willing to work for international companies than to internal ones. Have you ever considered the Baltics (LT, LV, EE)? As they are way smaller, they have no choice, but to be international (when it comes to language and tech stack) as the internal market is too small. However, pricing is extremely different per companies, so probably your negotiator skills would be tested there.

</comment><comment><USER6> It depends the field. Some companies in some locations will charge north of $250 an hour for some profiles, and more for an end to end product custom software. We shipped custom ML platforms for large organizations as part of our activities. The applications allowed their marketing and sales department to train models or load models on their data according to their workflow. Custom made. Some solutions allowed them to send personalized offers to millions of subscribers.

For some clients, on call 24/7\. Going to the client. Meeting their people. Handling regulatory paperwork for some projects in regulated fields. Even taking care of importing the hardware for them. Interfacing with their data people and learning their third party vendor's billing systems.

As with everything, it depends on the domain, the service, the support, and generally speaking what they're going to do for you, and which part or parts they're tackling.

Repeat business is common as when these organizations like the outcome, they want more. So that's my two cents from the vendor perspective.

<comment><AUTHOR> Are you saying that offshore shops in Ukraine/Poland charge $250/Hour for best candidates ? In that case, why would someone offshore it and not find devs in the US directly ? I am genuinely asking because the premise of my post was about finding the balance between cost savings and getting projects/work done effectively for companies that cannot afford to hire expensive devs in US.

<comment><USER6> No experience with Ukraine or Poland, we're based in Algiers and Paris and focused on ML. Our clients are in France and Algeria.

My point was that it's not automatically cheaper as many people I talk with in Algiers assume that our clients in France come to us because we're "cheap offshore services" and we're not.

Our clients come to us because we hold their hand from the moment they want to understand the value of this, to ideation on where in their business this can have an impact, to working with them to execute in that space learning their systems and all, to making sure they have good results. We've shipped products for banking, telcos, energy, rail transportation, and other domains.

We're a tiny company so we're very flexible and can make decisions very fast and clients seem to like that enough to come back and refer people to us.

So, that's the context for us. Not sure how it goes for dev or Web dev or mobile as it is something we did for our clients, but not something the company is focused on. As in, sure, we'll make a mobile application if the client needs it, but it is a vehicle of ML capability. I'm saying this to give more info from someone in such a company, on another continent, albeit in a field and a budget that may not be what you're talking about.

<comment><USER4> This makes sense. ML is also a high value specialty right now. I believe that general web/mobile development services are a totally different ballgame due to the proliferation of talent, free (and good) tools, etc.

</comment></comment></comment></comment><comment><USER7> Mid-level developer (3-5 years of experience) in Poland makes probably up to $3000 net (after taxes) per month. Dunno about Ukraine.</comment>


Algorithm could solve NP Complete problem in P time - <AUTHOR> https://medium.com/@calhoun137/this-algorithm-could-solve-np-complete-problem-in-p-time-6857b40d6586 <comment><USER2> > As a model for computation, P systems offer the attractive possibility of > solving NP-complete problems in less-than exponential time. Some P system > variants are known to be capable of solving the SAT (boolean satisfiability) > problem in linear time and, owing to all NP-complete problems being > equivalent, this capability then applies to all such problems. As there is > no current method of directly implementing a P system in its own right, > their functionality is instead emulated and therefore solving NP-complete > problems in linear time remains theoretical. However, it has also been > proven that any deterministic P system may be simulated on a Turing Machine > in polynomial time.

[https://en.wikipedia.org/wiki/P_system](https://en.wikipedia.org/wiki/P_system)

This is not as interesting as it sounds, since you're just trading exponential time for exponential space. It's still not practical or very interesting.

</comment><comment><USER3> You seem to have been quite adamant in your recent posting history that this is a major breakthrough [https://news.ycombinator.com/submitted?id=calhoun137](https://news.ycombinator.com/submitted?id=calhoun137) but a lot of people don't seem to be of the same opinion.

<comment><USER4> Indeed, calhoun137 appears to repeat a problem that I and another have pointed out earlier. Quoting from this link:

> The basic idea is to make use of a practically infinite amount of computer > power which grows exponentially in time.

The speed of light means computer power can only grow to cubic power - 4/3 π (c T)³, to be precise.

If T is small then exponential growth may dominate, but as T continues to grow, there's no getting around the speed of light limitation even in a universe made of uniform computronium.

<comment><AUTHOR> I agree with everything eesmith has said to me so far in our discussion. I apologize for not communicating how seriously I take all of his replies to me, or how helpful this is for my research

I am working on a very fun project making a 3d computer game in unity, its got a beautiful user interface where you can play with the parameters of a single self reproducing machine and it lands on a fake planet and you can do (fake/simulated) physics experiments with imaginary "programmable self- replicating 3d printers" and its all running a physics simulation of what a real planet might be like, but you can adjust these parameters in the game too.

It's inspired by John Conway's The Game of Life. It's quite fun! I believe I have discovered an infinite family of new 3-dimensional self reproducing machines, and own the website selfreproducingmachines.com for the purpose of releasing this game as a free open source program when its finished

Thank you so much for keeping me in line and helping me with these ideas. It means so much to me.

I did not post on this website so heavily because I didn't want to be mercilessly dragged by people like eesmith who know much more about this than me

I have many questions about a "fake math" theory I made up, where its kind of like theoretical physics, but its about the mathematical theory of life, evolution, dna; but from first principles

I have discovered the existence of mathematical laws which relate the properties of the environment, and the local encoding of a single self reproducing programmable machine, and the way these types of systems tend to evolve

Clearly, I am very likely making a large number of conceptual mistakes at this time. This is the purpose for my posting these articles on here. Any advice is most welcome</comment></comment></comment>