Be Kind - <AUTHOR> https://www.briangilham.com/blog/2016/10/10/be-kind <comment><USER5> When he returned to the air field, Bob Hoover walked over to the man who had nearly caused his death and, according to the California Fullerton News- Tribune, said: "There isn't a man alive who hasn't made a mistake. But I'm positive you'll never make this mistake again. That's why I want to make sure that you're the only one to refuel my plane tomorrow. I won't let anyone else on the field touch it."

<comment><USER6> There are two schools of thought, especially in stock trading.

1) Reversion to the mean. This is what the above person believes and that this likely won't happen again.

2) Indication of a trend. The pilot is actually incompetent, and this will happen more frequently with this pilot than an average pilot.

<comment><USER7> I know you're probably not implying regression to the mean is causational, but that was my initial reading so I want to clarify for those who may not be familiar with the concept.

Regression to the mean is simply that any given datapoint is most likely to be the mean, or close to it. This means that any exceptional data point,up or down, can be expected to be followed up by the mean.

The example of this being misinterpreted that I am familiar with is that of a flight instructor's belief on training. When a pilot performed well, they wouldnt comment. If a pilot performed poorly, they would be punished. They believed this was better because when they praised a pilot, they would usually do worse the following run, and when they punish them they do better. This isn't technically wrong, they are just ascribing causation where there is none. I think I saw this example in Signal vs. Noise, but I'm not sure.

Basically, regression to the mean isn't a reason to pick someone who did poorly, it's a reason that that person will do no worse or better than they do normally.

<comment><USER8> Yeah, I always make an example with coin flips to show how this is true.... lets say heads is success and tails is failure.

Flip 100 coins. Take the ones that 'failed' (landed tails) and scold them. Flip them again. Half improved! Praise the ones that got heads the first time. Flip them again. Half got worse :(

Clearly, scolding is more effective than praising.

<comment><USER9> Except, coins are not humans with emotions, and neither can they dupe probability to improve their outcome. The 50 heads(success) that you left are not going to do any better than the 50 tails you scolded. You are just changing the sample space in a biased fashion to prove your point.

<comment><USER8> I think you are totally missing my point. The whole point I am trying to make centers on the fact that the coins are all actually equal. The observed difference in performance is entirely due to chance.

While, of course, human performance is not always equal in the same way our coins are, the fact that performance (or whatever it is you are measuring) will still regress towards the mean still holds true. The coin example just gives an extremely obvious demonstration about what is happening when things regress towards the mean.

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

</comment></comment></comment></comment></comment></comment><comment><USER10> This was so nice to read. I think back to my very first coding internship after my freshman year of college when I messed up big time. I made a bad mistake that ended up forcing my supervisor to put down everything he was working on for a full afternoon and do an emergency fix. I so vividly remember sitting down in his office, trying to just calm down and keep it together. He never got upset or annoyed (at least he never showed it), instead he listened to me explain what I had done, figured out what was wrong, showed me what my mistake was, fixed everything up, and calmly walked me through the entire process, turning it into a learning experience. At the end he asked me some questions to make sure I understood everything that happened and told me "everyone makes mistakes, don't sweat it, just make sure you learn from it" and that was that. I remember leaving his office that day thinking "if I ever make it to the point where I have my own interns, I'm going to do everything I can to support them and treat them as well as he treated me." A little kindness really does go a long way!

<comment><USER11> when a supervisor gives a freshman work which can mess up erverything it is the supervisor's fault and not the fault of the freshman

<comment><USER12> Why do you need to assign blame?

My opinion is that trusting people and giving them responsibility is one of the best ways to let them learn and grow. The bigger the mistake, the bigger the lesson. As long as it is possible to recover, it's a calculated risk which may well be worth it.

</comment></comment></comment><comment><USER13> As software engineers:

As beginners, we're over-confident in our ability, even if we actually suck and make lots of mistakes: [https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect](https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect)

The opposite seems to become true - experienced engineers (who have learned from their mistakes) seem to be extra paranoid. I've seen also older engineers that seem to be confident still, talk a bit game, but they just never learned. It seems paranoia is a great indicator of experience, and over- confidence/arrogance is an excellent indicator of a lack of learning. Not to say those are the rules, as there are certainly arrogant engineers that are excellent but I'd rather work with the softer one personally.

I know as I have grown I have become softer, not harder, as I realize my humanness.

<comment><USER14> Overconfidence is a huge benefit in playing the political game - <USER2> people to take you seriously, managing up, interfacing with the outside world. Like it or not, humans are primed to respond to confidence; for most people, listing the dozen ways a system may fail signals that you shouldn't use the system, while for engineers, it signals that these are a dozen things to be fixed.

The trick - when getting to higher levels of technical management - <USER3> learning how to context-switch between being overconfident for the benefit of non-technical stakeholders and being paranoid with the technology so that the things that could go wrong don't actually go wrong.

<comment><USER15> This is why I don't really want to get back into management, even though sometimes I think at some point it will be the only thing I'll have the patience and mental capacity to do. I saw the best and worst of myself when I was a manager- the worst is what scared me. But moreover, I learned after I stopped being a manager that I didn't deserve the accolades I got. If you were to take the best manager in the world, give him/her a shitty team, a hell of shitty code, shitily designed application and infrastructure, a shitty relationship with the customers/users, shitty support team, and shitty project/product/upper management, and you don't let that manager work to fix these things, they'll quit or fail, guaranteed. If you give them the best of all of these things, they will succeed, guaranteed. Being a good manager- knowing how to manage well and doing it, can be critical. However, it is nothing on its own.

<comment><USER16> One big difference is that a good manager can take an average team and build a good team over time. If you can't do that, you aren't a good manager.

A manager that can't tell who on their team is good will (in the long run) take an average team and turn it into a bad team.

</comment></comment></comment></comment><comment><USER17> This was literally the biggest issue for when I started at my first job. We had a team member who was terribly condescending and talked down to everyone but especially me. You could tell that he hated the fact that he was on a team with a junior developer and took every chance he had to made sure I knew I wasn't as good as him. It makes a terrifying environment to ask questions because who knows what kind of response you're going to get.

<comment><USER18> Oh his behalf, I apologize. I literally started laughing at a junior's code once but in my defense, he had spent 3 years at Amazon.

<comment><USER19> I'm sorry, but you have no defense. Laughing at a junior developer'a code is completely inexcusable.

Simple fact is, if you worked for me, I would have fired you for that. Junior devs are supposed to do bad things - that's why they aren't senior devs.

<comment><USER20> I think you're quite possibly judging the guy too much based on a simple internet comment.

His statement could mean anything from cruelly laughing in the face of the junior dev during a face to face code review to having a quick heh under his breath from the privacy of his office at the developer's use of "if (foo === true)". Or anything in between.

<comment><USER21> If it was a completely private laugh, seems weird that they would apologize for the previously mentioned jerk.

<comment><USER22> Due to open office layouts there is no such thing as a private laugh.

</comment></comment></comment></comment></comment></comment><comment><USER23> Nice little read. There is that little answer in the back of my head of:

"It is a good question why I caused this problem. It is weird to think there is a competent company that has been around for so many years, yet they have no procedures in place to stop this from happening. You would think that any changes that could cause downtime on a clients website would go through an automatic test suite and only after passing all tests would it be tested by human QA and finally made live. In this particular case I am the one who has made a mistake, and being a sensible person who is eager to constantly better myself, I will try and learn from this error, however I work alongside dozens of other people on my team who like me, have every chance of making a mistake at some point. It seems like a bad policy for us as a company to say that we should expect every person on the team to break a clients site and then rely on overtime from other people to fix it. So of course I will try and do better, but this is not fixing the root of the problem, the root of the problem is something that needs to be fixed at a much higher level. Have you, as my boss, not considered this problem already? What has the company learned from this? I would be happy to be part of the team that solves this problem by creating unit tests and creating policy to avoid this."

Of course I purposely make this slightly stand-off-ish, over the top, and written from a very specific perspective, to illustrate a point. But the reason I do this is I absolutely agree a single developer shouldn't feel bad about making a mistake (they should try not to, but these things happen), but the company should put measures in place to minimise the impact of mistakes. When the company fails to do this, the company has screwed up a lot more than the developer.

<comment><USER24> Think of what you're saying on a meta-level here. You would basically be telling this guy, _" I fucked up, but I'm blaming you for treating me like an adult instead of a child. You screwed up by giving me enough autonomy that I could make a mistake."_ That might not exactly be a smart career move..

On a more personal level, if someone shows you kindness in the face of a mistake, the last thing you want to do is throw it back in their face and go on a tirade against them. That's a very quick way to make sure nobody ever wants to work with you again.

<comment><USER25> I disagree. If you have something that is of significant value to the company, you need to hedge your risk. Automation is a particular hedge. People fail, and while processes do too, they often fail less.

Would you be comfortable moving something fragile by hand that is worth a lot of money? Maybe. Would you prefer if the fragile item being moved was done with an automated process that was shown to best protect fragile items? I would.

"I'm really sorry I caused that car accident." "That's okay, next time take Driver's Ed and don't drive on sidewalks." "Thanks, I'll make sure to do that... by the way, why can I even drive on the sidewalk in the first place? Why wasn't it required to take Driver's Ed?"

I'm very obviously using hyperbole here, but questioning a process, to me, often shows a level of maturity in engineering. It's not blame-shifting - <USER4> clearly still made the mistake - but it's fixing a root cause.

I do think it has to be brought up carefully and with the right tone at the right time though.

<comment><USER26> I think you've hit the nail on the head at the end with "right tone at the right time" \- the right time is almost certainly not when one has screwed up.

<comment><USER27> Or if you think it can and should be fixed at that institutional level tell them what you've learned to do better on a personal level and then volunteer to help lead the effort to create the automation/systems to prevent anyone else from making the same mistake in the future.

</comment></comment></comment></comment></comment><comment><USER28> One way to avoid Friday deployment issues is to go to the pub. Obviously you need to spend all afternoon there and not be tempted to go back and deploy, otherwise issues may be compounded! It seems to be a common mitigation technique in some shops I've worked at ;)

<comment><USER29> I can confirm it is an approach taken by different companies out there.

I used to work for this company where every single Friday we would go out for lunch and get tipsy (wine with the food, some digestive liquor shots just at the end, then maybe a mixed drink or a beer at another bar) because we were the only team not allowed to go home early on Friday... for no reason. Mind you, we were some kind of internal IT team and there would be no one to request anything from us, so we never had urgent stuff to do.

Back in the office we would enable the "fire extinguisher mode" which meant "only move if there's a fire" and watch silly videos in Youtube, have some coffee with Baileys because why not...

</comment></comment><comment><USER30> I hope Kevin learned not to let a junior dev deploy to production on Friday.

<comment><USER31> Well, he'd have to sooner or later. Better start learning as soon as possible :)

<comment><USER32> Nobody should be deploying to production on Friday... Nobody.

<comment><USER33> My company just had to do it today in response to a critical security issue we identified in production.

Saying that nobody should ever do it isn't realistic, sometimes things go wrong on a Friday, sometimes you can't afford to wait 3 days to watch them become even worse.

<comment><USER34> IMO, if you deploy on Friday, you are promising to be available for fixing it on Saturday... which makes it not really a Friday in the sense in which it's meant.

Don't deploy when you won't be around to support it is a better description; but it doesn't roll off the tongue as easily.

<comment><USER35> So I should just leave a security vulnerability rather than fix it on a Friday, because I won't be available Saturday?

<comment><USER36> Read to comprehend, not to argue.

<comment><USER37> Great, _now_ what am I going to do with my life?

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER38> The reverse takeaway is perhaps even more valuable. Most are not going to be as angry as you expect them to be. When you mess up don't hesitate to tell people, it's going to be okay.

<comment><USER39> This is pretty much rule #1 for my team. If you make a mistake, I'm not going to yell at you, but

1) If you try to _hide_ the mistake I'll be mad. As soon as you know there's a problem, we can mitigate the damage by addressing it immediately.

2) I want to see that you're learning from it. A pattern of repeated mistakes may take some explaining.

</comment></comment><comment><USER40> Most of my career I've been the guy people come to when they get stuck and need a second pair of eyes or just advice. I enjoy it, we all have to start somewhere. For the most part this has been considered a positive by my bosses, because they see the value this creates even if it's not technically my core job.

I did however once work at a company that was very metric-focused. Turns out that the metric they used for our team was closed tickets, and they felt that given my salary I didn't close enough of them. No understanding whatsoever that others on the team were able to close more tickets because of my help (let alone that the tickets that made their way to me tended to be the complicated ones that others couldn't solve). After the first talking to, I stopped helping out my teammembers (I explained why) - and jumped on the first opportunity to get out of there.

</comment><comment><USER41> Mentoring is hard. It makes me question everything that I know, and worry about what this guy's code will look like in a year if I criticise this, or praise that. I wish there was some way we could all just work together, for real, in real time.

I miss construction. Back then, I could just tell someone "Hey! You! Don't fuck that up, I'm pouring concrete around it tomorrow!" And we would still be cool at lunch break.

<comment><USER42> Ha, it's true. I grew up around lots of construction and farming. Those people just aren't as sensitive as white collar workers. Probably why I'm not working at a place like that.

</comment></comment><comment><USER43> I run a number of side project sites and I do much of my work late at night.

I have one simple rule for myself - which is to never deploy anything at night before I go to bed. I've made several critical mistakes which I deployed to production and then went to bed only to wake up and find out that users couldn't use my products.

Thesedays, I do all deployment in the morning - that way, even if there is a critical bug, I am awake to catch it and fix it quickly.

<comment><USER44> Generally a good idea, if you don't have a setup where everything is validated end-to-end before you go to production - which is most software, and even if you have end-to-end automated verifications there's still risks outside of that scope / vision. (a server may run out of hard disk space from the new code, to name something random).

</comment></comment><comment><USER45> This reminds me of a similar story about being nice. It has nothing to do with software development but I want to share this anyway.

I was in Seattle and I took a public bus. The fee was $1. It was my second day in the US and I didn't have a dollar bill in my wallet (nor a transit card). I was assuming that I can pay with a larger bill just like Japan. Big mistake. The driver yelled at me but nonetheless she let me ride for one time. Then the guy sitting next to me suddenly offered a dollar bill and said "take this, so that you can pay for it by yourself." I probably looked at his face with amazement. "Thank you very much, sir." The guy got off the bus in a few stops later and I never had a chance to say this, but I know it's my turn now. I want to thank the nameless person who slightly changed me. Kindness is contagious.

<comment><USER46> I had a similar one. I was working in Rio de Janeiro, here in Brazil and money was really really tight back then. I would fly from Rio back to my city where my girlfriend is every other week.

So sure enough I got into a taxi cab and asked him to drive me to the airport, but make a stop at an ATM. When I went to withdraw the money for the cab, I noticed my payment didn't go through, it was still pending. I was desperate, didn't know what to do.

I kid you not, the guy withdrawing money from the ATM next to me somehow managed to notice my despair and got a chunk of money bills out of his pocket and said: "how much do you need?". I think I just stared back at him for a minute or so. "What?", I replied.

He told me that one day I'd have the opportunity to do the same for another person. I always remember this and always help strangers any time I can. And I realized that we are the ones that gain the most when we help.

EDIT: somehow somehow

</comment></comment><comment><USER47> I wish my first development job was like this place. Instead there was a blame culture and I'd get told off when I made mistakes, eventually getting fired for not progressing quick enough.

It's now 4 years since I was fired from that job and I'm still in development, despite that incident nearly causing me to decide it wasn't for me.

I was extremely happy to read this post, it gives me hope. I try and take a similar approach when working with newer developers, or those that are inexperienced in areas.

</comment><comment><USER48> This is underrated for managers and leaders trying to develop young talent. The takeaways:

      - With a system outage, don't lose your cool. Rationality is what's needed at the time.
      - Elevating "perfection" at the expense of potential breakage will ensure nothing ever moves forward and your team doesn't grow.

Some might believe that a serious ass-chewing is needed in this scenario; that would be a decision that's simple, quick and stupid. An emotionally-charged ass-chewing is almost always a sign of weakness in the ass-chewer. The only thing anyone ever learned about a beating is how to avoid it in the future.

Instead, this manager leaves his engineer with thoughts about how to avoid _that_ problem in the future. Always remember -- an outage is eventually fixed, but a damaged relationship continues forward.

</comment><comment><USER49> I have found that difficult people are a function of both themselves _and_ the environment they're in, and you can't necessarily say "be kind" without fixing the 2nd part.

The level of stress matters a lot. If a team is being run in a standard "everyday crisis" mode, they quickly reach the point where there is very little they can take. Every tiny mistake wears people down, reminding them of how much more there is to do, and turning them sour. Managers seem to panic and cut into their team's time even more by starting to have long, daily meetings to "fix" things.

If you want "nice" people, you have to set them up for success. Reward completing _the whole chain_ , not just hacking away (e.g. for software, not just coding but also testing, documentation, and seeking peer review). Keep meetings to a minimum. No overtime. When short-cuts were taken to meet hard deadlines, open up your schedule and scribble in the exact window after the deadline where you _will_ stop everything and clean up the mess that the short-cut created. Give your people the best equipment that money can buy. And so on.

</comment><comment><USER50> Seems like this story is being received pretty well here.

Though, in my opinion I think it's kind of insulting to be asked something like "What did you learn?". The question isn't really necessary. You know that you screwed up.

That kind of dynamic between an engineer and a team lead is off-putting to me.

I think the proper way for a team lead to handle it is to instead work with the engineer to help find ways to eliminate the human error by implementing tooling or processes. The conversation should go something like this:

Lead: "I wonder how we can make sure none of us break XYZ widget again"

Engineer: "We can build out ABC and run that, also generally just test better before pushing to prod".

Lead: "Cool, do you want to go ahead and take care of that?"

</comment><comment><USER51> This statement wraps it up:

 _"Great. It sounds like you get it. I know that you can do better."_

Giving folks a chance to communicate what they learned, and then encouraging them to "do better," is the best way to lead.

<comment><USER52> As long as it's not overdone. If every review ends in "you can do better" it just becomes the new "must apply themselves more in class".

<comment><USER34> So long as you're not having to "you can do better" for the same issue every time, I think it's fine. There's a lot of minutia to learn in software development; a lot of opportunity to screw up.

</comment></comment></comment><comment><USER53> I've worked with dozens of companies of various sizes over my career, and I've always found that this type of attitude starts at the top of the company. If managers are kind, curious, and tolerant of risks that might reap rewards, it is an indication the person at the top is running it that way.

If people are "blame-first, ask questions later" types, the person at the top is inevitably running the show by focusing on mistakes and miss-steps and their people follow suit. As result, people become wary of taking risk and run to assign blame, even before existence of an issue can be validated.

As a result, I don't think you can change these organizations. If their temperament doesn't match your own, you have to live with it or craft an escape plan.

</comment><comment><USER54> Also, never deploy and go camping. Not a knock on camping. You should also not deploy and head immediately to the hospital for scheduled surgery. The point is that if you deploy, on any day, you need to be available in case something is amiss. The only advantage to deploying Mon - Thur is that you're probably going to be available anyway.

</comment><comment><USER55> I have the similar problem with code reviews. It is really hard to not sound harsh when giving a code review, especially in ones from junior developers where a whole laundry list of fixes comes out.

<comment><USER56> Best way not to sound harsh is to ask questions. "What are your thoughts on ...?", "Is this really what you meant to do?", "Do you think there is a better way to handle...?". It puts the power and learning opportunity back to the other person and lets them feel the accomplishment of improving.

To the junior devs, when you screw up (and you will) own it and learn from it. Like public scandals, the cover up is almost always worse than original issue.

<comment><USER57> I find that tone works when the developer has clearly thought things through.

Other times, though, some developers need a very stern review. Things like: "Don't name your tests test1, test2, test3. Give them descriptive names," "Follow style," and "this does not belong in the dependency injector," and "don't screw with event publishing logic, filter this out in the event handler in the UI" are warranted when a developer isn't taking the time to think through his/her changes.

<comment><USER21> Does being stern actually produce better results?

<comment><USER57> Yes, much better. It establishes that we are a "clean code" shop, and that sloppiness isn't tolerated.

This is important when dealing with junior contractors.

</comment></comment></comment></comment></comment><comment><USER58> Be kind, but don't be passive either. Talk about it, be kind, but don't glaze over the learning experience.

</comment><comment><USER59> I heard a story about Pepsi (dont recall the names), where an executive made a decisiom that lost them 10 Million dollars. The CEO called the executive into his office... The executive shuffled into the office, head down, and meekly said, I guess you called me in here to fire me." To which the CEO replied, "FIRE YOU?! I just spent $10,000,000 educating you!

<comment><USER60> I recall that from Thomas Watson Jr's autobiography about his life working for his father at IBM.

[https://www.amazon.com/Father-Son-Co-Life-Beyond- ebook/dp/B0...](https://www.amazon.com/Father-Son-Co-Life-Beyond- ebook/dp/B00DXKJ6KE/ref=tmm_kin_swatch_0?_encoding=UTF8&qid=1476456773&sr=8-1)

</comment></comment><comment><USER61> I was just thinking about this today. Why is it that software engineers have a supreme mind set...

        "Oh you don't know that?"
        "Oh you don't know about that tool?"
        "Oh you use PHP?"

We categorize our peers into two buckets. One with whom you respect, and unfortunately the other as newbies, rookies, not worthy of our time and energy.

Listen, I am completely guilty of this behavior myself. Howerver, after reflecting I am going to try to be more helpful to peers. Remember that we are all constantly learning, and the knowledge and experience that you have took you time. That newbie was once you.

Finally, let's think about this in terms of rapport. If your dismissive and arrogant toward a peer when they ask a question, they are probably going to think you're a total tool and jerk. Howerver, instead if you have the knowledge and experience and show and teach them, they are going to admire and respect you. It is really the best option.

<comment><USER62> That sort of dismissive, arrogant behavior is my number one red flag during interviews whether I'm the one interviewing a candidate or I'm being interviewed.

The only time I would allow myself to react that way, and even that's a stretch, is if I was interviewing someone who claimed to have worked with something for several years, hands-on, and would've indicated to be a guru level expert on whatever it is, and then over the course of the interview couldn't answer even basic questions. You've just flat out lied to me and my team in order to waste everyone's time in an interview.

</comment></comment><comment><USER63> > _One Friday afternoon (...) [Kevin:] what did you learn? / [OP:] I talked > about the need for proper QA. About thoroughly testing my changes. About > taking the time to make sure the job gets done right._

Kevin sure sounds like a great guy. But there was a simpler lesson to be learned: never, ever push changes on a Friday.

<comment><USER64> _never, ever push changes on a Friday._

I think this goes a little too far.

I personally push code every Friday morning, and keep my Friday schedule relatively open so I have time to deal with any surprises.

Many successful companies brag (justifiably) about their continuous deployment systems and speed of deployment. I can't believe they suspend all of that every Friday.

[http://product.hubspot.com/blog/how-we-deploy-300-times-a- da...](http://product.hubspot.com/blog/how-we-deploy-300-times-a-day)

[https://github.com/blog/1241-deploying-at- github](https://github.com/blog/1241-deploying-at-github)

[https://www.wired.com/2013/04/linkedin-software- revolution/](https://www.wired.com/2013/04/linkedin-software-revolution/)

[https://www.facebook.com/notes/facebook-engineering/ship- ear...](https://www.facebook.com/notes/facebook-engineering/ship-early-and- ship-twice-as-often/10150985860363920)

<comment><USER65> Pushing twice a day in that Facebook story gave me a shiver.

<comment><USER66> If they were deploying to their entire fleet all at the same time, I would also shiver.

However, most likely that have many stages in their deployment with testing and monitoring that exponentially deploys and if any of those stages don't pass, they auto-rollback.

The End game: minimizing risk with code changes.

1\. Deploying more often allows easier root cause analysis to identify the code breaking change.

2\. exponential deployment allows developers to monitor their services as it partakes in more variation (more users = greater chance of edge case breaking bug)

3\. proper monitoring and test coverage while using auto-rollbacks allows developers to deploy without fear as any unintended effects will be detected at the soonest possible moment while minimizing cost to the users of that breaking change. Then, auto-rollbacks will redeploy code changes that previously worked which should automatically mitigate that code breaking change.

</comment></comment></comment></comment><comment><USER67> Junior devs should also remember that whilst they might be trying to be kind, sometimes the support person you are trying to instruct probably knows more than you do.

I was a bit bemused when a young guy who had just gone into devops and sysadmin gave me a mini lecture on the importance of open source and contributing to it if you have the skills, and that I really should give it a go one day, because open content is amazing.

I didn't have the heart to tell him I'd gotten into a few of the LibreOffice release notes for work I'd done on the project. Nor did I feel like telling him I'd made significant contributions to Wikipedia. I think I sort of weakly smiled and tried to change the subject.

<comment><USER68> Juniors in particular are guilty of this, I've found - spending the last few years solving problems, they often come into the real world looking at most problems as 'simple' or 'a waste of time', and tend to be dismissive of non- programmers or domain experts. Some young people can also be surprisingly arrogant. College tends to be a very different experience from the working world.

Good on you for being patient and not letting them drag you into a place that would have humiliated them, though.

</comment></comment><comment><USER69> Thanks a lot for sharing this. I've been in 3 different companies now where I learned a lot but the biggest reason I left my first job was because I was afraid to ask questions because my boss did not know how to respond to a simple question without being snarky or rude. I learned a lot from that job but I knew that I wanted to be in a better environment and I am thankful that I made that decision. Working in an environment where everyone is encouraged after making mistakes and learn from it is where I want to work for.

</comment><comment><USER70> The virtues of being nice are often extolled, but it's kindness that's truly valuable. You can do nothing and be "nice", but only actions can make you kind. When you strive to be kind, you'll also start noticing who around also tries to be kind and who is merely nice.

</comment><comment><USER71> Also, don't ship on a Friday unless you expect to work on Saturday.

</comment><comment><USER72> #FirstJobsMatter! Based on my subjective, statistically unsound observations, when it comes to bad, obnoxious, and intimidating work place behavior there are people who cannot be helped and are equal opportunity offenders, and then the vast majority who appear to have picked up poor behavioral habits from their old bosses, peers and companies that they were unlucky to be associated with early on in their careers. I would assert that very few of us are resilient enough to truly differentiate between good or bad workplace behavior [in an early stages] of our careers - especially when you scored a job in one of the many respected companies with a track record of success. No matter how toxic the culture - it must be right since company is doing good, right? And then as we move forward in our careers we take these 'learnings' with us. As a recent observation, this seems to apply to all phases of peoples careers where I witnessed an outstanding R&D manager / director turned into monstrous VP, who in reflection is just putting into action same management practices that were used by a pre-acquisition start up CEO he used to work for. And then of course there are those golden people that really make it worthwhile to come to the office and that you just love working with/for - sort of like the project lead described in the story here.

</comment><comment><USER73> Situations like this really let you know the true merit of your leadership.

I had a similar situation - where alerts based on bad data went out to customers, and hundreds of customer support tickets started flooding in. The VP, Director, and my manager all came to my desk.

Instead of chewing me out, or telling me how much I had messed up, they calmly figured out the issue, told me that mistakes happen, and thanked me for helping them figure out how unreliable the underlying data we were using was.

</comment><comment><USER74> Junior developers who make a mistake? Cut them some slack and teach them.

Senior developers who make the same mistakes over and over and never learn? I've kindly pointed out the mistake and invited them to avoid it in future. After a few more failures, I sometimes talk to them sternly, but the sad thing is that they won't learn from either kindness or harshness. I'm not in a position to fire them. Does anyone have an idea better than "Just suck it up?"

<comment><USER75> Talk to your manager. That is their job to make sure they are doing what they're supposed to in a more formal setting if informal coaching does not work.

<comment><USER74> Yes, I suppose this is the "correct" way. If my manager doesn't have a problem with my coworkers failures, then I'll just have to tolerate it too.

</comment></comment></comment><comment><USER76> This demonstrates two principles from "How to Win Friends and Influence People":

\- Don't criticize, condemn, or complain. \- If you're wrong, admit it quickly and emphatically.

There are many good anecdotes like this in the book, including endymi0n's example.

</comment><comment><USER77> I have witnessed the same thing at my current startup and this is the reason why I excel at my job and why my coworkers are some of my dearest friends. It is this sense of camaraderie that brings people together. We've all been through a lot, late nights of frantically pulling together an entire feature, reading scores of hibernate exceptions, debugging through IE bugs and jumping to help another developer with no questions asked. It is this through this journey that I learned how to provide safety nets for my junior developers and find ways to lead them to success just like my predecessors have done for me.

This is why I love being a developer.

</comment><comment><USER78> Great anecdote. We've all done it. Another thing I learned really early on - never deploy code on a Friday. Especially not Friday afternoon/evening. And definitely not if you're leaving for the weekend :)

</comment><comment><USER79> I had a similar experience when I first started as a junior engineer at a financial company. By accident, I dropped a database in production... immediately, people found out and the head of production support came to me and said "This is strike 1".

Terrified, I ran to a senior engineer, who calmly and efficiently proceeded to restore everything in a few minutes. The only thing he said to me was "happens to everyone, don't worry about it, just be more careful next time."

I was extremely thankful and a LOT more careful next time, and each time after that.

</comment><comment><USER80> This reminds me of one of my favorite blog posts: [https://circleci.com/blog/kindness-is- underrated/](https://circleci.com/blog/kindness-is-underrated/)

> The choice to be kind can be hard, especially when you're frustrated or > when, thanks to your gifts, you know that someone has made the sort of error > you could easily have avoided. It's easier to be direct; to not concern > yourself too heavily with the emotions of others; to want to be unequivocal > in your rejection.

Being kind is hard, and being an asshole is easy. People have a natural tendency gravitate towards the easy choice, the path of least resistance. Making the more difficult choice to be kind takes time, effort, and lots of empathy, but I firmly believe what you get in return is worth all that.

By being kind, you help create a more trusting, inclusive, and generally more pleasant atmosphere for you and your team to work and grow in. People also tend to respond to kindness in kind (bad pun intended, sorry!), and kind people tend to prefer working with other kind people, so in many ways kindness literally begets more kindness. Being an asshole also comes with similar feedback loops, but I know which one I want working for my team!

Disclaimer: I'm working at CircleCI now. :)

</comment><comment><USER81> I think there are few professions where people screw up a little bit (sometimes literally) and it gets logged, measured and escalated so frequently than in SW.

Computers are unforgiving. Humans err. This really needs to be at the forefront when selecting personal - developers and managers. The answer can't be all forgiving. It can't be you are fired. And it probably should not be ad- hoc all the time. Company values matter if they are lived by.

</comment><comment><USER82> The best teams and organizations are the ones that are constantly learning, and foster an environment that encourages and supports that.

And, can take those lessons learned, and establish practices to help prevent and minimize such mistakes in the future.

I've seen lots of teams totally embrace the first, but inexplicably, don't follow through with the second step. They go through the motions of "learning" without actually learning.

</comment><comment> d--b Is that so uncommon? I mean, maybe I've been particularly lucky in my career but that sounds like standard behavior to me. I mean you already feel bad enough for blewing it that it's no use to add some more to it. And as the article says it happens literally to every one of us at some point. So unless your boss is a genuine ______bag, that 's the expected way they should react

<comment><USER83> Unfortunately there are a non-negligible number of managers that take to the 'stick' approach and will yell at people, etc. Many people seem to be okay working in that environment so there doesn't seem to be pressure to stop that behavior.

<comment><USER84> I have been a graduate dev for four months now and i already feel like im not good enough on almost a daily bases. Though I do enjoy my code reviews because i know it will improve me as i go along.

</comment></comment></comment><comment><USER85> While it's nice that we know that the protagonist is agonizing over his mistake, in reality, that's not often the case.

Since I don't have insight into their heads, and I can't tell if something was a sloppy mistake because they were inexperienced, or a sloppy mistake because they were trying to get out the door to a camping trip and prioritized their personal life over the team or client.

Clear example of why it's bad to deploy on Fridays, why it's bad to have single-person deployments, why it's bad to leave your laptop at home, etc.

But how would the kindly Senior know the Junior dev just made a mistake vs. was a fuckup and was thinking, "I don't give a shit, Senior will catch it and I just want to be on a beach now. Fuck it, I'm 'done' \-- now to just sneak out and put my phone in the glove compartment for the next 3 hours while this blows over..."

The answer is he wouldn't.

So here's the other issue. Let's say I trust one person more than another. And Junior A -- who I believe to be a superior talent -- gets the benefit of the doubt, but Junior B gets scolded.

Now let's say there's even the slightest difference in hair length or eye color between A and B... and presto that's an HR discrimination complaint I now have to deal with. As it turns out, Juniors don't have insight into the minds of Seniors either.

So, some good advice... Be humble, do what you can to not make things worse for others, set up good practices that let everyone thrive (the best way you can do this is to avoid failure opportunities -- i.e. don't deploy on Fridays), and do what you can to treat everyone fairly and equally based on perceived actions and offenses.

We can't know what goes on in someone's head.

</comment><comment><USER86> All this talk about being kind (or staying calm) in tense situations reminds me of this video I caught on reddit last year. [0]

There is a dash-cam filming the inside cockpit of a plane when the pilot abruptly finds himself in one of those "death spirals" or "flat spins".

The pilot doesn't say a word.

He immediately reverts to his training, rights the plane, glides it towards the ground, and only grunts a bit when he crash-lands.

I found that absolutely amazing. To have that level of poise when you are literally facing death is unbelievable.

It is very similar to the simple advice given in the linked blog post.

Staying calm in difficult situations is the most efficient course of action.

Stressing out, raising your voice, yelling about things, or blaming others isn't going to do a damned thing when your plane is literally spinning out of control and going to kill you in a few minutes.

[0] [https://www.youtube.com/watch?v=bvbS- oHi9ro](https://www.youtube.com/watch?v=bvbS-oHi9ro)

<comment><USER87>
      > "death spirals" or "flat spins".

Just an aside, for the record, obviously not important but since the topic came up...

A spiral and a spin are two very different things, and a spin and a flat spin again are very different.

In a spiral you actually still _fly_ , in a spin you are not, you are in a continuous stall situation. That means from a spiral you can recover simply by "flying out of it", for a spin you have to do stuff you would not do when "flying", like _full(!)_ and sudden rudder.

This _heavily_ depends on the airplane, but a flat spin can be really dangerous, getting out of one often is much harder than from a "normal" spin. No problem in an aerobatic airplane, but in a jet it can be an unrecoverable situation.

</comment></comment><comment><USER88> Also as a senior developer you carry some of the responsibility for the junior's ability to make that mistake. You probably set up and maintained the development environment where such an error could slip through into production.

So in case of a critical error/melt-down you should first of all blame yourself and think about why you set up a process and an environment that let this happen in the first place.

Think about what went wrong and how you can prevent it from happening again. When I started at my current place of work, they had a horrible manual deployment process that was the cause of 99% of all problems they experienced. Rarely critical problems, but still annoying and unprofessional. So we implemented automated build, test and deployment process that got rid of almost all of these problems.

Now, whenever something bad happens, we realize it is a problem with the process (not the individual) and correct/improve it as needed.

</comment><comment><USER89> This reminds of important lessons I've learned from the classic How to Win Friends and Influence People - never ever criticize people and you will get the best out of them. There are countless other great lessons in this book about being a leader and dealing with people.

<comment><USER90> I agree except for the word "never". In this story he was able to say "Great. It sounds like you get it." If you can't honestly say that, then it's time for some leading questions possibly followed by criticism.

</comment></comment><comment><USER91> When I started of as a junior developer it was in a team of 3. 2 Senior developers and me.

One of them was really kind and a nice guy that was getting along with everyone else in the office (other teams etc). Also he was a very good dev. Nice personal projects, knew what he was talking about, humble and hardworking.

The other developer was aweful. He was slacking a lot, all day on facebook and doing his personal home-owned business over his actual work, not caring to help me at all on any request. We didn't get along, and at first I thought it was my own issue. Later on I realized and having a talk with my manager that noone really was getting along with him. At some point he thought it was a great idea to make an education session, I was like ok he is putting time into it. He then proceedeed telling me that he is gonna teach me the very basics of programming as "we" didnt go to uni, I told him I went to uni and I finished with a Distinction but sure he could tell me whatever. He was trying to teach me things he didnt even understand and I was taught about them at uni. (I understand this is a basic mistake junior devs make think that they know it all, this wasn't the case here, he was trying to teach me some basic CS concepts, I went to uni for it he never went to Uni for it, he was just a programmer, nor he had the interest or hobby to go more intellectual on the matter) This lead me into not trusting him at all, in anything, while the other developer was really kind and he let me on his own to understand that he was a really good developer and I should listen to him.

A year later my performance was really good in the yes of the company, I was producing a lot of stuff etc. The developer that didn't like me was clearly angry at me. He was producing things that could be done in a week in like 3 months. Well long story sort, the company wanted to fire him, although it wasn't very viable at that moment as they would have to pay him cause he was with them for a very long time, so they started a formal process against him by keeping schedule giving him a formal warning etc. He improved etc.

I stayed at the company till I became a developer and a year after. I was working alone on mobile apps, and I remember having a chat about an issue I had for the app and some ios apis and how I tackled it and I remember that dev still trying to tell me what to do and how although he never ever working in a mobile app in his life or any experience in that field whatsoever.

Anyways, please don't be like the 2nd developer, be nice and let junior developers believe in you and understand your actual skills and capacity on their own. You don't need to brag or try to showoff because you might end up making them not trusting you.

</comment><comment><USER92> I'm re-reading Peopleware this week, and this is one of the core points it makes. You need to give the team the flexibility to make mistakes. I'm not sure I've ever met a manager who has read that book and disagrees with that principle.

</comment><comment><USER93> While I fully appreciate the point of the post, the junior dev didn't screw up. The team screwed up for not having a process and practices designed to avoid these mistakes. Unless they do have those, and Brian decided to ignore them.

</comment><comment><USER94> 101: Never deploy on Fridays.

</comment><comment><USER95> > It's okay," he replied. "We've all done it." He paused for a moment. "But > what did you learn?"

Don't deploy to production on Friday! Queue it up in staging for Monday morning. Make a team policy for it!

</comment><comment><USER96> This is the Kaizen/Deming principle #8 of "Drive Out Fear". Here's a good in depth blog article about this as it's a difficult to explain topic that, especially for managers trained in the older methods of management, deserves a long form treatment:

[http://michelbaudin.com/2012/10/27/deming_8_of_14_drive_out_...](http://michelbaudin.com/2012/10/27/deming_8_of_14_drive_out_fear/)

</comment><comment><USER97> Had similar experiences in my first job with one of the smartest engineers I ever worked with (Claudio Marcio da Silveira). He early-retired to work on his family business (something related to flowers). But I can still remember all the times he let me learn by doing small mistakes, covered my bigger mistakes, and also educated me.

Trying to become that same engineer in my own way, but I definitely own a lot to him. And to other professors from uni/school that were extremely kind as well.

</comment><comment><USER98> > Jr Dev

> Access to production

> With clients that need the service running 24/7

Oh boy... is he used to work on facebook? when i was a jr dev, i didn't have access to production everything went to source control and then tested by my project technical leader and qa. This ensure that i won't do this things since my changes getting reviewed and tested plus we have reproducible builds that anyone can verify and continue working.

Case in point: No JR Dev ever need access to production ever, period.

<comment><USER99> I disagree. I work for a big company with a big product that shouldn't have a single minute of downtime. We let new devs deploy to production from day 1. We have ways of mitigating the risks, like a very sophisticated monitoring and the ability to rollback changes in seconds. Yes we sometimes have outages, and we lose money. But in our experience, empowering developers is much more effective than handcuffing them. They learn to be careful and freedom allows for creativity to flourish resulting in amazing solutions.

<comment><USER98> I think in your release model are forgetting about development and the staging areas that most devs can run or well use freely before ever going to production. Those are the places where the developers not only have access but are also encouraged to disrupt, destroy and let their creativity run before going to production. Giving access to production from day 1 its a disaster waiting to happen and m pretty sure stoling ip or databases aren't part of your monitoring software scope nor being able to detecting malice.

</comment></comment></comment><comment><USER100> Good to know there are people looking out for junior devs :-)

</comment><comment><USER101> Wow, this really resonates with me.

The very first day of my first 'proper' job, I made a total mess of something that cost the company around $5000. But my manager was like 'don't worry, we'll sort it, just learn to ask if you don't know how to do something'.

Many years on and I lead a development team. Now I always try my best to 'be kind', to coach and mentor, and it almost always pays back.

That one guy's kindness had a lasting impact.

</comment><comment><USER102> The hardest thing for me when I was junior dev was simply being noticed. I'd rather someone be hard on me than to pretend I don't exist.

</comment><comment><USER103> This advice is obvious. How can you not be kind with a junior person that makes a junior mistake? It's human. An angry phone call would not have made any difference (except damaging the relationship). But what if Brian deployed on Friday night without testing 4 times in two years? And 3 times it caused trouble for the business. How do you stay kind then?

<comment><USER104> You can be kind while still being critical. Even if it's kindly letting the person go with as soft of a landing as you can provide rather than the walk of shame to the lobby with security.

</comment></comment><comment><USER105> A mistake is an education. If you fire someone after they make a mistake then you are throwing away your investment in their growth.

</comment><comment><USER106> For actionable advice on how to be kind while still capturing the lesson. I recommend this article by John Allspaw on blameless postmortems.

[https://codeascraft.com/2012/05/22/blameless- postmortems/](https://codeascraft.com/2012/05/22/blameless-postmortems/)

</comment><comment><USER107> The mistake was launching something on a Friday before vacation. Wed or Thursday would solve this. Launching on Mondays or Fridays, not a good idea.

So that is another lesson learned in addition to being cool when someone messes up once in a while. In ego driven teams sometimes it turns into the blame game and throwing under the bus, that is not kind.

</comment><comment><USER108> Cmon. An article about kindness as top post on HN. This is taking the piss. This is a place that specializes in snark and dismissive discourse.

Everyone is a peacock here. The bumbling programmer should thank his stars his boss does not appear to be the typical agitatedly infallible HN commentator or monday would be a different day.

</comment><comment><USER109> proggit has a better title: [Mentoring Junior Devs: Be Kind]([https://www.reddit.com/r/programming/comments/57g3x7/mentori...](https://www.reddit.com/r/programming/comments/57g3x7/mentoring_junior_devs_be_kind))

</comment><comment><USER110> Maybe im just lucky but this is generally how any manger I've ever had normally would have handled the situation. Not every single time, of course, since they were all humans and got frustrated sometimes, especially after a few of these in a row, but for the most part, they weren't dicks.

</comment><comment><USER111> My first job was at an aerospace company in Florida. My boss was so nice.

I was really surprised to get the coveted desk in the 60° server room. Coming in off those 90° 100% humidity streets to put on a parka and sit at my workstation wearing fingerless gloves.

Man, anybody should be so lucky to apprentice with that guy.

<comment><USER112> For some reason I am imagining you working in a server room shaped like an equilateral triangle (i.e. the walls of the room meet at a 60° angle)

<comment><USER113> And he came out of an aquarium (i.e. 90° walls + 100% humidity)

</comment></comment></comment><comment><USER114> I have seen people that react positively to feedback.

But some people take things very personally, even if you try to be very polite and respectful.

Sometimes people, especially people with narcissist traits or people obsessed with rank, will not accept any feedback coming from a someone from a "lower rank".

</comment><comment><USER115> If someone asked, "what I'd learned" in the above context, I'd assume it was more to satisfy their needs of feeling important and superior than genuinely caring.

Much better is: "Shit happens." That's an empathetic attitude that reflects experience in our field.

</comment><comment><USER116> Well, this rule applies to basically every field of life. Most (if not all) religions and moral systems have rules that say to respect the others and be kind, even if they are not as we want them to be. But I'm not surprised that it's rediscovered over and over.

</comment><comment><USER117> I dont think "not getting angry" qualifies as "being kind" unless anger is the default state.

kindness doesnt automatically emerge to replace a lack of negative outcome.

"My father didnt hit me with his belt" is not kindness. "My boss didnt fire me" is not kindness.

</comment><comment><USER118> "One Friday afternoon, [...] I deployed the changes"

Good god, this should be taught in high school.

</comment><comment><USER119> I thought this article was fantastic. We could use more kindness at home, at work, and in general.

I find it really unfortunate when an engineer is fired because of a mistake. All the company is really doing is giving a more experienced engineer to someone else.

</comment><comment><USER98> Personally i prefer the type of mentor/boss that comes and says things straight, surgarcoating everything isn't good once you realize that everyone could think you are stupid or well starting to find your replacement.

</comment><comment><USER120> Stuff like this always boggles my mind - anyone can mess up. Mistakes happen, but if you didnt learn from it, history will repeat itself. I can't help to feel that common sense is sometimes lacking.. Why is that?

</comment><comment><USER121> Be kind, but also be honest.

</comment><comment><USER122> The key sentence: "Kevin gave me the space to screw up, as long as I learned from it." I like that concept of space to screw up. I definitely recognize the need for that.

</comment><comment><USER123> "Blame is not for failure, it is for failing to help or ask for help." It changes everything. Usually attributed to the CEO of The Lego Group, Jorgen Vig Knudstorp.

</comment><comment><USER124> I only had to rad the first three words "One Friday afternoon". I learned early that I was doing everyone a favour if no updates went out on Friday afternoon.

</comment><comment><USER125> I have wept in the night For the shortness of sight That to somebody's need made me blind; But I never have yet Felt a tinge of regret For being a little too kind.

</comment><comment><USER126> Being founder of a startup, I often get into position as this. I think there is alot for founders too to learn form this small story. Thanks for sharing.

</comment><comment><USER127> From my experience as a manager, being kind works very well. This is especially important in the stressful start-up world where tensions are high anyways.

</comment><comment><USER128> I really liked that article was short and to the point!

</comment><comment><USER129> > "It's okay," he replied. "We've all done it." He paused for a moment. "But > what did you learn?"

Never push changes on a Friday PM. Ever.

</comment><comment><USER130> Can't believe you could get fired for something like that. Do you work for an American company or something? Jeeze...

</comment><comment><USER131> > I walked into the office certain I was about to be fired. Wait, can you be > fired that easily ?

<comment><USER60> Many US states are "At Will" employment. You can be fired for almost any reason, at any time. At the same time, you can quit at any time. Giving notice is a professional courtesy, but not strictly required.

</comment></comment><comment><USER132> Right now, this post is 4 votes away from being in the top 10 most popular HN posts of all time.

</comment><comment><USER133> Every child should be so lucky to have this experience as well. Empathy goes a long way.

</comment><comment><USER134> Simple but highly effective writing . How can I learn to write like this ?

<comment><USER90> Here's a list of online writing communities slanted toward young writers but not exclusively: [http://study.com/articles/40_of_the_Best_Websites_for_Young_...](http://study.com/articles/40_of_the_Best_Websites_for_Young_Writers.html)

</comment></comment><comment><USER135> Rewind.

<comment><USER136> Came here for that :)

</comment></comment><comment><USER137> No. 1 rule for deployment: Don't deploy on Friday.

Let it be a deployment free day!

</comment><comment><USER138> That's why I never deploy on Fridays. For me, for everyone else.

</comment><comment><USER139> This goes for everyone on your team, not just junior devs.

</comment><comment><USER140> Very good advice. Your good deed rewards you over time.

</comment><comment><USER141> Isn't there supposed to be a code review before devs are allowed to deploy something to production?

Yeah, Brian screwed up. But the company has at least some fault for letting him get that far unchecked.

<comment><USER142> This varies highly depending on the organization. I've worked at places that do it both ways. Particularly in small places when resources are tight, teams are distributed, or there is a non-code safety measure in place (e.g. Business decisions are made ex-post of the code running dependent on the quality of its output), code reviews pre-deployment may not be necessary and can even be harmful (due to wasted resources).

</comment></comment><comment><USER143> Refreshing...

<comment><AUTHOR> Thanks!

<comment><USER113> No problem..

</comment></comment></comment><comment><USER144> Don't tell me what to do. ;)

</comment><comment><USER121> Be kind. Rewind. :)

</comment><comment><USER145> Amazing!

</comment><comment><USER146> We're an industry filled with people who have social disorders. Some people are just angry little people. Misspell something in a config file and they just ... go ... ballistic... It's not enough to just try and tell these people to be nice. They don't know HOW to be nice. Their brain isn't wired to be nice.

Edit: spelling.

<comment><USER147> I hate to be this guy... but 'ballistic' has two l's.

<comment><USER146> Correct, and thanks.

</comment></comment></comment><comment><USER148> interesting

</comment><comment><USER149> cool story bro.

</comment><comment><USER150> Life happens. Being kind shouldn't just be restricted to junior devs, or even just devs for that matter. I've seen many folks be flatout mean and unrealistic to adult freelance developers from low-income-countries. It's a serious problem.

</comment><comment><USER151> Except in real life people sometimes make malicious "mistakes" deliberately and when caught and called out on them either completely dismiss them or even gloat.

This reads almost like a fairy tale.

<comment> bjelkeman-again In my experience very few serious mistakes are deliberate and there is a huge gain to find a way to not make the same mistake again. Which include avoiding blame, but rather go looking for the root cause.

People who can handle serious mistakes in others are some of the best partners you can have in your efforts. IMHO they aren't fairy tales.

<comment><USER152> There's a story that I love about Pixar, a Black Swan event, and Toy Story 2 [0]. The gist was, the movie's files were accidentally deleted while still in production, and the backup was corrupted.

Instead of blasting people for mistakes they set about fixing the immediate problem, and then instead of demanding "accountability" from those responsible, they set about fixing the root cause.

A few excerpts from the linked article:

"Aside from the fact that there was immediate chatter about who might have made such a dumb move, the discussion quickly moved right on to how to fix the problem."

"Instead of dwelling on pinning the blame or lamenting the loss of time and effort, the team made sure to alter the backup strategy so that something like that didn't happen again, and it went about making up for lost time."

[0] [http://thenextweb.com/media/2012/05/21/how-pixars-toy- story-...](http://thenextweb.com/media/2012/05/21/how-pixars-toy-story-2-was- deleted-twice-once-by-technology-and-again-for-its-own-good/)

</comment></comment></comment><comment><USER153> > _That's why I want to make sure that you're the only one to refuel my plane > tomorrow. I won't let anyone else on the field touch it._

...he said, before his final fatal flight. Apparently some people DO do the same mistake twice.

([Edit] to avoid confusion: My addition is about giving a different twist to the story, to show that it's not a given that people who made a mistake will not be prone to repeat it. Some people seem to be extra prone in repeating certain mistakes. It's not saying Hoover actually died or anything... I mean, isn't it obvious?)

<comment><USER154> I don't know if you're being snarky or not, but Bob Hoover is still alive

<comment><USER155> This Bob Hoover? [https://en.wikipedia.org/wiki/Bob_Hoover](https://en.wikipedia.org/wiki/Bob_Hoover)

</comment></comment></comment><comment><USER156> > I talked about the need for proper QA. About thoroughly testing my changes. > About taking the time to make sure the job gets done right.

Oh good, a bunch of useless platitudes.

<comment><USER157> Honestly, I came to this page expecting some really intriguing story, from which I could learn a lot. Its been voted to 2000+ points, so must be it hit a nerve of a lot of people. But to me it seemed like a nice but very simple story.</comment></comment>


Facebook Pushes Developers To OAuth 2.0 And HTTPS this time - <AUTHOR> http://www.allfacebook.com/facebook-pushes-developers-to-oauth-2-0-and-https-2011-05

<comment><USER2> Ethical questions of Facebook's data sharing policies aside, this can only be a good thing for end-users can't it?

I'd like to see them move to being SSL only accessible, or at least making it the default and HTTP being the fallback for mobile devices and similar.

<comment><USER3> Initial cost should correlate negatively with independent developer participation.

</comment></comment><comment><USER4> Where the hell do people pay 1000 dollars for a certificate? There are comodo resellers for ten bucks a year.

Granted they should be forced to deliver basic certificates for free as a condition for having their root certificate included in browsers in the first place, but until that happens this is still pretty close.

<comment><USER5> They are free from <http://en.wikipedia.org/wiki/Startssl#StartSSL> \- trusted by most browsers you are likely to encounter using facebook (the exception being some users of IE6/7 under XP).

The cost issue is generally moot these days if you have a clue. There is an administrative hassle (getting a cert, configuring your host, and renewing each year), but not a financial one. There _might_ be an extra cost if your app is delivered from a shared hosting environment for your app because you will need a dedicated IPv4 address (as not all common browsers in the wild support SNI yet which would remove that need), and an administrative cost if you need to move host because you are on a very cheap provider that won't support SSL at all.</comment></comment>


Ask HN: Time to drop a client? - <AUTHOR>

I have a client who I first picked up over four years ago. As it was one of my first consulting gigs, the hourly was low, $25 an hour. Since then I have gained many higher paying customers. I brought up the idea of raising the price and it was quietly swept under the rug. They are now nitpicking at a minimum of one hour billed for one-off projects. They also are expecting unrealistic lead times (i.e.  requesting work to be done within the next two hours at 7pm)<p>Should I drop them? Any advice would be appreciated. <comment><USER2> One of the odd things about many businesses that involve providing expert services is that clients partly evaluate quality by assuming that high-price providers must have better quality. That may or may not be true, but if you are dedicated to developing your craft, you can learn how to provide high- quality services. Then you should make sure to bill for those high-quality services, to get proper return from your investment in developing your skills.

My wife is a solo-practice businesswoman (a piano teacher). From the beginning, I have advised her always to set her rates as high as those she hears about from other teachers in town. I know enough about her musicianship and her thoroughness as a teacher to know that she is worth as much as any piano teacher in town, and every minute that she contracts for at a lower price is a minute she could have contracted for at a higher price. Over the years, she has had quite a few long-term clients, and she has become quite busy. She is very grateful, of course, to clients she had when she was still building up her portfolio of clients. But whenever she adjusts her rates or her terms, she eventually sends out notifications of the new rates and terms to ALL clients, and the clients she wants to keep stick with her lessons. She has been sufficiently busy for a few years now that if a client balks at terms or conditions, she thanks them for their previous business and moves on. There is no need to keep a bothersome client in a world full of clients who are looking for the work to be done well and are willing to pay for that. Just make clear what terms properly reward you for your skill, and keep your life from being too bothersome, and serve the clients who meet those terms.

</comment><comment><USER3> >I brought up the idea of raising the price and it was quietly swept under the rug.

You don't "bring up" the new rates, you "inform them" of the new rates so they can plan accordingly. Cheap clients are just not worth it.

<comment><USER4> You should also add other pre-requisites to your agreements, e.g. 7 day lead time on all work, otherwise rate is 2X standard rate if you are available at all (since you'd need to move existing work to make yourself available for them)

Inform them of these changes in a formal way, and give them an implementation date: As of Feb 1, these are my new terms.

</comment></comment><comment><USER5> _They are now nitpicking at a minimum of one hour billed for one-off projects_

For no other reason that this, I would drop them. I do not like having to justify my time after the fact. They hired me because I am the expert, as such if it takes 5 hours to complete, they should have an issue with that up front not after the work has been preformed. If a client tries to negotiate hours after they have been performed, it is the last time I work for that client. The issue is, what if they have a huge emergency that required a good portion of hours, if they nit pick over a few, there is a good possibility in this situation, they will have buyers remorse after the crisis is over, potential stiffing you with a lot of hours, worse yet a lot of hours at a sub par bill rate. There is a high potential for you to get stuck holding the bag with a client like this.

</comment><comment><USER6> I don't know what kind of work you are doing but $25 is low even if it was a full-time gig, for doing just small tasks its absurdly low, I think you're right to drop them, that they would even expect you to be available for tasks less than 1 hour and then to nickel and dime you on that is ridiculous, you only get that kind of privilege when you're employing someone full time.

</comment><comment><USER7> Loyalty is a two way street. Many of us have 'preferred' clients who were there during the earlier days, but you need to remember that you were still working hard providing a service to them before and now. As a business, it's up to both sides to ensure and maintain a worthwhile business relationship, unless you're desperate for the money and are willing to compromise.

A few more points to consider:

* As others have mentioned, $25 is very low for consulting. Try shooting for at least hourly salary * 1.5.

* Think of what rate they would pay your replacement given today's market rates.

* You've likely grown in skill and experience from 4 years ago, so your rate should show it.

* There are other ways to show loyalty, such as market rate with 10% discount or providing a value added service.

* The nitpicking and increased expectations comes naturally when you're taken for granted. At this point there's very little you can do to win.

* Opportunity cost. The time you're investing doing work you feel is inadequate can be found looking for and doing better gigs.

</comment><comment><USER8> Increase your rate. Let them know that 2012 is a new year and every year, at some point early in the year, you increase your rates to reflect the growing cost of living, but more importantly, the growing value of the skills you've acquired during the preceding year. There is no reason you can't double your rates if you have enough clients who are willing to pay at those rates. If they don't value your work at your proposed rate, they'll drop themselves.

</comment><comment><USER9> I think you should give them a chance to get in line with your other clients. 80/20 principle and all, Get rid if they take up a disproportionate amount of your time vs the revenue they bring in.

Drop them a mail, inform them that your rates have changed, new working conditions, expectations, turnaround time etc details should be attached also. Clearly outline the working process should they wish to keep working with you.

If they can't agree to the new conditions you'll be happy to refer them to other consultants.

You might be surprised that they start to be easier to deal with. I guess it all depends on how much you want to keep them.

</comment><comment><USER10> You could always find someone with suitable skills to freelance for you. Pass off these clients to? So you keep them, but you don't actually handle their project. Of course you will have to state this to them.

</comment><comment><USER11> The first thing I recommend you do is increase your self esteem. Respect yourself and the hard work you've put into your craft a little more, and you will never ask this question again.</comment>


Mike Berkley: Preparing for the next web boom - <AUTHOR> http://siliconflorist.com/2009/09/23/mike-berkley-preparing-web-boom/

<comment><USER2> The subtitle here should probably be "Why my startup failed (and some tips to avoid making the same mistakes).</comment>


What rights do I have over my domain name? - <AUTHOR>

I bought a domain name about two years ago for a little web app I've been working on. For conversation sake lets call it Umize. Recently, a new startup launched with a similar name (Umizr).
Here's what bothers me: they use my name (Umize) as the title of one of their features. And this title is displayed prominently on their front page and throughout their web site. The feature is also somewhat related to my web app.
My question is: do I have any copyright for the use of my domain name? Do I have the right to ask the startup to rename their feature?
I'm not planning on taking any action now. I'm just wondering what my options are if this becomes a problem in the future.
Thanks so much! <comment><USER2> Keep a paper trail of everything, from emails sent relating to your service to any fees paid out to contractors or anytone else working under/for you w/ the project. If they make a stink out of it, I would suggest hiring a lawyer to represent you (we have one that we have on retainer -- tends to be cheaper this way). If you don't have the funding for this, you could always ask them to rename theirs and maybe they'll comply in good faith if you prove you had your name and whatnot first... or the last option would be to follow chandrab and just rename your product... it'll keep a stink down w/ the other company and won't be a costly blackhole to throw money you could have put into marketing the new name.

</comment><comment><USER3> Are they doing the same thing or something similar? The possibility of confusion exists...if you have copyrights on your name and predate them you might have a case (if you decide to spend the money on lawyers). Cheapest way out of it is find a new name IMHO.</comment>


Tech Startups Long for the Days of Yahoo's Binge Acquisitions - <AUTHOR> http://www.bloomberg.com/news/articles/2015-12-11/tech-startups-long-for-the-days-of-yahoo-s-binge-acquisitions <comment><USER2> Maybe Yahoo should focus on either user count acquisitions (see whatsapp, youtube) or product acquisition (youtube, instagram)</comment>


The Dutch Edition of Wikipedia Now Has 2M Articles - <AUTHOR> https://nl.wikipedia.org/wiki/Hoofdpagina <comment><AUTHOR> Some context: The English edition of Wikipedia has [six million articles]([https://news.ycombinator.com/item?id=22133434](https://news.ycombinator.com/item?id=22133434)).</comment>


Ask HN: Best Rich Text Editor - <AUTHOR>

Hi! I'm doing a rigorous search for the "one" WYSIWYG rich text editor. Is there something better than: http://www.zenpen.io/ http://xing.github.io/wysihtml5/ http://mindmup.github.io/bootstrap-wysiwyg/ http://hallojs.org/ http://epiceditor.com/
http://www.aloha-editor.org/ http://www.tinymce.com/ http://www.aloha-editor.org/<p>Submit your favorite, underground, elegant, modern, intuitive RTE :D <comment> saiko-chriskun imo textbox.io looks like it's going to be the best but it's not out yet :P</comment>


MySQL performance optimization: 50% more work with 60% less latency variance - <AUTHOR> http://engineering.pinterest.com/post/122520169079/mysql-performance-optimization-50-more-work-with <comment><USER2> My jaw landed on the floor when it said that pinterest runs on AWS. AWS is fantastic but I would've expected that the performance-per-dollar ratio is way below having your own colo'd hardware at pinterest scale -- and would leave you spending talent on trying to optimize your software, instead of just throwing more hardware at your operation.

Is this common now, that pinterest-sized businesses are running on AWS?

<comment><USER3> It actually can make more sense for larger websites than for smaller ones, as Pinterest can scale with demand and thus be running 50% or less VMs during quiet periods (e.g. middle of the night).

I'm not exactly sure how you jumped from them using AWS to the assumption that they're "throwing more hardware at [their] problems" rather than optimizing their software. AWS or other cloud services don't really indicate a certain priority as far as internal development, just like first party hardware doesn't (and there are companies that throw additional hardware at problems, just like there are companies that throw extra virtual capacity at it).

<comment><USER4> > It actually can make more sense for larger websites than for smaller ones, > as Pinterest can scale with demand and thus be running 50% or less VMs > during quiet periods (e.g. middle of the night).

You do understand we can buy things at 33% the price AWS charges, right? And have 24/7 access?

Oh, did you know you can do the same thing at other providers for cheaper? :|

AWS is overpriced.

<comment><USER5> Is it not possible that the peak load is more than 3x the average load? With your own hardware you have to be provisioned for peak load 100% of the time.

<comment><USER4> > Oh, did you know you can do the same thing at other providers for cheaper? > :|

[https://www.stormondemand.com/servers/baremetal.html](https://www.stormondemand.com/servers/baremetal.html) 32/64GB - $0.75/hr

[https://www.linode.com/pricing](https://www.linode.com/pricing) 20/64GB - $.96/hr _and_ bandwidth

[http://aws.amazon.com/ec2/pricing/](http://aws.amazon.com/ec2/pricing/) 16/64GB - $1/hr + bandwidth costs @ [varies]

Even if you take your premise at face value, AWS is literally the most expensive option.

Personally, I've never seen a real world use case where you dropped below 33% capacity. In practice, you can get hourly billing for cheaper than AWS anyway with providers large enough to meet most customers needs.

<comment><USER6> Linode, and most alternatives, don't have S3/Blob storage as a service.. also missing are distributed key-value storage as a service and sql as a service.

Generally, with any given service as you can scale it makes sense to run your own instances.. but realistically someone who knows _insert-tech_ better than AWS/Azure admins is a pretty rare breed, and having to in-source those specific skills costs in terms of time and money, redundancy even more so.

If you have a team of 3-5 people, you can do far more with AWS or Azure than you can most alternatives... Employees aren't free.

</comment></comment></comment></comment></comment></comment><comment><USER7> It sounds like they really ran afoul of the stable page writes bugs that exist in Linux 3.2.31 to 3.9.

Thread discussing the bug and a test program to show the issue.

[https://lkml.org/lkml/2012/10/9/210](https://lkml.org/lkml/2012/10/9/210)

Patch introducing the bug:

[https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=3d08bcc887a1c8d12be8d81f747ffa2e8a44b67b)

Patch fixing the bug:

[https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=1d1d1a767206fbe5d4c69493b7e6d2a8d08cc0a0)

It causes a huge dropoff in latency and throughput by causing all filesystems to block even when they don't need to.

In short, 3.2 is lethally bad in terms of database workloads.

</comment><comment><USER8> Would be interesting to see how this compares to RDS--i.e. perhaps all these optimizations are already in place, or perhaps it makes sense to not use RDS, and optimize mysql for your own workload.

</comment><comment><USER9> A question, with such high load, why not run it on dedicated hardware with PCI express SSDs? You are paying around $1000-2500 per month for the instance type for that you can get dedicated machine and lessen the total number of servers.

<comment><USER10> Or use Google Cloud which will stick a 375GB PCIe SSD in your VM for $80 a month.

<comment><USER11> Yeah their SSD pricing example seemed to blow AWS away [http://googlecloudplatform.blogspot.com.au/2015/04/understan...](http://googlecloudplatform.blogspot.com.au/2015/04/understanding- cloud-pricing-part-2.html)

<comment><USER10> Awesome.. As much as I dislike Google as a business, I love their engineering and despite being totally biased coming on to GCP, they won me entirely in a day. We're so, so very much happier dealing with GCP. No RAID to get perf - just ask for more. No complexity. Simple, damn fast, and cheap.

I cannot imagine how Azure or AWS compete (esp Azure - even without making a cheap comment about their terrible new portal) when it comes to IaaS. GCP is just flat out better.

</comment></comment></comment></comment><comment><USER12> When I see the prices / perf that AWS offers compare to high end hosting like Rackspace, its' crazy.

I don't know why people keep running MySQL on AWS.

<comment><USER13> Rackspace is on the high end as far as price. You can find DCs for much much less (multiple times less).

</comment></comment><comment><USER14> This article doesn't talk about the optimizations, it just mentions they were done. Clickbait, I'm afraid.

<comment><USER15> The link at the end points to this slide deck, which has more specific details: [http://www.slideshare.net/denshikarasu/all-your-iops-are- bel...](http://www.slideshare.net/denshikarasu/all-your-iops-are-belong-to-us- a-pinteresting-case-study-in-mysql-performance-optimization)

I recommend taking a look at it.

</comment></comment><comment><USER16> It's amazing to me that anyone still tries to run mysql with the glibc allocator. That allocator is not suitable for any kind of multithreaded workload. Use tcmalloc or jemalloc for everything.</comment>


EU Tackles Crisis With 50% Greek Writedown, $1.4 Trillion Fund - <AUTHOR> http://www.businessweek.com/news/2011-10-27/eu-tackles-crisis-with-50-greek-writedown-1-4-trillion-fund.html

<comment><USER2> Markets are acting in exuberance over this deal, but hard to see how this satisfies the underlying issue.</comment>


Interoperability and the W3C: Defending the Future from the Present - <AUTHOR> https://www.eff.org/deeplinks/2016/03/interoperability-and-w3c-defending-future-present <comment><USER2> I've said it before, and I am sure it will be as unpopular now as then: there are people here who should know better, who can see where this road leads, but they are selfish "I know DRM is bad, but I got ta have ma Netflix!".

Bad things happen because selfish people want to be spoon-fed digital junk food, and they will accept perverting the open web to achieve it.

At the point the W3C accepted eme/DRM, it was already finished as a standards org, it just didn't realise it yet.

<comment><USER3> I don't see an issue, I don't watch netflix on my browser anymore. IMHO we can live without EME and we can get Netflix proprietary apps natively doing whatever they want to decode DRM on their own. We don't need to break the web for that.

</comment></comment><comment><USER4> DRM must not be allowed into a W3C Recommendation. The W3C has already lost staff over the issue, and stand to lose more if they ignore the thousands of people who object to this. I really hope that the protests and press from the FSF and EFF have helped steer the W3C into doing the right thing.

</comment><comment><USER5> When reading the beginning of the article, I did not get what the big deal was. It seemed to me that W3C just wanted to standardize existing DRM on the web and if you did not want to use DRM, then do not visit the site.

But then I came to the part where developers can be sued under DMCA for trying to reverse-engineer the DRM (which inhibits new browsers, if they do not want to use proprietary binary blobs) and worst of all:

 _It would be a return to the bad old days of websites that advised that they were "Best viewed with Netscape" or "Best viewed with Internet Explorer," because the new browsers would be locked out of some of their content._

</comment><comment><USER6> I have really mixed feelings about this.

On one hand, I enjoy renting new material from Google Plus Movies and TV, enjoy Hulu and Netflix. I understand the need for some form of DRM.

On the other hand, I support the FSF and like to see open source options.

For me, the best middle road is to isolate all of the DRM in one closed source web browsers, and have the rest of my system as close to liver software as is practical.

<comment><USER7> Essentially, the choices are not "Standardize DRM descriptions in the w3c process or don't have browsers supporting DRM at the HTML-model level."

The choices are "Standardize DRM descriptions in the w3c process or have an ad-hoc collection of binary blobs, de-facto standards implemented by the dominant browser vendors, and external mobile players." If the w3c doesn't standardize the DRM descriptions, it just pushes the standards a little bit towards irrelevance as the industry interprets silence as damage and routes around it (especially given the current ecosystem where ever-more "web content" is actually vended through mobile apps).

This may very well be the principled stand that the w3c should take---it may be correct to curtail themselves to only standardizing things that can be openly implemented. But we should observe that their lack of a hat in this ring isn't going to kill DRM-protected video streams---the owners of the content want that and are willing to pay a LOT of money to be lied to.

<comment><USER8> Last time I checked, EME _still_ results in an ad hoc collection of binary blobs. There's Google, Adobe, Microsoft, and Apple all with competing blobs.

<comment><USER7> It results in a standard for describing them so that browsers can properly select the right one, or ignore all of them. That's less ad-hoc than the alternatives.

<comment><USER8> But it does very little, if anything, for the open web, and either needs total top to bottom specification for open implementation, or doesn't belong in a web standard.

<comment><USER7> That may be true, but it is irrelevant. I don't know why you believe that the technologies under the W3C web standards need be open. The _standards_ themselves need be open (they're published, after all), but the technologies underpinning them? Checking W3C's website, their guidelines for implementations appear to be "W3C issues a call for implementations as part of standardization and welcomes public participation" [[https://www.w3.org/participate/implementation](https://www.w3.org/participate/implementation)]. Nothing in the formal standards process [[https://www.w3.org/2005/10/Process-20051014/tr.html](https://www.w3.org/2005/10/Process-20051014/tr.html)] appears to require all implementations be "open," and that assumption flies in the face of previous legacy standards (<img> when .gif was an accepted file format but still encumbered by patent, the <object> and <embed> standards that specify closed-binary plugins to side-load).

While it'd be nice if it worked the way you described, it seems that the standard as currently codified (including one specified "dummy" open reference implementation) is all that is needed.

<comment><USER8> [https://www.w3.org/Consortium/Patent-Policy-20040205/#sec- Li...](https://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Licensing) (Royalty Free)

[https://www.w3.org/Consortium/mission#principles](https://www.w3.org/Consortium/mission#principles) (Web for All, Web on Everything)

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> Oh man, I smell a court case pitting the ADA against the DMCA. I have this feeling ADA would win.

<comment><USER10> The Library of Congress is permitted to create exemptions from the DMCA and there are two for accessibility: [http://itlaw.wikia.com/wiki/DMCA_Exemptions_to_the_Prohibiti...](http://itlaw.wikia.com/wiki/DMCA_Exemptions_to_the_Prohibition_on_Circumvention#Exemptions_granted_3)

</comment></comment><comment><USER11> We don't need the W3C and never have.</comment>


Ask HN: How important is internationalization for developer tools products? - <AUTHOR>

To what extent do developers around the world know English?<p>Is it important to develop multi language versions of developer tools? <comment><USER3> I need to start saving citations for this sort of thing to back what I'm about to say. From what I've seen, many international [0] programmers I've seen _prefer_ English documentation for their tools and largely work with English.

A large reason for that is because programming languages are (almost?) if not entirely in English. Take a look at _Japanese developed_ Ruby. What language are the keywords in? Not rōmanized Japanese, but English!

I remember reading a post here on HN just a few days ago from a Swedish programmer. When he developed a tool - he wrote the documentation in English. A dependency for his project had both Swedish and English documentation available. _He used the English documentation_ , even though his first language is Swedish.

Unless you are targeting an audience in a specific region (i.e India) - <USER2> would say i18n isn't very important. It's more important for end-users of a product that wants a global reach.

What's most important is to have examples in your documentation that can help explain themselves and show how the language is used.

[0] When I say foreign/international I mean countries where the official language isn't English. I feel the need to clarify this because it _bothers me_.</comment>


Customers furious over days-long outage at A2 Hosting - <AUTHOR> https://www.theregister.co.uk/2019/04/26/a2_hosting_outage/ <comment><AUTHOR> I have some non critical stuff hosted with these people and it's the push I need to move everything over to netlify. I trust them more and philosophically, with static hosting I can nimbly move house when I need to.

<comment><USER2> As long as you have short DNS TTL and don't use the same provider for DNS and hosting.

<comment><AUTHOR> Absolutely. These things I have.

</comment></comment></comment><comment><USER3> _" But I'm pretty sure about what happened. I was in a meeting with a customer, and we saw (yes, I've got witness) all my files (from my ftp area) were renamed to .lock and a message stating the area was attacked and encrypted."_

Interesting. I assume it's managed Windows hosting? Wouldn't really be A2's problem if not.

<comment><USER4> This is pure speculation on my part but there was a serious windows hypervisor bug patched in January, CVE-2019-0551

</comment></comment><comment><USER5> > That's why they didn't call themselves 'A1' Hosting

Ha!.. the Register's readers have some good banter!

</comment><comment><USER6> After 8 days of offline server. Now just server online. Still i am facing problems with a2 hosting. More than 1 month of data is lost. What a bad service. My friend recommended me to move to asphostportal. Is it good decision?

<comment><USER7> Yes, Asphostportal is good option to use. I have few clients that using their service. Maybe they are not big like Godaddy or EIG providers, but they really focus on their customers. Very good and offer reliable windows hosting solution. Price is also cheap</comment></comment>


Science courses nearly extinct in elementary grades, study finds - <AUTHOR> http://www.sfgate.com/cgi-bin/article.cgi?file=/c/a/2007/10/25/MNNKSVFOH.DTL <comment><AUTHOR> _"-- 80 percent of teachers say they spend less than an hour each week teaching science.

\-- 16 percent of the elementary teachers say they teach no science at all.

\-- Ten times as many teachers say they feel unprepared to teach science than feel unprepared to teach math or reading.

\-- Fewer than half of Bay Area fifth-graders scored at grade level or above on last spring's California Standards Test in science._"</comment>


How to End Mass Incarceration - <AUTHOR> https://jacobinmag.com/2017/08/mass-incarceration-prison-abolition-policing/ <comment><USER2> I should write something about Maricopa County, Arizona's recently-deposed & pardoned tin-pot dictator (Sherriff Arapaio)...

Thanks for the link.</comment>


Simpleweather.com for sale - <AUTHOR> http://www.simpleweather.com/ I thought that this sale was interesting because they include a pdf Media Kit on the site that gives a lot of details about the site. <comment><AUTHOR> I thought that this sale was interesting because they include a pdf Media Kit on the site that gives a lot of details about the site: <http://www.simpleweather.com/swmedia.pdf></comment>


I Was Wrong About Twitter - <AUTHOR> http://www.startuphustle.com/2008/05/06/i-was-wrong-about-twitter/ <comment><USER2> I finally took the plunge. I'll admit it: Twitter is fun.</comment>


Iran's Budget Report with Analytics - <AUTHOR> https://iranbudget.org/ <comment><USER2> The UI/UX is well designed.</comment>


Show HN: Input masking library - <AUTHOR> https://github.com/msafi/text-mask <comment><AUTHOR> Hey folks,

Over the past several months I've been working on this input masking library, Text Mask.

It takes a different a approach to solving the problem of input masking. Most input masking libraries read key-codes from browser events, and based on that decide what to do. Text Mask doesn't read any key-codes. It detects what the user entered by comparing the new value with the previous value, and works off of that. This approach eliminates cross-browser compatibility issues.

It's been a fun project to work on. But I would love to get more users and feedback!</comment>