How many times have you heard this? Or this?
Two of the most oft repeated, and driven home, ideas in modern times are be true to yourself and do what you love. But just because they’re oft repeated and driven home doesn’t mean they are actually true. The problem with both statements is they have just enough truth to sound really plausible—and yet they are both simplistic enough to be dangerous when taken raw.
Or maybe it’s just that I’m a grumpy old man who’s been in a bad mood for the last couple of weeks, and misery likes company. 🙂
Let’s try to put some reality into the do what you love statement.
Sometimes you’re just not very good at what you love to do. When I was a kid, I wanted to be an artist. And then a musician. Apparently there are no real jobs for artists or musicians with my somewhat mediocre skills in these two areas. I just have to face it—I’m never going to be a professional basketball player, either. Sometimes it doesn’t matter how much you love something, you just don’t have the skills to master it.
Sometimes there’s just no market for what you love to do. I know it’s cruel to say in the modern world, where everyone deserves fortune and fame, but there really are things you can love to do for which there is no market. Don’t despair, though, there’s still some use for those things you love to do—they’re called hobbies. There’s nothing wrong with them, honestly.
Sometimes you’re just in the wrong place or at the wrong time. If you have a passion for making buggy wheels, you’re in the wrong place or the wrong time. Trust me.
So what can we do about this whole loving your work thing? Maybe a more realistic take might be—
Do what you’re interested in, and think there’s good support for in the market.
Expect to do things you don’t like no matter what you do. Even the best job in the world will contain some stuff you love to do, and some stuff you don’t. If this doesn’t include the job you’re in now, just wait. 🙂
Do something you’re good at.
Do something that makes you feel like you’ve accomplished something at the end of the day. Some people really enjoy making other people happy. Other people really enjoy building something interesting. One note, though—if what you really enjoy is being noticed, give that dream up right now. The sooner you can do things because of their intrinsic worth, rather than for the attention you might get, the happier you’ll be.
Learn to like whatever it is you do. There are always interesting things about any job you can find, whether it’s the people, the weather, the work itself, or something. Find at least one such thing and try to develop it into a passion that will carry you through the things you truly don’t like. For the rest, learn to be content even in doing what you don’t necessarily enjoy.
Learn to learn and to grow regardless of where your job is taking you. This last one is important as a person, rather than just in a commercial sense. If you can’t learn to learn, other than “just to get the job done,” then it doesn’t matter what you choose to do—you’re never going to love it, and you’re never going to get rich from it.
The advice here might not be as catchy, upbeat, or happy, as the pretty pictures above, but it’s much more realistic—and you might actually find you really do love what you do, and work isn’t truly work all the time if you start from a realistic view of it.
In the last post in this series, I discussed using SR labels to direct traffic from one flow onto, and from other flows off of, a particular path through a DC fabric. Throughout this series, though, I’ve been using node (or prefix) SIDs to direct the traffic. There is another kind of SID in SR that needs to be considered—the adj-sid. Let’s consider the same fabric used throughout this series—
So far, I’ve been describing the green marked path using the node or (loopback) prefix-sids:
[A,F,G,D,E]. What’s interesting is I could describe the same path using adj-sids:
[a->f,f->g,g->d,d->e], where the vector in each hop is described by a single entry on the SR stack. There is, in fact, no difference between the two ways of describing this path, as there is only one link between each pair of routers in the path. This means everything discussed in this series so far could be accomplished with either a set of adj SIDs ore a set of node (prefix) SIDs.
Given this, why are both types of SIDs defined? Assume we zoom in a little on the border leaf node in this topology, and find—
- Router E, a ToR on the “other side of the fabric,” wants to send traffic through Y rather than Z
- Router Y does not support SR, or is not connected to the SR control plane running on the fabric
What can Router E do to make certain traffic exits the border leaf towards Router Y, rather than Router Z? Begin with Router A building an adj-sid for each of it’s connections to the exiting routers—
- A->Y on A1 is given label 1500
- A->Y on A2 is given label 1501
- A->Y ECMP across both links is given label 1502
- A->Z is given label 1503
With Router advertising this set of labels, E can use the SR stack—
[H,A,1500]to push traffic towards Y along the A1 link
[H,A,1501]to push traffic towards Y along the A2 link
[H,A,1502]to push traffic towards Y using ECMP using both A1 and A2
This indicates there are two specific places where adj-sids can be useful in combination with node (or prefix) SIDs—
- When the router towards which traffic needs to be directed doesn’t participate in SR; this effectively widens the scope of SR’s effectiveness to one hop beyond the SR deployment itself
- When there is more than one link between to adjacent routers; this allows SR to choose one of a set of links among a group of bundled links, or a pair of parallel links that would normally be used through ECMP
Again, note that the entire deployment developed so far in this series could use either just adj-sids, or just node (prefix) SIDs; both are not required. To gain more finely grained control over the path taken through the fabric, and in situations where SR wants to be extended beyond the reach of the SR deployment itself, both types of SIDs are required.
This brings up another potential use case in a data center fabric, as well. So far, we’ve not dealt with overlay networks, only the fabric itself. Suppose, however, you have—
Where C, D, E, and F are ToR or leaf switches (routers), and A, B, G, and H are hosts (or switches inside hypervisors). Each of the two differently colored/dashed sets of lines represent a security domain of some type; however, this security domain appears, from IP’s perspective, to be a single subnet. This could be, for instance, a single subnet split into multiple broadcast domains using eVPNs, or simply some set of segments set up for security purposes. In this particular situation, G wants to send traffic to D without F receiving it. Given the servers themselves participate in the SR domain, how could this be accomplished? G could send this traffic with an SR stack telling E to transmit the traffic through the blue interface, rather than the blue one. This could be a single SR stack, containing just a single adj-sid telling E to which interface to use when forwarding this traffic.
I had hoped to finish this series this week, but it looks like it’s going to take one more week to wrap up a few odds and ends…
A lot of people seem to be looking forward to the day we build a network without an operator; to wit—
Containerized solutions and machine learning may soon be more than tangentially related. Containerized solutions will usher in an era of operations that don’t require human intervention. Once humans are taken out of operations, we will be free to apply machine learning techniques to what is left. —The New Stack
I hope not, because machines are more brittle than humans. Totally automated security fails much more often than security that uses a blend of people and algorithms. Machines do well at repetitive tasks, humans at catching the things that don’t fit into the algorithm’s state machine. Taking the person out of the network just means there’s no-one there to see when the state machine fails.
And it will fail—at some point. I know we like to believe that machines break less often, but I’m pretty certain there’s a counterpoint to this: when machines break, it’s more likely to be catastrophic. I’m not convinced replacing people with algorithms always reduces damage so much as move the potential damage around.
I hope not, because machines separate the decision from the decision maker. Butting your head against reality means making decisions in the face of tradeoffs. Allowing machines to make the decision doesn’t really reduce the tradeoffs, it just pushes the decision back to the algorithm designer rather than the operator. Taking the decision out of the hands of a person who sees the actual situation, and handing it to a person who can white board a decision long before the situation occurs just means you’ve pre-decided, it doesn’t mean you’ve decided correctly. When a self-driving car faces the trolley problem, what will it do? Of course, a data center isn’t a car, but does that mean there will never be moral choices involved in running a data center?
I hope not, because when it does crash, someone still needs to know how to work on it. When machines become so complex that we can build them but not understand them, then maybe it’s time to rethink whether or not building the machine is the right thing to do in the first place.
When should humans be taken out of operations?
There are some days I wish I could travel back in time and “fix” the time I wasted through an hour, a day, or a week working on something that really wasn’t worth my time, or just wandering through links on the Internet, looking at things I don’t really (ultimately) care about. My time management skills are, honestly, often lacking. There doesn’t seem to be a way, does there, though?
Or maybe there is. Let’s twist our brains a little and think about it this way. Tomorrow is going to be the day we wish we could travel into from the day after tomorrow to fix, right? So what if we did reverse time travel and fix tomorrow today? Sure, sounds nice, but how? The answer might seem a little trivial, but it’s only apparently trivial, rather than trivial in real life.
Once answer is the humble todo list. I know, you’ve made one of these before—in fact, you probably already have one, don’t you? And it’s never really helped, right? Well, let’s see if we can figure out how to supercharge to make it a bit more effective. To begin, we have to try to understand how a todo list can help you be more efficient. What, specifically, does a todo list do?
Simply put, the todo list is just another form of constraining your future choices today. In other words, it’s like squirreling money away in a place that makes it hard to get to, or setting up a menu for the coming week and shopping for the items needed to bring the menu to the table. It might seem counterintuitive in our modern age of “freedom for all to do all at all times” to discuss ways of imposing decisions on your future self today.
But this is just because we misunderstand the real nature of freedom. There are stories—apocryphal, I’m certain—of people who’ve somehow moved from a life situation where they have few or not choices in what they will use to, say, wash their hair, to having thousands of choices. The result isn’t a great burst of joy and sense of freedom. Rather, it’s great confusion, a feeling of being overwhelmed, and, often, a frozen stare, or listless wandering.
This, in fact, is why one of the most depressing parts of my life is looking at my todo list. There is so much to do I can simply get lost in deciding what to do next. Remember the old error message, “processor thrashing on process scheduler?” That mode is far too easy to fall in to. So what you need to do is to limit your range of future options in a way that both doesn’t feel like it’s limiting, and yet meaningfully reduces the amount of time you spend making decisions.
Bringing this into a larger context, I always eat pretty much the same three or four things no matter where I go. In fact, at certain restaurants, I always eat pretty much the same thing. Isn’t that boring? Well, maybe—but I spend a lot less time and angst looking at the menu, and more time chatting with the people around me. In fact, in most of my “regular spots,” I don’t even need to order—I know the people, and they know what I’m going to order.
Which matters more: trying something new for dinner, or having that much less angst, and that little bit more time to chat with friends? Variety might be the spice of life, but time is the stuff life is made up of. Too much spice, and there’s nothing left to spice.
So let’s return to the humble todo list. I used to have several todo lists, primarily to combat the huge todo list syndrome. Seriously, I would keep one todo list for each “area” of my life, and then I had a master todo list that told me which todo list to choose from next. It might work for you, but it didn’t work for me.
Instead, I’ve gone to a single todo list. I don’t want you to get the wrong idea here—I still have lists of ideas, research progress in different areas, and the like. If you were to look at my folders in OneNote, you’d find I just about live my life in there. There’s no end of notes, ideas, lists, etc. But there is only one todo list.
What I traditionally do is to organize my list like a queue. I put the most important things on the top, but I “shake in” a few things that “aren’t important” here and there. Otherwise, I’ve discovered, the stuff that’s “not important” falls permanently to the bottom. Then, each time I find I’m in need of something new to do, I start at the top of the list. But this returns me to my todo list, and the angst attendant on looking at it, just about every day. My todo list is so huge that I actually get depressed looking at it. The one sure way to send me off looking through moderately useless link-fishing on the Internet is to get me to look at my todo list. Seriously, it’s huge. Beyond this, I still have weekly and other “regular” tasks I need to take care of. Somehow I have to make certain those are on my list, as well, or they just won’t get done.
So how do I solve all of this? I was reading someplace that “truly effective people” schedule everything—they don’t have todo lists at all. Rather than having a list, when they accept a new thing to do, they just schedule it on their calendar. Now when they get up in the morning, they not only have a list, they have a schedule to follow.
I tried this. There is one way to describe the result: time management disaster.
Some things took more time than I thought. Others took less. Sometimes I had to lay a project aside and take on some component of the project in order to do the larger project. So now I’ve blended the list and the calendar.
Once a week I look at my todo list. I choose a set of things off that list, and schedule them (using Outlook, but any calendar with the ability to set tasks with completion dates will do) to be done by the end of the week. I keep notes about these tasks back in OneNote—one of the nice things about the OneNote/Outlook combination is I can actually cross reference the two things with a link between items. This creates a weekly task list that I can actually look at without feeling overwhelmed, and it helps me set actual dates by which I need to get things done. To this task list in Outlook, I also add my recurring tasks, so I now have everything I need to do this week in one place. Some things bleed over into next week/month/etc., but my focus is always on this week. When I get to the end of the week, I look at the leftovers. I can either carry them over into next week by adjusting the due date, or simply decide they really weren’t that important, and just delete them.
It’s not a perfect solution, but it seems to be working better than earlier methods I’ve tried. There are some things I’m trying to figure out—how to defer a task for several days, for instance— but this system seems to be serving me better than previous ones.
So—remember this—the key to more efficient work in the future is often restricting your future choices today. The todo list is one of those practical ways you can time travel into tomorrow and help your future self make better use of your time—so in the future, your future self doesn’t regret what your past self, your current future self, spent time on.
Mind blowing, I know. But that’s my random thought for the week.
It’s a familiar story by now: on the 8th of August, 2016, Delta lost power to its Atlanta data center, causing the entire data center to fail. Thousands of flights were cancelled, many more delayed, and tens of thousands of travellers stranded. What’s so unusual about this event is in the larger scheme of network engineering, it’s not that unusual. If I think back to my time on the Escalation Team at a large vendor, I can think of hundreds of situations like this. And among all those events, there is one point in common: it takes longer to boot the system than it does to fix the initial problem. —CircleID