orangepenguin

Good point! I've definitely had that feeling as an individual contributor.

Indeed. The fact that Mel had enough control to place an instruction at the "most pessimum" location too! I sometimes feel that I missed a "golden age" of computing when one person could make such a tremendous difference with such a small amount of code.

Yes, that is also true, and my father-in-law readily admits that he was simply misusing the tool in a very dangerous way. I believe he was starting with 2"x2" bar and cutting off a 2" segment. The fence should not have been on the saw for this, and a sled would have been ideal.

I actually like this video better than the one we're all discussing. He does a fantastic job of safely illustrating the problem of kickback: how fast it happens, how little movement it takes to trigger, and how to prevent it all together.

When my father-in-law was a college student he was using a table saw to cut aluminum stock to make a 2" cube. He had the fence on. As he finished the cut, the 2" cube turned between the blade and the fence and launched at him, hitting him right on the lens of his safety glasses. He never saw the cube--it went out a window after bouncing off his glasses. His safety glasses were crushed, and he had pretty deep cuts and bruises around his eye.

He tells that story when he thinks people aren't having enough respect for power tools. He could have been much more severely injured. If he hadn't been wearing safety glasses he definitely would have lost his eye and could have had brain damage as well.

Human strength and reaction times are so insignificant compared to these machines. It's purely an illusion that we are in control of them, and there's no reason not to use all of the safety measures and precautions available to us.

And is the snapshot system also distributed and highly available? If so, wouldn't it take on the challenges of committing changes?

Exactly what I was thinking. If you have a system of input data snapshots that's also distributed and highly available, it essentially becomes the database (as far as complexity is concerned).

So then whatever process maintains the snapshots of input data must absorb all of the complexity eliminated from the workers, no?

Right. Talking about "Calvin", he says:

> Nonetheless, it was able to bring the processing of that transaction to completion without having to abort it. It accomplished this via restarting the transaction from the same original input.

I may be misunderstanding, but if you have transactions recorded in such a way that any worker can replay from any point in time and reach the correct database state, then the transaction log must absorb all of the complexity. The problem has moved, but not changed.

To me, the system-induced abort scenario is the more difficult to address, and this article hasn't really addressed the problem. It sounds like he's saying "just don't give workers the option to abort", as if the workers were deliberately causing issues.

One can say "just don't give the spaceship the option to go slower than the speed of light" but saying so doesn't change anything about the underlying physical constraints.

The sole purpose of this is to help eliminate some of the pain for people attending re:Invent. The scheduling interface isn't great. I did this for myself and thought I'd share.

DNS is resolving because people can get to the site. Because of the distributed nature of YouTube's resources (at DNS as well as other layers), it's very unlikely to be DDoS related. Static content loads, but video content doesn't. Seems like an application error, or a problem with media streaming infrastructure.

Always. If you can't resolve the exception and continue processing normally, you should never discard the exception you caught and create a new one of your own. If you must create one of your own, include the one you caught for the additional context.

It's pretty frustrating when you're debugging someone else's code and their error handling just throws away all of the useful information and replaces it with a generic "Something broke" kind of message.

Kount | Software Development & Business Roles | Boise, ID | Full-Time & Internships | ONSITE | INTERNS | kount.com/about/careers

Real-time fraud analysis and prevention for merchants with "card-not-present" transactions. Our product helps merchants decline to process fraudulent credit card transactions. Kount employees have a great work life balance and have opportunities during work hours to serve in the community. Our open, honest, and fearless culture creates strong teams and informed employees.

Positions:

  - Accounting Intern
  - IT Compliance Program Manager
  - Content Marketing Manager
  - Director of IT Operations
  - QA Automation Engineer II
  - Sales Executive
  - Software Development Intern
  - Software Engineer
  - Software Engineer (Front-End)

Benefits:

  - Generous 401(k) match, 100% vested immediately
  - Pre-tax options for medical/dependent care
  - Continuing Education Benefits
  - Paid Time Off (with rollover) / Flex days (good for cash at year end)
  - Medical / Dental / Vision / Life Assistance Program
  - Term Life / AD&D / Short & Long Term Disability
  - Great year end bonuses (or commission plans for sales)

Apply online at https://kount.com/about/careers

Email adam.jensen@kount.com with questions.

Can anyone give a summary or point me to another article (not paywalled) with similar information? I'm very interested, but don't have a WSJ subscription.

That looks pretty handy. I'm at work (maybe I shouldn't be on HN at all, haha...) and Facebook is blocked. But I guess that's my problem. :) I'll check it out when I get home.

I feel a little sad that pay-walled articles make it to the top of HN. I'm sure the article is interesting, but a lot of us can't actually read it.

I thoroughly enjoyed this story, but wonder if the details have changed a bit over time, perhaps? If light can travel ~558 miles in 3 milliseconds, it seems that mail sent more than 250 miles would have failed (because RTT)?

Also, I'm not sure how big a difference it makes, but signals propagate at less than the "speed of light" (vacuum) when the medium is copper.

There is obviously a lot of debate on whether or not fact checking is accurate and useful. I think simply presenting a fact check will help people think more critically about headlines they see every day. Like "Mythbusters Science". It's not perfect, but it helps people to think.

Relevant: https://xkcd.com/397/

Not my project, but I use it. It has helped me containerize older apps that are config file dependent. Helps bridge the gap without requiring a full refactor of the legacy application.

I think this comment is absolutely spot on. The biggest difference between software development and other careers is that people don't care how you got to where you are. They only care if you can produce good work.

And there's a LOT to be said for bringing the knowledge you have, and making something useful with it.

In my opinion, if you decide to switch, the best thing you can do is start practicing. Whether you learn from online courses, school, friends, or books matters less than how much time you spend practicing. Preferably, put as much of your own work as you can in a public repository (somewhere like github.com) so that people can see that you get things done.

Hmm... good idea. Added bonus, if he has to Google it to explain it, he'll learn how it works. :D

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.

It is easy to feel oppressed in software development. I don't mean to say that people in software development are oppressed, just that it's easy to feel that way. One of the goals of software development is to create a product that people don't notice or think about (something intuitive). I have found that it is common for developers to feel that their work goes unnoticed at times.

That being said, I would recommend three things:

1) Try to focus a little less on whether or not you've been treated as fairly as possible and look for ways you can improve things for everyone in the company. If you leave, someone else is going to have to deal with the same crap. Is there a way you can make it better?

2) Talk to higher management. Try to be objective and avoid blaming. Just identify things in the process that are causing you to feel unappreciated and ineffective. Could they involve you in more planning meetings? Could you start holding trainings to share knowledge among other developers?

3) Remember that you don't owe the company anything. You should absolutely be professional in all your dealings, but a job is a means to an end. If you aren't getting the pay, recognition, or satisfaction you're looking for, just look for another job. Companies live and die. Employees come and go. Don't get too emotionally tied to it.

Realize also that exceptional uptime is not easy to achieve. If you want to sell this service, you also need to have incredibly reliable infrastructure.

Example: I worked at a VoIP company. A mishandled call by another carrier in the chain led to the death of a child (it took several minutes to actually reach emergency services in the right country).

You don't want to advertise that your app is available when everything else has failed unless it always is.

It's back.

This is not mine, I just found it.

Relevant comics: http://xkcd.com/1004/ http://xkcd.com/1031/ http://xkcd.com/1288/ http://xkcd.com/1418/ http://xkcd.com/1625/

No the gun does not move. The author appears to have misunderstood this. I don't find it likely that he would have used the words "physically moves to point" if he meant that the electron beam is deflected magnetically. Still, great article.

You're right. I did misrepresent the situation. I've had quite a few positive experiences there too. Some of the best feedback I've gotten from this thread is that I should be looking at my own behavior and considering whether or not I'm doing my part to learn and be friendly to work with. I still may consider a job change in time, but I should be careful about where I place blame and what accusations I throw around.

Good point. If I am as mature an adult as I believe myself to be, I ought to be able to have a peaceful conversation about this with a couple of coworkers individually. Definitely would be better than putting them on the defensive by sending a manager after them.