Ask HN: What is the best pre-commit code review workflow? - <AUTHOR> I'm a lead developer who runs a small team of 3 full-time, in-office developers and one designer.
I'm a fan of reviewing code before it accepting a pull request and expect developers to properly rebase so they don't push conflicts onto anyone else.
I don't want to block my team but at the same time I don't want to switch to post-commit reviews since I can't ensure code quality.
What's the fastest and highest code quality pre-commit review system you've ever used? Note that the answer doesn't have to be technical. It can be a simple behaviour change.
Thank you :) <comment><USER3> 1\. The reviewee should self-review his code before he calls you over - <USER2> means going over changed files and undo'ing those that are unneeded (i.e. where only a newline/space was entered). They should also read through their changes in the diff window, and add in any comments where the 'why' is not clear from the code.

2\. There should already be a window open displaying how their changes affects the UI/behaviour of your product, so that you can immediately get into the right context/mindset when you come over. This way as they explain their changes you can compare with your mental model of how'd you'd have solved the problem, and notice any glaring problems along the way (like if they used a bunch of complex logic to parse a string when they should have used a simple regex)

3\. Coders should expect to get reviews every one or two days, otherwise they will build up a substantial amount of changes that will take longer to process. Additionally they may even forget why they made earlier changes!

4\. Once you've reviewed a team member a number of times you'll find that they 'get it' and have already predicted your questions and made the necessary changes. They are then ready to become a reviewer as well to lighten the load on you.

5\. Post commit reviews do not work. The damage is already done by then. They tried this at a place I used to work and nobody learnt anything from it :\

<comment><USER4> >3\. Coders should expect to get reviews every one or two days, otherwise they will build up a substantial amount of changes that will take longer to process. Additionally they may even forget why they made earlier changes!

NOT ACCEPTABLE.

Rationale should be documented in the ticket, and the ticket should be tagged in the commit message.

Any engineer rationale MUST be documented clearly with comments for all reviewers.

<comment><USER3> I find that 1-2 days, maybe 3, is a good number before getting a review. This doesn't mean they have to be finished with their piece of work, or that they even have to commit the code at the end of the review, this is just so a second pair of eyes can see it and both can agree that they are on the right track.

Then when the functionality is complete, the same reviewer can glance over the already reviewed sections before focusing mainly on the new changes.

</comment></comment></comment><comment><USER5> Here's a strong opinion, based on my own experiences here at Labs. As is traditional on HN, it doesn't directly answer your question, but instead assumes the universal superiority of my own preferences.

1\. Pair program.

2\. Drive code from tests, outside in.

3\. Rotate pairs frequently. Daily for short stories, no more than 2 days for long stories.

4\. Review your commits together.

Every other reviewing scheme I've seen quickly becomes an unacceptable bureaucratic drag on forward movement.

At best you wind up with an average of around 2-3 days lag, giving plenty of time for the original engineer(s) to lose context and for the master branch to be well out in front.

At worst you have patches sprinkled around multiple branches of multiple repos, everyone is blocked on everyone else and continuous integration is thought of as a joke about mathematicians.

The original literature on code reviews is based on a very particular and extremely rigid manner of developing software. I think pair programming captures 80% (or more) of the value for less than 20% of the effort and disruption.

</comment><comment><USER6> Besides all the good ideas suggested by others for high-level process optimization (small PRs, self-review first, prioritize reviews, have a larger pool of reviewers, etc.), you can also micro-optimize the time spent on reviews proper. A good tool can help a lot here: it will show incremental changes since the last review round (even if the branch got rebased), filter out changes due solely to rebasing, track resolution of any issues raised during the review, etc.

If you're using GitHub, the built-in pull request review system doesn't really do these things very well (or at all), so you end up wasting a lot of time and/or missing things. There are a number of third-party options that do much better but some of the best require you to host your own infrastructure, move your repo, etc. Selfishly (and again, only if you're using GitHub), I'd recommend checking out [https://reviewable.io](https://reviewable.io), as it integrates smoothly and requires nearly no setup. (Disclosure: I'm the founder.)

</comment><comment><USER7> Good questions.

1\. Everything must enter your main branch (master) via Pull Request 2\. Everyone can review it. Sometimes more than one person is needed. 3\. It's asynchronous - write comments on the code or sit together if you need to see UI / Changes. 4\. Code Review should also review unit tests (which pass) 5\. Merge PR

This shouldn't block your team and in a week of doing it people will adore this since it will save them at least once.

<comment><USER8> Is there something Im missing with pull requests? Or is it that even programmers like UIs?

1) Git log becomes useless.

2) You're merging code via a UI, without _ANY_ granularity whatsoever.

3) Does it not just FEEL dirty doing this in a UI?

4) A little appeal to authority: [http://www.wired.com/2012/05/torvalds_github/](http://www.wired.com/2012/05/torvalds_github/)

5) and a bit more: [https://github.com/torvalds/linux/pull/17#issuecomment-56637...](https://github.com/torvalds/linux/pull/17#issuecomment-5663780)

6) Efficiency lost w regards to minor changes. Youd actually write a comment to have someone change something and then RE-issue the pull request? Sure you would, because youre middle management.

Pull requests seem to be a hacky way for management to get involved with something they understand at the loss of control in arguably the most complex phase of coding: INTEGRATION.

<comment><USER9> You don't have to use the UI. If you're really anal about your git history, you can do the merge locally and squash everything into one commit. IMO, it's not worth the effort to do that, though. You probably don't actually care about the Git log - you care about the file history (i.e. git blame), which will usually point you to the right commit anyway, even if you have a bunch of extra merge commits in your log.

FWIW, you're not Linus. You don't get 17 million emails/day (exaggeration, I know). He has a very refined workflow based on many, many years of working with people all over the world on a gigantic project used by hundreds of millions of people.

Re point 6: You don't create another pull request. You just make another commit on that branch.

</comment></comment></comment><comment><USER10> Phabricator is great, can't recommend it enough.

<comment><AUTHOR> Can you edit your comment to include why?

</comment></comment><comment><USER11> I do what you are suggesting. Some other things:

1\. Always a PR that is ready to merge (rebased properly). I should be able to read commit-by-commit and it all makes sense.

2\. All reviewers are committed to review in < 24 hours, mostly the same day. Reviewing is considered an important high-priority activity for developers.

3\. Keep them small - we reserve the right to reject a PR on size -- split it down (in reality, this is rarely done, because we know this)

4\. Only make a comment if you think the code is unacceptable without the change. You can be convinced otherwise later, but no subjective comments -- it's either acceptable as is (no comment) or not.

What I wish we did (and will probably try to make happen)

1\. Work off a checklist. I have a couple of things I always check for -- e.g. i18n and accessibility, but we could do this a lot more.

2\. Have a common understanding on what acceptable test coverage might be

</comment><comment><USER12> Ugh. I would quit if I had to work in a pre-commit code review system. The idea should be that your team is so aligned that for 95% of all commits, you don't need any code review at all. If I refactor three common pieces of code into a utility function, why waste time code reviewing something that obvious?

> I don't want to block my team but at the same time I don't want to switch to > post-commit reviews since I can't ensure code quality.

You should have thought of that when you hired those developers. Now if you think that you cant trust them to produce quality code on their own then you have a problem.

</comment><comment><USER13> How is everyone not using github pull requests for this?

git checkout -b my-new-feature

<write code>

git add --all :/

git commit -m "added this awesome new feature'

git push origin my-new-feature

<open PR>

<wait for feedback>

<address feedback>

<merge PR>

<ship>

<comment><AUTHOR> We are. This is the part I want to optimize:

<wait for feedback>

<address feedback>

<merge PR>

<comment><USER13> Is the problem a function of the size each PR is? If each PR is small, it shouldn't take much time to review.

<comment><AUTHOR> Sometimes. Sometimes it's also a case of the first developer working on a feature which the second developer needs but is stuck in code review.</comment></comment></comment></comment>


Researchers show children are silent spreaders of virus that causes Covid-19 - <AUTHOR> https://www.eurekalert.org/pub_releases/2020-08/mgh-rsc081720.php <comment><AUTHOR> BOSTON - In the most comprehensive study of COVID-19 pediatric patients to date, Massachusetts General Hospital (MGH) and Mass General Hospital for Children (MGHfC) researchers provide critical data showing that children play a larger role in the community spread of COVID-19 than previously thought. In a study of 192 children ages 0-22, 49 children tested positive for SARS-CoV-2, and an additional 18 children had late-onset, COVID-19-related illness. The infected children were shown to have a significantly higher level of virus in their airways than hospitalized adults in ICUs for COVID-19 treatment.

</comment><comment><AUTHOR> Related Journal of Pediatrics Article: Pediatric SARS-CoV-2: Clinical Presentation, Infectivity, and Immune Responses [https://www.jpeds.com/article/S0022-3476(20)31023-4/fulltext](https://www.jpeds.com/article/S0022-3476\(20\)31023-4/fulltext)

Results A total of 192 children (mean age 10.2 +/\- 7 years) were enrolled. Forty-nine children (26%) were diagnosed with acute SARS-CoV-2 infection; an additional 18 children (9%) met criteria for MIS-C. Only 25 (51%) of children with acute SARS-CoV-2 infection presented with fever; symptoms of SARS-CoV-2 infection, if present, were non-specific. Nasopharyngeal viral load was highest in children in the first 2 days of symptoms, significantly higher than hospitalized adults with severe disease (P = .002). Age did not impact viral load, but younger children had lower ACE2 expression (P=0.004). IgM and IgG to the receptor binding domain (RBD) of the SARS-CoV-2 spike protein were increased in severe MIS-C (P<0.001), with dysregulated humoral responses observed.

Conclusion This study reveals that children may be a potential source of contagion in the SARS-CoV-2 pandemic in spite of milder disease or lack of symptoms, and immune dysregulation is implicated in severe post-infectious MIS-C.

</comment><comment><USER2> From the methods:

> SARS-CoV-2 viral load quantification: SARS-CoV-2 RNA levels were quantified > with a quantitative viral load assay using the US CDC 2019-nCoV_N1 primers > and probe set as previously described(10).

RNA. This _can_ mean that they have a higher viral load, but high level of viral RNA does not necessarily equate with live virus. Why didn't they try to infect Vero E6 cells with the swab samples? (My guess: lack of equipment). Given the day of sampling, it may be still related, but given studies in children are far and few between, this is an IMO glaring omission.

I checked the paper for cell cultures or in vitro assays for live virus, no dice.

I'm kind of disappointed. We're well into the pandemic and we still rely on the presence of RNA alone to infer infectiousness? Why didn't the reviewers ask for that?</comment>


Transitioning to SCSS at Scale - <AUTHOR> https://codeascraft.com/2015/02/02/transitioning-to-scss-at-scale/ <comment><USER2> 400,000 Lines of CSS over 2,000+ files? Is that a common scenario?

<comment><USER3> I assume that's all CSS across all of their projects, not just the main site.

</comment></comment><comment><USER4> I feel like postcss would work even better with their workflow since it converts css to an AST and allows you to transform it natively, whereas with sass you have to work around it.

</comment><comment><USER5> Bigger question is, why does a company like Etsy (or any non-trivial project) was not already using some kind of CSS preprocessor from day 1?

<comment><USER6> Etsy: Founded: June 18, 2005

SASS: First appeared 2006

CSS: Initial release December 17, 1996

If they knew how to time-travel I hope they focused on implementing other future tech.</comment></comment>


Uber Hired Investigators to Impersonate Journalists to Target Lawsuit Plaintiff - <AUTHOR> http://arstechnica.com/tech-policy/2016/06/uber-hired-investigators-to-impersonate-journalists-to-target-lawsuit-plaintiff/ <comment><USER2> another in a long line of alleged evil Uber always does. That company and ones like it are the reason capitalists get a bad rap - fighting dirty to become a monopoly is shit, and I hope they are regulated out of business.

<comment> King-Aaron Devil's advocate here: They have to fight dirty due to the established monopoly on the industry they're trying to break into.

It doesn't make it any less shitty, but their shittyness is a symptom of the shitty industry/government they're trying to disrupt.

Agree though, that this behaviour makes it worse for everyone.</comment></comment>


RAPTOR: Routing Attacks on Privacy in Tor - <AUTHOR> http://arxiv.org/abs/1503.03940 <comment><USER2> I wonder if there is a similar pipeline of developing hardening techniques based on the pipeline of research into vulnerabilities of things like Tor.

<comment><USER3> It's basically the same community working on both hardening and attacking Tor. Typically if you can find a vulnerability in Tor, you can patch it, and researchers usually work with the Tor developers to get the patches into Tor before disclosing them.

<comment><USER4> Some of the papers have definitely led to improvements in Tor (like refinements in how guard nodes are selected, or in other aspects of path selection) but I think there are also attacks from the research community that Tor hasn't found practical ways to mitigate yet.

Some mitigations may need to come from outside of Tor -- things that make the Internet as a whole more stable, harder to eavesdrop on, and harder to selectively disrupt.

</comment></comment></comment><comment><USER5> How fitting that arxiv blocks access by tor with a 403.

<comment> mike-cardwell They don't "block access by tor". They blocked the particular exit node that you were using, probably because abuse originated from it. I just managed to access the site via Tor fine.

<comment><USER5> I guess I've been very unlucky in my exit node selection then, the last few times I've tried to access arxiv through tor I've gotten a 403.

It's very common for sites to use third-party blocklists, and all those lists compete on number of blocked addresses so they all include tor. So lots of sites are not accessible through tor. I'm glad if arxiv is not one of them, though it sounds like their blocking system is a bit overprotective.

I wish these sites would just give read-only access instead of blocking access to content.</comment></comment></comment>


History tells us what may happen next with Brexit and Trump - <AUTHOR> https://medium.com/@theonlytoby/history-tells-us-what-will-happen-next-with-brexit-trump-a3fefd154714#.48sqmw4mu <comment><USER2> TL,DR: Trump! Brexit! Stupid masses ignoring the warnings of smart people like us! Nuclear war!

<comment><USER3> Don't worry Mr Zongle.

He also said that the survivors will be stronger and fitter once the radiation dies down. Those extra limbs will enable our descendants to access all of Unicode on a single keyboard thereby enabling international peace and prosperity ... until the next time!

I'd flag this as political nonsense contributing nothing but it's just too funny not to leave up.

</comment></comment><comment><USER4> Odd that the article didn't actually tell us what will happen next...

<comment><AUTHOR> Yes it does, near the end. A hypothetical scenario anyway.

<comment><USER4> > So I feel it's all inevitable. I don't know what it will be, but we are > entering a bad phase.

I don't regard "it will be bad", plus a hypothetical, as "telling us what will happen next".

[Edit: Oh, I see. The HN headline is "what _will_ happen", but the actual article headline is "what _may_ happen".]</comment></comment></comment>


Making OpenSSH on Mac OS X More Secure - <AUTHOR> http://jcs.org/notaweblog/2011/04/19/making_openssh_on_mac_os_x_more_secure/ <comment><USER2> I haven't played with this yet, but it's nifty. I tend to use keychain (<http://docs.funtoo.org/wiki/Keychain>), originally from Gentoo Linux and now included in Ubuntu, Mac Ports, etc. It's essentially a cleaner interface to ssh-agent, but with some of the same issues Josh writes about in this writeup.

I'll be trying this out.</comment>


How does JSFiddle monetize? - <AUTHOR>

JSFiddle.net is extremely popular (with probably high loads of traffic) and I was wondering about how do they make money to pay for servers, etc. ? <comment><USER2> They don't, but apparently they do plan on selling Pro accounts: <http://blog.jsfiddle.net/post/4255235684/going-commercial>.</comment>


10 Hours to Launch – DomainWatchBot on Telegram - <AUTHOR> https://medium.com/@spieglio/10-hours-to-launch-domainwatchbot-1008f6c5947e <comment><AUTHOR> I have been making side projects for the past 15 years. The problem: I never went public about them. In 2017 I vowed to myself that I will change that. I did a great job in procrastinating on this for the past 11 month. But now I kicked myself over the edge and just went for it.

I made @DomainWatchBot (on Telegram) in less than 10 hours. And now I am here to tell my story.

I hope you try the bot and please send me some feedback.

</comment><comment><USER2> Hey spieglio, nice project.

I'll be sure to send a telegram.

While I make projects on the side, the ones I've released so far have been free. It is a great feeling to finally have it off your chest and out into the wild Internet.

I think one of my projects is used around the world... as far as Russia and Australia.

I'm now working towards paid apps.

This bot will definitely be useful.. I've been waiting for a domain or two to free up. Last I remember to check is going to be in 2018.. but it'd be great to have something inform me of it.

+1 from men because damn man, might've only taken you 10 hours to up and running, but the idea and effort still went into it. Good to see efforts like these on Hacker News.</comment>


Why I Left Google - <AUTHOR> http://www.spencertipping.com/posts/2012.0530.why-i-left-google.html <comment><USER3> No mention seems to be made of how long Spencer was at Google.

As for the "pathological love of Java", Spencer has a distorted view. This will vary from project to project. I'd say C++ is more pervasive although Java may well dominate applications (rather than infrastructure) code.

Also there are lots of people who use Python but ultimately its production use is limited.

A common theme here seems to be that as an engineer you are discouraged or disallowed for doing things that are too "clever". This is something I approve of. Other people need to maintain your code after all.

For example, the abusage of automatic semicolon insertion that the Twitter devs behind Bootstrap seem to love (as some kind of "see how smart I am" display) would never survive at Google (our style guide expressly forbids excluding semicolons).

Anyway, sorry it didn't work out. Good luck, Spencer.

<comment><USER4> "Pathological love for Java and anything resembling Java."

I've often sensed this, when they push stuff like [1] GWT and to some extent Dart.

and of course the entire android brouhaha.

[1] <https://developers.google.com/web-toolkit/>

<comment><USER5> GWT takes the (very large) pool of capable Java programmers and magically enables them to become capable web programmers without mastering cross-browser subtleties. It's all about compartmentalization. For any/all its faults, that's an astoundingly immense value.

<comment><USER6> It depends what you mean by "capable". It's more accurate to say it takes large pool of Java programmers and lets them write slow and bloated UIs with canned widgets that are subtly (or not so subtly) inappropriate for the task at hand.

Google should be producing best-of-breed UIs, not ones that are easy for the unskilled to write. It's not like Google can't afford to hire the best.

A main reason for the slowness is that GWT obscures the boundary between the client and the server. People end up writing things like:

      for (x in hugelist) {
        doSynchronousCall()
      }

without realizing it. And then people test it on fast internal network connections and they don't realize what a poor experience results for average users/mobile users.

Another problem with GWT is that the JavaScript world has moved extremely fast in the 4 or 5 years since GWT was developed -- and most programmers don't know how to interface GWT with native JS (and that would defeat the "purity' anyway). So they're locked out of that functionality.

No matter how big the GWT team is, it can't keep up with the rest of the web advancing the state of the art in JavaScript.

I've also heard from people working on the Wave codebase that GWT was a big part of the reason they were locked into a particular design and couldn't iterate. For some reason Java just encourages people to dump out mountains of code. Maybe you can get away with that on the server, but when generating JS it just leads to UIs that crash the browser.

<comment><USER7> Maybe you shouldn't comment on GWT if you don't know anything about it. Pretty much everything you state about GWT is wrong.

1) GWT does not emulate synchronous APIs. That would incredibly expensive to do, requiring the implementation of continuation emulation or CPS transformation of the entire program.

2) GWT does not advocate "shielding" the developer from DOM or CSS. You are free to use the widgets, or not, just as you are free to use JS libraries with widgets, or not. The purpose of GWT isn't to hide the browser.

3) Most GWT programmers know how to interface with JS. I have not encountered any non-trivial GWT app that does not contain at least some portion that makes calls to JS.

4) On Javascript evolution. Sorry, Javascript has moved glacially slow. What has moved fast is the HTML5 API bindings. When ES6 arrives and GWT doesn't support it, then you have a point.

5) GWT is open source. It doesn't matter how big the GWT team is, it only matters how big the community is.

6) GWT UIs don't "crash the browser". Google derives the majority of its revenue from AdWords and AdSense, which are GWT, and if they were crashing customer's browsers like you say, I'm pretty sure Google would be in trouble.

GWT is a compiler. You can write bad code, or you can write good code. In 2009 I ported jQuery to GWT. The resulting code was smaller than jQuery, and faster than all other competing libraries at the time. See the result here: <http://www.youtube.com/watch?v=sl5em1UPuoI>

I don't have anything against JS, and I don't think GWT is the right tool for every project, but I don't think you should respond to threads like this and make what appear to be authoritative statements which are obviously and completely false (synchronous calls)

<comment><USER6> As mentioned below, the point about synchronous calls was made based on seeing 30+ second latencies in more than one GWT app and opening them up in firebug, and seeing a crazy number of roundtrips (with many of them serialized). With async APIs people can somehow still structure their applications so that logically many full round trips are needed to render the page.

I'm not necessarily saying that's GWT's "fault" -- the claim is that the developers writing GWT don't understand what they're writing. I said essentially what I said here to a tech lead of a GWT app and he's like... that's EXACTLY the problem we're having. This happened to be an app I've never even used, but he was shaking his head in agreement.

I think GWT was written by skilled engineers who had written tons of JS and got sick of the repetitiveness and the primitiveness of it in 2007 or whenever. But the claim of the OP: "GWT takes the (very large) pool of capable Java programmers and magically enables them to become capable web programmers" is not true. Empirically, people who've never written JS are writing GWT, and they are writing terrible web apps.

I guess you can say that tools create apps with a "smell". PHP creates web apps with injection security holes. C creates apps riddled with dangerous and costly buffer overflows (or used to before crazy amounts of compiler/library work). I'll take a dig at my favorite and say Python creates apps that dump stack traces on invalid input and don't handle signals correctly.

GWT's smell is creating bloated and slow apps now with bad UIs. I was pretty surprised at the number of upvotes I received, so I'm not the only one that smells it. Like C and others, it's possible that people will derive so much value the tool that they eventually learn how to overcome the pitfalls.

<comment><USER7> I smell selection bias. Have you never visited HuffingtonPost, Gizmodo, or PandyDaily and looked at the network tab? Javascript does not automatically make people produce fast and snappy sites. That is based on experience, regardless of language. There are tons of websites that make a boatload of script include requests and image requests because the developers haven't learned about UglifyJS or Closure Compiler yet, or don't know about CSS spriting. Take a look at flights.google.com, it is a GWT app of non-trivial functionality that loads faster than most comparable sites (<2 secs) and makes far fewer requests. Another good one is the SpeedTracer app for Chrome (it runs as an extension). It has a very very nice UI, better than Firefox and WebKit WebInspector, and it's a GWT app.

Anyway, why do you think Google does all of their hand-coded JS apps with Closure and the Closure Compiler? It's not because JS 'out of the box' is conducive to producing best-of-breed apps. Web programming requires a large amount of on-the-job acquired knowledge. How many people are aware of CSS selector performance, or the performance effect of reading element.offsetWidth?

GWT doesn't prevent you from shooting yourself in the foot, just like any other language. Producing optimal apps in any language requires experience in that language. Knowing how to arrange non-blocking behavior in script inclusion, or batching requests, is something that comes with experience. I wish I could produce a boilerplate framework that could make amateurs produce absolutely optimal apps out of the box, but that would trade off a lot of freedom.

However, GWT does offer tools to reduce your HTTP requests, and it's been doing this for years before they became common place in JS. For example, GWT has had automatic CSS spriting and image optimization since 2007. It's been doing CSS optimization nearly as long. GWT 'perfect caching' has been in from the beginning, which guarantees that most of the time, the app is loaded via a single HTTP request to a small 2k bootstrap file. In fact, it's possible to load your initial page: html, js, css, images in just 1-2 requests if you desire. Obviously, there are tradeoffs there too, that are platform and app- dependent.

There certainly are some APIs in the GWT SDK that can produce bloat if you use them, and that is wholly dependent on your preference. The GWT RPC system, for example, is great for internal apps, because it makes server communication trivial, but GWT also includes regular JSON/JSONP/XHR support. You can choose to use Widgets, or you can built your UI with HTML templates and CSS, just like you might do with Handlebars in JS.

I guess my point is this: I don't deny that an amateur Java programmer could take GWT and unknowingly compile a huge amount of junk into their app or make an insane number of HTTP requests. I just don't think producing apps with terrible startup latency is GWT specific, and I've seen enough websites in JS that are absolutely terrible to know that the way you get an optimal UI is by hiring good engineers with web experience, not by language choice.

And on that note, it's quite easy to get upvotes IMHO when you start a language war, because people are so opinionated on one side or another about it. My own personal opinion is that you should use the tools you feel most productive in, period, and if that's JS, or GWT, or CoffeeScript, or Objective-J, than more power to you.

<comment><USER8> > Javascript does not automatically make people produce fast and snappy sites.

He never claimed otherwise. His point seemed to be that if someone just picks up GWT and whips up an application, it's likely to exhibit some (severely) suboptimal behaviour here and there.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> A lot of the "cons" in the technical section just sound like a large engineering organization making pragmatic decisions. I can't think of any company working at that scale that's successfully integrated a non-trivial amount of functional or logic programming. As much as hackers might not like it, there are reasons that coding at that scale is almost always a matter of banging out a lot of imperative code in a boring language like Java.

And I'm definitely not the only one that appreciates Go precisely because it doesn't play the Scala game of integrating every single academic PL research feature of the last 20 years but instead tries to be as practical and simple as possible.

<comment><USER10> From what I've heard, Go goes too far in the opposite direction and integrates basically _no_ modern research.

<comment><USER11> Go is not a research language (e.g. Haskell), it is pragmatic. I suspect a part of the design decisions of Go factored in training for people using that language. At a certain point, features that are alien cost more in training costs than they will gain in "elegance" or whatever.

<comment><USER12> I don't think the concern is training, but the complexity caused by how various features interact, and how hard they make to reason about code.

Go is designed so it is very easy to read and reason about what code does.

<comment><USER10> I don't know. Maybe it's because I've been mostly looking at Haskell and OCaml recently, but most of the more "researchy" features and languages I've seen aim to be _easier_ to reason about.

Unlike most languages (including Go, I believe), researchy languages tend to have very well defined semantics based on well-understood math--really going out of the way to be easy to reason about!

</comment></comment></comment></comment></comment><comment><USER13> A few days ago I was at a conference and there was this Google recruitment desk, with gadgets and two nice guys. I walked near the desk and said: "Hi, can I have a t-shirt for my son?", and they said sure, asking me to compile a form in an Android tablet.

Basically it was a list of programming questions, and out of 5 questions I was able to reply only to three. One was the time complexity of heap sort, that's pretty obvious, another one a probability theory quiz about trowing balls into bins, also pretty reasonable. Another one I can't remember, still pretty general.

Then there were this two questions I was not able to reply: one was about Java argument passing conventions in some specific kind of method I can't even remember (I can't write "Hello World" in Java). Another was about graph theory and adjacent Matrix.

Well, my idea is, that a big percentage of Google problems are due to this kind of hiring process. It's good if I know the fundamental algorithms as a programmer, but why I'm required to know Java as it was a pre-requisite to be a good programmer? About graph theory, it's something that is rarely used, if I need to do something I can grab a book and check it, it's strange to remember this stuff when you don't use it a lot.

Now hiring only guys that know exactly the Java calling convetions AND graph theory means to apply a big filter between the programming world and your company. This filter is good as it's cool to know a lot of things, but it's also bad because, for instance, a lot of good programmers I know don't care about Java at all, and while they may have a generally good understanding of algorithms they don't remember how to factor a number with polland-rho, or dynamic programming, and so forth.

This filter does not tell you nothing about the real ability of the candidate to write good programs, to use the right abstractions, and to design beautiful systems. Actually it _may_ tell you that the candidate is focused on the details, and the brain is a zero-sum game sometimes.

Another thing I'm pretty convinced of is that this kind of candidates is not _the only kind of employees_ you want if you want to enter the social network business and compete with Facebook. Your output as a company will be a system that little resembles what average people want.

So the #1 problem of Google IMHO is to allow more internal divesification of cultures and programming backgrounds.

<comment><USER14> Did it ever occur to you that 5 questions at a recruitment desk might not be representative of the whole Google hiring process?

<comment><USER15> They are quite representative.

<comment><USER14> You don't have to know Java to get hired, any programming language is fine. You do get asked design questions. I think making the leap from these 5 questions to "This is the #1 problem Google has and why they fail at social networks" is a bit far fetched, but it looks like I'm the only one...

<comment><USER15> The impression I got was that you don't have to know Java, but you should know at least one of Python/Java/C++. They strongly prefer the latter two.

The leap from the questions to google failing at social networks is far fetched, though.

</comment></comment></comment></comment></comment><comment><USER16> This bit seems wrong (about private open source projects):

> Technically, Google owns everything you write while you work there, even if > it's on your own time and with your own equipment.

Google is a California employer, and that's directly counter to California law as I understand it. The only exceptions made are for product areas directly related to your work (not just the employer's business interests). Am I wrong about this?

<comment><USER17> As a lawyer (IP, not employment), i can affirmatively state you are wrong about this, for reasons various folks mentioned below (the actual phrasing deals with relating to your company's business, not directly related to your work).

Additionally, court interpretations of this statute are not as favorable as engineers like to believe (IMHO).

Living in !California, from what I see, California is only theoretically different from most states. In practice, for technology companies, the law basically means your employer owns stuff on your free time, in the general case.

(IE If you were working for a startup that does online home rentals, and you were making a video game, you may have an argument)

<comment><USER16> Surely those court interpretations are situations where employees left to pursue products though, right? Is there really case law where a company sued to recover ownership of a free software project? That just seems lose-lose all around. Bad PR, bad karma, no deep pockets to sue, no damages to recover.

Personally, I find this kind of bureaucratic nonsense infuriating. And I guess I thought Google was better about it, but it doesn't seem to be. My past employers have, for the most part, simply shrugged when told about open source work I've done. Honestly I have to think that if I really ran afoul of a rule like this I'd just call your bluff and see if you'd fire me over it (because as I mentioned, we both know you won't sue).

<comment><USER17> There is plenty of caselaw I can find where, for example, employees have _not left_ , but refused to sign over patents on stuff done in spare time, and companies sued to recover them while the employee was still working there. I have yet to find one where the company lost.

For open source work, if you go through the process, it's short and we're happy to approve it (patches take about 30 minutes, projects, 3-7 days). In the IP release process, it's longer. That is better than every company i have worked at.

You seem to think it's not very important, and just nonsense in general. Knowing who the legal copyright owners of the source code in your open source project are is quite important (in the cases you posit where everyone is just saying "whatever", the owner is unclear) If you don't think so, I can tell you in the _one_ important case in the US where an open source project had to defend itself, Jacobsen v. Katzer, that Victoria Hall (the lawyer) spent a very large amount of her time trying to get all this sorted after the fact, and it is only by luck that the 50+ contributors she had to wrangle were still around and accessible.

This is probably 300k in legal fees that could have been saved by having done the right thing up front at a cost of about 30 minutes. Note that these legal fees were paid by the poor guy who was running the open source project, not by his contributors.

If you want me to be blunt, no offense, I've met folks like you, who think all this is a waste of time, and you are generally not worth the eventual expense in legal fees to the open source projects you contribute to (IE when the open source project needs to actually defend its rights, or the company behind the OSS project gets sued). Shrugging and saying "whatever" also has a funny way of turning into "that was really mine and guess what, we want damages" when the company you worked for gets bought.

It's great to want the world to be different. I support all efforts to make life better for engineers around owning stuff in their spare time. I also spend a lot of my life trying to help open source in general.

But to be blunt some more: The world we live in right now is not a happy pretty place. The reality is if folks like me, and the companies we work for, tell you than when you release a new open source project we probably own, that you should spend 5 minutes filling out a 4 field form and waiting a day for some folks to click approve before you fly and be free, it's not because we are power tripping bureaucrats. It's because we're trying to save millions in legal fees when it matters, and make sure the open source project you want to release is not going to be in a bad place, at a cost of 5 minutes of time and a small amount of waiting.

So my advice is if you think you really want to "call someone's bluff", I would instead think hard about whether you are really expert enough in this stuff to be able to say it's all nonsense, and stop to think about whether the people who are perpetuating "nonsense" may actually have your best interests at heart. That is, trying to save you from yourself. If you really think it's a great idea to have an awesome open source project used by 1 million people, when it's not clear who actually owns the code, then all i can say is that i pity those people.

<comment><USER16> You're projecting pretty badly here, and are flaming where I really don't think it's appropriate ("People like you", indeed).

For clarity, though, when you say "the open source process", you mean the process where Google gets assigned ownership. An employee who wants to release something under an OSD compatible license without assigning copyright (for whatever reason, say because they want to use the GPLv3 and you don't, or because they simply don't trust a public company) does _not_ simply fill out a 4-line form and get an answer in a day, as I understand it.

( _edit: And you continue to euphemize this. It's not "special treatment", it's a flat out copyright assignment. Ownership isn't completely clear, so one of the parties needs to give up stake. And the process is clearly asymmetric in Google's favor. That's not surprising, really, but what is surprising is that you won't come straight out and say this._ )

And my advice to _you_ is that you consider the costs of this sort of thing to the employees and the engineering work when making your conservative legal pronouncements. As we've seen in the news today, even Google's rigorous IP process isn't enough to keep you from getting sued. The world is indeed not a happy pretty place; cavalier avoidance of process may not help things, but neither does paranoia.

<comment><USER17> 1\. I'm perfectly comfortable with what I wrote. I neither believe it was inappropriately flaming given what you wrote, nor do I think it is "projecting pretty badly", as you say (The "people like you" was intentional, and given the evidence I have, seems correct. If it turned out not to be correct, i'd happily retract it).

2\. Yes, people who want special treatment take time. We've made the common case fast, and the exceptional case possible.

3\. We do consider the costs, and try to keep the process as simple as possible while still accomplishing its goals. Note that I am an engineer as well as a lawyer, and contribute to a large number of open source projects and so I have to go through the same process everyone else does.

4\. You honestly don't know what you are talking about when it comes to things you've "seen in the news", and i'll just leave it at that.

</comment></comment></comment></comment></comment></comment><comment><USER18> What's so fascinating about this is that it provides a glimpse of the inner workings of the Google machine. Even Google with its second-to-none reputation, cool tech and HR practices ends up alienating this employee because of its bureaucracy. This in a company founded just fourteen years ago. On one hand it's comforting to know that even the best of the best lose an important aspect of their competitiveness and might be defeated, on the other hand it is troubling how all companies seem destined to lose their agility and flexibility. Not even Google with all their incredible resources and brilliant minds can solve this, it seems.

<comment><USER19> It sounds like you're reading an awful lot into one person's experience. Lots of people at google love their jobs, feel challenged and fulfilled, see all the oppertunities google provides from touching the lives of millions to open source projects to 20% time to access to every project at the company etc etc etc as an amazing blessing.

Others have either bad experience, a bad attitude or maybe a little of both.

I don't think one guy's opinion is really a reflection of most employee's experiences at google.

I've been here 4 years. Haven't written one line of Java. Get paid to contribute to open source, have started 5 to 20 side projects, all open sourced. I could go into a lot more things but suffice it to say Google is by far the best place I've worked out of the 10 places I've worked so far.

</comment></comment><comment><USER20> _Java was viewed as being "good enough"; alternatives like Scala and Clojure were not considered._

If a company enter the _what-is-the-hottest-language-of-the-week_ game it can easily drag itself in a downward spiral of death. Just because it boils down to taste! And it leaves a lot of hurted feelings around the way. Language is a lot about maintenance 10 years down the road.

 _Scala and Clojure each have significant design flaws, in my opinion, and neither would have been a significantly better choice._

Couldn't agree more! Be it a startup or a mega-corp, VPs should make their minds upfront and stay on their path until something _amazingly_ better comes down the road. C'mon, if Google had chosen Scala, for example, they could have produced clean, concise code, FP-oriented software at the price of sluggish compilation times (many wasted minutes), lots and lots and lots of generated bytecodes, and binary incompatibility (ouch!). Jump into the trendy language badwagon and you find yourself nowhere pretty soon. I know of at least two prominent startups in Bay Area who are switching of Scala and adopting the old-fashioned Java, for many reasons, but fondness of OO or lack of vision are not among them. And a third startup is stealthily switching to Clojure. On the other hand, you have C/C++.

</comment><comment><USER21> A big organization not wanting projects written in Clojure, Scala, or other language of the month? Yeah I wouldn't either. If 99% of your coders know Java, and there's no compelling reason otherwise, go with Java.

</comment><comment><USER22> > Pathological love for Java and anything resembling Java.

And I think that's the good thing. Over years I finally realized, it's not the programming language you use that matters, or makes you look smarter. It's the kind of problem you are trying to solve by writing code. Computer Science field is far, far reacher than the PL research subfield.

I mean, you may be writing another boring enterprise web application in Haskell, or solving Artificial Intelligence problem in Visual Basic. I would prefer later rather than former, although I hate VB. I know, both situations are contrived, this is just a thought experiment to illustrate my point.

Don't get me wrong, I love "esoteric" programming languages. Few years ago I spent quite a lot of time playing with Haskell, Prolog Lisp, etc, and I don't regret it. No, I don't use these on daily basis or going to, but I studied a hell lot of coll new stuff. Most importantly, it taught me about new _paradigms_ of programming, that I really think every programmer should understand.

These days, however, I try to squeeze as much math and algorithms from different domains as I can in my poor stupid head and I think that payoff of this would be much bigger for me.

PS

Few month ago at a local functional programming meetup some guys presented their Scala solution to a trivial problem of validating web forms in a rather trivial web application. Their solution employed the whole lot of functional stuff, like functors, mappings and the things whose names I forgot. I was trying to understand what they are doing but they lost me after fifth minute of the presentation. It took them maybe a week to write all this code. Do you see the irony?

</comment><comment><USER7> Most Google projects are not written in GWT for the frontend, they are written in Javascript using Closure and the Closure compiler, that includes Gmail, Search, G+, Docs, Drive, etc.

Really, it sounds like this guy got put onto a team project he didn't like, but Google has very large codebases in C/C++, as well as JS, and there is ample opportunity to work on non-Java stuff. Chrome and Android (non-userland) in particular.

Any company with a team of people is going to have to place limits on polyglotism and have standards for readability and coding. I like Scala too, but the idea that a company is going to allow anyone to just pick any PLT research languages that they personally like sounds far-fetched.

</comment><comment><USER23> Ouch this seems painful

The trend of "all OOP" especially in the Java world, and how OOP is done, is BAD. As in "there's something in my eye" bad.This reflects _exactly_ on this: "Reviews preferred local simplicity over global simplicity; abstraction was discouraged"

I feel like I'm a million years old, but I think procedural programming does it right.

It seems most OOP programmers want an excuse to do 10 levels of inheritance and split the functionality in weird ways.

The rest seems likely to derive from google's broken hiring process.

<comment><USER24> Even as a relatively young† programmer, I'm with you to a certain extent. OOP‡ is both technically and philosophically unsound.

However, though I use C quite a bit, I don't think procedural programming is the paradigm to end all paradigms. My knowledge, productivity, and code quality have all benefited from functional programming (Haskell and Scheme) and generic programming (C++).

Also, splitting up functionality is a part of good abstraction, and "weird ways" might only appear weird because you're unfamiliar with them. That's how I felt for a while about monads, for example. Some of it is just having the experience to see what qualities make code good in a particular paradigm. And regardless of paradigm, good abstractions are essentially about factoring and reducing repetition (DRY).

†though not terribly new

‡the "classes and inheritance" kind that Java epitomises

<comment><USER25> > both technically and philosophically unsound.

Philosophically? Can you please elaborate on this? Technically, I don't think there is any unsoundness in OOPs as compared to functional programming (or procedural or generic). Technically, there are paradigms available for all requirements. It might end up being messy or boring or bloated, but that is not a technical issue but more human. OO code on the other hand is incredibly easy to grasp and the ubiquity of OOP fuels itself. May be we would have been at a higher level in our enterprise codes if we had chosen a _superior_ language like Haskell, Scheme or Python for everything; but we don't it for sure. Code is as much an art as it is science, and sometimes better art is possible with outdated paradigms likes paint and paper than touch interfaces and brilliant applications.

<comment><USER26> I believe the GP is quoting[1] from Alexander Stepanov (author of the C++ STL).

Saying "pick the right paradigm for the task" is of course the correct answer, but it's fun to argue sometimes, and OOP is definitely overhyped in certain markets (for instance, university CS)

______________________

[1] <http://www.stlport.org/resources/StepanovUSA.html>

<comment><USER24> Yes, I was (somewhat accidentally) paraphrasing Stepanov. It's been a while since I read that.

But actually, I think "pick the right paradigm for the task" needs the qualification of "…within your other constraints". The most _expressive_ language for a job might not work in your situation—whether for reasons of efficiency, of maintainability (i.e., finding maintenance programmers), or of interoperability with the rest of your stack.

</comment></comment></comment></comment></comment><comment><USER27> I'm surprised by the tech part. I was under the impression Googlers used a lot of Python, for instance, and possibly other languages... Are these exceptional cases, then?

<comment><USER28> Google's a bit ambivalent about Python. On one hand, you have a contingent of programmers who don't consider python a "real" programming language. These types seem to be mostly on the search team. On the other hand, there are plenty of pockets within the company where Python is used pretty heavily. The most notable is arguably the App Engine team.

<comment><USER29> I found this out during my interviews at Google; after I solved a problem using Python the interviewer gave me another and said "this time use a real language." Ouch.

<comment><USER30> That's the sort of thing that would make me strongly consider ending the interview, at least if I was going to be working directly for the interviewer. No need to waste more of their or my time than necessary, and I really wouldn't like working in that kind of insulting environment. And from a probably-immature perspective, the feel of power from being the guy saying "sorry, I'm not interested anymore" instead of hoping they call you back is nice.

Or, if I was really annoyed: bust out some Common Lisp for the next problem, then leave.

<comment><USER31> Seriously, he said the next question was string manipulation or something:

        #include <stdio.h>
        char f[8] = {70, 117, 99, 107, 32, 121, 111, 117};
        int main(){
          int u; for(u=0; u<8; u++) { printf("%c", f[u]); }
          printf(".\n");
        }

Thank them for their time and walk out.

</comment></comment></comment></comment></comment><comment><USER32> This is the best "Why I Left Google" article I've read, and I really don't have any criticism for it. Everything he says is true on some level, but things that look bad don't look as bad with some context. So I hope to provide that in case you are thinking of working for Google but are pushed in the "nah, maybe not" direction because of articles like these.

First off, you have to remember that Google is a big company. It's one of the world's most profitable, and there are quite a few employees. This is not a startup. This is not a world free of politics. This is not a world where the execs will listen to all of your concerns. (With that in mind, it is very easy to get their ear and voice your concerns. It's just that they might not drop everything to do things the way you think they should be done.) This is a publicly traded company with lots of stuff to do and processes that scale to a large number of employees.

But, that's not a horrible thing. If you've worked at other big companies (or bigger companies), this place is like a dream world. You know what other people are doing. You can see their code. You can see their processes running in production. You can have internal mailing lists where you might accidentally say something that looks bad during discovery. Every change you make to the codebase gets another developer saying, "yes, this looks good" before you commit. Everywhere I've worked before, anything like these would have been immediately shut down. Code reviews slow progress. Mailing lists are a legal minefield. Sharing code doesn't allow the correct cost center to pay for its development. That's how it is. If you are unhappy with Google's corporate policies, try working for Bank of America. You will not complain as much :)

On the other hand, if you are the "I want to work by myself and be a product manager, engineer, sysadmin, and CEO", then the big-company culture is not for you. I write code and talk about writing code. That's it, someone else does everything else. I like that, but if you don't, you won't like the big company lifestyle.

(So, with that in mind, I don't think Google is a good place for your first job out of school. You will be annoyed with the M&M restocking policies, quit out of protest, and realize how horrible the real world is. IMHO.)

Now on to some specific points:

Programming-related:

 _Pathological love for Java and anything resembling Java._

This is a network effect. In any project I've started, I've been able to use any language I've wanted to. Plenty of projects are using Haskell, my personal favorite app programming language. The reason why I choose Python or Java at Google is because I want a large pool of people to get feedback from on code reviews, design reviews, at "could you take a look at this" time, and so on. Everyone knows Java, and so I can be more productive at Google if I use Java. I don't spend much time typing in code. I do spend a lot of time working with other people. I think Java is objectively a terrible programming language and I hate it conceptually, but the great internal community and great internal libraries make it quite usable. (Read my HN history. I am not kind about Java. But at Google, the limitations I complain about are not as relevant as they are when you are "out on your own". I don't foresee any personal projects in Java any time soon, however. It's too verbose for apps that don't need to be fast or scale. And it's not really _fun_ like Perl is.)

If you absolutely cannot work with Java, then there are plenty of C++ projects to work on and your skills will be valued highly. Go is probably quite acceptable, too, given the right project.

 _Most engineers were not comfortable with {functional, concatenative, combinatory, logic, meta} programming._

Even though it's Google, programmers are at various different levels in their programming careers. I personally like programming languages and their differences in style, but other people are more practical and just want to sit down and churn out features for their project. They don't want to switch to Haskell because it's better at X than Java. They just want to make something new. So, if you want to be different, you need to be prepared to go out on your own. And if you're new to Google, you might not be ready to do that for two or three years, because there is so much other stuff to do. You're going to be thrown on a team and expected to contribute. Establish rapport and then try to change the world. Don't do it on your first day. (Again, if that's a problem, big company life might not be for you. This is a team effort, after all.)

 _Reviews preferred local simplicity over global simplicity; abstraction was discouraged._

The first half is true, simply because reviews are line-based rather than repository-based. But there is a _design review_ stage of projects when you discuss high-level design. I was not used to writing design docs before writing code before working at Google, but now that I'm used to it, I like it a lot. It's saved me a lot of time, I think.

Code reviews depend on your teams' conventions. My team is super strict and nit-picky, but others will almost rubber-stamp changelists. Different personalities, different results. If you want harsher code reviews, review other code more harshly, I would say.

Abstraction is not discouraged.

 _Productivity was graded without much regard to the amount of technological debt accrued. (Though to be fair, this is a hard problem.)_

I don't know much about this. I work with lots of people that are at the level I would like to be at in a few years, and I don't foresee any problems for myself. My bosses give me the impression that I choose good objectives and key results, and I pretty much meet all my key results. But it's only my second quarter at Google, so who knows.

As for the corporate culture points, I basically agree with everything he says. I don't think Google+ is the finest Google product the world has ever seen. That's my opinion and since I don't work on the project, nobody really cares what I think. I can live with that and even think it's reasonable. But if you want to associate everything a company of 30,000 does with your personal thoughts and beliefs, you might be disappointed.

I know I sound like a total pushover when I say "that's just how the world is and you should adapt yourself", but honestly, I just want to receive large quantities of money in exchange for playing with computers, and Google gives that to me. And really awesome food. And wonderful coworkers. So I can't complain much, especially after the other places I've worked.

YMMV. Why not try Google out for a year or two and see for yourself? You might like it, you might not, but you'll definitely learn something.

(And if you want to apply but don't have a contact at Google, I'm happy to be one. Tell me about yourself and I will try to get you in touch with the right people. jrockway AT google.com :)

<comment><USER33> Mostly I agree with you.

But Google does have a strong C++/Java/Python bias. Even if it hasn't touched you personally, it is very likely that a new Googler will be using one of those 3 languages as her main language.

<comment><USER34> Most large companies (and even mid-sized ones) have some kind of "technological environment of choice" that sort of given (three languages is already not so bad). It does not means it cannot change or be lifted for a specific project, just that it is "what you are supposed to use", and that you are expected to provide heavy arguments to be allowed deviate from it.

In most situations, this is actually wise : behind development, you have a whole process (deploy, quality control, etc), and they will have the required tools and expertise for the languages they use on a regular basis. And when you start a project at a large company, you know that other people will take it after, so it is easier if it is close to the company technical standards.

Having written an application in Ruby in a Java shop, I remember protesting on the "rewrite in Java" that happened just after the prototype phase. With some distance, I think I understand the decision.

<comment><USER10> There's nothing wrong with having a uniform set of languages. I just wish they were _good_ languages and not Java or Python.

Having everybody use their own programming language would be crazy. Unless they're domain-specific languages, in which case it would actually be very cool.

Still, if I'm to be bound by a language choice, I'd really like to be the one making it. Which is why I think working for a tiny startup would be more fun.

<comment><USER34> It is important to know your own preferences, but as you said yourself, then you need to make your choices accordingly : it could be the startup, or aiming for a position in a big company where you have something to say about those choices. Both are interesting.

For the first point, I will not start a discussion about what is a "good" language (a large part of it being in the eye of the beholder and in the requirements of the projects).

</comment></comment></comment></comment></comment><comment><USER35> As someone who worked there 4 months last year, this is pretty accurate. I had a more negative experience because I got consigned to an obvious tarbaby team that was bleeding an engineer a month, but this seems more like the norm...

And yes, Google makes claim to everything you write while you're there unless they explicitly agree otherwise. They have set up a committee for making those decisions. This is probably a good thing IMO.

<comment><USER36> I don't know what you meant by tarbaby but that's a pretty offensive term. HN is not the place for that kind of speech.

<http://ycombinator.com/newsguidelines.html>

<comment><USER37> I gather he meant the colloquial meaning in most places of the world which is something to the tune of "Something best avoided rather than confronted.". I believe it originates from a story or fable as such.

However I assume you meant he was using it in the more offensive slang usage for african-american. Chances are he might not even know it has the connotation as it's pretty specific to America.

<comment><USER38> Nobody uses "tar baby" as a slur in America. It's like "niggardly" - <USER2> people use an incorrect interpretation to try to shut down people they don't like.

<comment><USER39> That said, you'd have to be crazy to use "niggardly" now after the reaction it got whoever that was. If you use words that most of your audience doesn't know, what does it say about you? :)

</comment></comment></comment></comment></comment><comment><USER40> As a guy who basically did Java/GWT at Google for a year, I feel like I could have written this exact article.

</comment><comment><USER41> "Pathological love for Java and anything resembling Java." "Java was viewed as being "good enough"; alternatives like Scala and Clojure were not considered."

Perhaps Google should have acquired Sun, and worked on updating Java to keep up with other C derivatives (e.g. C#).

<comment><USER42> Yes :-(

</comment></comment><comment><USER43> Correction: Pathological love of Java and C++

What's that essay PG wrote on starting Viaweb with RM where he said potential competitors advertising for Java and C++ developers did not make them nervous?

<comment><USER44> <http://www.paulgraham.com/pypar.html>

</comment></comment><comment><USER45> Spencer's comments are generally accurate. I might quibble with some of them or say that they vary from team to team. For instance, I have used R, Python, Java, and Sawzall in my work at Google and have had freedom to choose technologies on some of my projects with input from team members.

It is true that most of the larger production systems like the Search Engine are mainly written in C++ and Java and that functional programming isn't widespread, yet.

But you are free to take on a 20% project to show the value of other ideas.

I would also challenge technology cons #2, #10, and #11. I think a lot of Google Engineers do tackle fundamental problems.

</comment><comment><USER46> > _Efficient, well-managed HR system with minimal bureaucracy and red tape._

Noobs are under the impression that HR somehow supports employees. That is not the function.

There is one and only one function for HR: CYA for the company.

<comment><USER42> Why would you ever work somewhere where employees were not considered part of the company?

</comment></comment><comment><USER47> Dupe from the other day:

<http://news.ycombinator.com/item?id=4044219>

The only difference in the URL is the unnecessary "www." prefix. Perhaps news.arc could be updated to treat both URLs the same?

</comment><comment><USER48> > "I'm certainly not saying I'm right"

When you said it, if you did not believe in what you said, you better have not said it _. The world is filled with enough empty smalltalks. Moreover, if even you do not believe in what you say, who the hell would believe in you ("read you") next time you say something?

If you thought it was right but have changed your opinion in between, please state it clearly. It is a strong mark of cleverness (to me).

If you still think it is right, please stand for your opinion, it may have some value for others.

[_] Just finished a nice podcast about Wittgenstein...

<comment><USER49> Hang on, you're being a little unfair about this. I believe in what I said. I think FP is a great step forwards and I think it's going to win out. I'm biased because I think this.

But Google is worth billions of dollars and is succeeding wildly at innovating and changing the world, and I'm a lone developer. I can't very well stand here and tell Google, "hey you billionaire company, you're doing it all wrong; I've got the magic bullet right here."

Part of the dichotomy is whether to define success as financial wealth or as some kind of more abstract software quality. And I think that's a legitimate variable; if Google is wealthy but has lower-quality software for it, then they and I just have different priorities.

I stand for my opinion by investing all of my spare time into FP language development and research, but until I see a billion-dollar company using it, I'm not going to call anyone a loser for choosing Java.

<comment><USER48> OK. Maybe it should be another discussion but to me FP is a step backwards. Anyway I am glad to see you defending your position a bit.

</comment></comment></comment><comment><USER50> complains about the widespread use of Java, but also complains that Go is stupid. Sounds like someone is a bit difficult to please.

</comment><comment><USER51> What's sad is that when this get publicity the author has to shield up all the things he said, which were probably honest; in order to avoid troubles/ future employment issues.

Employment is always so taboo. Not so much freespeech if you don't wanna live with the "consequences".

<comment><USER49> That's not why I did it. I felt bad because my family and friends know me as being unreasonable, idealistic, etc. But HN doesn't know anything about me and might assume I'm an otherwise reasonable person. So I wanted to make sure I wasn't badmouthing Google here. They really are an awesome company and the point was never to make them look bad. More just to explain about where the incompatibility was.

</comment></comment><comment><USER52> "High turnaround time for my own open-source projects. [5] ... two-month lag before I got an official reply from them .."

What I would give for two months! At my current employeer the turnaround time has been up to six+ month which has killed a number of my personal projects.

<comment><USER17> See what Chris Dibona/I wrote above. The turnaround is not really two months for open sourcing, it's 3-7 days.

<comment><USER53> FWIW, Chris Dibona's record response time to a request I've made to open source a project was somewhere on the order of seconds. Maybe 10 seconds I think. It was like he had his finger hovering over the "Approve" button. Patent approval takes longer and does seem to push things into the 3-7 day range, but I once didn't get a response from them, and Chris basically just said, "Well, that's their problem. They were supposed to respond and they didn't, so you can go ahead and release." The open source team at Google is _amazing_ and frankly, more companies should copy them. This stuff matters.

</comment></comment></comment><comment><USER54> Mildly shocked this comment thread hasn't been hijacked by Michael O Church yet.

<comment><USER42> Passing the torch to the next generation of tourist cum expert. You can't expect these folks to stick with their avocatiom more than a few months before quitting.

<comment><USER55> You two are contributing to HN becoming cattier than a brothel of backbiters.

</comment></comment></comment><comment><USER56> I would like to hear your thoughts on Clojure's serious design flaws. I'm currently learning the language and haven't come across anything warning me of such things.

<comment><USER44> I have two years experience with Clojure and about a year working with Scala (plus use of Ocaml and a bit of Haskell). Clojure and Scala both have warts. Many, many warts, as all languages do. Still, I can't say that I've found major, intractable "design flaws" (as in, design decisions leaving me convinced I could do it better) in either. They run on the JVM, and they're ambitious languages, so warts are inevitable. That's hella hard, and both languages do an excellent job considering the constraints involved.

Most of the things I find myself disliking in these languages have more to do with JVM legacy (e.g. type erasure in Scala) but that's also what gave them a chance at being mainstream, so no complaints there.

<comment><USER57> It's worth noting that Reifeid generics also have their limitations. I believe Haskell also does a similar level of erasure. Reified generics makes it harder to include higher order types and so the level of abstraction in Scala's collections or monad transformers would be much harder without type erasure. Haskell's type system is better at keeping the annoyance of erased types away by not just casting every thing to a top type.

</comment></comment></comment><comment><USER58> I wonder if there are similar articles from ex-Apple people.

</comment><comment><USER59> The only Con that really made me nervous was 15 and even without context it doesn't say a lot. Boilerplate isn't _always_ bad though it usually hints at things that could be better and more reliably solved.

Funny, he complains about over-usage of OOP but off-handedly dismisses Go. Not sure I understand that.

</comment><comment><USER60> everybody leaves Google if there are better company

</comment><comment><USER61> offtopic nitpick: I have a really nice widescreen monitor, and you are giving me 13 words per line using about a quarter of the horizontal space. Why is that?

<comment><USER62> For the same reason that broadsheet newspapers and magazines put the text in columns, I imagine. Because if you make text too wide it's hard to read.

<comment><USER63> How about letting the user make that call?

<comment><USER62> That is the sort of thinking that gave us the X Windows configuration file.

Nobody wants to make that call for most things in their life. Nobody has time. There is definitely a minority of people who do want to carefully size each browser window for optimal reading, but it is a pretty small minority.</comment></comment></comment></comment>


ScreenTime – movies from periodic OS X screenshots - <AUTHOR> http://seriot.ch/screentime/

<comment><USER2> Kinda of related, but not the same use-case it seems activated bursts versus my passive running.

Anyway. I'm doing something similar using cron, imagesnap and some ImageMagick [0]. It takes a screenshot, a webcam-snap and puts them together every hour into an image like this: [http://imgur.com/JjUK0Rb](http://imgur.com/JjUK0Rb)

I tried with only screenshots and only webcam at first but the context felt lost so this was the end result. Pretty fun to look back at every now and then. I've had it running for something like 4 months now.

[https://gist.github.com/jontelang/0147787432152508f455](https://gist.github.com/jontelang/0147787432152508f455)

</comment><comment><USER3> I wrote a program like this which is still in development... albeit a bit slow atm. [https://etopian.com/software/automatic-screenshots- windows-m...](https://etopian.com/software/automatic-screenshots-windows-mac- linux/)

</comment><comment><USER4> Looks interesting. Is there any video example of this?

</comment><comment><USER5> Similar tool for Windows: [http://timesnapper.com](http://timesnapper.com) by @secretGeek

<comment><USER6> Similar and open source tool for Windows: [http://getsharex.com/](http://getsharex.com/)

It has a bunch of features, but it includes auto capture (both full screen and region only)</comment></comment>


Why I Prefer Functional Components - <AUTHOR> http://reactingonrails.com/prefer-functional-components/ <comment><USER2> Functional components are clearly the superior style -- the readability advantage alone overrides pretty much everything else (compare reading an almost-declarative function vs having to grok a mini state machine).

People always get dragged back to class components because some things (interacting with browser APIs) have to, at some point, be handled statefully. Some of the comments on that article seem to confirm this mentality. However, the better response when you find yourself "needing" a class component is to implement the stateful logic you need as an HoC (which may internally create a class component.. or recompose's `lifecycle`). This is always possible and you'll thank yourself later when that stateful logic is trivially reusable, easier to compose and test, and separated from any application logic.</comment>


Detecting cold pools with a hyper-local weather network - <AUTHOR> http://understoryweather.com/understory-captures-evidence-of-temperature-inversion-in-kansas-city/

<comment><USER2> These plots are very difficult for me to read. I'm not sure why the color maps span 90F+ when discussing nighttime radiative cooling on the order of 12F. I'm also not sure how a regression line with a negative slope constitutes a "weak" temperature inversion -- it's not an inversion at all.

It would be interesting to see the station data integrated with an urban land cover map. Surface air temperature is sensitive to the locations of buildings, roads, soil type/water/ground cover, etc., not just elevation.</comment>


Huawei Arrest Tests China's Leaders as Fear and Anger Grip Elite - <AUTHOR> https://www.nytimes.com/2018/12/07/world/asia/huawei-arrest-china.html <comment><USER2> "During the Sino-U.S. trade war, let's not buy any American products and let's not travel to the United States," wrote another internet user.

\- NYTimes Journalism 2018 quoting internet trolls.</comment>


A new Linux kernel source code cross-referencer inspired by LXR - <AUTHOR> https://github.com/free-electrons/elixir <comment><USER2> Here it is running: [http://elixir.free- electrons.com/linux/v4.12-rc2/source](http://elixir.free- electrons.com/linux/v4.12-rc2/source)

It's nice, but I prefer [http://lingrok.org/](http://lingrok.org/). It's definitely easier to browse previous versions using Elixir, though.

<comment><AUTHOR> Yeah, OpenGrok is also an awesome cross reference engine. However, its installation steps are a little difficult, especially for some non-web developer. I once wanted to host OpenGrok on my VPS, but I finally gave up :)

</comment></comment><comment><USER3> I noticed the other day that free-electrons had swapped their interface to the new one. It's nice they decided to make it free software (using git on my local machine always has taken quite a long while -- so long that I wrote my own .git parser in shell so that it could efficiently generate my terminal prompt).

<comment><USER4> Oookay, we're going to need the gist of how you built that. That sounds cool.

<comment><USER3> It's quite crude, since all I needed was the current branch name and the hash. git internally does a bunch of cache warming and verification that make it slower, so I just don't do that. The code is in my dotfiles[1].

I've been meaning to update it to include more information but I really don't want to have to touch packfiles in shell.

[1]: [https://github.com/cyphar/dotfiles/blob/acbd9096a1daead80ba5...](https://github.com/cyphar/dotfiles/blob/acbd9096a1daead80ba50ebef3fa1b6fdb5a89a2/.zsh/prompt#L49-L153)

<comment><USER4> Thanks! Parsing git information without using git has always been mildly interesting to me :)

This is most definitely for zsh, FWIW; I choked slightly on `echo $var[1,12]` for a minute there. That's not a problem - you wrote this for your shell prompt, you use zsh, it makes sense to use zsh features - I'm just noting that others might need to do a bit of porting.

(I personally use bash by choice myself because it's the most widely installed shell and I don't want to switch until I fully know how to make the most concise and least surprising use of it.)

</comment></comment></comment></comment><comment><USER5> How does it compare to the other existing solutions? (LXR? LXRng? OpenGrok? I'm not an expert here)

Does it work for other code (not Linux kernel) too? What are the requirements? Would it e.g. work for SQLite? Lua?

</comment><comment><USER6> We've taken "Elixir" out of the title above because otherwise the thread will be about nothing but that.

How about we treat this as an exercise in community self-discipline and see if we can resist the name-bait? I know it's hard.

<comment><USER3> I don't understand, the project is _called_ Elixir. Isn't it against HN rules to editorialize titles -- I would assume "The Elixir Cross Referencer" is the valid title for such a submission.

<comment><USER7> There's a reason they're called _guidelines_ not _rules_ :)

We don't want them to be rigidly enforced for their own sake, we want them to help cultivate more interesting discussions.

So, when a case arises in which the original title causes a discussion to be bad (e.g., it is becoming dominated by off-topic discussion of the fact that the project's name causes it to be mistaken for an established project that's already well known to the community), that surely warrants a deviation from the guidelines, no?

</comment></comment></comment><comment><USER8> Name collisions really should be getting less common, not more, given how easy it is to search things today.

<comment><USER9> There are only so many words in the language.

<comment><USER8> If by so many, you mean more than 170,000 in active use, plus all the puns, plays on words, or portmanteaus which don't qualify as words but can easily be the name of a software project.

<comment><USER10> And there are 10 million Github repos out there!

So yeah... we're running out. ;)

<comment><AUTHOR> Maybe we have to concatenate some words and create a new word which doesn't exist in English dictionary to get a unique project name :)</comment></comment></comment></comment></comment>


Boom Wants to Bring Supersonic Civilian Travel Back - <AUTHOR> http://www.bloomberg.com/news/articles/2016-03-21/this-aerospace-company-wants-to-bring-supersonic-civilian-travel-back <comment><USER2> For my current flight patterns, I typically spend more time off the plane than flying. Showing up early, dropping baggage, customs/security, waiting at the gate, inefficiently loading the plane, pre-flight checks, taxiing (on/off runways), getting my baggage.

Each of those points could be much more efficient:

1.) Prescreen me for all things so that I exit the uber and walk upto the gate directly 2.) Let me print my own baggage tag at home and drop it at the gate when I arrive 3.) Dont let cheap idiots bring on carry on baggage and take up 200 ppl's time trying to jam it into an overhead bin 4.) Dont make me sit on the plane until absolutely ready, with a runway slot ready to go 5.) When I get off the plane, hand my luggage directly to me instead of making me wander around an airport looking for a terribly slow conveyor belt to eventually get my bag

I presume all of the above doesnt happen because, at the end of the day, there aren't sufficient travelers willing to pay the cost of implementation.

<comment><USER3> _5.) When I get off the plane, hand my luggage directly to me instead of making me wander around an airport looking for a terribly slow conveyor belt to eventually get my bag_

It turns out that this has been studied quite a bit. You need to walk halfway across the airport because it reduces the amount of time you eventually stand staring at the belt waiting for your bag, and most people prefer "occupied time" (e.g., walking halfway across the airport) to "unoccupied time" (e.g., waiting at a baggage claim right next to the flight).

[http://www.nytimes.com/2012/08/19/opinion/sunday/why- waiting...](http://www.nytimes.com/2012/08/19/opinion/sunday/why-waiting-in- line-is-torture.html?_r=0)

<comment><USER4> Sure, but the point is you could, in theory, redesign both plane's cargo holds, and airport systems, so that the moment you get out of the plane (or within 2 min tops of docking) your bag is there in a square of the floor labeled with your name and sorted alphabetically. Of course, doing so might not be cost effective, but I bet it remains cheaper than supersonic flight.

<comment><USER5> In what theory? How would you actually go about accomplishing this? I'm sure the airlines would very much like to know how to unload a full plane's worth of cargo in 2 minutes.

<comment><USER6> they actually built systems for this but it has never been implemented. Basically you make the cargo hold completely removable from the plane. There is a box that slides in and out of the bottom of the plane. Someone just drives up with a fork lift style vehicle pops off the container and takes it inside the terminal where it can be dumped out onto the conveyor belt. I am surprised they have not automated the entire baggage system. It seems like it would be feasible to automate just about everything. You know where the plane is going to park every single time just fix that position and have something under it which can directly attach to the plane and pull the bags off and conveyor them under the ground and into the terminal and it can auto sort the bags to the right destination. It would not be easy to build but it is doable and would remove the need of large percentage of workers in the airport

</comment></comment></comment></comment></comment><comment><USER7> Supersonic aircraft projects have come and gone over the years. They usually dwindle away into oblivion.

The only company that I would take seriosly right now is Aerion ([http://www.aerionsupersonic.com/](http://www.aerionsupersonic.com/)). They are working on a supersonic private jet (12 passengers). They already have quite a few orders (notably 20 jets for Flexjet, 120 Mil a piece) and a cooperation with Airbus, who is apparently helping them. Probably in exchange for their drag reducing "laminar flow" technology.

Building a new aircraft is a huge undertaking, both in terms of technical challenges, financing and organization. A supersonic one even more so.

I'd love to be proven wrong, but this doesn't sound too promising.

<comment><USER8> All the same FUD spoken during the early days of SpaceX. It was correct in most cases; Bigelow, Blue Origin, Xcor are floundering, SpaceX is the exception. I just hope we have more entrants in this industry to increase the odds of success.

<comment><USER9> Space access never had the cost pressures of passenger air transport. It's not much easier than what Virgin Galactic is trying to do.

</comment></comment></comment><comment><USER10> One of the issues with airplanes in general but especially with the Concorde at high altitude was radiation [1][2]. Would a carbon-fiber plane protect better or worse than an aluminum plane? My intuition tells me that aluminum is much better at shielding from radiation than carbon-fiber.

The Concorde was flying between 45,000 and a maximum altitude of 60,000 feet. If Boom flies at 60,000 feet, radiation is also going to be a bigger issue. I'm curious how the engineers are planning to address this.

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

[2] [http://www.nasa.gov/topics/earth/features/AGU- NAIRAS.html](http://www.nasa.gov/topics/earth/features/AGU-NAIRAS.html)

<comment><USER11> They aren't going to address it because it isn't an actual problem that needs to be addressed. You have far, far more to worry about with radon gas seeping up through cracks in your own home's foundation than a trivially-higher amount of cosmic radiation plinking you for 2-3 hours. BTW, it's the density of a material which offers radiation protection, not solely whether it's a metal or not.

<comment><USER12> I disagree. Concord crew surpassed US and EU regulations for allowed dosages (see my post above). Different materials have different attenuation lengths. So it isn't just density. Especially if we get into the whole neutron problem. But I'm keeping this brief: materials make a huge difference.

</comment></comment></comment><comment><USER13> _"The people we talked to looked over our plan and concluded it is technically feasible," he says. "This is not science fiction."_

There is a big difference between being not Sci-Fi and being economically feasible. Though arguably, there is a subset of Sci-Fi that also includes social science ideas.

 _"You kind of design a plane around an engine rather than the other way around," Aboulafia says. "Let me know when we can hear their engine."_

</comment><comment><USER14> For more info, here's the previous thread about Boom which is a Ycombinator company. [https://news.ycombinator.com/item?id=11329286](https://news.ycombinator.com/item?id=11329286)

</comment><comment><USER15> A 40 seater is only slightly bigger than say, a Dassault Falcon. Dassault has been building supersonic jets for 60 years; they certainly know how to build a supersonic private jet, but they never actually tried it. Apparently, there are no suitable engines available (tough problem). And is there a market?

<comment><USER11> There are tons of suitable engines and engine designs. The big problem is: Who would buy it? No manufacturer in the already niche, thin-margined, and overstocked business/charter jet market is going to be the first penguin off the iceberg to find that out. Even with a new subsonic model, one flop can mean a rapid financial death for the company.

There are plenty of other considerations outside of the factory floor and design rooms to consider - operating costs, the availability of qualified A&Ps to fix the thing, the parts network, the cost of the parts (if you buy a $15M plane, you're going to pay $15M plane prices for spares and overhauls). Insurance will surely take their pound of flesh for something that's A) a company's first product B) a new category, and C) supersonic. Finally, with the general public being decidedly anti-aviation, the noise profile of this plane might very well limit where it can fly in and out of. It's a basic matter of aeodynamics, and the same problem that the Concorde experienced almost 50 years ago.

</comment></comment><comment><USER16> I would love to see domestic super sonic air travel. Sadly I don't think it will ever come to be.

[https://en.m.wikipedia.org/wiki/Oklahoma_City_sonic_boom_tes...](https://en.m.wikipedia.org/wiki/Oklahoma_City_sonic_boom_tests)

For international flights the technology is more than proven. It's purely a market problem. I wish the boom teem well.

<comment><USER5> It's still a long way off, but we are working on building quieter supersonic planes [1]. I think we will almost certainly see the return of international supersonics first, but never is a very long time.

[1]: [http://www.nasa.gov/press-release/nasa-begins-work-to- build-...](http://www.nasa.gov/press-release/nasa-begins-work-to-build-a- quieter-supersonic-passenger-jet)

</comment></comment><comment><USER17> I've said it before: don't call your airline company "Boom". Just don't do it. It's like calling your shipping company "Wash", or car company "Impact". You're just asking for the headlines.

Plus anyone in the airport discussing your company will be invited for some enhanced screening.

</comment><comment><USER18> Well since they're a y-combinator company maybe they'll build a working model and be bought out as so many startups are. With a working model in hand I could see BAC or Boeing saying "Great work, now let us show you how to get them through FAA's ETOPS certification and build 100 a year."

</comment><comment><USER19> I find it weird that they didn't mention the name of the UK airline in the article. When they launched around Demo Day it was all over the news that it was Virgin & Richard Branson, and all of those articles are still online.

</comment><comment><USER20> What is the carbon footprint of supersonic flight vs. subsonic flight?

<comment><USER21> Per wikipedia the Concorde and 707 are vaguely similar size and the Concorde successfully pulled off 15 passenger miles/gallon and the 707 got about 30 passenger miles/gallon around the same time.

Now JetA isn't service station gas so its slightly unfair to compare the 15 pMPG of a Concorde to a 12 MPG single passenger pickup truck. But it does give you a general idea that everything being equal (size, technology level, risk?) the supersonic plane will burn about twice the carbon footprint of a similar subsonic plane.

Note that with a full modern subsonic plane its quite easy to get a carbon footprint staggeringly better than a single driver in an obese modern SUV or truck. The problem is if you're fair and let the aircraft people use any thing they want such as 2016 technology and engineering, you have to let the car people use any thing they want, and my wife's Prius is trivially capable of providing reasonable comfort at 300 passenger miles per gallon.

Supposedly the largest 777 model does better than 70 pMPG per my commercial pilot buddy (who teased me quite a bit about my wife's Prius only getting 60 pMPG when there's only one passenger, so he burns less gas flying than she does driving). So everything being equal if stereotypical subsonic planes have roughly doubled in pMPG then its not ridiculous to expect over 30 pMPG on a modern supersonic plane. My Yaris commuter car struggles to get 30 pMPG with a single passenger (me) so to a first approximation a modern supersonic aircraft damages the environment about as much as driving alone in my subcompact commuter car. Not great, not awful. Eh.

Obviously my car's performance in transatlantic and transpacific service is somewhat inferior to the performance of the proposed plane.

<comment><USER22> Well, technically Prius would have 300-ish pMPG. If a pilot was the only person in the plane, it's pMPG would be much much worse. Even better comparison would be a shuttle bus pMPG..

<comment><USER23> But that depends on how it's typically operated. Nobody uses an airliner as a one-person transport, but unfortunately many people use a Prius that way.

<comment><USER22> On average, airplanes are not used to 100% capacity either. Some flights are oversold, some are half-empty. Sometimes they're almost empty. Cars frequently are occupied by 2 or more people, sometimes they are full too.

I never saw any hard statistics, but it's definitely not cars 90% 1 occupant, planes always near-full. It's anecdotal evidence for sure, but my car is, on average, as full as average plane I took. Especially if we count per-mile rather than per-trip.

<comment><USER21> Things also get weird with air cargo. My pilot buddy says they fill the cargo area and aircraft to the weight or volume limit pretty much every flight he takes. He may fly for a weird carrier or on weird routes, but it sounds believable that there is infinite supply of "I wanna get there faster" cargo. You might see ten empty seats but merely means there's a one ton MRI thingie that's on emergency shipment in the cargo area. He mentioned they're really into containerization and a small container alone costs $200 so I am almost scared to ask how much it costs to actually ship it. Then again everything aerospace rated costs a hundred times more, so a $2 isn't so ridiculous.

Aacargo.com division of american airlines proudly advertises they ship 100 million pounds of cargo per week, and also advertise they have 6000 flights per day so thats averaging about a ton of cargo on every flight and a ton represents maybe ten empty passenger seats, so your average flight should have ten empty seats. Of course reality is the seats might be near empty at midnight and 100% full during the day, etc.

</comment></comment></comment></comment></comment></comment><comment><USER24> So assuming they are get this to be feasible it seems like their model is that their are enough business travelers who are willing to forgo comfort for a slightly faster trip. My instinct is that no, they would rather have the comfort of a larger plane, but as I'm not an international business traveler I could very well be mistaken.

<comment><USER25> International flights can be brutally long. Los Angeles to Amsterdam is like 14 hours. I could definitely see a market for this.

<comment><USER24> But are they very brutal when you are in a nice big comfortable business class seat with room to stretch, more privacy, space to work, and a drink?

<comment><USER26> I do LAX-DOH every couple of months. It's 16 hours each way, and regardless of class flown it is hell.

Cut it down to five hours, and I'll gladly pay $5000 for a round trip ticket.

</comment></comment></comment></comment><comment><USER9> Everyone here would like to bring supersonic civilian travel back. That doesn't mean it's feasible.

Building an economically attractive passenger plane is the first part. Then it'll need to be certified. At some point, it'll have to be sold for profit.

I genuinely wish them good luck. They chose a formidable challenge.

</comment><comment><USER27> Then they ought to change their name. People are already afraid of flying and even more so at supersonic speed.

</comment><comment><USER26> The name is something I don't necessarily want to associate with an airplane.

<comment><USER28> It's a clever name, drawing on two of the three related meanings for Boom. But yeah, the first bad press will jump on that one.

</comment></comment><comment><USER29> I would expect organizations to pop up protesting the noise, similar to Concorde.

</comment><comment><USER30> Hm, I wonder if Boom Technology's SST or Moeller's Air Car will hit the market first?

</comment><comment><USER31> Propose submission title change to "Boom Technology" instead of "This Aerospace Company".

<comment><USER32> Old title: clear what kind of company was pushing supersonic air travel, but unclear which company in particular was doing it.

Proposed title change: clear which company was pushing supersonic air travel, but unclear what kind of company it is.

Actual title change: unclear that a company is involved at all. What is "Boom"? Do they just mean that a general economic boom is going to bring supersonic air travel back?

<comment><USER31> I feel "aerospace company" might be implied by the fact they're working to bring back civi supersonic travel. I suppose it could be "just" an advocacy group.

</comment></comment></comment><comment><USER33> This company appears to consist of software engineers playing dress-up. There is no reason to expect them to succeed, and no market need that they are serving.

Edit: I have worked on several teams in the past where the leadership consisted of people who "don't know what can't be done". They hire a bunch of domain experts, then ignore and/or contradict them until the company runs out of money.

<comment><USER34> From the article: "Today, Boom has 11 people, six of them pilots... Unlike Scholl, these folks have serious industry bona fides. Joe Wilding, the co- founder and chief engineer, was a standout at three aerospace startups, designing passenger planes from scratch. Andy Berryann, the head of propulsion, used to work at Pratt & Whitney, building parts of the engine for a supersonic fighter jet. Other employees came from NASA, Lockheed Martin, and a Northrop Grumman subsidiary, Scaled Composites."

<comment><USER35> I am pretty sure they know how to design (and maybe build) airplanes. This will not automatically mean they will be good at selling them, or build a business around them.

<comment><USER36> Isn't that the whole point of YCombinator?</comment></comment></comment></comment>


Understanding the Shadowban – Instagram Blocked Account from Hashtag Searches - <AUTHOR> https://www.thingsinsquares.com/blog/instagram-blocked-my-account-hashtag-searches/ <comment><USER2> The guy writing the tutorial on shadowbans doesn't even know if he's shadowbanned.

>Another way is to use this here Shadowban Analyzer (open it in an incognito window). It will test to see if your posts show up for #hashtags cited within their respective captions. (UPDATE: this tool indicates I'm not shadowbanned, which greatly complicates my understanding of what's happening, since I know that my following still does not growing):</comment>


How I landed an awesome career in tech with zero experience - <AUTHOR> https://medium.com/@christiehunter/how-i-landed-an-awesome-career-in-tech-with-zero-experience-695987df9dad <comment><USER2> Tldr: have daddy do it. Also, internship.

I get your motivation for writing. But landing a tech job with no skills because family had an existing business relationship with the company is not helpful to others.</comment>