I deploy, therefore I am - <AUTHOR> https://www.sleuth.io/post/i-deploy-therefore-i-am <comment><USER2> I really wish people would stop trying to reduce software development to simple metrics. Number of deploys is as meaningless as lines of code or number of story points as a metric for judging people's performance.

<comment><USER3> It does indicate a culture where there aren't massive barriers to getting changes in.

I worked at one startup on the AI team, and we were allowed to deploy at will, we iterated constantly, pushed multi times a day, and had a flat hierarchy. We weren't under the political umbrella of the engineering and product groups. It was definitely risky but no major issues ever came from it and we gained the trust of DevOps team and our CTO.

The back end team, different managers, was very hierarchical, had to schedule deploys well in advance and inside certain time windows, and non technical engineering managers would monitor and send summary emails to everyone after each deploy.

Guess what, that back end team sucked. Their timelines for features were embarrassingly long, they watched the clock, their managers loved to booze, they overcomplicated the architecture and never produced anything innovative for the company.

Deploys can signal culture.

<comment><USER4> _Deploys can signal culture._

I worked at a company that deployed multiple times a day too. There were no automated tests and the QA process was terrible, so most of the deploys were bug fixes.

Deploys can signal culture, but not always in a good way.

</comment></comment></comment><comment><USER5> When number of deployments becomes an evaluation metrics, I can imagine an engineering culture like this:

\- Dev rushes to make merge requests with the cost of thoughtful design and testing.

\- Tension around code review turnaround time: how dare you take hours to review my code when I'm far behind in the leader board.

\- Deployment has a bug? Awesome, now I'll have 2 deployments.

\- Deploy faster and break everything.

Frequent and continuous deployment is good. Making it a metrics is bad.

<comment><USER6> [https://en.wikipedia.org/wiki/Goodhart%27s_law](https://en.wikipedia.org/wiki/Goodhart%27s_law)

</comment></comment><comment><USER7> So if I deploy one critical, long-term project this month and my coworkers deploy around ten each say, how does this system know that the one thing I deployed was actually more valuable and impactful than all those little deploys? Or do I need to deploy the unfinished work in progress constantly to keep up the metrics because this is just another useless measure like lines of code or commits?

<comment><AUTHOR> Assuming your project supported continuous development, I'd probably say you should break that project up into multiple deployments, ideally hidden behind a flag and each easily revertable. This would reduce the risk of each step and hopefully eliminate a whole host of potential incidents.

<comment><USER8> How does code hidden behind a flag become less risky if it's deployed in increments?

You will only find out when you allow it to run.

<comment><AUTHOR> Well, for example, say you were adding a new preference page. First, I'd do a deploy of the new database table(s), even though they aren't used. Then, I'd add a link to the page in the UI and put that behind a flag, maybe with a small non-functional UI so that the designer could play with it. Then, I'd implement the basic functionality and open it up to my team to start playing with it. Then, I'd ship other deploys for things like tests, more edge cases, UI tweaks, etc.

At some point in there, I'd open that page up to my beta customers, trial customers, or whoever is less risk-adverse. Once I'm happy with it, I'd do a percentage rollout to ensure any issues don't affect all customers at once. Just an example, but the idea is to reduce risk of each step and make each step easily reversable/hidden if something comes up.

</comment></comment></comment></comment><comment><USER9> There's a reason the execs thinks in terms of revenue, cost, and profit. Why would you want your engineers, designers, or anyone abstracted away from that? From my experience, every time you try to do that you end up with the business and the workforce misaligned.

It's not always easy to quantify value, and sometimes the return on an investment is slow and that can be unattractive. However, that doesn't mean we should try and hide away from figuring out the true value of work in business terms.

In my opinion, we should judge the impact and effectiveness on the base line metrics as the rest of the org. In a for profit company that's measures such as increasing customer spend, increasing conversion rates, reducing churn, reducing operational costs. All of those measures can be directly tied to revenue, costs, and profit. It's the language the business speaks, why would you want to speak a different language to the rest of the business? More than that, why would you want to start measuring performance in a different way to the rest of the business?

<comment><USER10> Because, although it oughtn't, the culture that way of thinking produces some of the worst code because it's more difficult to quantify the direct value of a lot of the work that goes into good software engineering.

Security ends up just being a cost, nobody bothers to actually quantify the risk because nobody really knows. This leads down the path of "the only security that's quantifiable are my legal requirements."

You can't know the productivity gains/losses from a refactor until long after you've done it.

You can't know how productive different ecosystems are until long after your team adopted them. Your only measuring stick is how excited your devs are to use it. What's productive for one team might not be for another.

Nobody quantifies acquiring tech debt so it piles up while people "deliver" and the productivity losses come so gradually from it that teams don't even realize they've slowed down because their velocity says constant it's just that cards gradually get more difficult.

Performance becomes a cost because there's a huge grey area (Jira) between "so slow I consider it down" and "general annoyance that slowly nudges me away from the product." Unless you're planet scale or whatever your sample size isn't big enough to notice these things.

This way of thinking creates feature factories.

I agree 100% that we can do better than being totally disconnected from the business but this ends up being so much worse.

<comment><USER9> I do not disagree that it's really tough to quantify a lot of those things and most of them will be estimates and may be wrong, in particular over longer periods of time. But in the context of the article (a larger business with profit generating goals) I don't think you can walk up to management and say "lets switch technology, we're excited about this new thing" and expect to be taken seriously.

It's not dissimilar for security and code quality, they are just part of doing the job properly. They're also part of continually identifiying future business risk. If you find a vulnerability you can absolutely identify the risk of leaving it there, just like you can identify the level of risk of not thinking about it up front with a feature.

We absolutely can provide estimates to backup why we should tackle some tech debt, it may not be incredibly accurate but if you're unable to estimate any gain from tackling it, is it really a problem? When you see a security issue you've got legal risk and brand reputation risk. Both of those are very tangible, while they're not easy to estimate and there's a lot of room for error I don't know many businesses that would rather take the risk of EU data breach fines vs paying an engineer to spend a few days fixing it.

That doesn't lead to feature factories, it leads to informed decisions. Sometimes the business is going to choose to take on the risk of slower development in an area if they think they're unlikely to revisit it vs doing a refactor. Sometimes they may also take on a risk of security issues if they feel it's outside of their threat model. It's up to us as product/engineering teams to give a clear picture and side our professional advice in a way they can understand. In many cases we may need to push to do a refactor or learn a new technology, but we can't expect to persuade someone while we're speaking a different language to them. Saying that they're only interested in business value and that makes them a "feature factory" doesn't make sense in that regard.

Perhaps the business and leadership really enjoy the taste of risk, and if that's the case then trying to qualify value in some other language still won't help. There we have a larger problem with the practices of the leadership and company as a whole.

I agree that the areas you've mentioned are ones where it's hard to qualify value in terms the business understands, but it doesn't mean the system is broken. It's the language used to describe the goals of the organisation. If you're lucky enough to work in a company which places a goal as team happiness as well then you can also speak in those terms in some cases. However, in the context of the article (Atlassian) I struggle to understand why a team lead would try to abstract away the core business value a team is generating. A team leader should be rushing to quantify it as accurately and clearly as possible to give the team a leg up in the orgs career ladder.

</comment></comment></comment><comment><USER11> That scoreboard sounds particularly toxic.

<comment><USER12> Pure garbage. I still can't believe they actually think this is a good idea. That honestly is once of the worst metrics I've ever seen.

</comment></comment><comment><USER13> Reminds me of when my team at bigcorp noticed that you got given a badge on your personal page for being quick to respond to code reviews. Cut to suddenly every code review being immediately responded to with the comment "got it, will review soon".

That said, it really did change the team's behaviour. Code reviews became a priority instead of something left to batch up and do later. Whether that was a positive change or not it's hard to imagine an edict from management achieving the same result.

<comment><USER14> Yep, +1 from me.

They put a PR reviews scoreboard on the TV that displayed a random metrics dashboard and we immediately started teasing each other about it and did more PR reviews as a consequence.

We liked it because it wasn't seen by anyone else apart from engineers taking a coffee break. Many people ignored it and noone thought less of them. If they told me a part of my bonus would be tied to my PR high score, I would be seriously demotivated.

But all in all - I think that just proves gamification works. What you're using it for is what matters in the end.

</comment></comment><comment><USER15> So what happens if I'm working on a feature that I can't deploy in small chunks meaning I make fewer but larger commits and deploys? Even if I'm deploying good work by this system I'm ranked less than my co-workers by the nature of the work.

So now according to the companies public ranking system that is viewable to my bosses and coworkers, I look much worse than everyone else and the nature of the work keeps me in that situation.

Instead of feeling motivated, I'd go into the office every day feeling like crap because I'm doing my job and being told I'm less than my coworkers for it.

But hey, so long as we "move fast and break things" who cares right?

<comment><USER16> So you pick less complex stuff and look good and get promoted.

Or you do more complex stuff. No one else will want to do that so you become an expert in certain area and are above the leaderboard in a way. You answer to no one.

Or you get on the committee who decides these items and you push for a multipler for complexity.

Or you hack it.

</comment></comment><comment><USER17> I really despise this kind of 'pointed-her' writing style. It was popular in some older academic texts, and seems to be gaining popularity in blogs and the like in recent years. I have never written a sentence about a generic 'boss' as 'boss asks blah what do you tell _him_ ', nor was I taught it, nor would I expect to read it.

The genderless generic has always been 'they/them', it doesn't require positive action, nor discourse about a hypothetical generic's 'self'-identified pronoun. It has always been third-person, since long before anybody gave a shit.

<comment><USER18> Wow, I guess you must feel compelled to call out unnecessary male gendering all the time!

<comment><USER17> As I said, I consider them both incorrect.

Perhaps it's wrong, but much like incorrect use of 'I' vs. 'me', one annoys me more because, rightly or wrongly, it reads to me more like deliberate thought/effort went into it; that the author thought they were getting it right.

I should also say I don't object to gendering _specific_ hypothetical/imagined characters in a story-telling sort of way - 'let's say Sally is a software engineering manager, and her direct report Bob ...' \- but the generic case should always be third-person, even if interspersed with such story-telling.

<comment><USER18> I actually agree with you that the singular they should be used instead of any gendered pronoun, but I think your focus on only female pronouns is (very mildly and probably unintentionally) sexist, similar to how applying law enforcement unevenly can be racist.

<comment><USER17> Like I said, it just 'perhaps wrongly' stands out more.

I have said the same thing in threads where people are arguing over whether or not an author's sexist for saying 'him' or something though. Particularly on HN those cases are more likely to draw other top-level complaints from a political or societal perspective, I don't care about that, I just think it's annoying and bad grammar.

</comment></comment></comment></comment></comment><comment><USER19> Focusing efforts on smaller+faster deploys (along with some measure of deploy quality to weigh those deploys) seems like a far better indicator of a team's velocity than simply tickets closed.

<comment><AUTHOR> Exactly. Agreed to all the comments that trying to find a simple metric for developer productivity is futile, but there is value in encouraging people to ship more often, and in doing so, ship smaller things that generally have less risk. Also, ownership is key here as the person writing the code should be the one that pushes it to production and owns its impacts, as I've found this results in higher quality, more sense of ownership, and quicker incident response and frequency reduction.

</comment></comment><comment><USER20> As other people have specified in this thread, the underlying problem is Goodhart's Law, i.e. these performance tracking systems break down when pressure is applied to them.

<comment><USER21> There's a difference between "measurement will fail when there is poor management" and "measurement will always fail".

But having said that, a _leaderboard_ seems like a handing out poor management tokens.

<comment><USER12> I don't understand your point. It's not the measurement itself that is the failure. It's making that measurement a goal that's the problem. The real metric that matters for any company is profit. Anything else is just an arbitrary measurement that is believed to help achieve that goal. The metric of profit is also gamed which is why a lot of people and companies do shady things.

</comment></comment></comment><comment><USER22> Wait, what?

> It didn't matter [...] what tickets I closed, only whether I fixed that bug > that was bothering that one big customer

That's what "closing the ticket" means, right? You close the ticket when the bug is fixed. This is what matters.

The deployments are much more roundabout metric -- maybe you fix 5 bugs with one deployment, or maybe your bugfix is big, so you had to deploy schema change first. Only JIRA tickets (of the right type/severity of course) show the business impact.

</comment><comment><USER23> They sell CI tooling, they blog about CI tooling, what Jenkins just isn't cool anymore.</comment>


Inside Bill Browder's War Against Putin - <AUTHOR> https://www.vanityfair.com/news/2018/11/bill-browder-war-against-putin <comment><USER2> I recommend Bill Browder's book for a further backstory about how all of this came about. If you can get over the self-aggrandizing language, it's a really interesting perspective on business dealings amongst the elites in Russia.

[https://www.amazon.com/Red-Notice-Finance-Murder- Justice/dp/...](https://www.amazon.com/Red-Notice-Finance-Murder- Justice/dp/1476755744)

</comment><comment><USER3> Ah yes, Bill Browder, man who made his fortune making investments in Russia in the 1990s. Absolutely the sort of background that merits uncritical extolment in the prestige press. A likelier champion of freedom and justice you will not find.

<comment><USER4> Wow, a lot of snark for someone who literally has put his own life on the line to fight against the corruption that defines the Putin regime. But, easy to criticize from afar, I suppose.

The Magnitsky act is needed and brave, and would not exist w/o Browder. Can the dude get a little respect for that, at least?

<comment><USER3> Yes, it is possible that Browder is a noble soul, a "CEO turned human rights activist" tirelessly campaigning against corruption.

I think we (or more importantly, the press) should at least entertain the possibility that Browder's Yeltsin-era investments and subsequent financial arrangements in Russia were not entirely virtuous and that the Magnitsky Act sanctions are more about greed than concern for human rights.

<comment><USER5> > Browder's Yeltsin-era investments and subsequent financial arrangements in > Russia were not entirely virtuous

Even if they're completely non-virtuous, how that can justify stealing from him and attempts to jail him?

</comment></comment></comment></comment><comment><USER6> Not one mention of the movie - by the top anti-Putin Russian director - "the magnitsky files"

It took me two years to find a bootleg copy of it, thanks to Bill Browders efforts to bury that film.

(Before anyone asks, yes I am a Putin-bot working in a Moscow farm. Now go watch the f _%_ %ing movie)

<comment><USER7> Perhaps you could provide some more detail so others might be able to find it as well? For that matter, what's the name of the director? I'm assuming you are _not_ referring to "The Magnitsky Act. Behind the Scenes"[0], right?

[0] [https://www.imdb.com/title/tt6028446](https://www.imdb.com/title/tt6028446)

<comment><USER8> I think that is what the top commenter is referring to, see the story here: [0]

[0] [https://consortiumnews.com/2017/10/28/guardians-of-the- magni...](https://consortiumnews.com/2017/10/28/guardians-of-the-magnitsky- myth/)</comment></comment></comment>


Nationwide Blackout in Kenya Caused by Marauding Monkey - <AUTHOR> http://arstechnica.com/business/2016/06/nationwide-blackout-in-kenya-caused-by-marauding-monkey/ <comment><USER2> >> The company apologised for the "isolated incident" and said that it's "looking at ways of further enhancing security at all our power plants."

How about designing the system so that it doesn't have a single point of failure?</comment>


Crockford on Bootstrap's semicolon omission: "insanely stupid code" - <AUTHOR> https://github.com/twitter/bootstrap/issues/3057 <comment><USER3> There's something horribly wrong with everything about this. Why is such a smart person as Crockford wasting his time arguing about semicolons in 2012? Why is this at the top of the most popular hacker website? Why are people writing detailed opinions about semicolons in this thread (with surely more to come?)

One would hope that at least over time the bike sheds being argued about would start to at least evolve into arguments about bike garages and eventually bike factories. But I guess the bike shed is forever a bike shed, as long as we're making bikes.

Whatever the next disruption is in software engineering, please dear God let it be immune-by-design to this type of distraction.

<comment><USER4> Jacob ("fat") comes off looking far worse than Crockford, to my eyes (and that Kit character seems to be 7 years old). It's the arrogance and stupidity of youth facing the crotchety crankiness of experience. Crockford has earned the right to have a strong opinion here IMO.

But it's not just bike-shedding. It's more pernicious than that. It's actually something that _looks_ like bike-shedding to uninformed observers, but something that strongly affects cross-version compatibility. Javascript does automatic semicolon insertion by taking advantage of potentially ambiguous constructs that happen to be resolved in one way right now. But they may be actually ambiguous in the future - in the case where a unary prefix operator becomes a binary operator. Language extension usually works this way: a previously unambiguously wrong statement is made valid; but JS semicolon insertion often turns "wrong" statements into "correct" statements, so it leaves less "entropy" to be taken advantage of when increasing the power of the syntax. I think there's a strong case for JS to _not_ insert semicolons here, and I agree with Crockford's position on not handling it in JSMin. It's the right thing to do.

<comment><USER5> I have never written a line of JS in my life, which hopefully qualifies me as an unbiased outsider, but I don't agree that that Crockford's position here on JSMin is the right thing to do.

Here is what I see:

@fat is not inserting "!" needlessly as a statement separator. The "!" is there for its proper purpose, as a "unary not" operation, which will short circuit the second operand of the "&&" when isActive is false.

Given that, @fat has left out a semicolon in a way that is perfectly legitimate based on this language specification, at least as described in the 5.1 version linked from here: <http://inimino.org/~inimino/blog/javascript_semicolons>).

Could @fat have written the code differently so that he would have been required to include the ";"? Perhaps -- but I don't see why that counterfactual has any particular bearing here.

Crockford's own page on JSMin <[http://www.crockford.com/javascript/jsmin.html>](http://www.crockford.com/javascript/jsmin.html>); claims: "JSMin is a filter that omits or modifies some characters. This does not change the behavior of the program that it is minifying."

The fact is that @fat's code is legal code and JSMin is breaking it.

IMHO, Crockford is ignoring the technical matters at hand. @fat cannot be faulted for writing code that complies with the specification and for having a reasonable expectation that code minimizers will preserve the semantics of his legal code. Crockford (and others) may wish that the language specification did not include automatic semicolon insertion because it does hamper making changes in the language without breaking existing code -- but that does not make this piece of code "insanely stupid".

Yes, forward progress on the language would be better served if automatic semicolon insertion rules weren't in the specification. However, calling one particular piece of code that leverages those rules "insanely stupid" and refusing to acknowledge that JSMin is in fact breaking the semantics of the code is not productive. Refusing to fix this in JSMin does not somehow make the problem with the specification to go away.

<comment><USER6> Here is what you're missing.

Language lawyering is fine and dandy when you know exactly which compiler will be used and you know exactly how it works.

But on the web that isn't the case. You can write code, but you have no control over what browsers, past, present and future, it will get run on. And it is your responsibility to make that work. According to the spec, you may be right. But in practice you're the one who is wrong, because you're the one whose job it is to make your code work across browsers and future versions of the spec.

<comment><USER7> Crockford is releasing a tool which is compatible with his opinions, not with JavaScript. All browsers execute that code fine, present and past, and at least for the next decade or so.

Crockford can be an arrogant ass about this stuff, that's why jshint exists, because not agreeing with Crockford does not mean bad JavaScript, no matter what he would have you believe

<comment><USER8> It's about JSMin, not JSLint. Crockford has actually several products ;-) And JSMin is IMHO not really opinionated.

</comment></comment></comment></comment></comment></comment><comment><USER9> Jacob is an idiot for writing code with a ridiculous fragile syntax that takes _more effort to write_ in a vain effort to obtain "coolness" via winning a pointless language war that nobody on earth cares about.

Crockford is an idiot for writing an JS minifier which explicitly promises to _not_ break legal code but actually does, and then refusing to fix it because he's proud of his reputation for being an asshole.

And everyone commenting on this post is an idiot for thinking that any of this is worth the pixels it takes to argue about it. And yes, that includes me.

 _sigh_ This whole thing just makes my head hurt.

<comment><USER10> > a pointless language war that nobody on earth cares about.

The comment section disagrees with you. He's just _writing his damn code the way he wants to_ , which a large number of people seem to care about.

</comment></comment><comment><USER11> I'm new to JavaScript, but from what I can tell, the no-semicolons style

\- is incompatible with existing tools

\- is incompatible in places with upcoming versions of JavaScript

\- is harder to refactor, since you might need to add additional tokens to the beginning of lines depending on the previous lines

\- is confusing to new JavaScript programmers, since

      + it goes against the recommendations of many of the most popular books

      + it requires adding tokens to the _beginning_ of lines in places, making the entire enterprise more challenging to learn and of dubious utility

      + it discards one of the attractive qualities of JavaScript for programmers of other languages: familiar syntax

And further, the use of constructs like

        !somethingHappened && otherwiseDo(x)

instead of

        if (!somethingHappened) {
            otherwiseDo(x)
        }

is bad practice in any language.

"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" \- Brian Kernighan, "The Elements of Programming Style"

Although everyone has the right to maintain their projects with whichever style they prefer, given the above, I wonder why the chosen style was chosen.

<comment><USER12> Actually constructs like:

        somethingHappened or otherwiseDo(x)

used to be idiomatic perl (and might well still be for all I know).

Edit: Just for amusement it would probably be:

        somethingHappened not { x otherwiseDo } if

in PostScript

<comment><USER13> And would allow for constructions like

      open FILE, "filename.txt" or die

Which is nice enough to read (and can be seen in actual examples around the web: <http://www.perlfect.com/articles/perlfile.shtml> )

The semicolon wars frustrate me. We have an arbiter of what's correct/valid syntax and what isn't. It's the freaking lexer, heaping additional prescriptivism on top for something as trivial as semicolons is irritating. If your code has ambiguity problems, fix it by writing unambiguous code. Semicolons are not the only way.

</comment></comment></comment><comment><USER14> Frankly this is less about semicolons and more about two people who both have strong opinions and feel that they need to act in a certain way.

It doesn't take a lot more effort to rephrase fat's response to be more cordial.

        "Hi @englishextra, those two lines are valid JavaScript. We try not to use semicolons whey they aren't necessary.  See (insert link to the wiki).

        "JSMin doesn't perform well on bits of JS like this. Maybe you can discuss it with @douglascrockford ?"

Flamewar avoided (probably) and more stuff getting done.

<comment><USER15> I agree. The real problem here is the complete lack of courtesy from either party. Software developers seem to have problems with this, maybe because we spend so much time commanding machines to do things with brief statements without the even the least bit of a please or thank you.

</comment></comment><comment><USER16> Learning the minutiae of a language is important, sure, but I can't fathom why you'd willingly introduce unnecessary fragility or overthink into your codebase.

Ideally, your goal as a hacker is to make cool shit. Your goal is not syntax.

<comment><USER17> This is precisely correct. "Don't do _x_ , except in one or two cases where you have to, and then you can hack around it using _y_ instead of _x_ " - rather than "use _x_ by default."

Simplicity should win; but alas, being one of the cool kids is more important.

</comment></comment><comment><USER18> I think older programmers will side with Crockford and for good reason.

The bootstrap code makes assumptions about the future of the js spec and browser implementations that aren't safe. Young people don't remember the dark days of people writing js to leverage IE/Netscape specific bugs which then had to be turned into features because so much code existed in the wild that could be broken.

Crockford is a scarred veteran of the spec wars. I'm sure that when he sees young people trying to game spec/implementation ambiguities, he thinks, "Never again! Not on my watch!"

I think best practice is explicit, future-proofed code that doesn't tie the hands of spec authors or browser vendors. I know that Crockford's tool doesn't accept the current spec or browser behaviour, but his choice is informed by past experience and concern for the future. It's not just some random bug that he's too stupid or stubborn to fix.

</comment><comment><USER19> Ah, I'm so glad that Github allows animations in pull request comments. They really increase the level of discourse!

<comment><USER20> popcorn.gif

</comment></comment><comment><USER21> I am not experienced with javascript, so I don't understand this argument. Can someone please confirm the following, or explain what's going on?

Here is what I understand:

1\. Javascript will add a phantom semicolon at the end of each line if it seems like you need it, for some definition of seems like. To me, it sounds like this is so that new HTML writers in '98 wouldn't see their pages blow up when they forgot a semicolon at the end of a script. It doesn't sound like professional programmers are expected to leave semicolons out on purpose (this is the opposite from python). The bootstrap authors took advantage of this because somehow screwing with the compiler is in vogue.

2\. Crockford's tool broke when a semicolon was left out somewhere. I guess he didn't implement a proper js compiler that covers the entire language spec.

3\. There's some business about unary and binary ! operators? Something about sticking a ! in front of your line lets you leave the semicolon off the end? This sounds utterly braindead to me. It's no fewer characters, and the thing you're typing is going really far away (at the beginning of a big block of code) from where it's actually meaningful to you (at the end). Also, it looks like it relies on some fairly convoluted unintended consequences of the spec, that may not be future-proof.

Here is my analysis, if the above understanding is true:

1\. Bootstrap needs to fix their code. This business of the compiler sticking in semicolons where it thought you meant them is a crutch to prevent stupid errors from being fatal errors in the average case, but that doesn't mean they aren't errors. Be explicit.

2\. Crockford should fix his tool soon, not complain about other people's code, and say "I'll fix it soon, but for now, here's a workaround: just put a semicolon in your code".

3\. What the hell. Are people really doing this? Is the web one big obfuscated javascript competition? What happened to writing simple, explicit, readable, maintainable code? Are we really bickering over single characters and trying to play subtle tricks with language esoterica to save them like a bunch of 14-year old perl newbies? Man, I hope these morons aren't in charge of my bank account.

Overall, I'm with Crockford, but he doesn't need to be this much of a jerk about it.

Further analysis, now that I've read it with a decent (non-cell) data connection: allowing gifs in a public issue tracker is a terrible decision.

<comment><USER7> [http://blog.izs.me/post/2353458699/an-open-letter-to- javascr...](http://blog.izs.me/post/2353458699/an-open-letter-to-javascript- leaders-regarding)

That is a pretty good rundown of the rules. The only problem with not having semicolons is cases like this, where someone is using a bad tool to minify your code. None of the tools that currently do the best job will break on that code.

<comment><USER21> Yes, tool writers need to understand this behavior and handle it.

But I still don't understand why the hell you would want to do this. These are a lot of rules to remember, and I don't think it makes sense to think about them for each statement I write. Nothing here says "here is what you gain with this technique", all I see is "it's perfectly valid so quit whining". This doesn't satisfy my curiosity.

Then we have this:

 _For example, instead of this:_

        foo();
        [1,2,3].forEach(bar);

_you could do this:_

        foo()
        ;[1,2,3].forEach(bar)

_The advantage is that the prefixes are easier to notice, once you are accustomed to never seeing lines starting with ( or [ without semis._

So now the argument is "don't worry, you get used to writing stupid looking code"? This is getting depressing.

<comment><USER7> starting a line with a semicolon means "start a new expression", if it is done where it is meaningful. By putting it at the start of the line, it is easier to associate it with the statement that makes the character important, and calls out that you are paying attention to one of the biggest gotchas in the language

putting a semicolon at the end of every line is basically just noise. You get used to it, and I find semi-colon bugs end up happening much more frequently. More then that, you are essentially just typing an arbitrary character 99.99999% of the time. When you need a semi colon is essentially a corner case, so the vast majority of code is just getting appended with a character which has no meaning.

Its like the javascript community decided to surround all expressions with parens, since it makes things more explicit, and there are a few cases (much more common then semi colons) where you need it in the language. Or if they decided to end all lines with //, just in case someone wanted to follow it with a comment. Those two examples make as much sense as advocating semicolons at the end of each line.

<comment><USER21> No. Semicolons are statement separators. Every other language that uses them as such puts them at the end of every expression, but it's fine if you want to put a semicolon at the beginning of every expression instead, except that that will confuse people coming from other languages.

What's not fine is pretending like javascript has significant whitespace and then...oops! it doesn't work here so we need to add something in this one special case. That is guaranteed confusion. If your only argument is that most of the time it's unnecessary, all you're really trying to accomplish is compression (guess what, JSMin does that!) and you may as well write APL. "You get used to it" is meaningless. You get used to banging your head against a wall too, if you do it long enough. Doesn't mean it's a good idea. It's actually worse than that though, because other people need to get used to it too, so you're wasting their time as well.

Surrounding all expressions (not statements) with parens _does_ make sense, in many languages (because there are cases where you need them, and it pays to be explicit up front). That is something good style guides often dictate (like surrounding all if/else blocks with braces, even if they're only one line). Starting a comment after every line doesn't seem like a good analogy, I have no idea where you're going with that.

Let me be clear, and I've now wasted a bunch of time reading up on this so it's not just opinion: ASI is a crutch added to the language in order to minimize the effect of silly errors. It is not a language feature. Python was designed to have significant newlines, and they resolved the ambiguous cases. Javascript was designed to have semicolons between statements when written correctly. Abusing ASI is error-prone and not future-proof (against programmers, apparently language spec changes are going to maintain current behavior). If you think its abuse is a good idea, you should be quarantined from the rest of the programming community. Or write your own language and design it around this.

<comment><USER7> My argument is that ending every line with // is just noise, () is just noise, and ; is just noise, except for the one in 1000loc time that it isn't. And filling your code with noise not only makes your code harder to read and longer to type (if even by a little bit), but it trains you to ignore semi- colons, especially since you do not have a compiler complaining when you miss them. And when semi-colons fade into the background, it is MUCH harder to catch the one case where they are important.

If you were to write ruby, smalltalk, perl, google go, python, coffeescript or any of the other languages with asi, you find that people omit the semicolons in every situation unless for the few they need them, and never run into a problem. For some reason, that is not the case with js. Do all of those other languages "abuse" ASI? I work on a 500k loc ruby app, and I feel very confident in saying there has never been a single case of a bug from an ambiguous statement from asi (although there have been from the difference of && and 'and'), and there is only about 5 semi colons in the whole code base.

Now, js is different then those other languages in that it has a quirk where it treats whitespace and newlines the same for all types of brackets. Realistically (if you are writing for the browser), this only comes up in lines starting with an open parenthesis, since that is the one case where starting a new statement on a line with any kind of bracket makes sense. And even then, the one time you are likely to be doing that is for an immediately invoking function (function(){}()), which isn't exactly you do every few lines of code. So you have a choice on how to deal with this one, fairly uncommon case; either handle it in a special fashion when it occurs, or put a semi colon on every other line. I don't care which one you choose, all I ask is you afford me the same respect :)

My intent isn't to get into a silly language argument over this, but it seemed like you genuinely missed what I was trying to say. If you feel it would personally help you write better code, then more power to you. But I write a lot of semi-colonless code in various languages, and it has literally never caused a problem for me.

<comment><USER21> Ending every line with // is noise because it means nothing to the compiler or to the human. If I could write comments without prefixing them with //, I would (but the compiler won't let me). () and ; are not noise because they simplify the rules of the language. They make it so someone reading your code needs to remember fewer esoteric rules to understand it. That is a big win. Saving a single character of typing per line, for your fingers and your disk, is a miniscule win. I hope you're writing code that's more interesting than a typing contest (but if you aren't, maybe you care about the semicolons). The disk and the network don't care about one more semicolon per expression. They know about compression, they will deal with it. If your compiler doesn't complain when you miss them, you need a better compiler. Maybe a linter, or google's closure. Or maybe there's a market for a decent javascript compiler. I don't understand what you mean by "when semi-colons fade into the background, it is MUCH harder to catch the one case where they are important". If you use them everywhere and you miss one, it's easy to spot. If you have to examine each line with a set of rules in order to figure out if you actually needed one there, that's a more expensive task.

Ruby, python, and coffeescript were designed with significant newlines, and therefore designed around the corner cases. The only reason you'll need semicolons in those languages is to have two statements on the same line (coffeescript excepted, I'm not sure about it but my guess is that they did it right). These languages went to great lengths to reduce the cases where you need statement separators, and document this behavior widely and clearly. Perl requires semicolons, dunno where you got the idea it didn't. I don't know about smalltalk and go, I don't use them.

I probably did miss what you were trying to say.

In languages that weren't designed with significant newlines, everybody uses the statement separator at the end of a line, so it seems to me that moving them to the beginning of lines is just confusing. In any case, ASI is _not_ significant newlines, it's a hack. I don't know what more to do than to just beat it into your head. It is not a feature you should rely on.

The important part of what I'm trying to express is that, in _any_ language, the most important thing you need to do is to write explicit code. This means typing all the characters so that not only does the compiler (and tools) not get confused, but future human readers don't get confused either. Javascript intends for you to separate your statements with semicolons. If you start playing tricks with them, you are going to confuse people that try to understand (or, heavens, learn from) your code. You will get burned.

Consider this example (I'm a C guy):

        if (a && b || c && d | e || f && g)

How does this resolve? Does it help you if I write this?

        if ((a && b) || (c && (d | e)) || (f && g))

It sure as hell does. Now, these are semantically identical. But when you read the second one, you don't need to know that bitwise OR binds tighter than logical AND, and logical AND binds tighter than logical OR. These are details you _should not need to remember_ when you read my code. Are parentheses just line noise here? I think not. I think they are quite meaningful. Not to the compiler, but to the human consumers of my code. It's costs the reader a lot more to read the first one than the second. The first one is mentally _expensive_. (In fact, modern C compilers will warn you about not having these parens here because they know that adding them is a good idea. If you turn on warnings.)

The same applies for ASI. If you rely on extra compiler tricks a human needs to remember, that's expensive. It is a lot better to have a simpler rule: just put a semicolon after every statement, and don't make anyone think about it again. Or put one before, I don't really care. Just do something _consistent_. Try to code to a simpler subset of the language, to make other programmers' lives easier.

I really don't mean this to be an attack against you or the javascript community. Well, I sort of do, because abusing ASI is stupid, but I actually mean this to be an educational experience. Let me help you mature as a programmer.

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> I wonder if the "insanely stupid" comment isn't about the omission of the semicolon but about the omission of "if". Since when is a good old-fashioned if-statement out of style?

</comment><comment><USER23> It _is_ a bug on JSMin. Minifying should _never_ alter code behaviour.

<comment><USER24> The minification isn't breaking the code. The authors had an incorrect expectation of how JSMin would minify the code. By the very act of minifying code where new lines matter your are always potentially changing the behavior.

<comment><USER25> The minification _is_ breaking the code. If a minifier takes valid JS in and produces JS that behaves differently from the input, then that minifier is broken, full stop. It doesn't matter how anyone personally feels about ASI; what matters is that ASI is a part of JS, so if you're making a tool that processes JS, you need to respect its rules.

</comment></comment></comment><comment><USER26> Update: Bootstrap fixed their code as Crockford prefers. From _fat_ 's comment circa 11 am PDT:

 _fwiw, this was patched in bootstrap way before i even encountered this issue - otherwise i wouldn't have closed it outright.

Sorry for the confusion everyone.

You can see the code here in 2.0.3: [https://github.com/twitter/bootstrap/blob/2.0.3-wip/js/boots...](https://github.com/twitter/bootstrap/blob/2.0.3-wip/js/bootstrap- dropdown.js#L63)

I still maintain this is a bug in jsmin, but as others have pointed out - <USER2> and I do our best to make bootstrap flexible with other great tools out there (like jsmin). This includes adding semicolons where necessary or changing minor stylistic things._

</comment><comment><USER27> I happen to agree with Crockford on the omission of semicolons. I also have a strong opinion on clever code: you should always optimize for readability over aesthetics.

But... Crockford could have said it in a much more tactful way that could elicit a more positive response, spare the world from this sad discussion, as well as channel the man-hours dedicated to this into more useful endeavors.

</comment><comment><USER28> That code is bad for more reasons than the semicolon omission.

</comment><comment><USER29> While this "argument" has prompted several lol's on my part, JS really needs some equivalent of PEP8

And if you don't use semicolons you are an asshole.

<comment><USER30> Douglas Crockford's JSlint is pretty much that.

</comment></comment><comment><USER31> > _! is not intended to be a statement separator. ; is._

Which is why there is a line break there. He's far too stubborn to realize that JSMin is at fault for not being able to correctly parse JavaScript.

<comment><USER32> The line break will not help if ! becomes an infix operator.

<comment><USER33> But as of now it's not.

<comment><USER34> ! is already being discussed to be turned into an infix operator in a future version of JavaScript.

<comment><USER35> Future versions of JavaScript might also replace the 'function' keyword with a picture of a chicken, but I'm still going to keep typing the word 'function' for now.

<comment><USER36> That's not under active discussion. ! as an infix is.

</comment></comment></comment></comment></comment></comment><comment><USER37> "…Explicit is better than implicit… Readability counts… In the face of ambiguity, refuse the temptation to guess. There should be one—and preferably only one—obvious way to do it…" — The Zen of Python

Ironically, the Zen of Python supports using semicolons in JavaScript. Also, both sides come off like children, but at least Crockford's opinion seems a little less selfish. It's like politics, with the difference being in their premises so they'll never agree.

Also, why can't I (or anyone else) resist commenting on this rather pointless debate? I am disappointed in my weakness.

</comment><comment><USER38> It is hard for me to understand how one could make so many things in a programming language completely arbitrary - I mean it is natural for a language designer to have some vision of how the language will be used by other people, how will the common structure of the programs look like, but JavaScript looks like such a vision never existed, there are often several ways of doing the most basic things (writing vs. omitting semicolons mentioned here, writing vs. omitting "var", but above all else 1000 of ways of doing OO, all with it's own problems) and no easy ways at all of doing other very basic things (modules/namespacing). As a result you can find 10 or 20 programs written in JavaScript where each looks like it was written in a quite different language. Maybe it was an attempt to make an "easy" language for non-programmers (I doubt even this goal was in the end achieved), but as a primary language for programming client-side applications it is a utter disappointment. Not that I necessarily blame the JavaScript creator, I am sure there were plenty of corporate pressures involved and other factors of corporate/economic nature.

I wish we could get some other programming language implemented in all the major browsers, then at least in the perspective of the next 10 years we could completely get rid of JavaScript, I am not sure if it possible to really improve the situation in a radical way just via incremental changes to the existing design.

</comment><comment><USER39> Crockford wrote JavaScript: The Good Parts. He did not write JavaScript: The Cool Parts.

</comment><comment><USER40> if there's anything worse than crockford being a jerk, it's the self- aggrandizing asi crowd. Let's not give either any attention.

<comment><USER41> (what is an asi crowd?)

<comment><USER42> Gonna guess "asi" means "automatic semicolon insertion".

<comment><USER43> In German slang, "Asi" is shorthand for "Asocial person". Guess it works on many levels?

</comment></comment></comment></comment><comment><AUTHOR> For a good explanation of why it's a good idea to always use semicolons in your JavaScript, take a look at: [http://lucumr.pocoo.org/2011/2/6/automatic- semicolon-inserti...](http://lucumr.pocoo.org/2011/2/6/automatic-semicolon- insertion/)

<comment><USER23> The examples he gives are exactly the situations where you _should_ use semi- colons, as understood by those who skip them. Take a look at [http://blog.izs.me/post/2353458699/an-open-letter-to- javascr...](http://blog.izs.me/post/2353458699/an-open-letter-to-javascript- leaders-regarding)

</comment></comment><comment><USER44> Example when a semicolon is _required_ in non-minimized javascript.

        alert(1) // add semi-colon here to make this code work
        (function(){alert(2)})()

<comment><USER45> There are other options here too but, given the OP, people seem to get irate when you use the features the language specification guarantees :'/

      alert(1)
      void function(){alert(2)}()

<comment><USER44> Nice, didn't know void can be prepended to a function definition.

</comment></comment></comment><comment><USER46> Excellent - another internet cock-fight, with both sides managing to act like total cocks..

What would be better is for both sides to fix their code: Crockford to fix minify for the edge cases like this (result: better, more robust code equals a win), and the twitter boys to add a semicolon for these edge cases (result: better, more robust code equals a win).

But instead, as usual on the internet, it's just devolving into lots of "waah waah waah".

<comment><USER47> Crockford won't "fix" minify, because it's much easier to make JSMin work for a safe subset of JS than it is to make it work for all of JS.

</comment></comment><comment><USER48> What is insanely stupid is abusing the logical bitwise && operator rather than signifying their intent using a plain old if statement like the language intended.

</comment><comment><USER49> I'm sure this thread is going to be a good, old fashioned flame war. Let the games begin.

<comment><USER50> My favourite part is half-time, when the flame-war overseer yells "Change Places!" and everyone has to argue for the other side.

</comment></comment><comment> brown9-2 For those that agree with leaving semi-colons out of JavaScript that they write for projects, can you explain what the benefit of doing so actually is?

Seems like people are valuing aesthetics over producing code that works for 100% of the users/situations.

<comment><USER51> You will never produce code that works for 100% of users and situations.

<comment><USER52> Also: You can write clean bug-free code, but there will still be at least one person on the planet who think your code sucks.

</comment></comment></comment><comment><USER53> I agree with Crockford.

</comment><comment><USER54> Why is this discussion about semi-colon insertion and not about the use of short-circuiting as a replacement for specific 'if' statements and general inconsistency in the project?

[https://github.com/twitter/bootstrap/blob/master/js/bootstra...](https://github.com/twitter/bootstrap/blob/master/js/bootstrap- carousel.js#L91)

[https://github.com/twitter/bootstrap/blob/master/js/bootstra...](https://github.com/twitter/bootstrap/blob/master/js/bootstrap- modal.js#L61)

(Incidentally, would lines 54/56 of bootstrap-modal suffer from the same problem? Or does the fact that the last function call on line 54 is already in an && expression change things)

I'm kind of surprised that the bug wasn't fixed by changing the line to `isActive || $parent.toggleClass('open')` as is done here [https://github.com/twitter/bootstrap/blob/master/js/bootstra...](https://github.com/twitter/bootstrap/blob/master/js/bootstrap- alert.js#L52)

</comment><comment><USER55> The use of semicolon as best practice was sorted out years ago in the js community. Crockford has all his rights to tell these guys to sharpen up because that "fat" character is obviously a python smuch with no knowledge of JS history or respect for elders.

</comment><comment><USER56> Funny, I was just checking out Derby and noticed that their examples follow this style.

<comment><USER57> Why the hell people are refusing to use semicolons? I don't get it

<comment><USER58> I've seen a few reasons. The main ones I encounter are: raising the skill requirement to contribute (you have to know JS better than average to never use a semicolon, and do so correctly), aesthetic (fewer characters looks better), and minimalism (don't use what you don't need).

<comment><USER59> > raising the skill level to contribute

That's insane. Good programmers need not know stupid tiny nits about Javascript (heck, I've worked on a Javascript JIT and I don't really know Javascript). That does not mean that they are not skilled.

> aesthetic

I don't understand how "you must carefully understand how the language parses to understand this line of code" is aesthetically pleasing when compared to unambiguity.

> minimalism

Here, it is needed, at least arguably (by douglascrawford). You could argue that the "optional semicolons" rule is ugly and not minimalistic, and thus the minimalistic approach would be to not use that rule.

<comment><USER23> Sure the "raising the skill level" bit is just trolling. Omitting semi-colons _is_ about removing ambiguity, and making it easier to spot inconsistencies. As a bonus, code looks cleaner.

In this case, the minifier is breaking the code, regardless.

<comment><USER60> Can you parse this expression without parentheses?

        a && b && c || d || e + f > g && h

The parser sure can. Do you have all the operator precedences memorized, or do you use superfluous parentheses because you're not always sure?

It's true that the semicolon is not needed, and it's true that the minifier is breaking code. It may even be true that Crockford should fix it. But that doesn't change the fact that the omit-the-semicolons position is absurdly immature hipster posturing that serves no engineering purpose.

<comment><USER61> Do you use parenthesis to denote order of operations in all cases, even when extremely obvious? If not, should we assume your position is absurdly immature hipster posturing that serves no engineering purpose?

<comment><USER62> I use Lisp, so the answer to your question is yes. I do use parenthesis in all cases.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER63> My comment from the thread, buried under many pages of meme gifs:

>>>

@douglascrockford If TC-39 makes ! an infix operator, which causes \n to not terminate the statement, then that will be a syntax change that is incompatible with current code in the wild, which would be an insanely stupid move on their part.

The fact of the matter is that JSMin isn't parsing JavaScript correctly. I thought the separation of concerns was that JSLint tells you about stupid code, and JSMin correctly parses JavaScript according to the ES standard and minifies it safely.

>>>

</comment><comment><USER52> Am I missing something? Aren't Bootstrap and JSMin open source? Instead of focusing on coding philosophies, someone can simply fork JSMin's source and make the appropriate patch, or make a fork of Bootstrap that has JSMin friendly code.

Regardless of our many diverse opinions, Crockford and Fat are entitled to maintain their own libraries in whatever fashion they desire. The fact that they made the libraries open source means "if you don't like my code or the way it works, here's my code, customize it and leave me alone".

</comment><comment><USER64> I think the stupidity here is entirely isolated to using JSMin.

<comment><USER64> Allow me to explain further, as I've been down-voted a few times.

My point is that its stupid to use a tool on code it was not written to support. If you want minification with valid JavaScript, use something like Uglify-js.

If you write code, however, that works with JSMin, then use that tool. Douglass Crockford can write his software to work any way he likes and support any code he likes. Don't like it? Use something else, and don't be stupid.

</comment></comment><comment><USER65> If I remember well, bootstrap is using cat & uglyfy, not JSmin. Every jQuery plugging in BS starts with a semicolon. The Battle of the blind egos.

</comment><comment><USER66> Should JSMin being enforcing the spec or good practice?

My vote: Good practice

Upvote replies to vote. Please don't down vote the replies so we get a clear picture.

<comment><USER67> It's obviously should be the spec + warnings for good practice.

</comment></comment><comment><USER62> I am so glad that I am a Lisper. I haven't dealt with issues of text file size or syntactic standards for at least a year.

</comment><comment><USER68> I don't get it, @fat never said anything negative/positive towards Crockford. Why is this even a thread??

</comment><comment><USER69> "Be liberal in what you accept, and conservative in what you send." <http://en.wikipedia.org/wiki/Robustness_principle>

Its like the golden rule for software. It generally stops nonsense like this cold.

<comment><USER70> No, it just makes things worse. If people are going to follow the spec, they should follow it and reject bad input. Otherwise, you get a mess of code that tries to guess at what to do. This leads to inconsistencies, possibly security bugs.

Imagine if invalid HTML had been flat-out rejected by browsers since the beginning. Cross-browser compat would be, at least, somewhat easier due to less bad HTML surviving in the wild, since it simply would not have worked. In XML, for instance, I've never heard of the need to deal with invalidly formatted messages.

There's enough problems interpreting semantics, why do folks want to add syntax to the problem, too?

</comment></comment><comment><USER71> Real question is... why not just use UglifyJS or any one of the other js minifiers? So what Crockford is opinionated about JS, we all know this. Don't use his products if you don't like his opinions.

</comment><comment><USER72> The obvious thing to do is:

1) JSmin should be modified to handle Bootstrap-style semi-colon-ing

2) Bootstrap should adopt the more commonly understood semi-colon-ing

</comment><comment><USER73> Jacob/Fat was trying to minimize the code before it was run through minimizer and is surprised at the results?

Sounds like another emotional issue.

</comment><comment><USER74> If there is a tool to insert semicolons in all the right places, you could use that before using jsmin. Would that help?

<comment><USER75> The problem from my reading of it is that "all the right places" changes meaning depending on which specification of JS you're talking about. But yes it would work if you run into the problem and the semicolon-inserter targets the right spec.

</comment></comment><comment><USER76> How many times must this bush be beaten. I've read people complaining about no semicolons in javascript for ages.

Get over it...

</comment><comment><USER77> It's called forking.

</comment><comment><USER78> Oooh, developer drama.

</comment><comment><USER79> you don't have to use linebreaks either but people use it. There are lots of good practices making code easy to use, read and maintain. So just put f.. semicolon.

</comment><comment><USER49> yes, yes, yes.

</comment><comment><USER80> That's really stupid. There's no plausible reason that the end of that method shouldn't have a semi-colon. I honestly wouldn't advise anyone use Twitter Bootstrap. You should always use semicolons in Javascript even if you're hippie. Hippies use coffeescript.

And I think Google's style guide[1] is prevail over Github's style guide[2].

[1] [http://google- styleguide.googlecode.com/svn/trunk/javascript...](http://google- styleguide.googlecode.com/svn/trunk/javascriptguide.xml#Semicolons) [2] <https://github.com/styleguide/javascript>

</comment><comment><USER81> Crockford's stance is annoying purely because it's pedantic and because there are _many_ libraries that embrace this style. We use django_compressor and found bugs from the compressor that uses Jsmin. So I have to use something else to compress them before hand.

Are there compressors that use the syntax tree rather than transforming the source?

<comment><USER82> Is there any particular reason why you refuse to put in the semicolons in Javascript?

<comment><USER32> There's a whole hipster movement going on right now around the idea of omitting semicolons from JavaScript code. I believe CoffeeScript is the culprit.

Personally, I agree with Crockford -- it's dumb.

<comment><USER83> Kind of funny that you say this, since CoffeeScript inserts semicolons.

The lack of semicolons is the one major thing in the Github style guide that I think is stupid. It seems silly to avoid using semicolons in Javascript because it actually takes a little bit more effort than just using them.

<comment><USER84> On my team we've decided to use semi-colons in JavaScript for this exact reason: It would actually take more effort to stop using them as our other major language is PHP. More effort for no benefit is pointless.

</comment></comment></comment></comment></comment><comment><USER85> I don't care what Crockford thinks. He's irrelevant and his opinions are often confused with expertise.

</comment><comment><USER86> What a child... Has anyone read the GitHub style guide? 'Do your best to never use a semicolon. This means avoiding them at line breaks and avoiding multi- statement lines.'

Grow up Crockford. Do research before you post. Stop assuming because you supposedly once knew how to do something, you still do, and always will. Times change.

However, this is all very exciting. It gives Twitter, or whatever other start up, an opportunity to replace an outdated piece of software by a nut case!

<comment><USER87> Why do you believe the github style guide to be the authoritative source for JavaScript style? There is no benefit for avoiding use of semicolons other than not writing semicolons, whereas there are several detriments for their omission.

> It gives Twitter, or whatever other start up, an opportunity to replace an > outdated piece of software by a nut case!

I don't know where this ad-hominem is coming from, but Douglas Crockford is hardly a nutcase.</comment></comment>


Ask HN: Does anyone have a use for automated testing in specific countries? - <AUTHOR> The product I have in mind would allow you to use the same selenium scripts you currently use. By using our driver you would be able to target any country you'd like. <comment><USER2> What are you trying to achieve? Detecting state censorship, or dealing with location-specific speeds?</comment>


Huginn can now run for free on Heroku - <AUTHOR> https://github.com/cantino/huginn/wiki/Run-Huginn-for-free-on-Heroku

<comment><USER2> Useful background (not about the Heroku part): [https://news.ycombinator.com/item?id=7585605](https://news.ycombinator.com/item?id=7585605)

</comment><comment><AUTHOR> Another recent addition to Huginn are Scenarios, which are sets of connected Agents that can be imported and exported for sharing. When imported from another Huginn instance, they act like a subscription, pulling in any differences when you update them.</comment>


What Made Apollo a Success? (1971) [pdf] - <AUTHOR> https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19720005243.pdf <comment><USER2> Funny timing on this, I just came across my grandfather's letter from the Apollo program astronauts thanking him for his testing prowess and awarding him the "silver snoopy" for professional excellence.

My other grandfather was the first shuttle launch director, the shoes we fill..

Might interest some.

[https://lensdump.com/i/W1GAd0](https://lensdump.com/i/W1GAd0)

<comment><USER3> What did your grandfather do and which astronauts signed the letter?

<comment><USER2> It's signed by Ronald Evans of Apollo 17. Both of my grandfathers and a lot of my family worked for nasa for decades, though. We're all space coasters. A few pilots. My grandmother was a typist there for instance.

He was some sort of rocket propulsion engineer back then, I'm not sure what the actual title would have been. I asked him to write some memoirs a long time ago but I don't bug him about it. He doesn't seem to think it's very interesting. Guess that happens when it's your day job.

<comment><USER4> I certainly wouldn't ask you to bug him, but you might mention to him that there are lots of people who would find anything he has to say about his involvement with Apollo (and the space program in general) fascinating. His stories are important and interesting, even if he doesn't think they are. I wish I had a pointer to somebody who is collecting this history before it's lost. (I wish I had the time and financial freedom to be doing that!)

<comment><USER5> You might be interested in a book called Moondust. The author realized in the early 2000s that at some point soon all of the astronauts who walked on the moon would be gone. He set out to interview each of them about their experiences at the time, and since visiting the moon.

It's a mix of space history and personal reflections on the perspective they got, that none of us will likely have.

[https://www.amazon.com/Moondust-Search-Men-Fell-Earth- dp-000...](https://www.amazon.com/Moondust-Search-Men-Fell-Earth- dp-0007155425/dp/0007155425/)

<comment> frosted-flakes A Man on the Moon by Andrew Chaikin (1998)[0] is also a great read. The author explains in the forward that that was also part of his motivation to write the book. I have the 23 hour audiobook, which is also quite well narrated.

[0] [https://www.goodreads.com/book/show/896458.A_Man_on_the_Moon](https://www.goodreads.com/book/show/896458.A_Man_on_the_Moon)

</comment></comment></comment></comment></comment></comment><comment><USER6> This looks really interesting. "A series of eight articles … from the March 1970 issue of Astronautics & Aeronautics."

Quickly summarizing the table of contents and some of the internal content, these seem to be the main takeaways:

• Create design principles that stress simplicity.

• Test exhaustively.

• Develop mission rules, procedures, and plans for potential issues ahead of time; iterate as new information comes in.

• Execute rigorous post-mortems.

• Prioritize flexible yet disciplined management.

It's notable that this was published before Apollo 13. It'd be interesting to see what changes Kranz et al. would make to these articles after that.

<comment><USER7> I've heard or read of this before, the first bullet, and can't help but to compare this to what has happened with the 737 Max 8 current issue.

From the PDF comes: "Apollo gains a measure of simplicity from features simple both in design and operation, complex in design but simple to operate, or simple by being passive in function. The concept of simple design and simple operation is best illustrated by the Apollo rocket-propulsion systems (fig. 2-2)."

<comment><USER3> For a machine as complex as the Saturn 5 rocket, it is truly a credit to the builders that it never suffered a major failure in any of the manned missions. Same for the LM rocket which returned the astronauts to the command module. Both had to absolutely work and both did.

As John Glenn quipped "It's a very sobering feeling to be up in space and realize one's safety factor was determined by the lowest bidder on a government contract."

<comment><USER8> Gus Grissom, Ed White and Roger Chaffee :(

I do get your point, and it's amazing it worked as well as it did. Space is tough, and things are likely to go wrong, just as they still do with civil aviation.

<comment><USER9> Silly nitpick: Apollo 1 was a Saturn 1B not a Saturn 5.

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

<comment><USER3> It also wasn't a "mission". They were performing in a test. And, in any case, the fire wasn't a fault of the rocket; it was a fire in capsule.

</comment></comment></comment></comment></comment></comment><comment><USER10> Brady Heywood Forensic Engineering Podcast [0], has an amazing series on Apollo 13 [1]. It's 6 episodes, mostly narrated by Brady Heywood, with some audio recording from Houston as well as the Apollo astronauts. It's riveting.

[0]: [http://bradyheywood.libsyn.com](http://bradyheywood.libsyn.com)

[1]: [http://bradyheywood.libsyn.com/episode-21-apollo-13-p1-head-...](http://bradyheywood.libsyn.com/episode-21-apollo-13-p1-head- for-the-hills)

</comment><comment><USER11> The very first sentence is confusing to me:

> On July 20, 1969, man first set foot on another planet.

Has the definition of planet changed over time?

<comment><USER12> [https://en.oxforddictionaries.com/definition/planet](https://en.oxforddictionaries.com/definition/planet):

 _"1.2 Astrology historical

A celestial body distinguished from the fixed stars by having an apparent motion of its own (including the moon and sun), especially with reference to its supposed influence on people and events.

'the planets are presently influencing you in a positive way'"_

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

 _"In classical antiquity, the seven classical planets are the seven non-fixed astronomical objects in the sky visible to the naked eye: Mars, Jupiter, Venus, Saturn, Mercury, the Sun, and the Moon. The word planet comes from two related Greek words, πλάνης planēs (whence πλάνητες ἀστέρες planētes asteres "wandering stars, planets") and πλανήτης planētēs, both with the original meaning of "wanderer", expressing the fact that these objects move across the celestial sphere relative to the fixed stars."_

</comment></comment><comment><USER13> >the main point is that a single man can fully understand this interface and can cope with all the effects of a change on __either side of the interface__

(emphasis mine)

This is a really great and subtle point, and something that takes a lot of rigour to turn into reality.

</comment><comment><USER14> From the article: "If the design has been verified and if a thorough test program has been completed it should not be necessary to make any changes. Of course, this idealized situation does not exist in any program like Apollo where design, test, and flight often overlap and must be carried out at the same time." Wow, these remind me of the Joint Strike Fighter program, where design/test/production all overlapped (concurrency) and cost overruns where a huge issue. No doubt, we spared very little expense in the Apollo program, cutting only the last two missions!

</comment><comment><USER15> Had to be Agile dev with CI/CD</comment>


Google Spanks Microsoft's Recent Scroogled Antics - <AUTHOR> http://techcrunch.com/2013/11/21/google-spanks-microsofts-recent-scroogled-antics/ <comment><USER2> In which AOL takes another step towards replacing their "writers" with random SEO.</comment>