catproof your computer
“Combination of jargon and garbage. I just made that up.”
I’ve always had a difficult relationship with Uber: I love the service because the whole experience was so much more pleasant than that of a taxi. They had figured out a better solution to all the little things and the result was just wonderful.
But at the same time, it’s company run by a bunch of unethical, Ayn Rand-ian, bros. I want to support companies that are not just convenient for me, but are ethical as well, so Uber bothered me. But it was just so damned convenient that I suppressed my distaste.
Fortunately Uber has just gone so far over the line that I’ve come to my senses. I regret not doing so before, but at least I can hold my head up now and say “enough!”. Not sure what service I’ll use now, but it won’t be Uber.
Here’s an example of why merely showing an average, or even an average and a variance, is insufficient in the real world:
“Immutable Servers are a deployment model that mandates that no application updates, security patches, or configuration changes happen on production systems.“:
This is one of the fundamentals of my management philosophy: the team is more powerful than the individual:
While this article is about nuclear war, the same belief-in-the-absence occurs in software systems all the time:
As an example of the above, here’s a great story about a seemingly improbable bug that surfaced in Facebook’s systems:
A good article about how rewarding the wrong thing leads to bad behavior:
If I have learned anything from the Internet, it is this: be very, very careful when you put a number next to someone’s name. Because people will do whatever it takes to make that number go up.
Of course this applies to everyone, not just executives:
And, as a fun end to the list, here’s an article that includes the architect who designed the New Relic Portland office. And an excellent job he did:
Conservatives want you to believe that while the goals of public programs on health, energy and more may be laudable, experience shows that such programs are doomed to failure. Don’t believe them. Yes, sometimes government officials, being human, get things wrong. But we’re actually surrounded by examples of government success, which they don’t want you to notice.
People do their best work in the face of constraints, but the kind of constraints make a big difference:
Amazon continues to amaze:
“Customers crave completion” so the goal should be to build a complete something, even if it’s very small:
So build something like this:
Here’s a third-party who writes a good introduction to New Relic’s most recent product; he “gets it”:
In a SaaS business, one sells not only a product but also the operation of that product, thus it is essential that one spends the time necessary to make the system robust:
Humorous, but maybe partly true as you would have built-in vendor-lock-in. Of course in most cases one has vendor lock-in even if there are multiple vendors because the cost to switch is just too high, so perhaps that’s not really an issue…
Made my day:
Some of the signs are obvious (#3,4,5,6), others less so (#1,2):
- You’re never quite satisfied with deliverables.
- You often feel frustrated because you would’ve gone about the task differently.
- You laser in on the details and take great pride and /or pain in making corrections.
- You constantly want to know where all your team members are and what they’re working on.
- You ask for frequent updates on where things stand.
- You prefer to be cc’d on emails.
See here: http://bit.ly/1xvz0bV
Unwritten Rule of Engineering #7: Avoid the very appearance of vacillating.
One of the gravest personal indictments is to have it said that an engineer’s opinion at any time depends merely upon the last person with whom he or she has spoken.
Not to be confused with seagull management where the executive just complains about things, this is actually more damaging because of the lack of deep knowledge of the topic:
I love this definition of continuous delivery:
I don’t entirely agree with this opinion of how to do compensation but it’s at least a well-thought-out approach to the problem. It might work for the very first phase of a start-up but I believe it will quickly fail as the company grows beyond the initial founders:
A couple of good talks at QConSF:
Here is one of the five: “Leadership doesn’t settle for yesterday’s achievements.”
This is definitely my philosophy — I will consider myself a success if a dozen people from my organization go off to found their own startups and engineering organizations:
I believe that developers are optimists — you know it’s going to work this next time, for sure — and that testers are pessimists — it will never work and it’s up to me to prove that:
Microsoft is a good example of why it is necessary to change the leadership now and then. Sometimes it requires new people (Microsoft) and other times it can be the same people if they are willing to change (Amazon):
This is an idea that I’ve had for years (and I’m sure many others have had for years) and I’m glad that someone has finally stepped up and implemented it:
Back when developers were building client applications that ran on single thread on a single processor on a single machine, it was much easier to troubleshoot what was going on. Developers would still start with a problem and a stare at the code, but they could reproduce the problem, set a breakpoint inspect the stack and local variables and quickly find the solution. Cloud Debugger brings this productive style of debugging to modern cloud production troubleshooting.
Here’s a nice article about the balance between agile and architecture:
I have also seen teams lead with a series of sprints focusing entirely on architecture (we call it plumbing). This approach can be overdone and create months of design and development with nothing tangible to show to an end user, which defeats the purpose of agile. What we need is a balance of speed to market and architecture. What we need is a Minimal Viable Architecture (MVA).
Excellent career advice: “Success = Visibility, Image, and Performance.” As he points out, Image is more like your “brand”. When people think about you, what do they think of? Do they think you work on hard and important problems?
Everybody can be the most powerful person in the room at different times, so it is important to remember that people watch you, all the time: