Fly the Airplane - <AUTHOR> http://dcurt.is/2011/12/15/fly-the-airplane/ <comment><USER3> Great narrative, but factually wrong on at least two accounts:

>If the pilots has switched a button to re-enable autopilot, everyone on board would have lived. But they didn't. One co-pilot made a single, absurd mistake–for twenty full minutes–that brought the plane down.

First factual error: The button they should've switched is not the auto-pilot button (which they operate many times per flight), but the flight mode button (which most pilots never operate in their career). When the plane lost at least two of the three pitot tube readings, it went from the NORMAL "Law" to the ALT "Law", where the airplane doesn't guard itself against many pilot errors. When the pitots de-iced shortly thereafter, the plane did NOT go back to NORMAL "Law": it had to be switched there manually. The pilots did not do that and it seems to be the consensus so far (can't state that for certain before the official report is released) that they did not realize they were flying the plane in ALT and then DIRECT Law.

Second factual error: the "absurd mistake" lasted nowhere near 20 minutes. The first problem appeared at 2:10:03UTC and flying into the ocean occurred at 2:14:28UTC -- 4 minutes 23 seconds in all.

<comment><USER4> As it's completely meaningless to have the autopilot operate out of normal law (why would the computer operate the plane outside of the envelope the computer considers safe?), isn't it safe to assume that re-engaging the autopilot would have put the plane back in normal law?

<comment><USER5> Isn't it also safe to assume:

\- Pilots wouldn't be trained with marketing speak so they believe the Aircraft is uncrashable, and ignore 75 repeats of the STALL warning alarm.

\- The change of modes between "can't crash" and "can crash" laws normally never happens, so when it does it deserves a huge and explicit attention grabbing ongoing alert of its own.

\- The plane would never, ever, detect that it was barely moving forwards, nose pointing up, falling at hundreds of feet per second, and then switch the STALL alarm off.

\- The plane designers would make it so one pilot has no clue what the other is doing with the controls, and if both offer conflicting instructions, the plane will not alert them, but just average the instructions.

\- The "about to hit the ground" warning would be built to sound early enough that they could use it to avoid hitting the ground.

\- The pilots would be trained so that if something goes wrong, seems weird, panic is setting in, they must stop what they are doing and cooperatively restate their assumptions and reassess the situation.

<comment><USER6> These are excellent points. I was amazed at the behavior of the dual input sticks; in what world would this be a useful feature of the airplane (other than, perhaps, a training scenario?) How is the switch to alternate mode not made painfully obvious to the pilots?

</comment></comment></comment></comment><comment><USER7> A core concept they drill into your head in flight training is the following axiom:

        Aviate, Navigate, Communicate
        (in that order)

First and foremost, keep the plane in the air. Then you can worry about where you're going (e.g. don't fly into terrain, start heading towards an airport). Finally, coordinate with others (e.g. controllers) to let them know what you're doing and seek guidance.

This axiom can be applied to lots of other areas, too, including startups. For instance, it explains why I don't blog: I'm concentrating on execution and strategy.

It's one of the reasons I wonder if the many prolific startup bloggers have their priorities straight.

EDIT: oops, just saw yread's comment below. <http://news.ycombinator.com/item?id=3360071>

</comment><comment><USER8> This seems like a somewhat rough diagnosis.

The pilots were not making an 'absurd error'. They did not forget to fly the plane.

It is that _what they thought they were doing was not what they were actually doing_. Their mental model broke away from the reality. (They thought the plane was in 'normal mode' when it was actually in 'abnormal mode' -- an expression of which: one them declaring "this cannot be happening!")

Telling them just _fly the airplane_ is not (quite) the solution -- they thought they _were_ flying it.

But the remedy is sort-of basically correct. It just seems better expressed as: when nothing makes sense (your mental model has suddenly utterly failed), fall back to a more basic backup mental model and system -- like primitive manual override.

(How clear can such separation of a basic mode be? How practical would it be? How reliable? It leads to a set of engineering/UI questions . . . were they well designed in this particular case?)

<comment><USER9> I'm not so sure. They weren't flying the airplane, but rather were letting the computer fly it for them. (The control movements made by the one pilot who was horribly in error were not something that one would ever make if the controls were directly connected to the control surfaces.) Meanwhile, the computer was letting the humans fly. If the pilot in error had flown the airplane instead of driving the computer, everything would have come out fine. (And, while I'm not completely familiar with the Airbus's fly-by-wire system, I'm pretty sure that doing this still would have been safe in the event that the computer _hadn't_ given up, either.)

They spent all this time trying to figure out what was wrong with the plane when their immediate concern should have been to get the nose down and get their airspeed up. Figuring out the underlying problem can wait. That's what "fly the airplane" is all about. Even if stuff is on fire, the first priority is to keep your speed up and don't run into anything hard.

<comment><USER10> The problem is they did not know there airspeed and they did not understand they where stalling. The airspeed issue related to simple icing. Stalling was a little more complex than that. They had plenty of indications that they where stalling one of the pilots simply did not believe them.

<comment><USER5> Aside: Using the word "simply" glosses over the interesting bits.

Why did a pilot, a 32 year old, with Air France for 4-5 years, qualified to fly the A330 (for 2 months), with "under 3,000 hours of experience" [NYTimes] (so, a couple of thousand hours) not believe the stall warning? And what can humans do to guard against that?

That's an interesting question, "simply" doesn't do it justice.

[ [http://www.nytimes.com/2011/05/28/world/europe/28flight.html...](http://www.nytimes.com/2011/05/28/world/europe/28flight.html?_r=1&pagewanted=all) ]

</comment></comment></comment></comment><comment> bulte-rs I fully support this message; having performed an instrument rating renewal check just yesterday in sub-optimal weather I experienced a frozen pitot-tube (the thingie that measures dynamic pressure; or a component of the airspeed). Having no speed indication is scary in instrument conditions (i.e. no visibility) but continuing flying is the best decision you can make (that and turning on pitot-heat). But please apply this 'motto' to other fields as well. No matter how bad the situation is; do the thing you're supposed to do: Fly the damn airplane, Talk to your customer, Keep your hands on the steering wheel and: keep breathing.

<comment><USER11> in order of priority: aviate - navigate - <USER2>

I.e. make sure to stay in the air, know where are you flying and tell others about where you're going or what you've learned

<comment><USER5> They tried aviating. The person with control knew he was on manual controls, and did the wrong thing.

This is why the message "FLY THE PLANE" is a useless exhortion - he thought he was doing that.

Had the priority been: communicate - aviate - navigate, they might have been alive.

Imagine instead:

"Manual control"

"check"

"pulling back rudder to gain altitude and avoid storm"

"we can't go much higher, and we don't want to lose speed"

"ok, flying straight on"

<comment><USER12> Beg to differ, but he wasn't _flying_ the plane. He knew he was on manual control, but he apparently did not understand or did not appreciate the implications of the fact that the plane was flying on "alternate law".

With the normal flight laws, the pilot _cannot_ stall the airplane because the flight laws prevent it. On "alternate law", that protection is removed and the aircraft can be stalled. When flying "normal law", pulling full back on the stick is arguably a reasonable approach to stabilize the flight of the aircraft because the flight control system will fly the plane in a stable, just above stall, attitude and speed.[1]

On "alternate law", pulling full back on the stick resulted in the plane no longer flying, but stalling and falling. I would contend the copilot was not _flying_ the plane, he was relying on the _flight control computer_ to key off his "nonsensical" input and take over flying the plane.

Trivia: the report indicates the flight speed sensors de-iced and the flight system recovered full correct data input quite soon after the incident started. I'm rather surprised that the flight control system did not go back to "normal law" mode, but rather stayed in "alternate law" mode. I don't know what it takes to revert the flight mode - if it is a manual reversion or if the plane simply has to get back into normal flight, which never occurred for AF447.

[1] AF296 crashed at an airshow while the pilot was flying with full aft stick. It crashed not because it stalled, but because the pilot ran out of energy (altitude) and the engines could not spool up fast enough to stop the plane's descent before it hit the ground. <http://en.wikipedia.org/wiki/Air_France_Flight_296>

<comment> bulte-rs Reset from alternate law to normal law is - afaik - a pilot induced operation. The airbus computers will never initiate such a change by themselves. I.e.: They will drop down into a lower mode automatically; but they will not up the amount of support 'by themselves'.

</comment></comment></comment></comment></comment><comment><USER13> I followed through the entire essay in complete agreement, but I wished the following paragraph had at least a reference pointing to its claim:

 _The human body's physical "fight or flight" response evolved to help it evade a dangerous situation, which historically involved extreme physical exertion. The rush of steroids into the bloodstream essentially turns off unnecessary systems, including some higher thinking processes, to aid in escape._

When we make statements like this proclaiming we understand the complex workings of things like human physiology I always have to shake my head. We may be smart, us programmers and designers, but let's not pretend to understand the order and meaning of everything. And if you do understand and you have the means, provide some kind of reference to where the claim originates from so we can all learn more.

* edited because I sounded like a jerk and wanted to make my point clearer

<comment><USER14> It has in fact been shown in countless studies that corticosteroids (stress hormones that are released in situations like the ones I described in the article) cause cognitive deficits in humans and other animals. Here is one slightly strange example:

 _The present study investigated the acute effects of cortisol administration in normal healthy male volunteers on immediate free recall and recognition of pleasant, unpleasant, and neutral nouns using a between-subjects double-blind design. Two hours after cortisol (10 mg) or placebo administration, impaired recall and recognition of neutral and pleasant words was found in the treatment group, whereas recall and recognition of unpleasant words was similar in both groups._

See: [http://ukpmc.ac.uk/abstract/MED/12820857/reload=0;jsessionid...](http://ukpmc.ac.uk/abstract/MED/12820857/reload=0;jsessionid=84851F2AB6F2AACD220321FB3F51963E)

<comment><USER13> Your essay is well written, I agree with the premise of it and you clearly know a bit about biology. But I still think it's important that when we make these general claims of scientific fact we point to the giants whose shoulders we're standing on. Maybe it's just the ex-scientist in me, and if so, apologies. I appreciate you found a cortisol related article to prove your point, and I agree it's an odd choice as the abstract, which I'm assuming is what you read as well, seems to state little other than pleasantries are forgotten when under a chemically induced stress response.

<comment><USER10> The flight or fight response has been investigated for a long time. It's complex enough that you need to read a lot of relevant studies most of which are old before you can understand it. Which makes finding a single source hard.

If you want basic research start with Walter Bradford around 1915 _Bodily Changes in Pain, Hunger, Fear and Rage: An Account of Recent Researches into the Function of Emotional Excitement_. <http://en.wikipedia.org/wiki/Walter_Bradford_Cannon>

</comment></comment></comment></comment><comment><USER15> The Professional Pilots Rumor Networks has a bunch of excellent discussions about AF447 (and other incidents). It's nice to get the perspective of people who fly for a living:

[http://www.pprune.org/rumours-news/466259-af447-final- crew-c...](http://www.pprune.org/rumours-news/466259-af447-final-crew- conversation.html)

</comment><comment><USER16> There's a subtle shoutout to The Checklist Manifesto - that book is amazing. I thought it was another GTD-style productivity book but it's not, it's a lot more than that. It studies several seemingly unrelated fields like medicine and construction to bring together unique insights into group collaboration and workflow on complex projects with lots of stakeholders. The chapter about venture capital has a bit of a Moneyball vibe to it.

</comment><comment><USER17> Let he who has flown on untrustworthy instruments in the soup cast the first stone.

<comment><USER18> +1000. I'm a PPSEL of the Cessna-exclusively-outside-the-soup variety, and these kinds of transcripts often bring me to tears. I understand the fascination with (and importance of understanding) accidents and human-error events especially, but the pilot in question was just about my age, and I can't begin to put myself in his shoes in the first moments of this tragedy without crushing pressure entering my guts.

Rest in peace holmes, and don't take it personal.

<comment><USER17> I'm a PPSEL also, training for my IR right now. We had some icing on my last flight that caused some pitot/static issues, fairly quickly solved by flipping on the pitot heat and climbing out of the clouds. Very interesting psychological experience; I had to use a good deal of mental energy to shunt the terror out of the way and used what little was left over to fly the airplane.

I've come to the conclusion that dealing with those situations is analogous to lifting weights: when you start out your ability is weak. Experience and training increase your strength but there is an upper limit. You just gotta hope you don't have to press something that's beyond your max. The likelihood can be mitigated against but not completely eliminated.

</comment></comment></comment><comment><USER19> An even more interesting air disaster is United Airlines Flight 173. Just prior to landing a malfunction caused the indicator for the landing gear being lowered to fail to indicate that it actually was lowered. The plane circled the airport while the crew concentrated on figuring out what was wrong. The plane ran out of fuel and crashed.

It's easy to get side tracked by a problem while losing sight of the big picture. That crash led to a complete rethinking of the way planes are flown.

<comment><USER20> That is interesting. I'm sure I've read of planes doing a fly-by for the control tower to assess whether the landing gear is actually down or not in situations like this. Were there reasons something like this wasn't attempted in this case?

<comment><USER21> I've just been reading an autobiography of a WWII aviator (a tailgunner in a B-17). He mentions that for planes with substantial damage, it was standard procedure to bring the plane in on its belly with no landing gear. This was because there was a good chance the landing gear itself was damaged, and if so, having it there would do far more harm than good.

If it's possible to bring in a B-17 on its belly as a preventative measure, surely it's possible to do so with a modern airliner when the alternative is a real crash.

<comment><USER22> I do not know whether you are right, but I think most successful B-17 belly landings would involve ditching all cargo (i.e. bombs) before landing. AFAIK, doing that with a modern airliner only is possible in Hollywood.

</comment></comment></comment></comment><comment><AUTHOR> The transcription from the recovered recording of the pilots is also particularly unsettling: [http://en.wikipedia.org/wiki/Air_France_Flight_447#Findings_...](http://en.wikipedia.org/wiki/Air_France_Flight_447#Findings_from_the_flight_data_recorder)

</comment><comment><USER23> One thing this is, in my opinion, missing: panic is a weird state. You might even know that what you're doing is irrational. It doesn't really help, and to make things worse, people telling you what's rational don't actually help (you know that you're not doing the right thing, you feel helpless about it already, last thing you need is people passing judgement on you).

It's a tough problem, because sometimes panic attack strikes completely out of nowhere, even a person who was previously stable, even in situations less stressful than described (there's records of people panicking while crossing a street, to the point where they couldn't move). And it isn't always completely obvious to onlookers, and it might get your co-pilot, your climbing partner, or you.

</comment><comment><USER24> > Unlike car accidents, which are often blamed on driver (and thus human) > error, airplane crashes are considered engineering failures...

Forgive me if I'm misunderstanding something about the way these accidents are investigated and understood, but directly after this the author goes on to cite Air France 447, which many of us have by now read about in Popular Science, among other sources I'm sure, wherein it's made clear that that particular flight fell into the ocean for no other reason than a persistence fault on the part of the copilot who had control of the plane. So how does that qualify as an engineering error and not simply human error? Could the author mean by "engineering" such an abstraction as the engineering of flight training?

<comment><USER25> I think it means that any crash, even if caused by the pilots fault, is seen as a fixable technical problem, either in automation, equipment, reliability, or _pilot training_.

We don't send all car drivers back to get their license if somebody crashes his car. We do try to "fix" the pilots if something like this happens.

<comment><USER26> Maybe a better term is "systems failure", where the pilot is part of the system.

</comment></comment></comment><comment><USER27> >> _The rush of steroids into the bloodstream essentially turns off unnecessary systems, including some higher thinking processes, to aid in escape._

>> _So, the next time you're in a crushing situation, remember how irrational humans are under stress and remember to FLY THE AIRPLANE._

The advice is good, but irrelevant as the article itself states it.

Maybe the first step in the checklist manifest should be to take a steroid inhibitor pill, or even better, always take some pill that only kicks in when steroids are above normal levels (if that could even be acomplished).

</comment><comment><USER28> the co-pilot _did_ fly the plane, incorrectly, for 4 min & 23 seconds. he was pulling back on the stick to climb because he didn't have all of his instruments (due to the icing of the sensor) or understand why the plane was not climbing. the reason the plane crashed was because he flew the plane wrong, not lack of flying the plane.

<comment><USER26> Flying the plane wrong is not flying. The point of the saying is to not get distracted by what's happening to the point that you fail to fly the airplane. And that's _exactly_ what happened here.

</comment></comment><comment><USER29> I found the Popular mechanics article linked to in the OP well written and far more interesting. One of my family is a retired pilot so I'm gonna show him that article. The sad thing is, if they had gotten the captain into the cockpit a couple of minutes sooner, this may never have happened.

</comment><comment><USER30> I just can't believe the stall warning sounded continuously for 54 seconds and he just ignored that. WTH was he thinking the stall warning was for?

<comment><USER31> This has been mentioned in other articles about the crash, including ones that have been posted in HN.

Under normal conditions, when the flight computer is receiving airspeed and other telemetry normally, the fly-by-wire Airbus operates under "normal law", a mode where the pilot controls the aircraft but the flight computer prevents stalling and other dangerous situations. In this case, the pitot tube was frozen and the flight computer didn't receive proper airspeed data and went into "alternate law" mode, where the pilot controls the craft and there are no computer enforced limits. The co-pilot with the controls had probably not flown the aircraft under alternate law or incorrectly believed that he was operating under normal law, and had never heard the stall warning before. So either he thought that the stall warning was false and just another instrument malfunction or he just didn't understand it's meaning in the confusion.

<comment><USER32> The flight mode is important but not the reason why they crashed the plane (IMHO). The reason they didn´t do anything else but pull the sidestick and apply TOGA was that they thought it was the solution to the problem. The problem to them was thunderstorm + fast speed variation (unreliable speed indication or no indication at all)+ autopilot disconnected. So they applied one of the most practiced maneuvers in commercial airplanes simulators the wind shear which is one of the most dangerous situations an airliner could face, and therefore one of the most practiced maneuvers(due to economical reasons refresh simulators are more and more condensed and reduced, almost no time for "basic" maneuvers like real stalls, regular manual flying, etc...).

Usually severe wind shear takes place in the presence of thunderstorms (they were flying inside one ), then there is a severe change in speed indication and wind speed(also present at the AF flight) How do you fight a windshear?. First there is a loud alarm ringing(in modern planes like the A330) + visual alarms (that wasn´t present at the AF, at least not this particular one), then you apply TOGA and pull the stick full backwards (check this video, is very well explained, also the part of the plane taking care of the stall in normal mode [http://es- la.facebook.com/video/video.php?v=1015017491047010...](http://es- la.facebook.com/video/video.php?v=10150174910470106&comments) ). The plane will flight just above the stall speed (in normal mode) and that way you´ll be able to avoid ground obstacles, as the windshear is only dangerous when flying close to the ground (take off, approach, and landing). If you have altitude enough you are able to change altitude for speed and recover the control without further problems.

Obviously the wind shear maneuver is not designed to be flown at cruise altitude, as the engines don´t have enough thrust to take the plane of the stall and keep climbing, also the plane is already very close to the coffin corner (over speed and stall aerodynamic limits are just a few knots apart), so any "extreme" maneuver (banking more than 20º or pulling or pushing hard in the controls) will simply put you outside of the flight envelope creating a control loss (usually you lose 2000´to 5000´ being unable to stop the descend), this happens also to planes entering sudden warmer zones like the ones you encounter in the tropic(due to the loss of air density).

There is a point when you simply disconnect from the alarms (no matter how many times stall or alternate law where sounding), you don´t hear them anymore (this was discovered or more studied with the Vietnam war pilots, who had very complex environments full of radio communications and SAM alerts), you only keep trying what you think will work, may it be the correct procedure, the incorrect one or just touching buttons because that damned computer is not behaving the way you want to.

Is difficult to know exactly how they suffered the problem and is also extremely difficult to judge it from a computer chair(even in simulator is well known the fact that the instructor can see obvious mistakes from the instructor chair, which the pilots are unable to recognize or detect for several minutes, once he sits in the pilot seat it is very provable that he will make similar mistakes).

What initially seem the correct actions(to the autopilot disconnection and lost of speed indication)are: to use the unreliable speed procedure(keep the throttle position and a pitch position) and then try to recover at least one of the speed indications (or at least checking which one was correct). But setting TOGA and then pulling the sidestick, this is (in my opinion) the automatic reaction to thinking they were suffering a wind shear(incorrectly), and so they keep fighting that imaginary wind shear for the long, long remaining 4 minutes till they crashed. No amount of other information or alarms took them away of that mental procedure (unfortunately), not because they where lost in they assumptions (they were), but because they thought almost all of the time (till it was too late) that they were performing the correct actions.

I must say that almost none of the pilots I know have the same opinion as me.(I am A320 pilot with B737 and MD80 experience).

</comment></comment></comment><comment><USER33> While not relevant, the yellow color while selecting text makes it unreadable. (Yes, I select/highlight the text that I'm reading.)

</comment><comment><USER34> One obvious improvement would be to replace the warning "Stall!" with "Stall! Stall protection disengaged!" when flying in alternative mode. Even better might be "Stall! Push stick forward!" when a stall is detected and the pilot is simultaneously pulling back on the stick.

<comment><USER25> I don't think more complex aural warnings would have accomplished anything [1]. (Edit) This guy basically had his brain disengaged due to panic and was useless at that point. The tragedy is that the other pilots couldn't prevent it.

The plane also warned them aurally that they were giving conflicting inputs. None of them "understood" it, in the sense that they thought about what that must have meant.

[1] Though, having the stall alarm go _off_ when the stall was too deep is very, very weird and may have contributed to the issue.

(Edit: I initially said that pilots are deeply trained to use stick down to recover from a stall - but apparently this isn't really true for commercial pilots who are trained to avoid height loss when near a stall.)

<comment><USER34> The crash report says that the second pilot and pilot (when he arrived) were both unaware that the other copilot was pulling back on his stick. E.g. at one point the other copilot had his stick forward (causing an averaging of the two inputs resulting in nose still up) and right before the crash when the copilot replies "But I've had my stick back all the time!" the other two get a shock. The warning "Stall! Push stick forward!" would therefore have saved the day, even if the copilot pulling back ignored it (and it seems he thought he was doing the right thing by pulling back, so the explicit advice "Push stick forward!" might have helped in his mental state), the other two would realise he was contravening normal response.

<comment><USER25> _The warning "Stall! Push stick forward!" would therefore have saved the day...the other two would realise he was contravening normal response._

They already got this warning through a "DUAL INPUT" alarm, among all the other alarms that went off. When the pilots panic, adding warning after warning is useless, they won't hear them anyway, let alone the nuance in the stall warning. See for example: [http://msquair.wordpress.com/2011/09/16/pilots-in-the- loop-a...](http://msquair.wordpress.com/2011/09/16/pilots-in-the-loop-airbus- and-the-fbw-side-stick/)

"it turns out that in the circumstances identified as triggering instinctive responses the value of such alerts is degraded due to the inevitable attentional tunnelling that operators experience in high stress situations."

Hell, to put it in a software perspective: popping up warning dialogs for your users is pointless, as they click them away anyway without reading.

Tactile feedback, such as the stick itself moving or resisting input, is not possible to ignore, so it's not surprising the pilots would have preferred this.

Note that even in alternate law the plane actually attempts to correct the stall by itself, so its hard to see how giving an audible warning would have gotten him to realize he was doing things the wrong way around. He was already actively working against the correction. <http://www.airbusdriver.net/airbus_fltlaws.htm>

"System introduces a progressive nose down command which attempts to prevent the speed from decaying further. This command CAN be overridden by sidestick input."

<comment><USER34> The dual input warning doesn't inform specifically that copilot 1 is pulling back on the stick. It's clear from the report that was the problem, copilot 1 was pulling back the whole time and nobody realised.

I'm not suggesting adding "warning after warning" but an improvement to the existing warning, after all, when the plane is heading for the ground the warning is "Pull Up! Pull Up!" not "Ground!". If you want a software analogy, "Stall" is akin to "Error: Read Failure" and "Stall! Push Stick Forward!" akin to "Read Failure: Insert Disk".

Anyway it's a cheap to implement improvement and could save lives.

<comment><USER25> _The dual input warning doesn't inform specifically that copilot 1 is pulling back on the stick. It's clear from the report that was the problem, copilot 1 was pulling back the whole time and nobody realised._

There is only 1 pilot at a time that is supposed to fly the plane, so the warning in itself indicates that they are in serious conflict and should clarify who is flying and what to do. They payed no attention to it. Again, hard to believe adding more _audible_ warnings would improve that, rather than make it worse.

At some point they are discussing whether they are ascending or descending, while the stall alarm is blaring throughout. I don't think anyone will consider making the stall alarm go "Stall! Losing attitude!".

 _"Pull Up! Pull Up!" not "Ground!"_

Notice how in this case they did get that warning...and it further doomed them, because Bonin started pulling back again.

<comment><USER34> "At some point they are discussing whether they are ascending or descending, while the stall alarm is blaring throughout. I don't think anyone will consider making the stall alarm go "Stall! Losing attitude!"."

Yep, but your missing the fact that they didn't believe it was actually stalled or about to stall. They thought that was impossible since normally the fly-by-wire protects against it, so that warning can safely be ignored. That is why they ignored it. It's kind of like the boy that cried wolf. Normally, the warning can be ignored and so when it started sounding when it really mattered, they ignored it. Maybe interlacing "Stall! Stall Protection Disengaged!" (when in alt mode) and "Stall! Push Stick Forward!" (when stick back) is the ideal solution.

</comment></comment></comment></comment></comment></comment></comment><comment><USER35> On a whole other topic, that's quite the footer....Dustin Curtis is a superhero!!

</comment><comment><USER36> Reminds me of the Zen story which recommends just focus on doing the next thing, no matter how chaotic or absurd the situation. "Before Enlightenment chop wood carry water, after Enlightenment, chop wood carry water."

</comment><comment><USER37> Here's my preferred version of this koan:

<http://i.imgur.com/p7WU7.jpg>

</comment><comment><USER38> The solution is not to average flight stick data. Had it not, then non panicking pilot 2 would say why the bleep are you yanking back on the stick (fleeing the scary bear) when we are losing altitude fast and stalling.

Human panicking error. he thought the 75 stall warnings were due to loss of flight speed indicators.

</comment><comment><USER39> Much better article about the crash: [http://www.popularmechanics.com/technology/aviation/crashes/...](http://www.popularmechanics.com/technology/aviation/crashes/what- really-happened-aboard-air-france-447-6611877)

I don't feel like this article has any substance, and I am particularly annoyed by the lack of contrast.

Also, see <http://contrastrebellion.com/>

<comment><USER40> The OP links to the Popular Mechanics article in the first paragraph. I don't think it was intended as a replacement for the Popular Mechanics article, but as an addition to it.

<comment><USER39> And I feel it adds nothing to it, plus it hurts my eyes, for reasons explained in my second link.

Also, pretty pathetic I'm downvoted for personal preferences and opinions.

</comment></comment></comment><comment><USER41> Just curious how many purchases popular posts like this drive on Amazon / affiliate sites. For 10k visits, is it like 1% of traffic? Or more like .1% or .01%?

Would be cool to be able to preprocess blog posts through a product search engine that had links to everything (maybe just amazon) mentioned in the blog post-- then let the author affiliate link to those products and profit!

<comment><USER42> <http://yieldkit.com/></comment></comment>


US Postal Service "Informed Delivery" will now show you scans of your snail mail - <AUTHOR> http://realmail.usps.com/ <comment><USER2> "Cost?" and "Where?" from the FAQ:

> The service is provided at no additional cost for all Informed Delivery > users.

> In the Fall of 2015 the service will be available in the New York City metro > area

</comment><comment><USER3> more here: [https://news.ycombinator.com/item?id=10688164](https://news.ycombinator.com/item?id=10688164)

</comment><comment><AUTHOR> Didn't USPS threaten a startup out of business for this very service last year?

Yup, 2013, it was Outbox [http://www.wired.com/2013/08/outbox/](http://www.wired.com/2013/08/outbox/)

[http://www.thefiscaltimes.com/Articles/2014/04/29/How-US- Pos...](http://www.thefiscaltimes.com/Articles/2014/04/29/How-US-Postal- Service-Crushed-Innovative-Startup)</comment>


30 Days of Answers on Stack Overflow - <AUTHOR> http://technicalrex.com/2014/07/14/30-days-of-answers-on-stack-overflow/

<comment><USER2> It's funny, but when you are after reputation points, then SO is very similar to app markets: one lucky or well-designed generic question ("Flappy Bird", "Candy Crush Saga") can generate and will keep generating much more "profit" than a dozen of much more useful but very specific questions ("indie games").</comment>


Ask HN: Do you internationalize/localize your apps? - <AUTHOR> Hi HN,
We are in the process of building a reporting tool that would be mostly used by sales / marketing executives to monitor ROI.
This is not a consumer facing product rather a B2B product.
We are unable to decide whether to internationalize/localize the application or not.
Here are the two approaches we are thinking
1) Launch English only for now, but plan for localization in the future
Pros:
Make the product accessible for a larger market
Cons:
Long term maintainence cost (translation would be needed for every new screen-string pair)
Seems a bit like premature optimization
2) Dont internationalize at all, given that this is not a consumer facing product
Pros: Simplify development and maintainence over long term, not having to deal with I18N
Cons: Loose out on new audience who would like to use the software in their own language
What approach would you recommend?
Also HNers whose first language is not English,
1) Roughly what percentage of software you use has option available for your language
2) Do you prefer to use software in your language if there is an option available
3) Does not having your language impact productivity while using the software.
Thanks! <comment><USER3> Tech lead of a smallish/medium saas startup here.

A couple years back sales convinced the CEO to internationalize for a European expansion... Starting with Turkish of all things.

It was a terrible waste of resources. We were still trying to find product market fit, and internationalization is a tricky, labor intensive problem. It's not just a matter of putting in hooks for internationalized strings in your code -- that's the easy part. It's setting up a great localization process that's the hard part. And even if you do a great job at building out that pipeline, it's a massive drag on the speed of developing new features. Every change needs to go through localization.

Don't do i18n until you have found product market fit, IMO.

<comment><USER4> Having built and used internationalised and localized applications for many years (answered no when asked by Netscape at the time whether I18n domain names were important), my advice is:

I18n, not that important. I.e. likely your target audience is familiar with English. L10n, more likely to be needed for the ability to use a service.

As a European user, I need at least: (1) Have weeks count as starting on Mondays. (2) Have ISO-8601 / rfc3339 date and timestamps. (3) Decimal point and (4) 1000 number separators localized, time zone indicators, (5) UTF-8 support.

<comment><USER5> Parent is spot on. Just to drive to point, I completely agree with points 3-5, on point 2 I would demand only ISO 8601, and regarding point 1 my weeks would absolutely have to start on _Sunday_. The UI _language_ is almost not even a consideration.

Now let me add point 6: Proper RTL support in user-entered strings and data.

<comment><USER6> The ISO 8601 calendar week starts on Monday. I'd be interested in reading why it's such an important point for you, though. I'm an American and having the week start on Monday makes absolutely no difference to me.

<comment><USER5> In my language we call Sunday "First day", we call Monday "Second day", and so on until Saturday which is called "Day of Rest". Additionally, our work week starts on Sunday.

</comment></comment></comment></comment></comment><comment><USER7> I've found adding it to an app after the fact to be much more work than just doing it up front.

But with that said, doing it up front even if it is less work than doing it later, is still way more work than not doing it at all. And if your app is in English your TAM is likely huge and you won't need to expand international for quite some time.

It's more than just localizing your app. You also need to do the same with your sales, support, and billing.

What do you do when you get a customer support request in a language your app supports but no one on your service team speaks? How do you get the customers in the other languages?

Also, what differences in laws regarding data protection / privacy / terms of service are you getting yourself into?

If you're charging a fee, do you need a bank account in the foreign country to charge the fee in local currency? If you do, what laws and regulations are you required to follow to get that bank account? What about tax? The US doesn't charge tax on services but many places do.

<comment><USER8> To note, all of these are not mandatory and can be done in steps as it becomes interesting to do.

You can start by having multi language support on most user facing screens, as long as you make it clear that it's mot full support and you only accept help requests in one or some of the languages.

Same with sales structures, making deals in english is doable, as long as the end user product supports their language.

Some people won't go into internationalisation because it's too costly to do it in full. I think it's ok to do it peacemeal and along the way. Most user will prefer to have some vs nothing.

<comment><USER7> > To note, all of these are not mandatory and can be done in steps as it > becomes interesting to do.

I agree with your point in general but would like to add a disclaimer. Local legal requirements if you target a specific non-domestic audience are mandatory. Sure you can skip that part and hope you fly under the radar but I wouldn't personally take that risk.

</comment></comment></comment><comment><USER9> Your pros and cons for option 1 are wrong. You don't incur the long term cost of translating all strings just by making your software localizable - <USER2> incur it by releasing localized software. (Same for making it accessible to the larger market). It should say something like "pro: reduces future cost of deciding to release in other languages. Con: may be extra work". And how big a con that is depends a ton on what technologies you're using and whether your current plan is to just hardcore strings everywhere.

</comment><comment><USER10> I think you could do a bare minimum and be ready to do more work to finalize it later if there's demand. If you think there's a good chance there won't ever be demand, then maybe it's not even worth this.

I think the bare minimum would be gettext style string marking, which is generally gettext("english string") in the source; other string marking techniques may provide a better localization, but this one is easier. Also, try to follow general guidelines for creating strings so they're likely to be localizable. Gettext's guidelines[1] are decent. You don't actually need to use gettext -- you can make a 1 line function or macro that just passes through the english text as is for now. Even if you don't mark strings, at least thinking about string guidelines will help for the future.

If you ever decide to come localize in the future, at least you won't have to markup all the strings, and hopefully you won't have done a lot of "string math" which is painful to unwind. You'll still have a big amount of work to test and fix any strings that were missed, but you'll be a lot farther ahead.

[1] [https://www.gnu.org/software/gettext/manual/html_node/Prepar...](https://www.gnu.org/software/gettext/manual/html_node/Preparing- Strings.html#Preparing-Strings)

</comment><comment><USER11> As it's a B2B app, I don't think there's a pressing need to localize. It might be interesting though to keep things localizable (not only for I18N reasons - documentation and testing come to mind)

Now, what you should absolutely DO is make sure your system doesn't break with foreign names/data/locales

Locales to test: RTL locales (Arabic and Hebrew for the most part) and maybe Turkish (the infamous dotted capital I)

Names: Chinese, Japanese, Russian, Latin Extended (ñ, œ, ø, á, é, etc), even names in English can break stuff (O'Brian)

Dates: does it work with DD/MM/YY or YYYY-MM-DD and keeps consistent?

</comment><comment><USER12> When I worked on Google AdWords, i18n was a huge deal despite it being a business-facing product. More than half of the revenue came from outside the US. I'm not sure what percentage wasn't in English, but it had to be large. I regularly got users filing bugs against me in Easter European languages or in Arabic (these seemed to maximize buggyness * number of users). So there is definitely money to be made selling to non-English speaking businesses, especially when the competition isn't.

That being said you need to actively pursue international sales for this to work, and i18n software is only a part of this. If you aren't making the effort on the sales side it probably isn't worth it on the engineering side.

</comment><comment><USER13> If you use a lowly PHP MVC framework, you'll get I18N pretty much for free. It's just a customised echo / print statement. Same for any Django, Rails app. So if what you're using is more difficult than that I'd question what you're using to build your app. Admittedly React is pretty far behind for doing I18N. i18next [0], seems quite promising for that.

The app I built had no need for languages for the first 3-4 years. Then suddenly a foreign client comes in (ours is translated into Spanish, Portuguese, Russian and Chinese) and you've got a ton of code written.

[0]: [https://www.i18next.com/#](https://www.i18next.com/#)

</comment><comment><USER14> Have you validated your MVP? (ie acquired enough initial users to know that this is a viable business idea, and commit the next few years to it).

If not, then do not worry about internationalization at all, and do just English. Validate your MVP first. At this stage, you're trying to find people who have a pressing, immediate problem to solve - and even if some of them are not native English speakers, it shouldn't be too much of a deterrent because your product will still be a godsend to them.

If you have already validated your product, or when you have done so, but it is not immediately clear what languages besides English you should pursue, then I would recommend still picking a second language to make sure that your codebase has basic, initial support for multiple languages. If you are not in a primarily anglophone country, or members of your founding team are native in another language, then pick that one (it'd be dangerous to pick a language you have no familiarity with, as a team, because high quality translators are hard to find, and translators who can work with your designers to address more subtle cultural details are close to impossible to find).

This won't solve all your problems - for instance if you support English and Spanish out of the box, but a few years later you realize you need to support Hebrew, you'll likely have work to do to support a right to left script. But at least your codebase will have initial support for more than one language, which will make the effort a little less insane.

</comment><comment><USER15> The solution is: Build support for translations into your code and only offer English as language. You can later add additional languages without having to replace every hardcoded text with a translation ID.

The most basic version of how it works: Where you want your translated text, put a function, e.g. called "T" that takes a string as argument and returns a string. The function uses this argument (translation ID) to look up the actual translation in a map.

<comment><USER16> Unfortunately that's only a partial solution. Some languages produce much longer text than English, either by using more words or just longer words. If you design the UI with only English text lengths, then you'll still need to redo the UI layout. Similar problems for languages which aren't read from left to right like English.

</comment></comment><comment><USER17> As someone with over 10 years of professional experience in g11n, I must point out few things.

First and foremost i18n is not about extracting strings to make application translatable. Before you actually do that you should think what actual markets you will be targeting. Actually, even by your rough description of what your application will do, I can tell you that the major will be cultural fit. You may think that people tend to do business roughly the same way all other the world. And nothing could be farther from the truth.

Should you ever want to sell it outside US, you should think how to suite your target users' needs. And this is much more related to behaviors / workflows than to translation.

By the way, I don't care that much if something is translated, what I care most is how things like date, time and currency is presented. This is crucial; I can't comprehend dates like 4/11 quickly.

To answer your specific questions.

1) Frankly, I have no idea about percentage. Personally I tend to use English versions if that's possible as Polish translations tend to be horrible. Well, it is usually result of concatenating strings which does not allow for re- ordering the sentence, but still.

2) I already answered to some extent. I actually prefer everything to be in one language (be it my native Polish or English). Having part of UI in English and part translated is really irritating. And as I said, following local formats is much important.

3) This depends on your user base. In case of Poland, I believe financial / marketing people will use so many English terms that untranslated app would be easier to grasp. Should you follow local formats (or allow to change them in user preferences), that is.

</comment><comment> r-s I generally do internationalize apps that I build right from the start. The cost for switching at a later date I have found to be very significant.

I do not however localize them until its needed. Often working with translators and ensuring the quality of the localized application is not a huge priority in the beginning.

<comment><USER18> I believe you, but my experience is different. IME i18n and l10n are a lot of work even if you plan on them from the beginning. For projects I've worked on it wouldn't save that much effort to architect for i18n up front. I would go with just one language until product-market fit, then assess whether it's worth internationalizing/localizing.

</comment></comment><comment><USER19> Short version - if you have to ask the question, then the answer is no.

More fully, what's your customer acquisition pipeline like? How many people on your team are fluent in another language? If the answers are "we don't know yet" and "none, except I think one guy speaks a little X", then I18N is the last thing you should be thinking about. You have access to a plenty big market just working in English, figure out how you're going to get customers and what they want first. Establish yourself as a viable business. Get as many customers as you can with your English-only app.

Once you know how to get English-speaking customers and what they want, you can at least make a reasonable estimate on what will be required to get international customers. You should already have some English-speaking customers in any country worth targeting for a more directed sales effort. That'll at least give you a starting point for people to talk to to figure out how to service those customers better and what you might need to change to operate more effectively in that country. This may include actual good translations, units and date handling, any cultural differences, legal and tax compliance, accepting foreign currency for payments and how to handle that, etc.

</comment><comment><USER20> This may not be a fair answer but being based in bilingual Canada has made localization a defacto process. We only support English, French, and have recently added Spanish so languages like Cantonese would be a challenge yet. That said it forced us to learn to structure applications with that in mind from day 1 and I'm quite glad we don't have that refactor process still ahead.

</comment><comment><USER21> I'm German and I hate half assed i18n.

Often the translation is done poorly, E.G. the word "open" has two different meanings when translated to German, depending on if it's used as a verb or adverb.

I especially used to hate the translation for git, because I couldn't understand it, since they even translated all the core concepts like "branch" into "Ast". It seems like it's better now, but there are still errors which are not translated, so the screentext is mixed German and English.

In the software I maintain I hate translations, because all the time project managers forget that I need the texts in two languages. Also there's never the perfect time to do the texts, since you almost always have to change the UI and all translations.

One tip: if you use dates, please use YYYY-MM-DD and not MM/DD/YYYY. The first format is universally understood, the second one almost always trips me up since we use DD.MM.YYYY in Germany.

<comment><USER22> > One tip: if you use dates, please use YYYY-MM-DD and not MM/DD/YYYY. The > first format is universally understood, the second one almost always trips > me up since we use DD.MM.YYYY in Germany.

Usually, datetime stringification takes a locale, and uses the formatter for that locale. Doing i18n by picking one "universally-understood" format, rather than just giving each user the format colloquially familiar to them, is rather uncommon.

<comment><USER21> You're right. This tip was meant to be used in non-localized UIs.

</comment></comment></comment><comment><USER6> I wouldn't do any i18n or l10n. It increases complexity and it's very expensive. It's also difficult to get things right unless you have someone familiarized with the target audience's culture.

Also, isn't CSS support for RTL languages kinda iffy? I've noticed that in newer versions of the spec they've begun using start/end rather than left/right, which I'm guessing is meant to help when creating bidirectional interfaces. But how well supported are these changes?

My first language is Spanish. No idea what percentage of my software supports it since I never check. I always prefer using English. Not having a Spanish option has zero impact on me.

I'd be interested in hearing arguments from the pro-i18n/l10n side. I actually have lots of questions about why certain things should be supported at all. For example, why should we support +10 different calendars instead of making everyone use ISO 8601?

</comment><comment><USER23> I don't i18n. It's a good amount of work for little benefit. I've only seen one industry capture metrics on i18n usage and that is (was?) the social games industry. All of the findings I saw pointed to the fact that even international players would prefer to play the game in English rather than their native language. I believe there's two reasons for that: to better learn English and to avoid the bugs and layout flaws that come with blindly internationalizing an app.

If you have enough customers to warrant an international version of an app, it might be worth it to completely redesign the UI around the new audience. The language used applies constraints and makes assumptions that may not be true in other languages. And then there are the culture differences...

<comment><USER24> > All of the findings I saw pointed to the fact that even international > players would prefer to play the game in English rather than their native > language.

Would love to see that. In Clash Royale there's a bug that makes it show what language your opponent is using and English is not even in majority.

<comment><USER23> What's the most used language? And does that language have its own UI layout or is it just crammed into the English language UI?

I don't think I have the raw data anymore. They don't let you keep that sort of thing when you leave. :)

</comment></comment></comment><comment><USER25> Honest answer - we don't. In markets, even with global corps using our platform English is the business Lingua Franca. The clients usually expect their users to work in English. Works for us.

</comment><comment><USER26> I used to add i18n on rails apps only when needed, because it forced to create a decent yaml schema for translations (how/where to put keys in the right namespace can be hard).

Instead, Elixir/Phoenix uses gettext, you wrap strings with a gettext call, then you run a task and it generates all the files ready for translation. This means I can still use a main language and translate it if needed, without touching the codebase.

</comment><comment><USER27> For all new projects I always use internationalization. Instead of writing something like

<button>Sign Up</button>

I simply write

<button>{{ 'Sign Up'|trans }}</button>

That way I don't need translation files (EN is default). If translation is not found the "key" is returned which is fine. Once the app is ready I call a command to create my language files and simply translate them.

</comment><comment><USER28> Can you quantify the revenue impact? Do you know your userbase at all?

You're missing some useful data that would make this decision easier.

<comment><AUTHOR> We havent yet released the product, so we dont really have metrics around usage from international users.

We could launch English only for now, making sure that the application is ready to be internationalized in the future.

<comment><USER29> That's what i'd do. launch, get feedback.

Most people understand business-english. If your team is English-speaking, chances are, you will have much much higher chance of succeeding there.

</comment></comment></comment><comment><USER30> Like others here, I always recommend to internationalize right away, but localize later only if/when you need to. Internationalization is like portability and testability--if you do it from the start, it's much, much easier than if you try to cobble it in later when your project is huge.

</comment><comment><USER31> You should launch without it, but with a framework to do it when necessary, i.e. Keep your strings file in one place at a minimum. You may find it necessary sooner than you think. For example, many governments and academic institutions cannot legally purchase non-localized software.

</comment><comment><USER32> Yes, add translation keys at a minimum now, no one wants to spend time in the future trying to i18n a product after the event, especially one that is constantly being worked on and improved and your playing catch up. It should literally cost you nothing to do as you go along.

</comment><comment><USER33> Indian by nationality here, so English is just kind of my first language; but not completely. I would always prefer software, apps, websites in English rather than my own Punjabi/Hindi language. Reason, I learned/always-used computers in English.

</comment><comment><USER34> I'm French. Most (99.9%) of my countrymen (and women ;-) won't bother with something that is not translated.

I think (but not 100% sure) that it will be the same in southern and eastern Europe.

Northern Europe should be different, they're usually better at learning English.

<comment><USER35> Same here. I've worked in B2B SaaS companies that had clients in Belgium, Portugal, Spain and the Czech Republic, and decent localization (both translations and date/currency formats) was crucial to get our clients. This has been true from two-person companies to multi-million euro companies. Unless you have no real competition, I would advise against ignoring it.

Also, if you want to land a governmental bid to provide software for some department, it might even be a legal requirement.

</comment></comment><comment><USER36> I usually just create things in english. If I then decide to ad other languages it defaults to English and I don't have to worry about having everything translated instantly. The other way around wouldn't work.

</comment><comment><USER37> If your short-term, addressable and referenceable market can use your product in English, I would focus on releasing as soon as possible, without distractions. You need to ensure you have product-market fit.

</comment><comment><USER38> Depends.

For instance, in the scientific or some high-tech branches even for some IT topics, there are sometimes no official translations of the new ideologies.

</comment><comment><USER39> do this with a sales first mindset

do you have a large customer who can fund the internationalization?

is there someone who would most certainly become your customer if you internationalized?

otherwise it's a very hopeful use of your valuable engineering resources.

</comment><comment><USER40> don't forget that full internationalization also includes taking care of layouting issues i.e. words that are longer in other languages. Characters that are higher. Right to left text.

</comment><comment><USER41> The stuff I work on uses Qt, which makes internationalisation a breeze.</comment>


Ask HN: Those making $1,000+/month on side projects - what did you make? - <AUTHOR> It can be a SaaS app, a mobile app, or any side project that is netting you recurring revenue. <comment><USER4> [http://www.brombone.com](http://www.brombone.com)

It's a service that solves SEO for javascript driven websites.

For the most part, Google can't crawl sites that manipulate the DOM using javascript (AngularJS, Backbone.js, Ember.js, etc). The solution is to use a headless browser to make html snapshots for all your pages and serve those to Google instead of the page that requires javascript.

This turns out to be a bit of a pain in practice. So, BromBone does it for you. It generates, hosts, and updates the html snapshots. When Googlebot visits your site, you proxy the snapshot from BromBone and serve it to Google. Now Google can see the same thing your users see.

<comment><USER5> Huh. I totally thought Google would penalize your ranking for trying something like that. Have you heard of that happening at all?

<comment><USER4> This method follows Google's own guidelines on Making AJAX website crawable.

[https://developers.google.com/webmasters/ajax- crawling/](https://developers.google.com/webmasters/ajax-crawling/)

</comment></comment></comment><comment><USER6> My blog at [http://erica.biz](http://erica.biz) makes more than $1,000/mo in advertising and affiliate commissions.

I built the blog after I bootstrapped and sold my first tech company. I talk a lot about growing your business/startup, and especially about all the failures I had while building my businesses. It became popular (1.2 million unique visitors last year alone.)

I've now been blogging there for just over 6 years. Today I'm more focused on my startup, so my blog isn't bringing in as much income as it used to (though it's still over $1,000/mo.) My best month was over $24,000 in income.

<comment><USER7> Have you noticed a decline related to the rise of AdBlock (and related)?

<comment><USER8> Interesting question. I read her post, checked out the blog, disabled Adblock but still didn't see any ads. So I disabled Ghostery as well and finally saw the source of her income. My initial thought was "who the hell clicks these ads?". I suppose the target group isn't people like me who use extensions Adblock and Ghostery. And people like me are (and probably most of you) - <USER2> least for now - a pretty small group among web users.

<comment><USER9> you don't have to click the ads to mean something. every time you see an ad you're most likely getting cookie retargeted as well, meaning the advertizers now can uniquely identify you across the internet. The next time you purchase something related to an ad you saw half way across the internet, she gets paid for showing you the ad.

</comment></comment></comment></comment><comment><USER10> [http://rebrickable.com](http://rebrickable.com) \- a LEGO database that does some number crunching and tells you what you can build by combining parts from all your sets. Lots of user submitted content that is also searched and can be built, everything with instructions.

<comment><USER11> easily coolest idea in the thread for me (and I posted as well). Nice!

<comment><USER10> Thanks, it's a lot of fun too :)

</comment></comment></comment><comment><USER12> I started a bag company, [https://www.missionarybag.com/](https://www.missionarybag.com/), for a niche market (young adults who leave home for 18 months to 2 years). A contract sewer here in the US makes the bags and my stay-at home wife does the shipping/handling. This is our first month to hit $1,000 profit in a month in under 6 months. After spending 12 years in software development, I wanted to create something tangible. And all the ecommerce/SEO/marketing I have helped others with over the years has come in handy - learning a lot in the process. We are looking to fill some larger orders with an overseas manufacturer.

<comment><USER13> Important to note: Missionaries are now discouraged from using backpacks, so a sidebag like this is great timing.

<comment><USER14> Tangential curiosity: Why discouraged from using backpacks?

<comment><USER15> I can't speak for the church or any particular mission, but from my experience as a Mormon missionary over a decade ago, backpacks 1) Make missionaries look like students, when they are not. 2) Are awkward on public transportation (and using them on transport is considered quite rude in some cultures). 3) Are more prone to being pickpocketed or losing things than a bag at your side/front that you can see more readily.

<comment><USER16> The first option is the one I've heard the most.

</comment></comment></comment></comment></comment><comment><USER17> [http://pizzacodes.com](http://pizzacodes.com)

My goal was to break $1k / mo by the end of this year. Last month I not only broke that goal, but more than doubled my next highest month.

<comment><USER18> That's great. I usually wade through Retail Me Not on my own, but it's time consuming to go back and forth to see what's available from different stores (and they try and hide the actual code). I'll give it a try next time.

<comment><USER17> They hide the actual code until you click on their link so they can get the affiliate traffic (otherwise people would just copy the code, and leave, resulting in no revenue for them).

Retailmenot was part of the inspiration for the site - I always found pizza coupons on their site to not be very accurate.

</comment></comment></comment><comment><USER19> I made a nest egg of $150,000 through advanced use of the "spend less than you make" framework. I invest passively with index funds. I average about 6% annually, but this year was significantly more than that. Easily $1k/month.

<comment><USER20> Is that from dividends or growth of capital? 2013 is definitely a historical anomaly when it comes to returns, not hard to do well when the S&P 500 is up 27% YTD

</comment></comment><comment><USER21> A good old fashioned web site which ranks high for a resort town which has a lot of tourists who don't know where to eat so they search in the Google. My next venture is a run on sentence shortening service.

<comment><USER22> do you make money from the restaurants advertising directly or adsense etc?

<comment><USER21> Direct only. Our competition is tripadvisor, it a david and goliath situation, even though we specialize in just one area for one thing. My friend owns a similar site in a much larger demographic and makes a lot more, but be advised.. this works mainly because of salesmanship and ranking well, the per month hours are now very minimal (5-10).

<comment><USER23> So, do you call the hotels/restaurants and try to sell banners/ads?

</comment></comment></comment></comment><comment><USER24> I run [http://postertext.com](http://postertext.com). We design art prints for bibliophiles. All illustrations are made entirely out of text.

I've been running it while traveling the world for 3 years non-stop now. Check out my AMA on reddit if you're interested: [http://www.reddit.com/r/IAmA/comments/1rneli/ive_been_travel...](http://www.reddit.com/r/IAmA/comments/1rneli/ive_been_traveling_around_the_world_for_3_years/)

<comment><USER25> I bought a couple poster texts about 3 years ago. They're awesome :)

<comment><USER24> Thank you for your business!

</comment></comment></comment><comment><USER26> I run a forum (historic vehicles) members donate to see additional content, mainly old posts and bigger images, this is the primary income. Our recurring income is in that range.

Certainly not hi-tech but valuable to our membership and increases by at least 10% each year.

We don't run any keyword advertising but in the past year I we started selling advertising space in 12 month plans which has supplemented income.

Facebook has taken a bite out of our daily posting figures but it has made no difference to traffic/income. Facebook can't compete when it comes to delivering old content.

There are several associated niches to ours which don't have a centralised web site, much potential, you do however need a good knowledge of the subject matter and time to build the community.

</comment><comment><USER27> I made an Android app, Unlock With WiFi, three years ago. It has brought in about 64K over that time. The app unlocks your phone when you're connected to your home wifi. I'm currently working on a complete rewrite that will support patterns and face lock for root users.

[https://play.google.com/store/apps/details?id=com.benhirashi...](https://play.google.com/store/apps/details?id=com.benhirashima.unlockwithwifi)

<comment><USER28> Great idea.

</comment></comment><comment><USER29> [http://www.shipadick.com](http://www.shipadick.com) \- no joke. They sell themselves.

<comment><USER30> Ha. Gotta love sh*t like this. Hilarious Probably most sales from college kids

</comment></comment><comment><USER15> I built and sell a collection of plugins for the Delphi IDE at [http://www.twodesk.com](http://www.twodesk.com). (Yes, people still use Delphi), for a consistent single-digit multiple of $1K each month.

<comment><USER31> That is AWESOME... back in 2000, I was writing a vertical app for an oil company using Object Pascal/Borland Delphi (it was still Borland... and Kylix... at that point) It got me using Interbase/Firebird/FirebirdSQL for a couple of years. Glad to hear it's still around.

<comment><USER15> Thanks! I've been doing this since 2002. It's a fun project and a very interesting business to be in.

</comment></comment></comment><comment><USER32> [https://coderpad.io](https://coderpad.io) is a SaaS product I built that provides the highest fidelity experience out there currently for interviewing other programmers over the phone.

I got to my current rev with a mix of self service plans and enterprise deals.

<comment><USER33> I use coderpad.io for remote pair programming interviews. Great work!

</comment></comment><comment><USER34> I built and run the internet sales for my fathers and friend company and both produce over $1k a month for me: [http://bluebidet.com](http://bluebidet.com) and [http://naturalsinsonline.com](http://naturalsinsonline.com)

</comment><comment><USER35> In my spare time i make more than $1,000/mo designing and building Android Native Applications for companies and businesses. Is hard to balance your time between your day-day job and your personal projects but i think is possible with a good management of time.

<comment><USER36> Cool. How do you find clients? Its one of the biggest challenges I have to deal with.

</comment></comment><comment><USER37> My mobile app, Routesy ([http://routesy.com](http://routesy.com)), falls into this category through a combination of sales of the paid version and advertising in the free version. It was one of the first 500 apps in the App Store when it launched in 2008 and has been pretty consistent in its earnings ever since then.

<comment><USER33> Thanks for Routesy, I use it most days. :)

<comment><USER37> Aww, thank you. That always makes me feel good to hear.

</comment></comment></comment><comment><USER38> [https://snipcart.com](https://snipcart.com)

It is a shopping cart service developed for developers and web design agencies.

This is the a side project we have with the team @ spektrummedia.com.

We are up and running since last August, we won the site of the day on Awwwards.com back in August and then we have a lot of traffic and we are getting new customers everyday.

</comment><comment><USER39> A music album I made fits that description, although it is winding down, as to be expected: [http://lifeformed.bandcamp.com/](http://lifeformed.bandcamp.com/)

Via album sales, Spotify streams, iTunes, etc, all done through TuneCore ([https://www.tunecore.com](https://www.tunecore.com)).

<comment><USER40> Cool album. How did you get a big enough audience to make real money from this? Was it just word of mouth from making good tracks? Or was it also from doing shows or reaching out to music blogs or something?

<comment><USER40> Nevermind, I got it: [http://www.google.ca/trends/explore#q=lifeformed%2C%20dustfo...](http://www.google.ca/trends/explore#q=lifeformed%2C%20dustforce&cmpt=q)

<comment><USER39> Yup, it was mostly piggybacking off of the game itself. Also, it was in a Game Music Bundle, which got another $10k in a week.

</comment></comment></comment></comment><comment><USER41> I make quite a bit more than $1k a month from Duet - [http://duetapp.com](http://duetapp.com)

It's a project management app for freelancers and small businesses. Hopefully one day soon it will be more than a side project.

<comment><USER42> Good on you! Curious to know how do you market & promote the app, considering that project management is a very competitive/saturated market segment?

<comment><USER41> It's very difficult and I'm still figuring it out, but I get a decent amount of traffic from the free version [http://getsoloapp.com](http://getsoloapp.com).

<comment><USER30> Freemium model almost always works best! Best of luck

</comment></comment></comment></comment><comment><USER43> [http://www.supportfu.com](http://www.supportfu.com) \- SaaS. bootstrapped.

</comment><comment><USER44> I was making ~$3k/month with [http://myapptemplates.com](http://myapptemplates.com). Recently sold it. Now working on an ad tech startup.

</comment><comment><USER45> I make ~$2.5k a month from my simple iOS apps [http://www.bytesizeapps.net/](http://www.bytesizeapps.net/)

<comment><USER46> Very clever 4 in a row game! Makes me want a 5c.

<comment><USER45> Thanks!

</comment></comment></comment><comment><USER47> Kickstarted a Python course (now 2, soon to be 3 courses) - RealPython.com

<comment><USER48> My work VPN blocks this as porn. Ha!

<comment><USER47> Oof, good to know... Any other false positives you've had so I can maybe figure out why?

Edit: Never mind, I think your censorware might just have a more inventive sexual imagination than I do when it comes to domain names...

<comment><USER49> Not sure it would be related, but python.com used to be a _startling_ high-res extremely NSFW spread that you really didn't want to accidentally visit in a public setting when you really wanted python.org...

(They are now 'no longer accepting new affiliates' though, and the pictures are gone.)

</comment></comment></comment></comment><comment><USER50> Adult comics - [http://www.8muses.com](http://www.8muses.com)

<comment><USER51> How did you obtain the right to distribute jab comix for free?

</comment></comment><comment><USER52> This is my brand new project: [http://metrics11.com/](http://metrics11.com/) It helps you find profitable keywords niches you can use on your site to get free traffic from Google. It shows you how many people search for given term per month in chosen country, what is competition for that term, and other metrics like trends or domains availability. We focus mostly on competitors metrics. I think it is the most comprehensive keyword research tool on the market right now. Try the demo on the front page.

</comment><comment><USER53> getsentry.com - <USER3>

<comment><USER54> How long has the sentry app been live? It looks pretty useful.

<comment><USER55> The company I work at uses it across all products - Javascript and PHP. It's super handy and has helped us find bugs before our users! Definitely recommend giving it a shot since you can have Sentry logging your Javascript errors in 2 lines of code.

</comment></comment></comment><comment><USER56> My first software product I launched on the side 5 years ago still makes quite a bit more than $1k/m (and that's in non-recurring revenue). Its best month was more than $15k while I was working full time. I was able to quit my corporate job back in February to focus on some new products.

<comment><USER57> Can you share what the product is?

</comment></comment><comment><USER58> A service that helps businesses recover from Google Penguin penalty. The number of websites using poor link building and seo practices is unbelievably high. I help them undo the poor practices and recover/prevent from Penguin penalty.

<comment><USER59> How do you identify your leads?

<comment><USER58> Mostly through referrals from existing clients. Also, got a few clients from various blogs and forums.

</comment></comment></comment><comment><USER60> Have you thought about some kind of drop shipping business? Find a vendor, make a store on Shopify/Volusion/BigCommerce, whatever. A lot of items can have 50%+ margins while still staying within range of competitors.

<comment><USER30> promoting it is the hard part. You also have to beware of the bargain basement shoppers that will vampire you

</comment></comment><comment><USER61> My side project : [http://html5portfoliotemplate.com](http://html5portfoliotemplate.com) is generating some revenue. (not closer to above mark but in next few months it may reach there)

</comment><comment><USER62> [http://www.visadoor.com](http://www.visadoor.com) Visadoor lets you search through employment based green cards petitions and H1Bs. I make a couple of hundred dollars from adsense.

</comment><comment><USER11> 1\. Niche music site monetized with apparel sales

2\. Network of content sites monetized with ads

</comment><comment><USER63> [http://best.ly](http://best.ly)

It's a SaaS providing A/B testing for mobile apps that started out as a side project.

</comment><comment><USER64> I started [http://buildtracks.com](http://buildtracks.com) as a side project. Now working on it full time.

</comment><comment><USER65> I made a course and documentation management, and grading system for speech pathology students. Netted me >12k last year (before tax).

</comment><comment><USER66> I made a service where I find leads for other freelancers. Something I desperately wanted for my own freelance biz.

<comment><USER67> Any chance of posting it here? I am sure people on this site would find it useful.

</comment></comment><comment><USER68> I wrote a short book on Ruby ([http://dmtri.com/posts/65/just_enough_ruby_to_get_by](http://dmtri.com/posts/65/just_enough_ruby_to_get_by)) for beginners. I wanted to publish it via LearnPub originally and earn some money, but I decided to release it for free instead.

<comment><USER69> And how is it generating revenue?

</comment></comment><comment><USER70> Personal blog: [http://ashishb.net/](http://ashishb.net/) Makes money from adsense. No where close to 1K/month but growing towards that.

<comment><USER71> I bet you're making no where close to 1k. There's no ads.

<comment><USER72> found the ad, it's waaaay down the footer

</comment></comment></comment><comment><USER73> A tiny Zombie Shooter (www.snipezombies.com)

</comment><comment><USER74> builtwithbootstrap.com

</comment><comment><USER75> \- I will like to thank everyone for their contributions. I have learnt so much from Hacker News.</comment>


Google CEO bets Scoop could be the next Facebook on campus - <AUTHOR> http://social.venturebeat.com/2010/08/23/scoop-eric-schmidt-tomorrowventures-trumpet-technologies/

<comment><USER2> I'd also like to point out that Trumpet is hiring and has a fantastic office environment. If you have any questions feel free to ping me.</comment>


Git Whore – Find the ones doing less everyday ..do not trust the blabber - <AUTHOR> https://github.com/Idnan/git-whore <comment><USER2> So is being a git whore a good thing or a bad thing?

<comment><USER3> apparently it is a bad thing if you read the description.

"do not bring it up in front of your team or they might end up committing meaningless stuff just to avoid being whore ;)"

I think this project is a stupid idea, if nothing else it will incur the wrath of the SJW and his reputation might be forever marred whatever the intent behind the project might be.

<comment><AUTHOR> Why are you all criticizing? I explained in my project that its just for fun "Project was made just for fun and the number of commits is never the window to who is doing more and who is doing less." Not to show who is doing less work or more.

<comment><USER4> What does the name have to do with sex work.</comment></comment></comment></comment>


Get your fix of new music, movies, & books every month - <AUTHOR>

Hey y'all, We've just launched our new venture, Moshbag beta (http://moshbag.in) for all ye musicados, filmatoes, & bookies.
What's it all about? Every month, Independent musicians, film-makers, & writers from around the world upload their their new & unreleased singles, movies, and books on Moshbag. & You! Lucky You! get to download it all at the end of each month for a small subscription fee.
Looking forward to receiving your comments & feedback!
P.S. If you also happen to know some awesome musicians/writers/filmmakers personally do share this with them & help us out! <comment><USER2> Europe is covered ?

<comment><AUTHOR> Barret, YES Europe is covered! :)

Thanks for taking the time!</comment></comment>


Show HN: My GPL/Creative-commons xmas game. (Github link at bottom of page) - <AUTHOR> http://dalliance.net/xmas2011/

<comment><AUTHOR> Mostly creative commons blender models sourced from opengameart.org and blendswap, Jamaendo sourced music.

Built it weekends and evenings in November as an experiment to see what came out of starting coding with no aim other than "Something xmasy built from creative commons things" and then coding based on what I found through searches.</comment>


Strong opinions, weakly held. - <AUTHOR> http://unspace.ca/blog/strong-opinions-weakly-held/

<comment><USER2> I think a key statement is missing from this which is that the opinions should only be weakly held in the face of little information. Once you have convincing evidence, you should also hold your opinion strongly.

<comment><USER3> People should only have strong opinions because they have convincing evidence. The point of the statement is that despite the fact you have convincing evidence from your perspective, you need to consider the possibility that your perspective is biased and that your opinions maybe invalidated as the problem scope and externalities evolve.

It's very hard to work with people with strongly held opinions, especially when there are more than one such people in your group.

</comment></comment><comment><USER4> "It's a deer". Blam blam blam. "Oh, sorry dude"

Sometimes you need to sure.</comment>


Why drivers in China intentionally kill the pedestrians they hit - <AUTHOR> http://www.slate.com/articles/news_and_politics/foreigners/2015/09/why_drivers_in_china_intentionally_kill_the_pedestrians_they_hit_china_s.html <comment><USER2> Is this credible? This sounds extremely horrific -- warranting immediate changes of law.

<comment><USER3> Credible? Video evidence of these cases is everywhere - and for the very reasons stated. It's often cheaper to kill than to injure.

This is also why if you are injured - nobody will help you in China. If they save your life, they're responsible for your well being/medical bills. So people will let you die on the street.</comment></comment>


The 3 Basic Tools of Systems Engineering - <AUTHOR> http://teddziuba.com/2010/12/the-3-basic-tools-of-systems-engineering.html <comment><USER2> The "you fucked up somewhere" without any explaination of his opinion makes this piece look childish.

<comment><USER3> he assumed most of his readers are smart enough to know where "somewhere" is.

<comment><USER4> I'd say "demands" more than "assumes."

The "somewhere" is, of course, in one of the previous steps. I agree with him that there are vanishingly few legitimate[1] use cases where a queueing system is the right solution.

More, but only ever so slightly, more frequently, a spool is called for, and that can be loosely simulated by a queue.

[1] This excludes situations of ones own making, such as designing a system that requires asynchronous but ordered execution in the first place.</comment></comment></comment>


SEC Issues First ICO "No Action" Letter - <AUTHOR> https://www.sec.gov/divisions/corpfin/cf-noaction/2019/turnkey-jet-040219-2a1.htm <comment><USER2> What is the point of the token then? It's simply a presale tool?</comment>


Deleting data distributed throughout a microservice architecture - <AUTHOR> https://blog.twitter.com/engineering/en_us/topics/infrastructure/2020/deleting-data-distributed-throughout-your-microservices-architecture.html <comment><USER2> > First, you'll need to find the data that needs to be deleted.

Microservices do not get you out of having to have an information architecture. They add more friction if you don't have one, but it's entirely possible to have an unspoken/undocumented information architecture that mostly works.

If you don't have a System of Record for data, you for sure aren't going to be able to find it. Similar problem with no Source of Truth. For some business models you will have both and they will be separate (especially with 3rd party data).

You still have the problem of logs, but at least the problem is tenable. Without any of this it's just chaos and who knows where the data went or really even where it came from?

<comment><USER3> It's also possible to completely automate this. Flow.io has a great talk where the CTO talks about everything they do from an engineering perspective. Just annotate data in your API spec language as PII. This can allow you to also have policies that can be verified by this. If some advice has PII you can enforce that some other service can never talk to it, for example.

<comment><USER4> Link? I would love to see this as excuses not to do so come up often at work, sigh.

<comment><USER5> I'm pretty sure they're referring to this talk: [https://www.youtube.com/watch?v=j6ow- UemzBc](https://www.youtube.com/watch?v=j6ow-UemzBc)

</comment></comment></comment></comment><comment><USER6> My favorite approach is encrypting all of a user's data (everywhere) and just deleting the key from a central store instead of actually erasing.

<comment><USER7> What's the problem with actually just deleting this data when you're done with it though?

<comment><USER8> Because FKs on a relational model.. as an example, deleting a user/account might end up being a task on going through every reference to it, and the references to its references, etc.

This is actually the reason some companies do not delete users/accounts [0].

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

</comment></comment></comment><comment><USER9> One should really consider DevSecOps when dealing with a large infrastructure involving dozens or hundreds of micro services. Security as Code by design should be implemented as soon as possible. In my current gig - the following 3 points are key:

\- 24x7 Proactive Security Monitoring

\- Shared Threat Intelligence

\- Compliance Operations

I would really advise anyone interested in this subject to check out DevSecOps manifesto [1].

Also - if you are running a k8s cluster for all your micro-services, there are several guides online as to best practices (see [2] for example).

\</comment><comment>----

[1] [https://www.devsecops.org/](https://www.devsecops.org/)

[2] [https://dev.to/petermbenjamin/kubernetes-security-best- pract...](https://dev.to/petermbenjamin/kubernetes-security-best-practices- hlk)

</comment><comment><USER10> This is relevant for enterprises with legacy systems, too, like shops that have multiple interfaces that extract, transform, and load data across point- of-sale systems, warehouse fulfillment systems, and data warehouses.

</comment><comment><USER11> This gives me nightmares about having to retrofit GDPR requirements into a complicated system with many data stores and applications. Not only the difficulty of ensuring data is deleted but tracking data lineage so you can delete derived data too. Fun times!

<comment><USER12> > This gives me nightmares about having to retrofit GDPR requirements into a > complicated system with many data stores and applications.

This is true when the domain is not well defined, that is the case for many legacy systems. Usually this systems have also problems with de-normalized data where there is several copies of the same entity across the system. Copies get out of sync.

I do not think that nowadays is as common as it used to be. When I was a kid, I saw many systems where you had "customer" data that was replicated in the two or three applications that were using it. Then, maybe at night, some task will "make sure" that all the data was on sync or in real-time with triggers in the database. Applications that were not part of this synchronization will pop up, some fields will be in one application but not in another one, etc. Bad-defined domain objects and identifiers will make sometimes fields too small to fit the original data, being in the wrong format (text vs numeric) or miss unique keys and duplicate rows.

Q: "Can you send a mail (stamp-based-mail) to everybody that works the Christmas shift?" A: "No. That data is in the scheduling system. We can only send mails from the Human Resources system as is the only one that stores the address".

I hope new generations of developers do not find themselves in this situations, but they will need to maintain the many legacy systems that still live way beyond what anyone expected.

</comment></comment><comment><USER13> This will help us [https://bitmovin.com/finding-memory-leaks- java-p2/](https://bitmovin.com/finding-memory-leaks-java-p2/)

</comment><comment><USER14> My company recently decided to switch over to microservices. It was a long an arduous process but we chose not to compromise.

Basically for the greatest amount of modularity, we divided all 400 functions in our monolithic application into 400 individual servers because obviously functions aren't modularizing everything enough. You really need to put more and more wrappers around all of your functions. First put a framework around your function, than put an http api layer around it, then wrap a server app around it, then put an entire container around it and boom! More wrappers == Less technical debt. To illustrate how this works see example below:

       wrapper(
         wrapper(
           wrapper(
             wrapper(
               f(x)
             )
           )
         )
       )

See that? Obviously for every additional wrapper you add around your original function your technical debt becomes less. This is why it makes sense to make to not just use functions to modularize your data but to wrap all your functions in containers and then put those containers in containers.

Now all 400 of our engineers each as an individual manages one entire function within one entire container. It's amazing, they don't have to think about two things anymore, they can just concentrate on one thing.

While I'm not sure what has improved yet, everything feels better. Our company is following industry trends and buzzwords. Technical debt actually went up but that's just our fault for building it wrong.

Some engineer asked me why couldn't we just load balance our original monolith and scale it horizontally. I fired that engineer.

Another engineer came to me and told me that for some function:

       func some_func(a: int, b: int) -> int: {
          return a + b
       }

It's probably better to do 1. instead of 2.

       1. Call the function: some_func(2,3)

       2. Make a request: request.get("http://www.pointlessapi.com/api/morecomplexity/someextratechnicaldebt/randomletters/asdfskeidk/some_func?a=2&a=3")
       and parse the json:

       {
         "metadata": {
             "date": "1/1/2020"
             "request_id": "123323432",
             "other_pointless_crap": ...
             "more_usless_info": ...
             "function_name (why?)": "some_func"
         }
         "actual_data": 5
       }

I fired that engineer too. Obviously 2. is better than 1. Also why am I using JSON? Not enough wrappers! You have to wrap that http call in additional wrappers like GraphQL or GRPC!!! (See wrapper logic above).

Have you guys heard of a new trend called Sololithic architecture? Basically the new philosophy states that all of 400 of our microservices should be placed in 400 containers and run under a cluster of 399 computers under kubernetes!

I may not understand where technical debt comes from and I also may not understand how all these architectures will fix the problem of technical debt forever... I know that industry trends and buzzwords are more intelligent than me and monoliths are bad bad bad and obviously the source of all technical debt! Just cut everything into little pieces and technical debt becomes ZERO.

Right? The technical definition of Technical debt is not enough cutting of your logic into tiny pieces and not enough wrappers around your modules so all you need to do is cut everything up and put wrappers around it and problem solved! Makes sense!

<comment><USER15> You used words like "buzzwords" which makes you sound facetious. I know you aren't, but others could get the wrong idea. This is a very useful piece of advice that should be taught in CS 101.</comment></comment>