The Ephemeral Nature of Tech Work

I just passed the 35 year mark in tech last fall. Maybe it's because I'm winding down career-wise, maybe it's just something that happens in your late 50s - whatever it is, I've been prone to reminisce. 

 As I was thinking back at all of the post-college jobs I've had in engineering it occurred to me that there's not really anything I can definitely point to that's still in production. I don't recall ever being told as a young engineer that most of the stuff you're working on just won't exist in a few years. An architect or builder can drive by the building they designed or built every day and have the sense that they did something that's had an effect on the landscape - they can even go into the building and appreciate that feeling of accomplishment. The building will probably be there for a few generations and the grandkids of the architect will point to the building and exclaim to their friends: "My grandfather designed that building." For most that will not happen in tech.

 I started out in hardware and embedded development transitioning to software development after a few years. I've worked in startups as well as midsize and large corporations - pretty much the full spectrum of companies.

The startups I was involved in no longer exist - well, one of them kind of still does. There's a website, at least, but it will never be anything more than the CEO's pipe dream. With startups the reason your work doesn't endure is simple: most of them just cease to exist after a few years. Funding is lost. Investors willing to invest aren't found. And all that work you did there is just gone. Sure, some startups get bought out and their code/designs live on somewhere else. But that didn't happen in any of the ones I was in.

Even during the time a startup is still viable things tend to be quite unstable which leads to work being thrown out. I recall that in that first startup in my 20s we were working on a project developing some embedded code and awaiting some hardware from an outside contractor. Our manager told us young 20 somethings that we needed to get the code done by the time the hardware arrived - we pulled some all-nighters working towards that goal. Said hardware was always about to arrive imminently... but it arrived months beyond when we thought it would. And by the time it did arrive, the priorities from management had changed. And all of our embedded code as well as the hardware were pretty much scrapped. As one of my young co-workers observed: "We could've spent the last six months on the beach and just as much would have been accomplished." Indeed, I'm starting to think that a lot of the last 35 years would have been just as productively spent on the beach.

So what about the larger companies - those are more stable and you'd think that projects would endure longer? Not really. Big projects are started with great fanfare and lots of hope ("This product will be the future of the company!"). Only to be canceled a few years later, if not sooner. I can point to several projects that I was involved in where that happened. Lots of long hours put in by lots of people - mostly all for naught.

There were some projects that made it out into the world, but the other factor in tech is obsolescence - it happens very quickly. Products are released and soon replaced by new products.

There's really only one product from a mid-sized company that I can point to and say "I think there might be some code in there that I wrote." But, of course, I'm not completely sure. They could have rewritten a lot of code by now since it's like a dozen years since I was there. I suspect my most enduring contribution to that product were the tests I added.

So what's my advice to those of you just starting out? Be very careful about what you're going to spend long hours working on - don't be convinced by management that long hours are even going to be helpful in the long run. In my experience the work you do after about 40 hours probably isn't going to be your best work anyway. And even if your hard work and long hours do end up "saving the company" be aware that in a short time (much shorter than you think) the stuff you worked on will be gone. Choose accordingly. Live a balanced life. Enjoy your work, but also enjoy the other areas of your life.

Waiting to hire the Perfect fit

I started seeing the job match emails in July. The ones that say "We think you're a good match for a job at Company X". Most of the time I either wasn't interested in Company X or their algorithm wasn't all that great at finding a good fit. But this one was intriguing.  There was a wide range of technologies involved that ranged from very close to the metal to very high level development. It was actually a pretty good fit - not a perfect fit, but pretty good. It seemed like interesting work.  I was pretty happy with the current gig, but I was curious and after a few weeks of seeing this job post, I finally gave in and applied on their online site. Crickets.

Another month or two passes and I'm still getting these job alerts. It's going to be tough for them to find someone with that mix of qualifications. At that point I realize that I know someone who used to work for someone probably connected to the group in The Company that's trying to do the hiring.  I send him an email and, sure enough, he does know the people who are trying to hire for this position and he introduces me via email. I send that person my resume and he says he'd like to bring me in for an interview, but it would have to be after he gets back from some travelling. I wait a few more weeks and email him again and he apologizes and says he still wants to bring me in, but they're kind of busy at the moment. I'm in no particular hurry.

Now it's mid-November and I've still been getting the job alert emails for this position every week or so.  It appears they're doing some A/B testing of the ad as the job title sometimes changes, but it's clear that it's still the same general position. Finally my contact gets back to me and sets up an interview for just after Thanksgiving.

Monday morning 9AM. Waiting in the lobby for Mr. A who is supposed to meet me and take me up to a conference room for the interviews. He apologizes and says he's got a cold so he shouldn't shake my hand. I appreciate the consideration. We get into the room and he reads over my resume for a minute and says "You're not a perfect fit for this position." And I agree that I am not and mentally add, But apparently you've been having a tough time finding a perfect fit for this position.

Mr. A then zooms in on a project I did ten years ago and asks me to talk about it. It was one of the more interesting projects I had done and I jumped right in explaining it, though some of the details were a bit fuzzy and I needed to recall them.  But Mr. A wouldn't let me finish a sentence without interrupting. I'd try to explain something about the project and he'd be like "Yeah, but what about ...?" Well, I was about to get to that... I'd then try to present more detail and he'd interrupt again. The interview is going south pretty quickly, it was almost like the guy just wanted to have an argument. Maybe it was his cold that led to this impatience? I'm an anxious interviewee in general but when I checked in on my mental state it wasn't panic I was feeling. Strangely, I was pretty calm and I wondered about this because I'm usually not calm in an interview. And then I realized why: Mr. A had managed to convince me that I did not want to work with him in less than 5 minutes and so I had no reason to be nervous because there was nothing at stake. First impressions go both ways, Mr. A.

Mr. B comes in next. He's the software architect. He asks about teams I've worked in in the past and how they managed their work. Scrum, agile processes, standups, unit tests, etc. that's what he wanted to hear about. When I mentioned that in one of my previous jobs I had been a software guy for a hardware team he asked something along the lines of: "But could they have done your job?" No, they weren't software people, they didn't know C++ and there was a good bit of C++ to be written. "Could you do their jobs?" Maybe bits and pieces as I had been a hardware person in the past, but I wouldn't be anywhere near as efficient. To which he replied: "But on a team everyone should be able to jump in and take over for anyone else." Oh, no, one of those shops where all the workers are just interchangeable cogs. "I don't agree." I said. "It's OK to have specializations especially when you're working on a project which requires such a wide range of skills."  He then went on to lecture me on the dangers of specialization (and I agree with some of them). Strike 2! Now I'm starting to see why these guys can't hire anyone.

Ms. C was the next interviewer. She was the software manager. She actually did a good job of explaining what they were up to and what they needed. They actually needed to hire 2 or 3 people she said. Good luck with that, I thought. It was a much better interview than the first two and it seemed like she would be a good person to work with. She also explained that they had a very tight schedule with an alpha release in mid-January (a month-and-a-half away) and a beta a couple of months after. They really needed more people to get there and it was imperative that they meet these deadlines to secure further funding.


Finally, I spoke with Mr. D who I had communicated with via email and who had set up the interviews. After talking to Mr. D I concluded that he was someone I could work with. 

To cut to the chase: In the current hiring environment it's near impossible to find a perfect fit for positions that have many technical requirements. If you're trying to hire in this environment you need to be creative about fitting applicant skill-sets with your requirements: for example, so they don't have Ruby experience, maybe their Python experience is applicable? And you also need to be careful that you're not scaring people away. You can wait around to find the perfect fit who may or may not exist while your deadlines are looming, or you can hire someone who is a pretty good fit and have them start coming up to speed and actually make progress.

A Plan for Funemployment

Up until last Tuesday I had worked 2.5 years for a large semiconductor company that shall remain nameless. They're a household name. Their CPUs are in your laptops & desktops... but the problem that's causing them much consternation is that their CPUs are very likely not in your phone or tablet. OK, you know who I'm talking about now, but I'll refer to them as MegaCorpCo in this post.

So why the heck would I leave my job at MegaCorpCo? Especially since they're working on some of the most interesting projects in the area?  MegaCorpCo with it's 100,000+ employees was the largest company I had ever worked for by at least 2 orders of magnitude.  In a word, I think the main reason was bureaucracy.  That bureaucracy was primarily fed by a quaint kind of 20th century security paranoia that made it very difficult to share information internally (code, documents, etc.). This security paranoia led to very real delays and frustrations. It's as if they never got the memo about the benefits of sharing information openly.

The other part of working at a mega corporation is that you work on such a small piece of the puzzle that it's kind of tough to get your arms around the product and when the product is done you don't get to actually "play" with the it (and the product was actually very interesting, I must admit).

Let me be clear that the people I worked with and for were great. And I think my manager was certainly one of the better managers I've had; MegaCorpCo seems to do a great job with manager training. 

But there was the gnawing sense on Sunday afternoons that Monday morning was coming which led a sense of dis-ease (BTW: check out Kent Beck's excellent talk on experiencing Ease at Work ). Then last summer my appendix burst and that gave me about a month to think as I recovered. And by the time I went back to work I had concluded that I need to probably be somewhere else. Someplace a lot smaller.

Enough 

Around that time I started reading the excellent Mr. Money Mustache blog where the topic is generally about early retirement. Not "retirement" as in the cessation of all work. More like working on things you want to be working on - sometimes for even for money. I went through some of the calculations and figured that if we were very frugal I could probably have enough saved to "retire" (to work on projects of my choosing not necessarily for money) in 5 to 7 years. So for a while I figured maybe I could tough it out for 5 to 7 years (MegaCorpCo did pay pretty well, after all).

Then early in the year there were beginning to be rumblings & rumors of layoffs at MegaCorpCo. This goes back to the lack of success in getting their CPUs into mobile products that I mentioned earlier. In February that was formalized. We were told that it would be X% of our supergroup. (where X is actually quite a bit larger than the numbers published externally, which is why I'm keeping it as X here). Then we were given an offer of a voluntary severance package (N months of pay and M months of paid insurance). It was a pretty generous offer given my short tenure, so I decided to apply for the VSP which was billed as a sort of lottery.

It wasn't that I was worried about being laid off, it was more that it seemed that after laying off X% of the group that it would become a much less pleasant place to be. That and my general dis-satisfaction as outlined above led to the decision. Near the end of March I found I had been selected \o/ and that my last day was to be April 1. 

Of course, I don't yet have enough to really "retire" for good - Like I said that would take another 5 to 7 years of working for pay. But who says that "retirement" period has to happen all at once? Another way to look at it is that I really only have to work for money for another 5 to 7 years.  Why not mix periods of funemployment with paid employment?

This is quite possible now because the Affordable Care Act breaks the tie between insurance and a job. Prior to the ACA, once you were in your 40s or 50s it could be very difficult and expensive to obtain insurance. By the time people turn 50 pretty much everyone has had some pre-existing condition that would disqualify them from getting insurance under the old regime. And this kept people tied to their jobs.

The fun part

As programmers, we have certain advantages over other occupations when it comes to times of unemployment. We can start or contribute to open source projects and by doing so build our portfolios on sites like GitHub. Future employers can examine these portfolios.  I can't imagine that accountants, for example, can or would work on accounting in their spare time and put the results up on a GitHub for accountants. ( But who knows, maybe it happens, some accountant decides to audit some corporation's quarterly report and finds discrepancies and blogs it - I suppose that could happen, but it doesn't seem very likely). 

As a programmer it seems to me that we're living in a sort of golden age. So many open source projects out there. So many new languages to learn. So many new frameworks to try out. So many free classes (MOOCs). Now that I've got some time, I'm really looking forward to digging into learning. I'm taking the Coursera Machine Learning class now, for example, and plan to take a few others.  I'm also looking forward to reading more. And I plan to dust off some long dormant programming projects and start some new ones. 

Of course, having the Spring and Summer off means I can also do a lot of outdoor activities that I wouldn't have as much time for if I was working in a job for money and I plan to do some of that as well. 

The Plan

I'm aiming for a 4 to 6 month period of "funemployment". I suppose that if the perfect job comes along after 2 months I'd probably accept the offer, but at this point I'm not planning to start looking around much in the first 3 months and figure it could easily take 3 months to find a good fit (given the current good job market for developers - if it slows, it could take significantly longer). I'm planning to do at least one blog post per week related to programming. I'm also looking forward to playing with my Parallella board when it arrives (hopefully in the next few weeks). And I want to play with Mirage OS as well.

Plans can change, of course. I did something similar back in the Summer of 2001. I figured it was time for a break after paying off the mortgage of our first house. I quit a job I had had for 8 years to take 6 months off. Yeah, the Dot-com bubble was bursting, but these things generally only lasted about 6 months, right? Heh. Then there was 9/11 a couple of months later and the economy got really slow. The six-month-off plan turned into 10 months off (and even then when I went back to paid work it was only a 4-month contract gig... though it was also one of the most interesting, enjoyable gigs I've had and I learned a ton.).  I can recall going to user-group meetings in Portland back in 2002, 2003 and asking for a show of hands of who was working and it wasn't unusual to only see half the hands go up. But on the positive side, due to the slow economy I decided to go back to school and get a Masters degree and related to that I got to go do research in Italy for 3 months back in '04. Money was definitely tight during those years, but they were also very good years.  

So while plans are good, one has to remain flexible.  

A follow up on the interview anxiety post

First off, I'm really surprised how many views yesterday's post got: over 17,000 views in about 24 hours.  It also got a surprising number of upvotes on Reddit as well as Hacker News.  I was expecting views to be in the hundreds at best, so it seems my post struck a nerve out there.

As for the responses they seem to fall mainly into the following categories:

"Why don't you medicate?"

I'm really hesitant to go down the medication route at this point. My concern is that I don't need to take medication to cope on a daily or regular basis and I don't want to have to. I guess I'd worry that popping a Xanax once for an interview might actually feel too good and I might be tempted to start taking it in other situations. In the past when I experienced situational anxiety issues around more common activities (driving for example) I decided very early on that any kind of drug that would take that feeling away would also become necessary.  I figured that if it really worked I'd quickly become dependent and never want to leave home without it. That's why I went with a cognitive approach to work through it. It's not as fast as a pill, but it eventually worked and I didn't need a prescription. I realize there are people who do take these medications and I do not want to sound like I'm saying that no one should take them. This was what I decided was best for me. Your mileage may vary.

"Therapy?"

I think it's a very mixed bag. Works for some, other go through years of therapy and don't see much difference. What does seem to work, in my experience, is talking to others who struggle with the same issue. It helps to realize you're not the only one. It also helps to share ideas about what has worked and not worked. I guess it comes down to this: if the therapist has never experienced a panic attack, I really don't think they have the cred to talk me through it. I'd rather talk with someone who has gone through it (therapist or not) and come out the other side.

Of course, I can hear the arguments now: "But if you had pneumonia you'd go to a doctor for treatment whether or not that doctor had had pneumonia before." Sure, that's absolutely true, you don't care if the doc has had disease X as long as they can treat you for it. But when it comes to something like anxiety it just seems quite different. I think someone who has struggled with the same kind of issue can actually be a lot more helpful than someone who hasn't.

"Blame the interviewer!"

There were some responses like: "An interviewer shouldn't ask certain kinds of algorithmic questions in an interview, you should refuse to answer!". I have to say that I absolutely do not agree with that. The interviewer is trying to find the right candidate for the job and most programming jobs require that you write code. So the interviewer has every right to ask. 

Other responses had to do with the attitude of the interviewer. Situations where the interviewer is being a jerk or trying to purposely stress out the interviewee. But in my experience, that's generally not been the case. Some interviewers have actually been quite accommodating. 

Ultimately, it's my issue. I own it. I need to work through it. Putting the blame elsewhere only prolongs that process.

"I'm an interviewer, how can I help you have a good interview?"

These responses were very gratifying. My motivation for the post was mainly to raise awareness and a response like that show that there are interviewers who want to be aware. So I really commend the folks who had that kind of response.

As for the answer to that question, it's going to vary depending on the anxious interviewee. I think in my case the following could be helpful:

• A coding problem given prior to the interview. Then go over the resulting program in the interview.
• A written 'test' with a few different questions delivered by the interviewer. Interviewer then says, "I'm going to head out for a coffee, I'll be back in 30 minutes or so to see how you're doing."  I had an interview where that happened and it was fine and apparently I did well on the test.  I think there were a couple of factors here: No one was looking over my shoulder while I tried to solve the problems. If I got stuck on one question, I could go on to another and come back to the problematic question later. 
• REPL instead of whiteboard.
• Walking and talking outside. Walking, especially outside, calms me down.  A walking conversation actually sounds quite nice. 
• Going over code in my github, perhaps?

"I've had exactly the same (or similar) experience."

There were lots of these. It's not an uncommon story. It's good to know you're not alone. 

Interviewing for the anxious programmer

Hi. My name is Phil and I have situational anxiety related to technical interviews - specifically, the coding part of the interview. Now, of course, everyone has this to some extent, but maybe I should clarify: I panic when the interviewer says "Could you code this algorithm on the whiteboard". And when I say panic, I mean PANIC: racing thoughts of doom, impending death, doubt about my abilities, dizziness, difficulty breathing, feeling like I'm gonna pass out - the classic panic attack.

As I step up to that whiteboard, my brain launches several spinning thought-processes that suck up the vast majority of my processing power. First thought-process: "Oh, no, what if I can't do this? What if I look stupid?". Followed quickly by: "Try not to hyperventilate! Hold it together, man!". And then several others: "My heart is pounding!", "I feel dizzy!", "My stomach, it's in knots and I feel nauseous - don't get sick in an interview!". I call these spinning thought-processes because they're sort of like processes running in different threads on a CPU. They run in loops.  Now, of course, all of this makes it difficult to actually work on the coding problem posed by the interviewer. From the outside, from the interviewer's perspective, it probably looks like I've locked up. Stumped by the problem itself. When really, the posed problem is only getting about 10% of the mental CPU at this point. 

How did all this start? Well, I think I've always had a propensity towards anxiety even in childhood. I can recall in high school having full on hyperventilating panic attacks in my senior year around that time when I needed to decide where to go to college, etc. Of course, at that time I had no idea what they were - I'd be taken to the school nurse and she'd have me lay down for a while and pretty soon it would pass. After I went off to college they didn't happen anymore. But then after college at some point when I had a job where I needed to travel some, I recall a particularly bumpy flight where I had that kind of feeling again - now I would characterize it as a panic attack. And a bit later I had some health issues that also caused similar anxieties to resurface. This was about 20 years ago. At some point it developed to the point where just driving to the store to shop became quite a challenge. By then I realized that these episodes were panic attacks. I read up on the topic and basically went through a lot of cognitive self-therapy and after a year or so I was able to drive without issues and life was good again.

I think I've always been a bit nervous in interviews (who isn't?) but a few years ago, I had an interview in a small, stuffy room with no windows. The interviewer asked me to code some algorithm on the whiteboard and I suddenly broke out in profuse sweat and... well, the whole thought process thing I outlined above took over. As I felt quite physically ill at this point, I had to ask for a 10 minute break. After the break I came back and gave it another try, but by then I was just too run down by all of the stress hormones rushing through my bloodstream and I had to just call it off and leave immediately. And that was, I think, the interview that triggered the association. Since then, I've had mixed results. Some interviews have gone OK. Others have been close calls, and still others have gone about as badly.

So why am I blogging about this in... public? Let me clarify that my motivation isn't to elicit sympathy or to somehow get a pass on interviewing. Interviews are kind of a necessary thing. Sure there are alternatives like auditions, but even then you need to have some kind of interview to figure out who you're going to audition. No, my motivation here is to try to take some of the power out of the anxiety. Part of the fear is that people around you will discover that you're having a problem with anxiety and that they'll judge you for that. Well, if I tell them up front, then that takes some of power out of that fear.

Strategies for coping

In some cases, I've noticed that perhaps low blood sugar has played a part, so I tend to take some kind of snack along - nuts, energy bars, etc. The brain uses a lot of glucose and needs to be well supplied in order to function well. Usually, an interview lasts about an hour and you get a little break in between - I try to snack some during those breaks. 

Another factor can be endurance. I've definitely noticed that things are more likely to go downhill near the end of a day (or even 1/2 day) of interviews. So now I try to ask that a full day of interviews be broken into 2 half days instead. Sometimes I even think I should ask that a 1/2 day of interviews be broken up into even smaller chunks over a couple of days.

I also try supplements like l-theanine and GABA, but I can't exactly say that the results have been consistently good. I think they help take the edge off, but they certainly don't completely eliminate the problem.

Ultimately, I think I just need to practice more. Whereas I overcame anxiety issues related to everyday issues (like driving) in the past, it's a bit tougher to work through interview-triggered anxiety as you don't get an opportunity to interview every day.

No Or-Patterns in Haskell?

I ran across Chris Okasaki's excellent Red-Black Trees in a Functional Setting article a few weeks back.  Excellent functional take on Red-Black trees - so much easier to understand than the imperative explanations I've seen elsewhere.  Highly recommended.  

The example code in the article is in Haskell.  I've been learning OCaml for several months now and reading an article like this helps me learn a bit of Haskell along the way.   I did a translation of the code in the article into OCaml which lets me compare and contrast the languages.   Here's my OCaml translation:

(* RedBlack trees in OCaml *)
(* see Okasaki paper: Functional Pearls: Red-Black Trees in a Functional
                     Setting *)
type color = R | B ;;

type 'a tree = E | T of color * 'a tree * 'a * 'a tree ;;

let rec member x t = match t with
 E -> false
| T( _, a, y , b) -> (  if x = y then true else
                       if x > y then (member x b) else
                          (member x a) ) ;;


let makeBlack node = match node with
 E -> node
| T( _, a, y, b) -> T( B, a, y, b) ;;


let rec balance t = match t with
 T(B, T(R, T(R, a,x,b), y, c), z, d) | T( B, T(R,a,x,T(R,b,y,c)),z,d) |
 T(B,a,x, T(R,T(R,b,y,c),z,d) )      | T(B,a,x,T(R,b,y,T(R,c,z,d))) ->
    T(R, T(B,a,x,b), y, T(B, c,z,d))
| _ -> t ;;

let rec insert x s =
let rec ins s = match s with
  E -> T( R, E, x, E)
| T(c, a, y, b) -> ( if x = y then T(c,a,y,b ) else
                     if x > y then ( balance (T(c,a,y,(ins b))) ) else
                                   ( balance (T(c,(ins a),y,b)) )  ) in
makeBlack( ins s) ;;

Notice that in the balance function there are four patterns which lead to the same result. OCaml handles this nicely without repetition of code. However it seems that the Haskell version requires that the result be repeated for each of these cases as Okasaki notes in his article. His article was written in 1993 and he mentions that in the future Haskell could have or-patterns, but from what I can tell by googling around a bit and asking on the PDX_func mailing list this feature is still not in Haskell. So here's a situation where I definitely can say that I prefer the (OCa)ML solution. I'm sure there are other things to prefer in Haskell, though, like type classes.

This American Life Explains the Mortgage Meltdown

Not programming related, but This American Life did a great show on the Mortgage Meltdown.  If you've wondered what led to this debacle which will lead to $Trillions of lost wealth in the US (technically speaking, it's not being lost, it was never really there - it was pretend) give this show a listen.