Monthly Archives: September 2013

Announcement: Challenge Failed

2 Replies

Hi Gang,

So, my plan this week was to blog every day, and today I planned to post the final post in the Loyalty and Layoffs followup series. Life got increasingly out of hand this week and I’m not ready to post the finale. I could jam something out over lunch, but I wouldn’t be happy with the result.

I wouldn’t normally post a “No Post Today” announcement. Don’t point out your mistakes, right? However, I did promise you a post each day this week, and based on my web traffic stats, some of you have been showing up every day to read those posts. I am grateful for that trust, and I don’t want to leave you hanging.

I’ll be back Monday with the followup, and it’ll get the attention it deserves over the weekend.

Thanks!

Parentheses in Ruby

10 Replies

I’ve been doing a lot of “heart” and “mind” posts lately, and “code” is starting to feel neglected. If you’re not a programmer, feel free to give this one a miss.

I put off writing this post til the last minute because I want to talk about parentheses in Ruby, and I’d like to give you a definitive “do this” answer, but the reality is I just don’t know, so I’m gonna throw out some thoughts and let you guys tell me what you think.

Ruby Makes Parentheses Optional

Okay, that’s not news. But a lot of people come to Ruby from languages where parens are required, and they see that they’re optional in Ruby, and so they keep them in out of habit. And then they complain that Ruby is dumb for not having first-class functions.

What is often overlooked here is that optional parens are important. Matz chose to sacrifice first-class functions just so he could make parentheses optional. So when I started programming in Ruby, I made an effort to eschew them when possible. Now, “optional” means optional–it doesn’t mean banned and it doesn’t mean required. So there’s room for wiggle here.

Some Strong Styles Have Emerged

There are some very strong idioms that have emerged, however. Well, mainly just one: Never use empty parens. This is actually two rules: never put parens at the end of a method definition if the method takes no arguments, and never use parens when sending a message that takes no arguments. There’s a lot of really good reasons for doing this, and I won’t go into them here.

Generally Favoring Parens

I know some smart programmers who favor parens in ruby. Their general argument is simply “it makes the code more readable”.

My experience has been that this argument is indistinguishable from “it makes the code look like the other languages I’ve spent years learning to read”. This is not necessarily wrong. I think both styles have tradeoffs, and there’s a mental cost to be paid to learn to read a new style. Since this cost has to be paid up front, the tradeoff is really imbalanced in the short-term. But is this a false economy in the long run? I’m asking because I don’t know.

Generally Eschewing Parens

On the far other side of the spectrum lies “Seattle.rb style”. Josh Susser originally coined the term “Seatttle style” to mean “not using parens in method definitions”, but Ryan Davis and Seattle.rb have taken it and run with it to mean “never use parentheses unless the compiler requires it”.

I spent a couple weeks experimenting with this style. It definitely had an effect on my code. I never did get to where I like omitting parens from method definitions, and maybe I am subject to my own argument above about embracing the tradeoff. One thing I did find, however, was that trying to avoid parens everywhere else had a profoundly rewarding effect on how I felt about my code. The original argument from Matz about making parens optional was that parens are often just noise, and getting rid of this noise is important.

Parens and Readability

When I talked about this with the rest of the Ruby Rogues, I quickly found myself in a 3-against-1 battle (Katrina wasn’t available). Josh made the argument that omitting parens decreases readability. You have to read this entire line of code to know when the first method call is actually done:

puts array.delete hash.fetch :foo

And I have to agree. That line of code is horrible.

But… it’s not the lack of parens that make it horrible. That line of code is horrible all by itself. I don’t think this is really any better:

puts array.delete(hash.fetch(:foo))

(Another strong convention in Ruby is to never use parens with calls to puts; otherwise another layer of parens could be added, but they would be gratuitous.)

Now, some programmers will find that line of code more readable. My point is that this is a problem. The line looks a bit more comforting, but you still actually have to read the whole line to know what’s happening. This line is doing two manipulations on unrelated primitives followed by a side effect call to puts. This line desperately needs some intention-revealing variable, methods, and selectors.

I see code like this all the time in parenful code. It sort of gets a pass with the parens stuck on. We say “yeah, this could be refactored, but it’s readable enough for now.”

But scroll back up to the version without parens. That line is unforgiveable. It has to go.

How valuable is that? I’m asking; I feel like it’s a lot, but I had to spend a few weeks learning to read a whole new style before I got that value. So I don’t know the answer. I don’t if it’s worth it. What I do know is that by eschewing parens, I never ever write lines like the above. The code just won’t let me. It bugs me, and I refactor it, and then my code feels better to look at, and the whole program becomes much more readable. That’s immensely valuable to me. But I don’t know how to communicate that it’s worth the trouble–or even if it’s worth it at the end of the day.

Readability For Other Developers

Another good question is if one developer hasn’t learned this style, and another one has, should parens be the default to maximize readability? I grind my teeth whenever people start making “lowest common denominator” arguments because it’s really hard sometimes to see the line between “this is overcomplicated” and “let’s do something more stupid because it’s easier”.

So part of the experiment this week has been paying attention to how my coworkers react to my code. It’s hardly been a scientifically rigorous study, but given a sample size of one week and two code reviews, I have one data point. It comes from a coworker who strongly favors parentheses, but has been tolerant of my style. His exact words were:

“Your code is a pleasure to read.”

I am confident that he was not talking about my parenthesis usage, but rather about the clean, refactored, expressive code that resulted from me not liking the way some lines of code looked without parens stuck on.

It’s hardly a conclusive argument, but it’s one that encourages me to continue researching. I’m not ready to stand up and proclaim that parentheses are nothing but noise that covers up code smells, but I am giving serious thought to secretly believing it. 🙂

Weirich-Style Kung Fu

A hybrid style is emerging from these discussions, and it’s structurally based on “The Weirich Rule”, which is about blocks rather than parentheses, but the similarities are definitely there and I find the analogy appealing. In Ruby you can write blocks with braces or with do…end; the Weirich Rule states that if the block returns a value, using braces signals that intent to the reader. If the block exists for its side effects, using do…end signals this intent.

A Weirich-inspired rule for parentheses, then, look like this:

If you care about the return value, send the message using parens.

The people who have I have talked to–well, listened to–about this rule are passionate about it and convinced that it increases readability and communicates intent. I want to get behind this rule, I really do. it’s a clear, bright-line rule for when to use parentheses or not. It’s the sort of rule that might get included in a book about ruby, for example.

But…

But I still have a problem with this style: when I went full-on no-parens mode, I was forced by the ugliness of my code to refactor it to be simpler and cleaner. When I use this paren style, I can feel that pressure evaporate. I’ve tried this rule for a week, and and I can feel my code quality suffering. I’m not convinced it’s a good rule.

Maybe I just need more engineering discipline. On the other hand, however, I have found that coding styles that require more discipline tend to embarrass me when I don’t step up. I gravitate much more strongly to coding styles that encourage and support me in having more engineering discipline, because they result in me writing better code.

But that brings me back to square one, which is trying to convince everyone to try giving up parentheses all over the place, and I don’t know if I have enough tin foil hats.

So that’s where I’m at. Thoughts?

Loyalty and Trust

5 Replies

This post is part two of a three-part followup to Loyalty and Layoffs. Part one, Loyalty And Your Professional Network was posted Monday. I’ll post Part Three on Friday.

Betrayal is a recurring theme of my loyalty posts. I’ve talked about work like it’s a sinking ship, a burning theater, or a hike through tiger-infested grass. It’s pretty depressing stuff, isn’t it? Don’t you wish you could just do fulfilling work and not have to worry about all this treachery? Wouldn’t it be great if you could just be happy at your job without being paranoid? How would it feel to like your company and not have all this mistrust floating around?

Would it surprise you to find out that I am happy at my job, that I do fulfilling work, and actually like my employer? And that I am not, in point of fact, certifiably insane?

I said I was going to wait to talk about “good loyalty” versus “bad loyalty” until after I finished this series, but I realize now that I can’t put it off any longer. All this treachery and mistrust business is coming from getting our terms mixed up. We need to talk about what loyalty actually means. And then we need to see how it fits into a larger cycle of vulnerability and trust.

Loyalty

Let’s start with loyalty:

Loyal
Giving or showing firm and constant support or allegiance to a person or institution.

I want to make this clear: Yes, you should be this kind of loyal to your company. I’m not happy with everything every employer or client of mine has done, but I don’t badmouth them during or after my engagements with them. Once I’m hired, I am hired. If I’m cashing a client’s paycheck, then I am very focused on helping them succeed. I don’t care about office drama. I want to get the product built and shipped and into the customer’s hands. I’ve worked W-2 jobs and 1099 jobs over the years, and my definition of loyalty doesn’t have to change. Firm and constant support.

I try to give that to the company, and I also try to give it to my coworkers. But when I do that, something very different happens.

Vulnerability and Trust

When two humans share loyalty, an interesting cycle begins.

  1. I open up a little bit and share a little bit of vulnerability with you.
  2. You respect that vulnerability by showing support and respect–loyalty.
  3. I feel I can trust you more, and open up a little bit more.

While I’m doing this, you are doing the same in return. It is in our shared moments of vulnerability and compassion that we find our truest happiness. This is part of being human. We need this. I show you vulnerability, loyalty and trust; you show me the same in return. All three emotions go in both directions.

Of course, sometimes we share too much, before trust has been earned, or the other person doesn’t honor the vulnerability that we’ve entrusted them with. When that happens, we feel shame and betrayal. I’m not telling you anything new here… at least not yet. But now try this: run that sequence backwards. If you’re feeling betrayed, it is because you were not given loyalty after you showed vulnerability. Make sense? Hold on to that thought, we’re going to come back to it.

This full cycle of vulnerability, loyaty and trust is what I’m talking about when I say that loyalty to a corporation doesn’t make sense. Allegiance and support is fine, but vulnerability and trust? We can’t have the cycle of vulnerability, loyalty, and trust with a corporation, because the corporation is incapable of reciprocating. But sometimes we want to feel that trust so much that we pretend that the company is participating. We cross a boundary we shouldn’t, and we pretend that the company is honoring it… and that’s where it all goes wrong.

Have you ever been laid off and felt a mild sense of professional annoyance, but mostly you were just sad to no longer be working with great teammates on a worthy project? That means you’ve got a good sense of boundaries.

But the Loyalty and Layoffs post is full of comments from people who have been laid off and feel betrayed. When Evans & Sutherland let me go out of the blue, even with all that severance, betrayed is exactly how I felt.

Huh. Feeling betrayed… how does that happen, again?

Loyalty Only Goes In One Direction

One of the things my friend Rodney taught me is that, in a corporation, loyalty only goes one way: up. You show your allegiance and support to your manager, she shows her allegiance and support to her boss, and so on, up the chain to the CEO.

Now, most of us have worked with great managers and leaders. People who go to the mat for us. These are fantastic people, and I highly recommend seeking them out and working for them whenever possible. But do they prove that loyalty also goes down? Think about this: what happens when their boss tells them they have to fire you?

They do their job.

To be sure, they absolutely hate their job that day. But they do it. Why? Because they’re loyal. And that loyalty, ultimately, only goes in one direction.

Trust Only Goes Goes In One Direction

When we show loyalty, we earn trust. So the corollary to loyalty only going up is simple: trust only goes down. Your CEO trusts your manager to be loyal, your manager trusts you to be loyal, and you… you trust the plant on your desk to keep on doing that photosynthesis thing.

Trust
Firm belief in the reliability, truth, ability, or strength of someone or something.

I’m not saying you shouldn’t trust anyone with anything. That’s a little bit crazy, and a whole lot of no fun. I’m just talking about the trust that loyalty earns. You can trust a good company to pay you, because it’s against the law if they don’t. You can trust a good manager to keep office politics away from you. But if you know loyalty does not come down, and that a company will act in its best interest even if it’s at your expense, then that trust, the specific “firm belief in the reliability” of your company, should not go up.

Vulnerability Doesn’t Go In Any Direction

In theory, vulnerability could go down. You show loyalty, the company shows trust; in theory your CEO could share vulnerability with your manager, and your manager could share vulnerability with you.

But they don’t, do they?

I’m not talking about friendships, here. I’ve shared plenty of vulnerability, trust and loyalty with managers as friends. But I can’t think of the last time a manager told me he was worried about getting laid off, or thinking about leaving to work for a competitor, or afraid the company might not make payroll next month.

I think they actually teach in MBA school that “complaints go up, never down.” No, wait, that’s a quote from Saving Private Ryan. But my point is, vulnerability could go down the chain… but it never ever does.

So what about up the chain?

Because the company does not show you loyalty, it cannot earn your trust. So the big question is: in spite of this, are you sharing vulnerability up the chain?

Vulnerable
Susceptible to emotional or physical attack or harm.

If you’re afraid of losing your job because you have no idea where you’ll go or what you’ll do… maybe you’re letting yourself be “susceptible to harm”. There are two things you can do about it. The first is to continue to offer this vulnerability to your company, and pretend the company has reciprocated with loyalty, and feel the warm glow of trust that all will be well. You’ve crossed a boundary inappropriately, and the company probably doesn’t care. The only cost of this is that if the company lays you off, you will feel betrayed… and it’s not the company that will be paying that cost.

The other thing you can do is own your own career. You take back that vulnerability. Interestingly, when you do you, you suddenly realize that the company could fire you if it was in the company’s best interest. I mean, it always could, but once you take vulnerability off the table, it stops being a disaster and becomes just another thing that could maybe happen.

Take Vulnerability Off The Table

Once you accept the truth that your company can, and will, and should act in its own best interest, it’s easy to take vulnerability off the table. And then an interesting thing happens: you don’t have to take trust off the table. It evaporates on its own. You sort of realize that it was never there to begin with.

Loyalty goes up. Trust goes down. Vulnerability is something you save for those coworkers and friends who are willing to reciprocate.

Finding Happiness

You can not only be happy at a job with this arrangement, but happier than you would be otherwise. Owning your career means you have alternatives, and that means you have a choice. Suddenly there is more fulfilment in your work, because it’s work you choose. You get to feel the joy of personal growth. You have the confidence of knowing that, if you really had to, you could quit instead of putting up with an abusive boss.

And you have the peace of mind that, should you arrive at work to find a pink slip waiting for you, you’re going to feel a lot of things, but not betrayal. Not again, not ever.

Luck Is Not A Factor

13 Replies

Once Upon A Time, A Nonsequitur

“You can observe a lot just by watching.” — Yogi Berra

Late in 2006 I was sitting in Rodney Bliss’ office for our weekly investor debriefing. Rodney was the President of the company; as the Director of Technology I reported to him. In theory, Rodney ran the company and I ran the development team. In practice, the investor would change our priorities and expand the scope of the project every week and it was all we could do to keep up. Rodney had just returned from meeting with the investor, and we were going over the new list of features so that we could prioritize dependencies. And then he casually told me of another request that our investor had made.

“He wants me to put together a list of all our expenditures, from payroll to soda pop–”

“Aw, CRAP!” I interrupted.

“What?”

“You’re going to get fired!”

“What…? No I’m not!” Rodney actually laughed. I just stared at him in horror. I couldn’t believe he couldn’t see it. It was so clear.

“Rodney, I’m not joking. You’ve got 2 months at best; less if he’s smart. Based on the way things have gone this year, I’m guessing right at about six weeks.”

“Dave, calm down. I am not going to get fired.”

Six weeks later, almost to the day, Rodney got called in for his exit interview.

Rippling Grass Is Always Caused By Wind Except When It’s Tigers

The thing was, I knew Rodney was going to get fired, but I didn’t know how I knew. It was a very chaotic time for all of us, and there was no one significant indicator that I could point out, but sitting in that office, I could see all these tiny little details suddenly adding up to a starkly clear pattern. I’d worked for half a dozen clients in as many years, and based on all of my experiences joining and leaving companies, this request from our investor was… odd. Not just odd, but totally out of keeping with his character and with the way he had behaved towards us all that year. All of these things added up instantly in my gut, if not my head, and what was odd suddenly became ominous. Our investor had always respected Rodney’s autonomy, and aside from some ineffable “leadershippy things” that Rodney did, budgetary discretion was the only thing Rodney actually did… at least on paper. And now the investor was taking that function over. I knew–knew–Rodney was going to get fired, just as soon as our investor put all the pieces together.

It took me seven years to figure out how I figured all that out. It was just last weekend, in fact. Rodney and I were arguing good-naturedly–we’ve stayed friends over the years–about a blog post he’d just written, titled And Sometimes You Just Get Lucky. Go read that post; I’ll wait. It’s a lot of fun to read and most importantly, Rodney is wrong and I can’t resist the temptation to point that out. Especially because it’s the kind of wrong where I get to point out how awesome Rodney really is.

Luck Is Not A Factor

For those of you who didn’t go read his post–for shame!–the TL;DR is that Rodney got lucky debugging a computer problem. He sat down and typed a few commands, and noticed something out of the ordinary. To everyone else in the room, it was ordinary–just a very large amount of free disk space. But Rodney was one of the first SWAT engineers at WordPerfect, and had been steeping himself in the engineering lore of the company for years. He just happened to know that Shell.exe counted up free disk space when it started up. He just happened to know that computers at that time were occasionally experiencing growing pains, where the size of the place in memory for storing numbers was turning out to be too small–like the number of free bytes on disk, in an era where people still carried floppy disks that held less than 2 megabytes, but now you actually could have entire gigabytes(!!!) of disk space lying around–even, in this case, the 2.147 gigabytes needed to overflow a signed 32-bit integer. And lastly, but most definitely not least, he just happened to know the name and phone number of the guy at WordPerfect who wrote Shell.exe in the first place.

Rodney says he got lucky. Rodney is wrong. He was no more lucky that day than I was at guessing he was about to get fired. A hundred tiny factors, measured in our brains against a hundred past experiences, and suddenly we knew that particular ripple in the grass was a tiger.

Cool Story Bro, But So What?

Well, for starters, Bro, start looking at the grass. Unless you’re down with getting eaten by a tiger. That’s very eco of you, man. I mean, hardcore. I can, like, totally respect that.

No, the thing is, if this isn’t luck, then maybe this is a force we can harness for good. Or at least maybe luck is something we can measure. You know, with science and stuff. Or something. Richard Wiseman set out to do just that, measuring the skills and abilities of people who considered themselves lucky against people who considered themselves unlucky. One of the tests he gave was to ask participants to count the number of images in a newspaper:

"I gave both lucky and unlucky people a newspaper, and asked them to look through it and tell me how many photographs were inside. On average, the unlucky people took about two minutes to count the photographs, whereas the lucky people took just seconds. Why? Because the second page of the newspaper contained the message: "Stop counting. There are 43 photographs in this newspaper." This message took up half of the page and was written in type that was more than 2in high. It was staring everyone straight in the face, but the unlucky people tended to miss it and the lucky people tended to spot it."

You can read Wiseman’s entire article here. It’s fascinating. He even changed the message to say “Stop counting and tell the experimenter you have seen this and win £250.” There was no change in the survey results–except that now the lucky people were going home £250 richer.

I don’t want to steal Wiseman’s thunder, but his bottom line is that lucky people relax more, and tend to be more open to noticing things even while they are focusing on accomplishing a task.

No Seriously, So What?

Dude, seriously. You need to relax. No, I mean literally. That’s the whole point of Wiseman’s article.

I read his article a long time ago–It’s ten years old now–and I’ve been fascinated with the kinds of pattern recognition our brains are constantly doing. I began to notice more and more that I was spotting tigers in the grass in the weirdest of places. I began to notice much more subtle tigers. I began to spot tigers from much further away with less and less data. When I called Rodney’s termination, I knew the investor personally and had a lot of information about him personally. Turns out that was mostly noise; the “tell” is an executive with insufficient personnel knowledge asking for a budget spreadsheet. Earlier this year, a manager at one of my clients commented offhand that he had to prepare a budget breakdown for an executive that nobody on the team had ever heard of. I sighed, and smiled wistfully, and told him that it had been nice working with him. When he asked me what I meant, I shrugged and said “that executive is going to have all of the contractors fired. In my experience, it takes”–waaaiit for iiiit–“about six weeks.” This time I was watching the calendar carefully, and I called it exactly to the day.

Okay, So Spidey Senses Are Neat, But Can You Use Them In Anger?

Yes.

Specifically, the question I am putting in your mouth here is whether or not you can use this pattern recognition skill actively and aggressively, not just defensively. The answer is most definitely yes.

You can use it to hunt tigers.

A couple years ago I was working at a company that handled some sensitive data. I’m used to playing things fast and loose, by which I mean empowering team members and requiring them to be responsible. Unfortunately, we had a sysadmin who didn’t want anybody touching anything for fear of accidentally exposing our production data. He knew his stuff and I respected him, but our approaches to development were worlds apart when I first came on board, and part of us working out our kinks was having some splendid arguments about silly little things like “being able to do my job” and such. You know, trivia.

I remember we had a problem on our production database server that was just beyond bizarre. We had a fairly intensive query that we had been optimizing. A typical query returning a few hundred records would take 10 seconds, which we optimized and got down to half a second. The worst-case queries would return 10 or 20,000 records and would take 90 seconds or more. We optimized those and got them down to 2 seconds. Things looked really good. Except… well, every thirty minutes or so, the queries would take 30 seconds to run. It didn’t matter if they were worst-case queries, or typical ones, or a mixture; the database would just go away for 30 seconds and all the queries would wait before suddenly coming back all at once.

What I desperately wanted to do was log into the production server and watch it run. I knew our sysadmin was absolutely freaked out by the very thought of this because, well, I asked him, and he absolutely freaked out. So I checked everything I could in the code again. Then double-checked. Then triple-checked. The code was fine. There HAD to be something weird going on on the server.

Our sysadmin wasn’t totally unreasonable, he just absolutely refused to compromise the safety of our data. This is a good trait to have in a sysadmin! But it was early days for us working together, and we hadn’t quite learned how to do it. Work together, I mean. He kept asking me, “Tell me what you want to know about the server, and I’ll tell you.” And I kept responding by holding up my hands and saying “I don’t know. I’ll know it when I see it, but I won’t know it until I see it.”

Months later we would work out how to work together effectively, but at that point in time it literally took the intervention of a Vice President to work things out. The proposed solution was laughably simple. To the sysadmin, he said “do you see any reason Dave can’t watch over your shoulder and tell you what to type? He never touches the keyboard, and you have veto power over him looking into sensitive data.”

The sysadmin grumbled that this would be okay, but that he was sure it would be a total waste of time.

We sat down–well, he sat down. I was literally forbidden to be within arm’s length of the desk. I asked him to start looking around the server. Logfiles, running processes, network I/O, database load. As we were looking at running processes, I noticed that the database was running a reverse DNS lookup on an inbound query. I also knew that, for security purposes, none of our webservers had reverse DNS lookups enabled.

“Hey, how long is the timeout if reverse DNS fails?”

The sysadmin stared at the screen for a long moment. I couldn’t tell if he was embarrassed, or angry, but I could see that we had just seen what we’d come to see, and he was piecing together all of the implications in his head.

Finally, all the implications came together and he said, all at once: “Thirty seconds, there’s the query delay. And when it fails, it caches for 30 minutes, so there’s the problem frequency. And reverse DNS shouldn’t even be enabled on the database. Hang on, let me turn it off.”

Total elapsed time, from the time I walked out of the VP’s office with the sysadmin, to the time I returned to tell him we had found and fixed the bug?

Four minutes.

Wow. Can You Ever Use It Defensively And Offensively At The Same Time?

In theory, yes. In practice I’ve only ever seen it done once.

Here’s the theory: if you see that ripple in the grass a long, long way off, but you can’t change your course, you know a tiger attack is coming. Tigers rely on the element of surprise, but you have time to prepare. How much time depends on how far away you saw the ripple. So you try to pick where you’ll make your stand, and you try to bolster your defenses, and when it becomes clear that you can’t avoid the tiger, you… relax and let it happen. As the blur of black and orange streaks up at you from the grass, you can learn a lot about a tiger in a few milliseconds if your life depends on it, and in those milliseconds, you can discover that tigers are often quite surprised by having their ambush turned into a deft counterattack.

That’s the theory, anyway. In practice… well, remember the first story I told, about Rodney? I called the ripple six weeks before the tiger attack. Rodney didn’t believe me at first, but as the weeks went by, other signs began to become clear. I don’t remember what finally convinced him–I think there was a planning meeting on the calendar, and I told Rodney that if I was right, the investor would cancel it, because it made no sense to waste time making plans with somebody you’re going to fire. Sure enough, the investor canceled the meeting at the last minute for “personal reasons”. More importantly, after a year of working with the investor, we knew he was very organized, and always moved appointments instead of canceling them. This time, the investor didn’t set a date to reschedule. When Rodney asked when would be a good time to reschedule, the investor said “let’s talk about that after next week.”

“Next week” was six weeks after I’d said he had about six weeks left.

Rodney went to his weekly meeting with the investor, calm and ready for another normal day of meetings, but also on the lookout for anything out of the ordinary. And there it was: this time there was an extra person in the room–the CFO. Rodney knew from corporate experience that he was there to be a witness… and that meant that this was going to be his exit interview. He sat down, and they sprang what they thought was going to be an ambush.

As the blur of black and orange streaks up at you from the grass, you can learn a lot about a tiger in a few milliseconds if your life depends on it…

I don’t know what happened in that room that day, but Rodney walked out of there smiling, and still very much the President of the company. Oh, they still wanted him gone, but instead of kicking him to the curb as planned, they ended up timidly asking him what terms he would like for them to come to some sort of arrangement regarding that…?

Rodney met the tiger… and then the tiger met Rodney.

But… that part of the story isn’t my story to tell. Which is why I sat him down and made him promise to tell the story on his blog someday soon.

“Dave, calm down. I am not going to get fired.”

Huh. I guess he was right.

Loyalty and Your Professional Network

5 Replies

I still want to talk about what “good” loyalty looks like, but we need to get the medicine part out of the way first. This post is the first in a three-part series about that medicine.

Emergency Action To Take Immediately If You Are Comfortable At Your Job

Perhaps complacent might be a better word here. I’m not going to talk about jobhunting or boundaries or even loyalty today–well, that’s not true. I’m going to touch on all of them a bit. And all of this will be advice to invest loyalty in your own self first, and to be honest, I think this will make you more valuable to your employer.

So let’s start by talking about you quitting your job.

Know Where The Emergency Exits Are

How on earth does talking about quitting make you more valuable to your employer?

There are two kinds of people who don’t worry about burning to death inside a movie theater: People who don’t believe theaters can burn, and people who know where the emergency exits are.

If you know where the emergency exit is for your current employment, you no longer have to worry about losing your job. You can focus on the task at hand and be productive, even if the company is facing tough times. Managers don’t like me much when they try to “sell the dream” because I don’t buy it. But on the day when the main investor pulls out or the biggest customer switches to a competitor and all the employees are milling about in a blind panic, managers love me. Why? Because I don’t buy the nightmare, either. I can smell smoke in a theater and remain calm, because I know where the exits are.

Important loyalty note: This is not the same thing as watching the exits. I’m not saying you should try to always have an alternate job offer waiting. I’m just saying you should know what you’re going to do if you lose your job.

And let me be a bit more specific: the thing you are going to do if you lose your job is this: draw on your professional network.

And yeah, that means you’re going to need to have one first.

Build Your Professional Network

I think this might be the single most important piece of career advice I can ever give anyone: Have a professional network. When Evans & Sutherland laid me off, I didn’t even know what a professional network was. But once I started building mine, my fear of ever being unemployed vanished. Why? Well, because being unemployed vanished. I think I spent about six weeks jobhunting once in 2005, but not counting that fluke, the longest I’ve ever been unemployed since 2001 is ten days. The shortest? Four hours. And that’s only counting the gigs I’ve left cold, without anything else already lined up. I mean I walked into work, found out I was unemployed, and by lunchtime I had a job offer to start the next day.

As a result, one of the weird things that loyalty means to me is that I never jobhunt when I’m working for a client, even when I know my contract is almost up. It’s just not worth the headache to me, and I have absolutely no fear of walking out of work with no idea where my next paycheck will come from. Because I know it is coming.

I credit this attitude entirely to my professional network.

What Exactly IS A Professional Network?

A professional network is simply this: a list of people who know you that you can call when your chips are down. To build it, you make friends with people outside your company. You help people. You tweet funny things. You join organizations. You take old coworkers to lunch. You contribute time and effort to your professional community. Then, when you need a safety net, you let those people know you’re available. Since they know who you are, and what jobs you’d be a good fit for, you suddenly have 50 or 100 or 1000 pairs of eyes looking for your next job for you. All you have to do is get the word out.

A professional network is NOT a linkedin profile. That can certainly be part of it, mind you; linkedin is pretty popular right now and I recommend keeping your profile current. Just make sure that whenever you’re using the site, that you’re not thinking about “your profile”, but instead about the people in it. They are your safety net. LinkedIn is just a tool to reach them.

Build It BEFORE You Need It (This Means RIGHT NOW)

You cannot tie a net and fish with it at the same time. Your network is a group of people who know you well enough that you can ask small favors of them. You earn the right to those favors by investing time in those people–by sharing time with them as mentioned above. If you meet a stranger and ask them if they know who’s hiring, you’re just a stranger who needs something. But if you’ve met them before or had lunch or contributed code to their project, you’re not a stranger anymore. You’re a member of their “loose acquantances” tribe. And people love helping each other out in that tribe.

I cannot stress this enough: If you are employed, you need to be investing time outside of work in other people.

The time to build your professional network is before you need it. There is only “right now” and “too late”.

But What If I Need It Now? (I’m Asking For A Friend…)

Okay, so… let’s say you didn’t take this advice or, like me in 2002, didn’t hear the advice until it was too late. First, you need to embrace the bad news: You cannot tie a net and fish with it at the same time. This will not stop being a thing that is true, no matter how bad you want it to. You have to embrace it. You’re going to have to fish without a net, which means jobhunting the old ways you’ve used before, without a professional network. But more importantly, it also means you have to spend time tying your nets while you’re starving.

Do lunches with people. Contribute to projects. Attend professional meetups. Make friends. Here are three rules of thumb I use, but they all boil down to the same thing: when you’re meeting people, decide whether you are fishing or tying nets, and do only that and not the other.

  • In a professional social setting, I tie nets. I focus on contributing rather than jobhunting. It’s actually relaxing and more fun to stop worrying about the jobhunt for a little while, which in turn makes me more fun to be around. So if I’m in a user group, I’ll speak up if I can help someone. Sometimes I know a clever answer, but people appreciate it even more when I offer to pitch in on their project and help. In a 1-on-1 lunch, I ask about the other person and what they’re working on. Even if I don’t have great insights into their situation, just listening to another human being is a great way to connect with them–and letting them talk it out often provides them with their own answer. If someone has come to lunch with me, and they’re worried about a tricky problem at work, and I blather on about myself and how I need a job for an hour, at best I may give them a distraction but at worst I will annoy them with my problems when they have their own. If I want to tie nets, I have to tie nets. I cannot try to fish.
  • The exception: when you’re tying nets with someone, you should mention that you know how to fish! I DO tell people whenever I’m looking for work, but I try to be casual about it. In a big meetup I’ll introduce myself to the group and mention that I’m available, and that’s it. In a first-time 1-on-1 lunch, I don’t worry about it, because one of the first questions we’re going to ask each other is “So, where do you work?” No need to bring it up special. When I tell them I’m between clients, they’ll often ask followup questions about what I’m good at, and I’m happy to talk about that, but I try not to let it turn into an interview. Even if they say “Oh? We’re hiring, you should apply!” I will respond with “Really? Cool! What’s your company like? What are you working on? What do you like about it?” and turn the conversation back to finding ways to be helpful to them. I have to remind myself: “I am not fishing, I am tying nets”. Oh, don’t worry–I won’t let them leave without asking them who I should talk to at their company for more information! But I always try to remember that my goal for the lunch is not to get a job. My goal is to have this person want to have lunch with me again sometime. I am not fishing. I am tying nets.
  • Lastly, if you are fishing, fish! Don’t do this instead of jobhunting. Building your network will pay off huge in the long run, but there’s no guarantee of any payoff in the short term. When you’re unemployed, your full-time job is to get a job. And just like you should continue to build your network by doing things outside of work when you’re working, you should build your network by doing things outside of jobhunting when you’re unemployed. Time spent building your professional network doesn’t count towards the time you need to spend jobhunting.

I have spent a decade building and maintaining a professional network that I feel very comfortable with, so now my jobhunting looks a LOT like networking. But it’s fishing, not tying nets. I call people and say “Hey, my contract just ran out, wanna grab lunch?” They know I’m gonna chat and be friendly and ask about their kids, but they also know I’m gonna hit them with fishing questions, asking them about who’s managing who and what teams are working on what. But they’re okay with that, because we’re friends, and they want to see me get back on my feet.

How To Use Your Network

A lot of people talk about building a professional network, but I very rarely hear people talk about how to USE that network when you need it. Probably because it’s rare to find a jobhunter that HAS a network to begin with, but I think it’s also true that once you know a bunch of people, you stop thinking of them as “your network” like it’s some foreign thing. Once you figure that out, you realize that you don’t “use” them. You don’t need an instruction manual to know how to talk to your acquaintances.

Actually, wait. There is a mistake I made early on that made it harder on myself than it needed to be. I would call or email people and ask them if their company was hiring. The tech recession was hitting Utah in the early 00’s, so the answer was always no, and that was the end of the conversation. I had to learn the hard way to stop asking yes-or-no questions. But then I made another mistake: I would ask them who was hiring, and they would always say they didn’t know anyone.

I had to learn to ask questions that would get people talking.

Here’s my secret weapon: I just ask people who they know that’s working with a technology that interests me. “Who do you know that’s working with HIPPA?” “Who do you know that’s doing credit card payments?” “Who do you know that programs in ruby?”

That may seem silly and a bit stupid, but I kid you not: I literally turned an exit interview into a job referral with that last question. I was subcontracting for a software-for-hire shop, and the client I was assigned to pulled the plug unexpectedly. It was a tight economy, and the shop didn’t have anything else for me to work on, so they had to cut me loose. My manager was a good man, and he felt bad that he had to let me go with no advance warning. At the end of the conversation, he glumly said, “I know there’s probably nothing I can do to make this easier, but I have to ask, is there anything I can do to help?”

“Actually, yes,” I said immediately. “Who do you know in town that’s programming in ruby?”

He thought for a moment, and then started listing names of companies. I already had a pen in hand, and I started writing. After each one I’d ask “what do they do?” and “who do you know there?” I never asked if they were hiring. I would occasionally ask “do you think I could talk with that person about who else in town is working in ruby?” He listed maybe a dozen companies. But even better, halfway through the list he said “You know, I’m friends with the CTO at that company. I’ll introduce you.”

The introduction included a heartfelt recommendation, which got me a lunch meeting with the CTO, which got me an interview with the team, which got me a place to report for work the following Monday. Even though they weren’t hiring.

The trick to drawing on your network is don’t haul on it. You’ve made friends with these people. Just be human, and get them talking. (And it doesn’t hurt to work for good managers who try to look out for their people.)

That’s It, Really

No, seriously. I’ve got two more posts to talk about “the medicine”, but if you only read one, this is it.

Go tie some nets. 🙂

Announcement: Daily Posts This Week

Leave a reply

Hi Gang!

I’ve been trying to write the “medicine” followup to Loyalty and Layoffs for two weeks now, and it just keeps getting bigger. I have too many points I want to make for a single post.

So… stay tuned: I’m going to challenge myself to post every day this week–and this post doesn’t count! I’ll break the Medicine post up into three separate posts for Monday, Wednesday, and Friday. Later today I’ll put up the most important and urgent piece of medicine: how to build and how to use a professional network. Wednesday I’ll talk about emotional and psychological boundaries and how certain myths we have about them play right into the bad kind of loyalty. And Friday will be the “juicy gossip” post: I’m going to talk about office politics.

That leaves Tuesday and Thursday free to mix things up a bit. On Tuesday I’m going to talk about how wrong my friend Rodney is, and why that’s a good thing, because he’s awesome. And on Thursday… oh what the heck, let’s actually talk about programming computers for a bit. I’ve been writing a lot of Heart and Mind posts, but not many Code posts. I need to clear that up a bit.

So here’s to this week: may I make my challenge, and may the posts I write be worth your time. See you soon! 🙂