25 August 2016

(North) Austin Traffic

"Hey, this traffic isn't so bad!" I thought a month ago.  It was July and I was averaging 15-20 minutes to work down a 6 lane surface street with an effective 70mph speed limit (Yay, Texas?)

...then school started back.

That same street became one backup after another this morning, and it took me 30 minutes door-to-door, even though I live 9 miles away.   Between schools being back in session and UT classes restarting, something like 40,000 more Austinites are on the road each morning and afternoon.


It's not so bad, of course.  Between the EV mode on my Fusion Hybrid and the regenerative braking, I'm up past 32mpg even in that gridlock.  Not bad for for a now 7 year old paid-for car.

23 August 2016

When Do You Leave?

I've been reflecting lately.  Huge life changes will do that to you.  You know, things like: Quitting your job of 17 years without another one handy, moving to a state you've only driven through once, working at one of the big 4 tech firms, and being fired as a Dad by my own son.

So, when do you decide to make a change?

Looking back on it, there were several discrete moments where I was 'out'.

  • Philosophic Disagreement: I was still an intern when I learned the company decided to shut-down all manufacturing at our site.  This fundamentally changed the company, from being a team-oriented place where we did everythig soup-to-nuts (R&D -> Manufacturing -> Sales) to being wholly white-collar.  I was so upset I called my Dad and said I wanted to quit, to never go back to that place.  I went back the next Monday.
  • Burnout: When I was promoted waaay too fast and burnt out, at 25.  I was leading a team in America and one in India, and every single person on both teams was older than me.  I handled it....by working about 80 hours a week.  I was increasingly unhealthy and stressed, and if you look back at my blog in 2003->2004, you can see it clearly.  
  • The Deathmarch: In 2008->2009, I worked on an 18 month deathmarch project full of politics, deadlines, and impossibility.   We got it done and made it work, but I was working 80 hours a week minimum for that time.  I remember distinctly having a shouting match with my manager at 3am on a Sunday night.  I tried to get out, but I didn't try very hard.  One interview went badly and I just slumped back into my job.
  • Peter Principle:  I got promoted 3 levels up the org chart to report directly to a director.  I saw the reality of corporate middle management, and it made me sick.  It got so bad, my wife drew the line and said she wanted to hear nothing about my job ever again. (A bad sign unto itself)
  • The Pie Shrinks:  Sometimes, you have to look around and realize that every year, bit-by-bit, you're shrinking.  There are fewer people than there were, and just as much work.  Think of it like Germany in 1945:   It makes little sense to run a things the way you once did when you're just trying to stave off the Soviet Army at the gate.
Thing was, I saw the pie shrink something like 7 times before I got out.  Seventeen years  Why did I stay?
  1. Insecurity.  I've never been a "natural" at CS stuff, I went to a no-name school, my natural accent makes people think I should have a banjo instead of a keyboard.
  2. Loyalty.  I am loyal.  I was brought-up to be loyal to family, country, and (yes) company.  My father worked for the same company his entire career. 
  3. Family Circumstances.  I'm the sole income-earner and I support 4 other people.  "Risk tolerant" was not something I could be.  I needed steady income and job security.
How did I break that down?
  1. Seventeen years of experience.  People really don't care what school you went to after a few years in industry.  They care about your body of work and what you bring to the table now.
  2. There is no loyalty to employees.  It's fantasy.  Individual managers are great (and I've had many that were), but a for-profit, joint-stock corporation has nothing in its corporate charter about loyalty to employees.  In the end, both sides operate best when seeking mutually beneficial outcomes: Great work in exchange for great compensation.
  3. I got down to zero debt (thanks Dave Ramsey) and got a separation package.  
So, like most things, fear and pride were why I stayed.

Realistically, things had run their course in 2005, 2009, and 2011.  All of those were great opportunities to tie a bow and do something else.

18 August 2016

[Code Review] 1. The Case for Code Review

Just wanted to pause and write about that super-exciting topic: Code reviews.

Let's begin with defining what code review is, and establishing the case for making it part of your development process.  We'll also take a trip down memory lane and acknowledge doing code reviews was really hard for years, and now it's laughably easy.

What is Code Review?

Simply, code review is when someone else looks at your code to critique for defects.  

Metaphorically, it's like when you hand your rough draft of a piece of writing to someone else and ask: "Does this make sense to you?"   The writing process and programming process are close kin, but that's another post unto itself.

So what is the reviewer looking for?
  1. Does the (changed) code do what you set out to do?
  2. Have you considered various types of good and bad input?  
  3. Do you handle errors appropriately?
  4. Does the work communicate intent clearly and concisely to the reader?
There are more, but #4 interests me, because it's the same thing you'd say about a piece of prose.  Again, a topic for another day, but it's quite interesting that it's relatively easy to compiles reliably and which accomplishes a task.  It's harder to make code a human can understand days, weeks, even years later.  See Software Craftsmanship.

Why Review Code

Code review promises many things:
  1. Fewer bugs in your production code.
  2. Cross-training people, lessening the business risk of turnover.
  3. Promotes better "team" ownership of a codebase.
Let's unpack that a bit.

Bugs happen.  Thankfully our tools handle things like syntax errors, module integration issues, and style-guide problems automatically, most of the time.  However, logic and design problems still occur, and other sets of eyes really help find that before your customers do.

Cross training and collective ownership don't happen organically.  People--especially software folks--like to specialize and master things.  They like doing what's comfortable and easy.  In absence of other energy or intent, you'll quickly find that a codebase turns enclaves like "Carl's Code" or "Larry's Code" with everything but a 


comment on it. Actually, I've seen those comments.  They're funny!

In any case, a session where other folks have to review code forces them to read and understand the code.  At minimum, some awareness of how another piece of code works, and it de-personalizes the code and makes it more a property of the entire team.

That being said....

Why Doesn't it Happen?

I submit: Doing required code review isn't self-evident.  It takes time.  It can be frustrating, both for the reviewer and code author(s). 

I've been programming professionally for 17 years, but during that time I've only been in groups with effective, systemic code review for ~5 years, and even that off-and-on.   Why is that?

It's useful to look at the reasons people don't:
  1. ROI: It takes too long / We don't have the time.
  2. Operational feasibility: It's too hard.  
  3. ROI: I have no way of verifying the code under review actually got fixed.
  4. ROI: We have tools that enforce most of this stuff anyway.
Thus, the resistance factors are: (1) Is this worth my time? (2) Is it necessary? (3) Is it practical, day-to-day?  To answer, we need to contrast programming before ~2009 and after.

The Before (Tools) Time


You've done 3 months worth of work on a new feature for your software, largely by yourself.  You've already committed the code 2 weeks ago and people have change it since.   There's a ticky mark on your Project Manager's spreadsheet she copy-pastes under everyone's quarterly features: Code Review Complete.  So, you call a meeting of the whole team and email them links to your code in CVS.

If you're lucky, everyone brings their 7lb+ laptops with PCMCIA wireless cards to the meeting.  If you're not, people bring page after page of print-outs of the .h/.cpp files with scribbles.  The pedant(s) will bring a set of style sins you've committed and hand you those on a sheet (with a superior smile). 

Then the meeting begins.   If it's a formal review, the author (you) says nothing.  This is formal.  This is by the book, dammit.  The facilitator reads your code, line-by-line, and people raise questions and defects.  Another participant--the scribe--writes down those defects along with line numbers.  

Lord willing, you make it to the end of your changeset by the end of the hour(s).  If it's anything non-trivial, you probably won't.  You're handed/emailed the defects, and you're expected to fix them and call another verification meeting where we'll do this all again.

Yes, that's what code review looked like in 2002 or so.


Let's acknowledge that the above can work.  It's a very formal process, developed and codified.  I've done it, probably 3 times in 17 years.  One of those 3 times it was effective.

Centrally:  Who has time to do that?

The problems I observed with the above:
  1. It's a "super meeting": Everyone has to synchronize the prep-time, the meeting, and the follow-up.   A meeting like that is man-weeks of impact to your schedule.  
  2. No one does the prep work.  Well, the pedant(s) on your team will.  They'll love eschewing real work to critique others (yet another topic for another day).  In reality, of 8 team members who walk in that door as reviewers, maybe 2 will have read any of your code before that day.
  3. It's painful to collate, parse, and take action on the review comments.  They're out of context, and use absolute references to code:
    • Doofus.cpp, line 1337: Consider 'switch' instead of repeated 'if/else' blocks.
      • Thus, you have to take action on the reviews from bottom to top or your line numbers get messed-up.  Tedious, at best.
  4. No one wants to attend the follow-up meeting to verify your changes were correct.  People will acquire strange illnesses and schedule vacations to garden spots like Detroit to miss that meeting, believe me.  
Like most business problems, the above have very little to do with technical issues.  Mostly it's people.  If it's too hard, people find ways to not do it.  Also, code reviews were the second thing that got cut to meet schedule, right after that nebulous 'Unit Tests' line item on the Gantt chart.

Code Review in the Github Era (post 2009)


You have a user story you took off the Kanban board this morning.  You code up a unit test and write the code for it before lunch.  You check-in your changes to a git branch and push that branch to 'origin'.  Once the ad-hoc build for your branch completes (automatically), you create a pull-request to your team.

Wherever they might be over the next 2 hours, your team members review your changes--it's only ~40-50 lines of ruby/groovy, anyway.  Their screen shows them the current code and your suggested changes in a two-pane view.  When they have comments, they click on the line number on the screen and type-in their comments.

At around 3pm, you see Sue has given some feedback you need to integrate; she found a critical corner case you didn't account for.  You update your unit test and your code, then push again.  The code review updates automatically with the change.

You receive 3 '+1' comments from your teammates and you merge the changes by 4pm.

How is this better?

  1. It's asynchronous.   Your teammates may review your code  any time the review is open.
  2. It's location-independent.  Your reviewers could be anywhere in the world.
  3. Zero prep work is required.  Given reasonable familiarity with the codebase, the 2-pane diff view shows you the changes in context.
  4. The system handles the comments, rework, and verification for you.  You have:  Unit tests, Integration tests, automated build, and a code review system.  There's no way to lose the context of the review.
  5. Verifying your rework is usually trivial for the reviewers.


Going back to our original resistance factors:

1) Is it worth my time?   Unless you're doing 50 pull requests per day, yes.  Reviews can be less than 10% of your time every day.

2) Is it necessary?  One can produce working code without code review.  Arguably, if one wants a codebase that can sustain a 100% developer turnover in 3 years, then I'd consider it essential.

3) Is it practical?   Formal reviews were never practical, unless you worked at NASA or on flight control software.  The ROI wasn't there.  A more github-style flow is entirely practical.

* * 

I'd argue Code Review was an ad-hoc, spotty practice before the tooling improved.  Like diet and exercise, it was "What we should do," but precious few of us were diligent about it.  The ROI was barely there before tooling caught-up to how people work in the git/github era.

Now, given excellent tools like Github and ReviewBoard, an engineering group can integrate a code review into their workflow easily.  Again like diet and exercise, if one is diligent every day, it's easy to make it a lifestyle.

03 August 2016

How are you today? I'm wonderful

Thus far the quote of the month has been:
We should've moved here 5 years ago.

So far Austin is amazing.  In true Freudian fashion, my fingers wrote that last sentence as 'Austin is amazon."  :)  Amazon is amazing, too, but I can't quite talk about that.

So, it's August.   It's 100 degrees every day, 81 degrees at 7 am, and it's great.  Pollen counts are laughably low here, so everyone's improving in their allergies.

Traffic is bad, but manageable.  I have 3 good ways to work, two of them toll-free.  I can generally make it to work in 20 minutes on a 9.8 mile commute, getting 30+ mpg with the a/c on full blast.  One real blessing: Our building has a free parking structure next door, and that lets me park my dark-colored Fusion out of the sun.  I've so far washed the car once since I got here and the exterior still looks great--no rain and shade/garage will do that for you.  Getting home is a bit more 'fun', usually taking 20-45 minutes.  The one time it rained it took almost an hour.

My  office environment is open floor-plan with 4' walls.  Our entire development team is in one big room I'd estimate at 30' x 60'.  And that's everybody: Project managers, developers, managers, etc.  Conversations do carry, and there are usually lively debates ~4pm or so every day on various topics: Static -v- dynamic programming languages, type safety, interview experiences, etc.

The building does lack a cafeteria, but there are usually adjacent food trucks, and a great street with lots of options is about a quarter-mile away.   That is, easily walkable.

The only thing that's not going so great is our ongoing search for a new church.  The results so far:

  • A great little church with awesome music, good sermon, and somewhat friendly folks.  But simply too small at 100 people.  We've done the small church thing once and would prefer to avoid it.
  • The hollow shell of a megachurch complete with vegas-quality AV/lighting and production values.  The place can't pay its bills after several scandals in the past decade.  Again, we've done a church that can't pay its bills, and would prefer to avoid.
  • A church that, on paper, seems perfect--~400 or so attendees, life groups, beliefs that match our own.  Problems:  We went to service and walked out with a literal headache from loud, bad worship music and a diffuse, monotone sermon.
If it were just me, I'd love to go back to that little church again.  I really felt the Spirit there and man could they sing!

25 July 2016

Reboot: Now in Austin

A letter to myself in July 2015 from July 2016:

Dear sir,

This is your future self speaking.  Don't question and go all 'Dr Who' on me, just listen.  

Your life is about to change.   You've worked at Lexmark for 16 years unofficially.  You're looking forward to that congratulatory "15 years of service" email you'll get on June 4th, 2016.  

You'll never see it.  Let me explain a bit what's going to transpire:
  1. The company will "explore strategic alternatives" beginning in October.  I still can't tell you much about what happens after that, legally.  
  2. You'll start getting signals it's time to go from above.
  3. The company will announce a voluntary exit program with 'N' weeks of pay and benefits.
  4. You will accept this offer on the last possible day you could, March 4th.
  5. You will exit the company on April 1st.
  6. You will have job offers locally, but you'll turn them down in favor of rolling the dice in Texas.
  7. You'll finally accept a job with Amazon in Austin, Texas.  By the way, Amazon has a development team in Austin, TX.
  8. You'll sell your house with it only 2 days on the market.
  9. You'll be technically out of work for 3 months.  Yes, you'll survive that somehow.
Future You.

* * *

So, yeah....down here in Austin.  So much to say, but I'm so woefully behind on blogging that it'll require some effort to catch up.  Work is great.  Our (rental) house is like a big apartment.  Austin is great so far.  Today begins my 3rd full week of work in Austin, 4th week at Amazon overall.  

Quite a change :)