tim_h
Joined 15 years ago
Joined 15 years ago
I like the simplicity of this approach. It's best to keep the low-level stuff as simple as possible when building distributed systems. It will get complicated soon enough at the higher levels.
Edit: I'm surprised to see this downvoted. Care to comment why?
Is it not paying attention to the news cycle? Or knowing that the company is on a bad trajectory but still working there? Surely it's not the focus on work-life balance.
I could see myself working at Yahoo. I bet they still have interesting problems to work on. Yahoo Research does awesome stuff with computational advertising. Hypothetically speaking, would this opinion disqualify me from your hiring consideration?
I'm trying to estimate the chance that me not knowing C++ will pose a problem later in my career. I normally pick up languages quickly, but the C++ learning curve seems a bit steeper, both in terms of language nuances and libraries. So my normal approach of "wait until I need it" may not work that well.
1) Minimize the overall time investment required to have an acceptable solution to the problem. Time investment includes maintenance and debugging.
2) Make sure the marginal benefit to additional time spent in one area of the project exceeds the opportunity cost of focusing on other areas. E.g. It's good to spend a lot of time on getting the overall architecture right but it matters far less to optimize the business logic (for one thing it tends to change more often and for another it's hardly ever the performance bottleneck).
Contrast this with physical-stuff engineering (which I think is what you're referring to by saying "engineering background"), where the requirements tend to be better-defined and the cost of experimentation/refactoring is a lot higher.
> The most important characteristic of a suffering-oriented programmer is a relentless focus on refactoring. This is critical to prevent accidental complexity from sabotaging the codebase.
I can't tell you how many times I've seen accidental complexity creep in because someone adds a new feature without taking the time to refactor to the simplest set of abstractions. But - and here's the flaw in the approach - you have to be an expert in the code to produce such a set of abstractions, which is a potential bottleneck when your codebase is big enough to require multiple developers. Not everyone has the time/capability to be an expert.
My question is: how was consistency maintained? What mechanism prevented the same record from being changed both in Tokyo and in New York while the network was split? Or, what mechanism resolved the conflicts? I think the article might be glossing over some details here. I'm guessing that either one side of the split was offline (or at least read-only) during the outage or that the writes were made without guarantees.
Having said all this, I want to point out that my doctor told me that different medications work for different people. I may just be lucky enough to have the right body chemistry for a drug like Dexadrine to work well for me.
Perhaps the timeline will help overcome this tendency. By making everyone's history more visible, maybe people will become less sensitive to seeing past examples of immaturity and therefore weigh them less when making judgements about a person.
http://hnofficehours.com/profile/tim_h/