Many years ago, I did a brief stint at Google. A lot has changed since then, but even that brief exposure to Google’s internal developer tools left a lasting impression on me. In many ways, the dev tools inside Google are the most advanced in the world. Google has been a pioneer not only in scaling their own software systems but in figuring out how to build software effectively at scale. They’ve dealt with issues related to codebase volume, code discoverability, organizational knowledge sharing, and multi-service deployment at a level of sophistication that most other companies have not yet reached. (For reference, see Software Engineering at Google.)
In other ways, however, Google’s internal tools are awfully limited. In particular, nearly all of them are tightly coupled with Google’s unique internal ecosystem. Unfortunately, that means you can’t take them with you when you leave.
The Google diaspora has seeded so many other organizations with amazing talented people who bring lessons learned from working inside one of the world’s leading technology organizations. But adapting to programming outside of Google can be tough, especially when you’ve come to rely on tools you no longer have at your disposal.
Over the years, I’ve learned from my own experience and the experience of lots of others who have left Google. Many of Sourcegraph’s early customers began with an ex-Googler missing code search after leaving Google. I worked closely with these people to understand the gap they were trying to fill, so that we could build Sourcegraph to meet their needs. Over time, patterns emerged in terms of how ex-Googlers sought to introduce new dev tools into their organizations, inspired by their experience with dev tools at Google. Some were successful and others were not.
I thought it would be helpful to write a guide to dev tools outside of Google for the ex-Googler, written with an eye toward pragmatism and practicality. No doubt many ex-Googlers wish they could simply clone the dev tools ecosystem inside of Google to their new company, but you can’t boil the ocean. Here is my take on where you should start and a general path I think ex-Googlers can take to find the tools that will make them—and their new teams—as productive as possible…
- A fallacy is the use of invalid or faulty reasoning in an argument.
- There are two broad types of logical fallacies: formal and informal.
- A formal fallacy describes a flaw in the construction of a deductive argument, while an informal fallacy describes an error in reasoning.
In arguments, few things are more frustrating than when you realize that someone is using bad logic, but you can’t quite identify what the problem is.
This rarely happens with the more well-known logical fallacies. For example, when someone in an argument starts criticizing the other person’s reputation instead of their ideas, most people know that’s an ad hominem attack. Or, when someone compares two things to support their argument, but it doesn’t make sense, that’s a false equivalency. But other fallacies are harder to spot. For example, say you’re arguing about politics with a friend, and they say:
“The far-left is crazy. The far-right is violent. That’s why the right answers lie the middle.”
Sure, it might be true that moderation is the answer. But just because two extremes exist doesn’t mean that the truth necessarily lies between those extremes. Put more starkly: If one person says the sky is blue, but someone else says it’s yellow, that doesn’t mean the sky is green. This is an argument to moderation, or the middle ground fallacy — you hear it a lot from people who are trying to mediate conflicts.
When you find yourself in arguments, it’s valuable to be able to spot and, if necessary, call out logical fallacies like this. It can protect you against bad ideas. Check out a few more examples of logical fallacies that can be tough to spot…
Recently I (along with a few others much smarter than me) had occasion to implement a ‘real’ production system with Istio, running on a managed cloud-provided Kubernetes service.
“My next ulcer will be called ‘istio'” by Ian Miell
Istio has a reputation for being difficult to build with and administer, but I haven’t read many war stories about trying to make it work, so I thought it might be useful to actually write about what it’s like in the trenches for a ‘typical’ team trying to implement this stuff. The intention is very much not to bury Istio, but to praise it (it does so much that is useful/needed for ‘real’ Kubernetes clusters – skip to the end if impatient) while warning those about to step into the breach what comes if you’re not prepared…
“The most damaging thing you learned in school wasn’t something you learned in any specific class. It was learning to get good grades.
When I was in college, a particularly earnest philosophy grad student once told me that he never cared what grade he got in a class, only what he learned in it. This stuck in my mind because it was the only time I ever heard anyone say such a thing.
For me, as for most students, the measurement of what I was learning completely dominated actual learning in college. I was fairly earnest; I was genuinely interested in most of the classes I took, and I worked hard. And yet I worked by far the hardest when I was studying for a test.
In theory, tests are merely what their name implies: tests of what you’ve learned in the class. In theory you shouldn’t have to prepare for a test in a class any more than you have to prepare for a blood test. In theory you learn from taking the class, from going to the lectures and doing the reading and/or assignments, and the test that comes afterward merely measures how well you learned…”
The self-healing letter of complaint
You’ve been wronged. The service was terrible. You went unseen, disrespected and abused. You didn’t get your money’s worth. The software is sloppy, the people were rude, the entire experience was lousy.
A letter to the organization is called for. At the very least, you’ll get an apology, some free samples, and maybe, just maybe, they’ll fix the problem for everyone who comes after you. How generous of you to dig in and share the vitriol.
Better put a sharp point on it, personalize it and make it sting.
Here’s the thing: Every angry word you write is only going to confirm the story you’re already telling yourself, the story that’s still making you miserable. The more spite you put into the note, the worse you’re going to feel. You’ll relive the event again and again. And, it’s pretty certain, if a human reads the note, they’ll now feel lousy too. They might go home and kick their dog, it’s that visceral.
To what end? Is it going to increase the chances that change happens?
Here’s a different tack, a selfish one that pays off for everyone involved:
Write the most positive note you can imagine. Write about how much the brand/service/government agency means to you. Let them know just how much you trust them, how much they’ve helped you in the past. Lay it on thick, that’s okay, it’ll remind you of why you care in the first place, and it will build bridges instead of tearing them down.
Then, say, “Here’s what didn’t work” or “But I have an important suggestion…”
And, without adding the hurt and anger that you feel, explain what went wrong. Explain it clearly, in a useful way, but give the reader the benefit of the doubt. Assume she knows that it didn’t make you happy, that it completely ruined your wedding, that you’re never ever going to return. Just leave that part out.
After all, if you didn’t care about them, you wouldn’t bother writing a letter, would you?
Two things will probably happen:
- When you hit ‘send’ you’re going to feel better about yourself and the process you just engaged in, and
- It’s more likely that the long-suffering recipient of your note will actually take action
We can change the stories we tell ourselves.