Category Archives: mind

When Tinkers Attack

4 Replies

Hey, you in the mood for an electronics-heavy, hardware hacking post? Who cares, my blog my rules. Anyway: lotta words and science and eventually pictures, I promise, but it’s nerds all the way down from here.

Okay, I gotta at least sum up the background of this post: I’ve been playing around with a device called a Photon, made by a company called Particle. It’s a tiny little microcontroller device that seriously blurs the line between the “programmable ICs” I played with a decade ago and, well, computers. It’s the size of my thumb, costs less than $20, and its killer feature is an onboard Wi-Fi radio. They’re at https://particle.io. Go buy one, I’ll wait.*

* Disclaimer: While I have received a free Photon from a friend who works at Particle, I also bought a handful of them on my own, and Particle probably doesn’t want me writing a review for them anyway, honest or otherwise, and in fact are no doubt reading this with an increasing sense of dread. (Plus I bricked the free one right out of the gate. I’m just saying.) My opinion, which is possibly biased, is that you should buy a bunch of them. They’re awesome.

So with all that summed up, I can now move on to the problem I’ve had all week with it: I want to drive a super-bright LED module with my Photon. Seems pretty straightforward, right? With my Teensy USB (another cool product, go buy some of them, too!) I could just push current out to the red, blue or green pins of the LED module and it would light up. It is worth noting that the Teensy was a current-bearing** beast. It could shovel 80mA of current out of each pin at 5V without even getting warm. Well, without getting hot. Well, without burning the house down at any rate–look, the point is this module will take a full watt of power and the Teensy could deliver it easily.

** ampiferous? Heh. Shut up that’s an awesome word right there

Enter the Photon.

This thing is unrelentingly awesome, I won’t hear a word otherwise. One of the great features is that it runs on a super-low power budget. It runs on 3.3V (even though it will accept 5V). This means I can plug it straight into USB (5V) and it runs just fine. But those pins only spit out 3.3V. And to make matters worse, it’ll only give 25mA per pin and 125mA overall. It has a lot of love to give, but not a lot of power: 82.5mW per pin means that even with a pin driving each LED separately, it puts out less than a quarter of a watt.

But wait! My LED module has tiny little load switching transistors on it! You plug the board into 5V and ground, and then you just signal which LED you want to light up. All the drive power comes directly from the power rail, not the microcontroller… less than a tenth of a watt, in fact! Yay!

So how come, when I hook it up, the LEDs barely glow? Where my photons at, Photon?

It’s not the Photon. It’s the module. The LED module is a Sparkfun 11588 Tri-Color Breakout. This is a fun little kit you assemble yourself, and more importantly everything is easily understandable as you build it. In order to drive the LEDs, you build a circuit that is very easy to follow and understand: you drive a little current into the base of the transistor, and the collector responds by pulling down big current from the 5V power supply and dumping it through a resistor and the LED before returning to ground. More current means more light. It’s simple, it’s straightforward, it’s comprehensible.

It’s also not the best design for many applications. It was great for what it did, mind you; it just doesn’t adapt well to changing requirements. This circuit has what is called “High-Side Drive”, meaning the transistor (which “drives” the circuit) is connected to the 5V side. If we took the transistor out and moved it down next to the ground side, it would be called “Low-Side Drive”.

Why does this matter? Well… okay, TL;DR it just does and if you don’t want a longer explanation skip to the next paragraph. The longer explanation is this: I don’t actually know. Man, I sure hope you skipped this part. What I think is happening is that with 3.3V on the base and 5V on the collector, a 1.7V volt drop is created across the Collector-Base junction (Vcb for you electronics nerds), artificially limiting the output from the transistor. Normally a transistor can be thought of as an entirely current-based device, but in this case the transistor is forced to throttle the flow all the way back until a 1.7V drop is maintained from the 5V rail down to the 3.3V signal.

Now, there are a few ways you could fix this problem. The first is to alt-tab over to Adafruit and buy a 3.3V to 5V signal converting chip. They’re like $1.50, no biggie. You’d pay more in shipping than you would for the hardware, though, and if you’re like me–and this example you are–you’re gonna throw ton of other in your cart, so that chip is going to set you back closer to $50.

A second option is to dig around in the garage for some old reed relays you have lying around in an old junk parts drawer full of electronics components. You have one of those, right? Hey, me too! So you wire up the Photon to open and close the relays, and the relays switch the 5V supply directly to the signal pins on the module. Check it out:

Oh, wait, sorry. I said it was bright. (Fun fact: I have never seen my cell phone create an internal reflection like this before.) Here, let me turn it off.

There we go. Now this circuit works and all, but it still leaves something to be desired. I can switch the relays on and off, but that’s all I can do: turn the lights on–all the way on–or all the way off.

You can dim LEDs from a digital circuit if you turn it off and back on really fast. You shut it off and then back on before the eye can see the flicker. Do this over and over really fast, and it looks like the LED is getting darker. This trick is called pulse width modulation, or PWM. But to trick the eye, you gotta send these pulses out super fast, and those poor little relays have no chance of keeping up: they contain actual, physical, mechanical switches that are controlled by magnets. (No, I don’t know how magnets work. Yes, I am Mormon. NO, I really don’t know how magnets work. Please stop asking.) The point is, because they’re mechanical devices, they can’t switch on and off faster than you can see. We need a way to switch them on and off electronically.

A third option is to call your friend Kevin (you have a friend named Kevin, right?) who is really good with tools and insanely good at electronics (MY friend Kevin is, too–this is getting weird). He’ll tell you that you can use a 74HCT240 CMOS/TTL buffer, which is a chip that looks exactly like the one you were gonna get from Adafruit, and does exactly the same thing, but has been around for years and years–certainly long before 3.3V computing ever existed. More importantly, he can come to your house on Saturday and bring you one of these chips out of his electronics parts bin.

Cool! So you’ve got a free part coming, now you just have to wait…

Yeah, me either. Time for a fourth option. Let’s head back out to the garage. Do you have a can of solid-state relays left over from when you were manufacturing audio cutout boards for vibration control computers? No? Thank goodness, that would have been way too freaky. Anyway, I DO, so I went ahead and grabbed some.

Just one problem. They’re left over from building computer parts, parts which I built in this millennium. That’s a problem because computers nowadays use all SMT stuff: surface-mount technology. When I used these SSRs, I would etch a flat circuit board, hold the chip where it was supposed to go, then wash hot solder over the feet to make it stick to the copper. Those little feet have big flat pads on them so they can stick, and that means they don’t have the spiky pokey feet I need to jam them into my prototyping breadboard. If only I had some way of attacking wires to the SMT pads.

So, anyway, last night I sort of crafted an unholy abomination of electronics.

(That’s option four: “craft an unholy abomination”.)

The SMT chips need a flat board to stick do, and the prototyping board needs wires or leads. So how about a board with wires on it? This is a real thing you can get professionally, called a breakout board. I don’t have one, but I do have a lot of parts…

I grabbed an unetched circuit board and cut it down to size. I don’t have any etchant, but that’s okay. There are plenty of… decidedly mechanical… ways of removing material. Marked off the little SMT pads, and started scratching a channel before I realized I needed to be taking pictures of what is no doubt going to become a triumphant abomination.

I ditched the knife and got out my handy dandy Dremel tool and the tiniest burr head I could find for it.

Okay, time to slap some solder on there. It’s been 10 years since I’ve held a soldering iron, and all I can say for this solder job is that I did not, at any point, try to hold the iron by the burny ouchy end.

Okay, halfway home. Now it’s time to give this little breakout board some legs that can go into my prototyping board…

If you’re looking at this and jumping up and down and shrieking “SOLDER IS NOT GLUE” you probably need to work on your impulse control. You’re not wrong, mind you, but dude. Settle down. People are staring.

I’m not gonna lie, soldering is NOT like riding a bicycle. Shaky hands, cold joints, poor temperature control, good times. Here’s the finished product in all its lumpy abominationy glory:

I bent the legs under and then down, so that the legs could squeeze the circuit board because solder is not glue I get it shut up already.

And there we go. Just about ready to plug straight into a circuit board!

Oh, but one last step before we plug it in. Solder is not glue, but you know what IS a good glue?

Actual glue.

And now, the moment of truth! I’m so excited! I take it to my breadboard and plug it in, and…

…nothing. No circuit, no blinking, no flickering, no joy. Completely dead. The above picture was taken between blinks on the little Photon board, so you can’t tell that it is turned on and trying to drive the LED board.

I checked the circuit very carefully for continuity faults before plugging it in, so what could OHHHH MAN.

Fun fact about CMOS chips, which these SSRs are made out of: If you handle them without static protection, especially in a dry house in Utah in October, you will fry them.

See? NOT like riding a bicycle at all.

Ugh.

LOL.

LOL! No seriously, LOL. This was a lot of fun. Not every story has to end with an epic win to have a happy ending. In this case, I got some practice soldering, and got to remember that there’s a fair bit of skill involved there. The whole time I was soldering the smell of the rosin flux burning off the iron transported me back to my teens, where I spent hundreds of hours hunched over a crappy little Radio Shack 5W iron, putting together (and tearing apart) radios, amplifiers, oscillators, power supplies… any number of crazy projects, just for the fun of doing it. I’m happy I did it and will always treasure OH OF COURSE I GOT IT WORKING BECAUSE YES AN EPIC WIN IS REQUIRED IN THIS INSTANCE.

Let’s talk about option five. I sort of hinted at it accidentally when I was describing the problem earlier. So the original SparkFun design is flawed because it is high-side driven. If we could somehow change this circuit to be switched from the low side… well, ground is zero volts, whether your circuit is 5V or 3.3V. If we can ground one circuit, we can ground any circuit.

I don’t have a schematic drawing of a Low-Side Drive circuit, but if you look at the circuit at the top of this post, the circuit you want can be created by turning it upside down. The 5V comes in and hits the LED, then goes through the resistor, then through the transistor, and out to ground. Heck, I don’t even have to change the circuit board!

Well, okay, not the board itself anyway… readers familiar with electronics will realize that you can’t just run electricity backwards through a diode. That’s, like, a diode’s entire job in electronics, to keep you from doing just that.

So I desoldered the diodes, flipped them around backwards, and soldered them back in.

Transistor? Same problem: current won’t flow up the emitter and out the collector. Same solution: desolder, flip them 180°***, put them back in.

*** That’s 82.2°C in metric

This was a lot harder to do than it sounds. Fortunately, I never had a lot of money for electronics, so I always got most of my parts by scavenging existing circuitry. Here’s a #ProTip for you: remove the component before you remove the solder. You can jam the iron in so that all of the solder joints melt at once, and the parts slips out easily before taking heat damage. Then you can mop the solder out of the joints with a solder sucker or desoldering braid.

Here’s what the module looks like with diodes and transistors reversed:

You can’t really tell with the LEDs, but the transistors have their flat sides facing backwards from the little white outline on the circuit board.

Another fun fact is now I have to remember to always hook VCC and GND up backwards. There is something so perversely satisfying about that. It warms the filthy cockles of my gross disgusting heart.

And now, the question: does it work?

Well, at full power it looks about like the first photo of the board way back at the top of this post. But what if we tell the Photon to drive each LED at a different amount of power? Well… now that’s a different story:

Pay more attention to the bar graphs than the numbers; A5 and A3 have different PWM timers, and for some reason one goes to 256 and the other to 4096. (A5 might actually be a true DAC, I’m not sure. But A3 is definitely PWM.)

So… there you have it. High-side drive is a pain, low-side drive is awesome. Ground is ground is ground. and if your circuit has HSD, you need to use LSD to see all the pretty colors.

You heard me.

A Dream of Simplicity’s Tyranny

Leave a reply

This is an actual dream I had this morning, which was so profound it woke me up. Usually when this happens I smile knowingly that as soon as I’m wide awake it won’t seem very profound at all. But this time the profundity stuck with me, so I’m writing it down. Here it is, for your amusement.

I dreamed that I was an artist, and I was showing an exhibition. The first piece was a seven-foot square piece of white paper, on which a broad, bold, simple stroke bit of calligraphic art appeared. The piece was titled “Simplicity is Best”.

The second piece was also a seven-foot square piece of white paper, again with a single, swooping bit of line art. It was titled “Simple”.

The third continued the theme: a giant white sheet of paper, this one with a tiny word printed in the center, reading simply “Always.”

Several more pieces lined the wall, each exactly seven feet by seven feet, driving home the notion that these ideas were all big and simple and precisely the same shape.

The final piece was at the end of the wall in the gallery, but there was only three feet of wall left. The piece was still seven feet by seven feet, however: the paper smoothly covered the last three feet, with a huge, bold arrow pointing into to the corner, where the remaining four feet of the piece was folded up accordion-style. A tiny post-it was affixed to the folded paper, reading “visitors to the gallery may touch the art to unfold it.”

Unfolding the paper turned out to be difficult. It wasn’t just zippered shut like an accordion, but also folded up top-to-bottom, like a map. Anyone who has ever attempted to unfold a paper map knows the annoying sensation of trying to get one unfolded, and the hollow yet comforting satisfaction of successfully doing so. Achieving this victory over origami rewarded the visitor with a hyper-complicated bit of calligraphy, words spinning webs into each other scrawled across the entire hidden surface of the paper, and ultimately spelling out this message:

“The world is not shaped like simple ideas. The most complicated ideas are the ones we create to make the simple ones fit, but even then they do not fit, they merely mostly fit. And yet, we do this all the time, because a collection of simple ideas that mostly fit is much more attractive than a complicated and difficult idea that turns out to be obvious. The real art installation is not these sheets of paper, but the coat of paint I carefully applied to all of the brickwork on this wall, neatly covering it top to bottom and end-to-end. It is unremarkable, and completely hidden by these beautiful, simple, badly-fitting ideas. And if I hadn’t told you this, you’d never have noticed the paint, would you? Even now, as you contemplate attempting to fold this piece of paper back up, think about describing this art installation to a friend. What sounds better, ‘a lick off paint on a wall’, or ‘a series of simple ideas on big sheets of paper’? If you do tell a friend, please don’t give away this secret. Just tell them the title of this piece.”

The plaque beneath this piece displays the simple, single word: “Mostly”

At this point I woke up.

The reason this dream stuck with me is that, as I turned it over in my mind, I started thinking about the software I write every day, and I realized that, if I were that dream artist, I’d go back and change the last folded up sheet to read

“If this was software there would be a hole in the gallery here and the wall would be extended four feet to accommodate the simplicity of this idea. And no one would ever think this was odd.”

Risking Regret

2 Replies

Just north of Moab, Utah, a sandstone fin called The Lion’s Back rises about three hundred feet above the blowsand of the desert floor. It’s closed to the public now, because the public can’t be allowed to have nice things, but it used to be a famous Jeep trail. If you are a fan of scary youtube videos, you’ve probably seen the famous crash that happened there years ago (don’t worry, no one was hurt died). But back in the 1980’s, before the Jeepers really discovered it, it was just a big rock up behind the city dump.

When I was 14 I jumped off the top of it.

lions_back

You Wait What, Off The What of the What Now?

Oh, relax. I had a rope. I even had responsible adult supervision! Well, I had adult supervision at any rate.

My mom was pretty overprotective of me, and when my friend Kenn called and said “A big group of boys and girls from scouts and church are going rappelling today, do you want to come?” I was very excited but also pretty sure I wouldn’t be allowed to go. I remember asking my parents, and my mother making her “worried disapproval” face. But then Dad turned to her and said,

“If you don’t let him go now, when will you?”

Two hours later I was up past the dump near Lion’s Back learning how to rappel.

They chose a small fin next to Lion’s Back and set up practice stations for us. The first jump was maybe five feet high: just high enough to learn how to lean back into the harness. The next was ten or twelve feet: here we learned to work our way down the face. The final station was thirty feet high, enough to get a couple really good bounces off the rock as you came down the rope.

We had arrived in late afternoon, and there were enough of us there that by the time I had tried all three rappelling stations, the sun was starting to set. I figured that was the end of the day, and that it had been a lot of fun. I was really happy I’d come, and I really didn’t see what Mom had to worry about.

“All right,” hollered Kim, our rappelling instructor. “We’re running out of light, so anybody that wants to jump Lion’s Back, we’re going right now.”

Maybe Mom Was Right

I turned around from the tiny fin we had been practicing on. The Lion’s Back went straight up in front of me over 300 feet. I had a sudden attack of vertigo and I wasn’t even looking down. I remember thinking, “I’ll let the other kids go, and if it looks okay, then maybe I’ll try it.”

I think a bunch of us were thinking the same thing, and had the same looks on our faces, because Kim then said “It’s a half-hour hike to the top, and we only got time for one jump, so if you ain’t coming right now, you ain’t coming.”

I knew this was my one chance. I looked at the cliff again. So high, so impossibly, terribly high. The only thing a rational human could do from up there was fall instantly to their death. I mean, obviously. I sighed, and decided not to go, and looked down at my feet.

But then something happened. A tiny little voice in the back of my head piped up and said,

“If you don’t do this right now, you will regret not doing this for the rest. of. your. life.”

I looked back up at the cliff. Yep, still terrifying. But I looked over at Kim and said “I’m coming.”

Fear Is Intense, But Regret Is Forever

By the time we got to the top and anchored our rope, the sun was low over the horizon, starting to turn the desert flame red. Being the chivalrous young men that we were, we let the girls jump first. It was a long drop, and it took each person maybe ten minutes to get down the rope and the next person to get hooked in. By the time the boys could go, the sun was starting to dip beneath the horizon, bathing us in dusk. I was about third from the last, so as jump after jump happened in front of me, dusk came and went, and night settled upon us.

Remember, this was when Moab was a boom town gone bust: there was no light pollution. There was no moonlight to jump by because it was very close to New Moon, but just by starlight alone I could see for miles and miles, the once-red sandstone fins now blue and black but still clearly visible, marching off into the high desert as far as the eye could see.

I figured I could maybe just not jump and hike back down. Since it was dark and all, obviously I wouldn’t be expected to jump. But still that voice told me, convincingly, of the lifetime of regret I would have if I chickened out.

Kim had been bantering with us the whole time, making jokes about how it was such a lovely night for some rappelling, that sort of thing. And suddenly it was my turn. Kim could tell I was terrified, and was about to back out. He smiled kindly, and said in his soft cowboy drawl, “David, me’n your dad used to work at Rio together. We was on the mine rescue team together, and I took him rappelling, too. We’ve jumped some pretty crazy stuff, me’n your dad. But he ain’t never done a night jump. If you tell him you walked back down the trail with me, he’ll understand.”

He could have appealed to my pride, told me how jealous my dad would be if I jumped. He could have urged me to jump, pressuring me a dozen different ways. But all he did was show me what the choice to give up looked like, and reassure me that it would be okay. And it’s taken me nearly thirty years to figure out just how wise his words were: he put the full weight of the decision and the consequences on me, and took the fear away from the decision itself. This was exactly what I needed.

“I’ll never forgive myself,” I said as I straddled the rope.

Kim grinned from ear to ear as he started the safety check. “You’re right,” he said to me quietly. “You never would have. But now… here you are instead.”

Owning Choices Is The Only Way To Own Consequences

The rappelling rig was a friction-stop rig, which meant that to stop, all you had to do was pull down on the loose end of the rope. Unfortunately, this meant that for a stick-thin, 100-pound teenage boy, just the weight of 300 feet of rope hanging down from me was enough to lock up the rig. Kim laughed. “You’re literally gonna have to haul the rope up and pull yourself down the first twenty or thirty feet. It’s okay. Just start walking backwards, and remember not to sit down, just lean back.”

I hauled up on the rope, and it started letting me inch backwards over the edge. For the first twenty feet or so the slickrock curved away, and I was unable to resist the urge to keep my torso vertical. My descent became more and more difficult as my body slowly bent into a sitting position. Above me and now out of sight atop the fin, Kim called down: “David! Lean back!”

I leaned back.

Imagine for a minute that you are not leaning against a mountain, but standing on a wide, flat sandstone floor. Behind you, hundreds of feet away, the desert floor rises like a wall. People are walking around on the wall and if you could turn around, all you would see is the tops of their heads. But you can’t turn around. You can only stand there, hanging in free space, staring at what is directly in front of you:

Infinity.

The stars went on forever. The Milky Way blazed as brightly across the sky as I’ve ever seen. Outside the band marking our galaxy, blue-white dots pierced the utter blackness. And in the gaps between those stars, the inky void of space went on and on to eternity.

There was no up or down to it, just infinite thereness, right in front of me. I stared, openmouthed, at the night sky I had looked at thousands of times already… but somehow, never, ever, actually seen. It spread out before me with a beauty that still, thirty years later, takes my breath away.

And Owning Bad Consequences Is Easier When You Owned The Choice

The sound of a titanium anchor piton snapping is very distinct. To this very day, that single, sharp Tink!, so quiet yet somehow louder than a rifle shot, followed by the gentle feeling of weightlessness as the sandstone began to fly up past my feet, will always be a thing that never actually happened because gotcha.

In reality, I rappelled down Lion’s Back in fine form, had a blast, and formed a memory that will burn bright in my mind until I die (or get Alzheimer’s as karmic retribution for the previous paragraph). That day I swore to never back away from a choice if it would leave me with a lifetime of regret.

And I’ve had to own a lot of consequences as a result. I’ve made bad decisions. I’ve made bad calls. I’ve made bad estimates, done the wrong work, shipped the wrong product at the wrong time to the wrong people. I have permanently screwed up the lives of a few people. I have deeply hurt many others. And I have offended so many people that I’ve lost count. All because I made a choice and took a risk that didn’t work out. And you know what? I don’t feel good about any of those consequences.

But I don’t feel ashamed of the choices. I made the best call I could at the time with the knowledge and abilities I had. Don’t get me wrong–sometimes it takes me a long time to forgive myself when I say or do something hurtful or ignorant or blithe or just plain dumb. But it’s so much easier than forgiving myself for not making a choice and choosing to own it.

Of course I’m only talking about the bad choices I’ve made here. I’ve made lots of good ones, too, and owning the choice is the reason I don’t feel guilty or ashamed that I get to have the nice consequences. There are lots of great things that happen to me on accident, and sometimes I even feel good about them. But sometimes I was just in the right place at the right time with the right skin color or nationality or gender. I can accept those and appreciate those and be grateful for those, but I can’t really own those. And that’s what I’m talking about here: the kinds of choices you can own, and owning them, and owning the risk of choosing–regardless of which side of the choice you took. That’s how you own the consequences.

You Never Regret Taking The Risk

I want to clarify that sometimes the risk is to take the safe path instead of the path everyone expects you to take. I’m not talking about being reckless, or risking more than you can afford, or making a decision before you need to without gathering the information that you need. That’s knowingly making the wrong decision, and there’s no prize for that. That’s stupid at best, and evil at worst. When I say “taking the risk” I mean studying out the odds, calculating the costs of failure, and deciding if the decision is important enough to get wrong.

So you know the kind of risk I mean. The kind where you have the information you need, you know what success could look like, and you know what failure could look like, and you know exactly what living another day without choosing looks like. That decision. THAT risk.

I have never regretted taking that risk, success or fail.

Of course I don’t mean I’ve never regretted a bad decision. But having the chance to make that decision, and thinking I had enough of the right data, and then making the choice–taking the risk–to the best of my ability? Never. Not once. I’ve never cared for the question “what would you do if you knew you couldn’t fail?” It doesn’t motivate me because I can’t know that I can or cannot fail. But Brené Brown rephrased that question into something so much more beautiful that I now keep it on a post-it on my monitor: “What’s worth doing even if I fail?”

That’s the kind of risk I’m talking about here.

I just tried to think of the dumbest risk I’ve ever taken and I ended up spending over an hour writing and deleting and starting over with just the things I’ve failed at this month. I could be the poster child for failure. Not just because I’ve failed so much, so hard and so often, but because I would also look hilarious on that poster.

So What’s With All This Regret And Risk Stuff?

Dumb choices are not the enemy. Big risks are not the enemy. Crazy failures are not the enemy.

Paralysis is the real enemy here.

If you have a choice in front of you, and you don’t want to make it, there’s a hundred things I could say to you. I could remind you that every day you don’t decide, you slide closer to being stuck with the default choice. I could point out that success would be just so awesome. I could say that you miss 100% of the shots you don’t take.

But I’m not going to. I want you to look at that choice, and look at that failure. Just look for a moment. Look at walking down that mountain instead of jumping off of it. And remember: We’ll understand. Stop being afraid of that walk. If you can own that side of the choice, you’re halfway to owning the decision, and owning the risk.

And if it’s a risk that makes sense–I remind you again that I jumped off with a rope–maybe you can let yourself own that, too.

You might regret the consequences. But you’ll never regret taking the risk.

What’s worth doing even if you fail?

How long will you regret it if you don’t even try?

–David

P.S. I’m still writing the Job Replacement Guide, and this post was definitely inspired by my recent research. If there was one thing I could magically place in the book, it would be something that would wave a magic wand and help you get out of your paralysis. Whether you need to network with people you’re afraid of or ask a potential employer to negotiate your salary when you’re currently unemployed, or just put “I enjoy creating abominations of nature” in the interests section of your resumé (join the mailing right now if you want to hear the true story behind that quote, by the way, because it’s a story too good to not include in the book and I’m telling it on the mailing list today or tomorrow.)

jrg_cover_small

The Job Replacement Guide

Learn how to replace your job with a better one in record time. Whether you’re unemployed, hate your job, or just wonder what you could accomplish at work if you were utterly fearless, this guide will give you the confidence that comes from being “unemployment-proof”.

Coming Soon!
Click here to sign up for the mailing list to get updates, advance content, and a discount on launch day.

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. 🙂

Teach Yourself a New Programming Language in 21 Minutes (Or 2-3 Years, It Depends)

17 Replies

You’re sitting at work, grinding out a bug in the legacy system, when your boss comes in and tells the team that you finally get the chance to rewrite the whole system–and even better, you get to do it in Clojure! (Or Scala or Erlang or Rust or Dart or some other Language You Only Know A Little About But Have Secretly Wanted To Learn For A While Now.)

Or maybe you’re happy with the language you’re using, but your VP of Software Architecture just spent $150,000 on a suite of Enterprise Tools which includes a module that will let your project scale infinitely into the cloud… all you have to do is learn Clojure. (Or Scala or Erlang or Rust or Dart or some other Language You’ve Only Heard a Few Mutterings About But Desperately Want To Avoid Learning.)

Either way, you’ve got a problem: you need to ramp up in this new language. And whether you want to become a super expert guru ninja rockstar in the language, or just learn enough of it to make it go away, you want to do it fast–and that means you want to avoid making the same mistakes I made learning Ruby and JavaScript over the years. Mistakes which I have learned to fix, mind you, and so without further ado I present:

Teach Yourself A New Programming Language In 21 Minutes (Or 2-3 Years, It Depends)

All you need to do to learn a new language is learn:

  • How the language encapsulates data
  • When the language invokes execution of code
  • Where do the semicolons and braces go

I’m not entirely kidding. This was my strategy for a decade and to this day if I need to get something bashed out quickly in a new language I’ll skim a language reference and let the compiler tell me when I make syntax errors.

In general, as long as you’re staying largely inside the world of what I call “BOLS” (Block-Oriented, Lexically-Scoped) Languages, such as C, C++, VB, Java, C#, PHP, Lua, Python, Ruby or perl, you can in fact learn enough pidgin to get by very very quickly with this method. Granted, in those last three languages it will be obvious to experienced programmers that you’re writing inelegant code. But you can get by, is what I’m saying.

If you’re the second kind of programmer I mentioned, you might be done. Just read this next section for a caveat and then you can hopefully stop there.

Don’t Stop There If You Can’t Stop There

As you’re learning the new programming language, ask yourself the two vital tradeoff questions:

  • Do I really want to learn this language bad enough to actually learn this language?
  • Can I afford the time and energy needed to fumble around being bad at this language?

See, this strategy is especially useful if you know you don’t plan to ever actually learn the language. I have written some pretty arcane bash scripts in my day, but to be honest I wrote my first bash script 10 years ago and in that time I’ve written less than 10,000 lines of bash scripting code. It’s just not worth learning to me, so I keep some files around with examples of the most obvious kinds of things I want to do, and when I need a new bash script–usually about twice a year–I have all the pieces I need right there. BAM. Ignorance is bliss, and laziness is, occasionally, brilliant time management.

But this strategy is especially awful if you know you don’t plan to ever actually learn the language, but you turn out to be wrong. It ends up that you find yourself using it on a regular basis, and hilariously, you don’t even notice this for years and years. This is true for me of elisp, the flavor of lisp used to program emacs. I’ve written elisp for years longer than I have bash, but maybe only twice as many lines of code. I find myself needing an elisp tweak on a weekly basis, and end up spending an hour researching how to do it. And two or three times a year I find a problem that I could solve elegantly in elisp, if only I knew how to express what I was thinking as lisp code. But I don’t solve the problem. I merely sigh, and learn to live without whatever cool new feature I was thinking of.

I wrote that paragraph in present tense because I still haven’t figured out that I really do need to actually learn that language. Shut up.

Sometimes work and politics can affect your decision as well. If you and your boss agree that the Next Big Thing will be written in Language Y, then you have the need and your manager has the afford.

(And sometimes these two forces are in conflict. I could write an entire blog post on the political machinations involved when you and your boss disagree on the do/don’t want or can/can’t afford questions. Skunkworking a cool language or shirking a lame one is a topic for another post, one I’ll probably never write, but basically it would be all about office politics. I’ve seen people get fired for a successful skunkworks project and others get promoted for sandbagging a project. People sure are complicated!)

Okay, NOW if you’re the second type of programmer, you can safely stop reading. If not, you’re pretty much out of luck for the “21 Minutes” part of learning a new language. But keep reading, because the 2-3 years bit isn’t until the very end. Most of the mistakes I’ve made learning a new language I have made in the first few days.

Truly Embracing A Language Takes Time, But You’re In A Hurry, So…

If you want to embrace a language, it’s going to take time. You’re going to have to internalize the language’s entire approach to solving problems. You’re going to have to learn its idiosyncracies and its warts, and you’re going to have to learn its power moves and elegant applications. That all takes time, but if you’ll permit me to point out my favorite pitfalls and some less-traveled paths around them, I can maybe show you a trick or two for leveraging your learning.

But first, good news/bad news. I’m writing this assuming you already know a programming language or three or seven. The good news is, the more languages you know, the faster you can recognize the basic syntax patterns and logic structures of a new language. But the bad news is: the more languages you know, the more they tend to blur into a common model of computation in your head. This can make you blind to the elegant weirdnesses of your new language. Resist the urge to judge weird things quickly; they often turn out to be the most powerful features of the language once you “go native”. If you see something you can’t stand, remind yourself that you haven’t seen everything there is to see, and give the new idiom a chance. Try it out and learn its tradeoffs. It’s okay to discard a bad idea in JavaScript once you understand why it’s a bad idea in JavaScript… but it’s never a good idea to discard a feature of a new language based on your instincts–because your instincts come from other languages, not this one. (Read up on The Blub Paradox if you haven’t heard of it before.)

TL;DR This Is Mostly About Your Blind Spots

I should have put that TL;DR up at the top, but if you don’t know by now that I’m that kind of jerk, you must be new. Welcome to my blog! Anyway, here’s the list. I’ve included illustrations about Ruby, Python and JavaScript, because those are the three languages where I stunted my own growth unnecessarily the longest.

  • As you start learning the core principles of the language, listen hard for hints and clues from its culture. Ruby has block syntax, but a rubyist often cares more about naming than blocks vs. Procs. Python has list comprehensions, but a pythonista often cares more about being able to quickly uncover all the working parts than to have a slick but magical-looking API. JavaScript has objects and polymorphism, but listen to a good JavaScript programmer and you’ll find them more interested in the functions themselves–and their prototypes.
  • Be ready to try totally new ways of thinking. Be ready to abandon bottom-up provability for Ruby’s top-down “programming by wishful thinking” approach. Be ready to trade off a more efficient algorithm in Python for one that is more readable and maintainable. Be alert to the pains you’ll feel trying to write object-oriented code in JavaScript–that’s JavaScript’s prototype system refusing to be hammered completely into an OOP-based inheritance model.
  • Learn where the minefields are. Ruby is a memory hog. Python’s primitives aren’t actually objects. All numbers in JavaScript are floating-point numbers–there are no integers.
  • Learn which minefields you can ignore or work around. Entire models of webservice design have been rethought and reinvented to compensate for Ruby’s apache-unfriendly execution model. Python isn’t THAT slow to begin with, but if you really need bare-metal speed it’s easy to write a C extension. Many JavaScript libraries provide “polyfills”–bits of code for old versions of JavaScript that implement features added to newer versions of the language so that you can write code against a stable JavaScript version and still have a prayer of it working in most browsers.
  • Most importantly, learn which minefields you CAN’T ignore. Treat them like minefields that you must commute through daily. Stop and pay close attention. Map them out carefully. For example, metaprogramming in Ruby is a very dangerous feature, but it’s not a defect; it can be used responsibly. Python’s whitespace enforcement makes it difficult to express certain ideas succinctly, but that whitespace enforcement produces a predictable rhythm to the trained pythonista’s eye, and it is most definitely a feature–don’t let your code fight it; learn to restructure your thinking. And while almost everybody considers JavaScript’s semicolon insertion rules to be eccentric bordering on insane, you MUST learn them if you want to avoid having your program suddenly stop working just because you deleted a comment or swapped the load order of two completely unrelated files.

You can make good inroads to these blind spots in a few days or weeks if you’re just aware of them. So here’s the hard part: Last of all, learn the idioms. From here on out it’s all about learning to think in the language. That’s going to take you a bit longer, and there’s nothing for it but to talk to other programmers, find some online references, maybe buy a cookbook… but mostly, it’s going to take writing code. Lots and lots of code. In my experience (both personal and observing coworkers and clients) this last part’s a doozy–plan on it taking a couple years or more.

Whaaat. You did say you really wanted to learn this language, didn’t you?

Start Small. Start Growable.

Leave a reply

Languages Should Be Growable

One of the fun things in Computer Science is finding new and mind-blowing stuff that turns out to be 15 years or more old.

I just watched Guy Steele’s 1998 OOPSLA talk, Growing a Language. If you haven’t watched it, go watch the first ten minutes and you’ll be hooked for the rest of the talk. I don’t want to give anything away but there’s a huge bomb that he drops in the first ten minutes that not only kept me riveted for the rest of the talk, but then made me rewind it and watch it again. (Remember how you watched Sixth Sense, and the bomb gets dropped at the end and you had to watch it again? And then the director explained his use of the color red in the movie, and you had to go watch it a THIRD time to see that the bomb was constructed right there in front of your face the whole time? Yeah, Guy’s talk is like that.)

In his talk, Guy discusses whether a language should be large or small; a large language lets you say many things easily but requires that you and your listener both learn many words before you can say anything. A small language lets you both start talking immediately, but requires that you spend a lot of time creating new words before you can say anything interesting.

I won’t tell you whether Guy thinks you should create a large language or a small one–in fact, Guy won’t tell you either. But he does make it clear that a good small language must be growable, and a good large language must be both well-groomed and still growable. He even goes so far as to say that most good large languages are the ones that started small and grew over time, with good cultivation.

Bless his misguided heart, he then says that Java is a good language. I have to point out that this establishes his crazy-person street cred right there, but in a way, he’s right: Java DID start small enough to be easily understood. It grew slowly, and with careful curation. This was in 1998, and Guy then goes on to point out that Java is fundamentally broken and ungrowable unless they add some growth mechanisms to the language, such as generics and operator overloading. Most Java programmers today think of these as “having always been there” in the language, and they’re probably part of the reason Java is not only still around, but a dominant language in the industry today.

Applications Should Start Small… and be Growable

So I’m working on an new app right now, and I want to do some good OO design up front to ensure that the app looks and works well. But I’m stuck trying to figure out where to start. Funnily enough, I opened Sandi Metz’ book, POODR (Practical Object-Oriented Design In Ruby) for some guidance, and I found this astonishing guidance right there at the top of chapter two:

“What are your classes? How many should you have? Every decision seems both permanent and fraught with peril. Fear not. At this stage your first obligation is to take a deep breath and insist that it be simple. Your goal is to model your application, using classes, such that it does what it is supposed to do right now and is also easy to change later.”

Sounds familiar, doesn’t it?

Libraries Should Be Growable… or Well-Grown

I’m a fan of RSpec. If you’ll permit me stretching Guy’s language metaphor, it’s a big language for testing, with many words. I can test very complicated ideas without extending the language, and someone who has learned RSpec’s language can read my complicated ideas without learning new words.

MiniTest is a very tiny testing language. It has only a few words. As a programmer not used to constructing new words in my testing language, I initially found MiniTest to be insufferably repetitious. Each test used ten words or so, and nine of them were identical in all of my tests. When presented with this frustration, Ryan Davis shrugged with annoyance and snapped “so write an abstraction method!” It wasn’t until I watched Ryan write tests at MountainWest RubyConf this year that I realized that he does this all the time. This means that a) he was not kidding b) he was not being dismissive and c) that adding words to minitest’s language is in fact exactly how MiniTest expects to be used.

Interestingly, while I think RSpec’s large language is elegant and well-curated, many programmers feel that RSpec has grown in the wrong direction, or has at least become buried by overgrowth. Ryan felt that even Test::Unit had too much cruft in it, let alone RSpec, so rather than prune the language back, he started fresh, started small, and most importantly, started growable.

When Ryan spoke at MWRC, he created a new testing word that I felt did not make much sense. Even watching him define it I thought “Okay, I understand the abstraction, but that word is horrible. It doesn’t communicate what the word does at all.” That’s the drawback to small languages: naming things is hard, and small languages require you to name things from the start. Had I been pairing with him we’d have had a splendid argument about the name of the abstraction method he wrote. But that sort of fits into Guy’s logic as well: growth should be carefully curated. As you grow, you’ll create new words, and those words should be easy to learn and understand or you can’t communicate well.

Growth Should Be Curated

I’m gritting my teeth as I type this, but I have to own up to it: The growth of Java has been well curated. C# has also been well-groomed, even if I think the language designers have carefully and consistently solved all the wrong problems with the language.

I think PHP is probably the poster child for bad growth*. That’s in addition to its internal syntax inconsistencies; I’m just talking about the language’s internal methods. For a quick example, see how many different clumps of consistency you can find just in the string functions. For a longer example, read @eevee‘s rant, PHP: A Fractal of Bad Design. (TL;DR? Fine, just click on the rant but don’t read it–just scroll down to see HOW LONG it is.) PHP’s problem is twofold: they added things inconsistently, and they were unwilling to prune things back out of the core once they had been added. PHP has grown much faster than Java and C#, because the maintainers were willing to make mistakes rather than deliberate for years in committee, but like Java and C#, PHP hasn’t gone back and fixed mistakes once made.

In my opinion, Ruby sort of gets a B+ on growth curation. A lot of words are unnecessary synonyms (count and size and length, for example) while other words are occasionally synonyms that suddenly change meaning when you’re not expecting them to (Array#count and ActiveRecord::Base#count, for example). Some things in the language are pretty bizarre edge cases (The Kernel#test method, for example) and in the new Ruby 2 release one major feature (Refinements) was brought in under strident protest. But by and large the methods across the entire language are consistent with each other, and when they vary it is usually to be consistent with some external protocol that they are modeling. Ruby 2 was willing to break backward compatibility in order to fix mistakes and grow sufficiently. I also cut Ruby some slack because it’s growing extremely fast in comparison to other languages, and having the breaking changes in Ruby 1.9 for 3 years before committing to Ruby 2 let the community keep pace.

So Grow, But Grow Carefully

And that’s sort of my whole point here: Size and growth are key tenets at every level of abstraction: for a single application, a broadly applicable test suite, or an entire language, two rules I’m drilling into my head right now are

  1. Start Small. I can’t say “Always Start Small” because sometimes the problem you need to solve is big. But it is fair to say “Always Start As Small As Possible”.

  2. Start Growable. This one IS gospel for me. However big I choose to start, I think growability is essential for success.

  3. (Bonus Rule) Curate your growth, but don’t be so afraid of growing wrong that you become afraid to grow. Be willing to grow and then weed.

And if all else fails, start over with a new small thing and start growing again.

* Note: Every time I kick PHP’s tires I get hate mail from offended PHP programmers who assume I’ve never used the language. The fact that PHP programmers are the only group worse than rubyists when it comes to language fanboyism is a topic for another day, but for now, let me just say $$dispatcher->$$method. If you’ve never written your own framework in PHP, that little snippet of code means I am better at PHP than you. I have pushed out, much like an agonizing stool the day after an all-night taco binge, a little over a million lines of PHP code. It is the foul tongue of Mordor, but I have earned the right to dislike it purely on its lack of merit. If you like it, that’s fine. It’s your choice. I’m not saying PHP doesn’t have its good points or that I can’t write clean code in it. I’m just saying it’s not worth it to me.

Stop SOPA: An Open Letter

Leave a reply

Copy of a letter I have sent to my representative. Similar letters have also been sent to both of my senators.

Dear Representative Chaffetz,

When you campaigned in 2008, you promised to go to Congress and fight for me. As your constituent, I am writing you to ask you to PLEASE do everything in your power to fight SOPA and PIPA.

I create content for the web, and I go out of my way to ensure that everything I create is legitimate, original and worthwhile. I have had that content pirated, and I feel firsthand the frustration of seeing others use and profit from my stolen efforts and being unable to find effective recourse against these people.

I want good anti-piracy legislation. We NEED good anti-piracy legislation. But SOPA and PIPA are NOT good legislation. While I appreciate the effort put into helping web-based businesspeople like myself gain speedy recourse against pirates–and this should be a part of good anti-piracy legislation–I am unsure if the laws will help a small business like myself, and I am genuinely terrified of the breadth and ease with which this recourse may be misapplied to legitimate content created under fair use.

I know this is a tricky issue. Balancing speedy recourse against infringement versus appropriate defense against censorship of free speech will require some clear thinking, tough negotiating, and hard fighting. But that’s what we elected you for.

Please give us good anti-piracy legislation. And please, do it by first stopping SOPA and PIPA.

Thank you,

David Brady
President, Shiny Systems LLC, and active Utah District 3 voter

Software and Chicken Entrails

Leave a reply

I had a collection of epiphanies today about Informational Software.

“Informational Software” is a term I use to describe software that helps you understand and make decisions about information. It is not a product and does not make your business money, but it can be used to help you understand your business and therefore, in theory, help you make money. For example, analytics software does not make you money, but you can use it to understand your traffic and hopefully to then minimize your costs and maximize your revenues. (Note that if you are selling an analytics package, this definition is still true, because in that case the software is a product, not an information tool*.)

Informational Software comes in two types: software that interprets trends and data and makes decisions for the user, and software that collects and reveals data so the user can make their own decisions. Expert systems are an example of the former, analytics packages are an example of the latter.

Let’s call this mess of data the chicken entrails. We want to read them and predict the future, right? Sure we do. That’s what chicken entrails are for.

Okay, enough definition. Here are the epiphanies:

First: If your users are untrained and the data is simple, your system can advise the user and/or make decisions for them. If they cannot read the entrails, or the entrails are too simple to bother the entrail readers, do not let/make them read the entrails.

Second: (Pay attention, this is the important bit) If your users are highly trained and the data is very complex, do not attempt to interpret the entrails for them. Just show them the entrails. Highly trained users who have asked you for information software do not want you to do their job, they want a tool to help them do their job better.

Third: My instinct is always write software that interprets entrails, regardless of the complexity and regardless of user knowledge. Learn to stop and figure out what it really needed.

Fourth: Interpreting complex data is really, really hard. On a small, knock-it-out project, it is almost certainly doomed to fail. Now reread the 2nd epiphany: On small, knock-em-out projects, it is completely unnecessary.

Right now I’m working on software that reveals entrails to some truly arcane masters of entrail reading. They have become masters because the information system currently available to them is literally designed to protect the data from their eyes. I have found two pieces of data, correlated them, and put them into a report, and they think I’m a super genius. Not because my software is smart, but because it is smart enough to be dumb.

I really like epiphanies where I suddenly realize that it is not necessary to be doomed to failure.

* And if you’re smart enough to reason “but what if you’re using your analytics tool to analyze the sales of your analytics tool”, I congratulate you on your cleverness. Can you also see the flaw in this reasoning?