Meta

This chapter alone is SDE Mentoring 101. Many of my mentees through the years have struggled in these areas, and improvement is often following these principles, whether by design or by accident.

This is a “soft” skills chapter, yes. Later ones get much more technical. However, most tech ICs (and managers) don’t struggle with technology; we struggle learning these lessons ad-hoc, through experience.

– Harold, 08 January 2020

Foreward & Preface

They don’t talk down to you. They don’t assume you are an expert. … They take you as you are–programmers who just want to be better.

Why is the world going to hell, Harold?

It seems a right of passage for people of a certain age–typically over 40–to look around them and ask certain questions:

• “What’s with kids these days?”

• “Why aren’t things like they used to be?”

• “Why is no one moral anymore?”

• “Does NO ONE have any work ethic?”

This isn’t exaclty, new. Listen to this modern voice:

The children now love luxury; they have bad manners, contempt for authority; they show disrespect for elders and love chatter in place of exercise. Children are now tyrants, not the servants of their households. They no longer rise when elders enter the room. They contradict their parents, chatter before company, gobble up dainties at the table, cross their legs, and tyrannize their teachers.

Disclaimer: There’s probably a term for this, but I’ve this pattern in teams and I’d like to discuss it.

Scenario

You have a high functioning team of 6-10 individuals.  Team culture is great.  Everyone is pulling in the same direction, and lots is getting done.  Yet, in under 4 months half the team will be gone and the rest will be considering it.  As a manager, you’ll realize you can’t deliver anything and it all seemed to crumble overnight.  What happened?

I’m a 40 year old working software engineer.

I’m not a program manager, project manager, team lead, architect, business analyst, sytems analyst, or whatever other term means “Doesn’t code anymore.”

I make my living by telling machines what to do so the company I work for can make money (alot of it) and pay me money (a little of it, but an obscene amount still).

As I sit here, I’m 2 days away from ending a three year stint with one team, and picking up with another within the same company.  The reasons aren’t complicated, but it’s impolitic to go into them.  Suffice it to say, I’ve been looking around for about 6 months internally and it took about a month to get through the transition.  Monday is ‘Go’ day.

A programmer dies and goes to heaven, meeting a rather stern St. Peter at the Pearly Gates.

“You do know we have a record of every sin you’ve committed?” Peter says.

“Sure, whatever…I’ve got nothing to hide.  I lived a very clean life.”

Peter continued: “…and your full git history of every commit.”

The programmer just smiled.  “Great!  I’m quite proud of everything.  I practiced Clean Code.”

“…and the full DAG.  No rewrites of history in Heaven.”

I say this after 19 years making software:  There’s always a date.  Get over it.

I’ve lived through the Agile Revolution, and various schemes to sell consulting named: Spiral, Rational Unified Process, eXtreme Programming, Scrum, Kanban, and the Scaled Agile Framework.

Through it all, there’s always some sort of date.  Words like:

• Milestone
• Need by date
• Deadline
• Start of Production
• Promise Date
• Customer Promise
• Statement of Work

Honestly, if they’re not there, you should probably be worried.  Projects of significance require planning and planning requires dates.  If you haven’t seen a date in quite sometime, you might want to join the rest of us getting paid oodles of money to ship features to customers who’ll pay us.

Postulate:

No matter the brilliance of a given development team, it’s always more efficient to Analyze/Groom/Think about requirements before you’re in the meeting where you commit to delivering those requirements.  

I’ve been developing software with groups of fairly brilliant people for some time.  The above is my genuine experience.

Corollary:

When a group of people encounter a set of requirements and expect to scope and commit to them in realtime while reading the document, it wastes everyone’s time.

Too long for a tweet.

Too short for a blog post.

These are some tech-related skills I’m glad I have.  They come in awfully handy:

• Touch typing.  You’d be surprised at the number of people who work with computers for a living who can’t actually touch type.  

• Markdown.  Markdown is incredibly handy for tossing-off documentation and forum responses.  I’ve actually considered hosing this blog entirely and converting to posts hosted on Github, formatted in Markdown.

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.  

I’ve been a software developer throughout the “Agile Revolution.”  My first team lead, back in 2001 said these words to me and I’ve always taken them to heart:

I think the world’s pretty done with us [Software Developers].  I feel like we’ve got about 5 years to get our act together or that’s it.

Apropos, that same year a highly influential group of practitioners signed the Agile Manifesto.   Amid waves of Dot-Com-Bubble-Bursting, offshoring, and right-sizing, they kept it simple:  Here’s what works; apply liberally.

Thus far on this little experiment, I’ve:

• Overslept by 1 hour.
• Completely lost track of time innumerable occasions.
• Discovered an odd blurring & vibration in my vision.  Generally, it feels like I’m looking through a tunnel or a straw at the world.
• Had insatiable cravings for caffeine and sugar.
• Hyperfocused on assembly language programming and exercism.
• Generally feel like I got hit by a truck–slow, plodding, etc.

On the bright side:

I still remember an interview I had around February 2001, in which +Ron Garnett talked about how his team wrote code:

We write stuff in Assembler, because we’re too lazy to write stuff in C.

Wait…what?  I thought the whole purpose of C was to have portable Assembly, so you could control the bare metal correctly.  I did get an inkling if you were that good, assembly could be seductive in your ability to do whatever you want.

I try to pause every so often and record what my toolchain looks like.   Sort of like people posting on Everyday Carry, but for what I use every day in development.

• Development machine: 13" MacBook Pro Retina, 2.8GHz Core i7, 8GB RAM, 250GB SSD.  I love this machine.  My wife calls it my woobie.  She’s not far from right.

• OS: Mac OS 10.9.4.  Unix when I want it to be, polished Consumer OS when I just don’t care.   It’s been 3 years since I ran a windows box as a development machine and with virtualization I can’t see running windows as a primary OS ever again.
• Physical Setup: Thunderbolt Gigabit ethernet, Thunderbolt-to-DVI single 23" monitor, Microsoft Natural Ergonomic Keyboard 4000.   I’ve dabbled in multi-monitors and buckling spring keyboards, but this setup keeps my attention focused and my repetitive strain to a minimum.  I’ll eventually wear out this keyboard and probably buy another one just like it.
• Note taking tool: Evernote, but honestly I’m dissatisfied everywhere I turn.  Evernote gets closest to what I want amid everything else I’ve tried:  Google Keep, OneNote (which is an abomination on the Mac), paper notebooks, PDAs, Google Drive Documents, emails.  I basically pendulum between over-noting and under-noting everything.  Google Drive wants to be the master, but I resist.  I’m not sure why.
• Blogging Platform: Blogger, through simple inertia.  Wordpress seems like exchanging one master for another.  I’m taking a hard look at Github:Pages and Jekyll because I like finer-grained creative control and Markdown, but I can’t commit to it.
• Terminal Program: iTerm.   Tabs are nice.  I spend lots of time here these days in irb or grails shell.
• Command line shell: zsh + oh-my-zsh.   Tabbing command-line completion and aliases for most things.  (Ex: gc == “Git commit”), with a vibrant community to go with it.
• Package Manager: Homebrew.   I have no idea how I survived on windows without a decent package manager like apt, yum, or brew.  I’d switch away from Windows to *nix or Mac for this alone.
• Editor: Sublime Text 3.  I’m an old vi guy.  Sublime has let me forget the envy I always had for not learning emacs.  Like homebrew or oh-my-zsh, has a rabid, vibrant community.
• IDE:  Honestly, none.  I like command line tools and Sublime, but I acknowledge IntelliJ 13 is peerless in the Java/JVM IDE world.  (Sorry, Eclipse…I’ve been a user since 2.11, but you’re just a hot mess.)
• Virtualization: VirtualBox.  A colleague turned me on to this a few years ago, and paired with Vagrant for setup/teardown, it’s great.
•  Scripting Language: Ruby.    This one feels like the old Simpsons plot “So you finally decided to steal cable tv.”  Ruby is NICE.  It’s like PERL grown-up, without the awk acne:    The language just falls away, and you’re dealing with the problem at hand.
• Backend framework (tie):  Rails 4.x or Grails 2.x.  Yeah, I’m not taking a position here.  If you’re playing with the JVM ecosystem, Grails is the obvious pick.    Rails is (and remains) a breath of fresh air, especially with the tools that go with it:  Bundler, Berkshelf, rbenv.  Moreover, there’s a frenetic vibrancy in the Rails community that’s infectious.   Maddening–sure–but infectious.
• Browser: Chrome.  Frau Perry croons, “We fight, we breakup, we kiss, we makeup.”  Chrome makes me uneasy the same way IE 5 did back in the day–it’s becoming a monoculture, and Google’s starting to get evil with it.  Still, it’s fast and its fundamental architecture still has Mozilla’s Firefox playing catchup.
• Source Control: Git, specifically Github and Github:Enterprise.  Pull Requests and social coding have changed how developers work in the last 5 years.
• Mobile: None.  I was a phandroid, but I’m still on the smartphone wagon for 1 year and 6 days now.  I’m not first in line for a mobile development position, but there’s enough left in server and web development that I think I’ll be okay.
• Social Media:  Twitter for short-form and Facebook for long-form.   Facebook’s just inescapable if I want to interact with family, friends, and church.  They seem intent on running everyone away, but the simple network effect keeps everyone there.  I much prefer twitter, but understand not everyone can stand it, particularly since they went public and started screwing with everyone’s   Google+ is dead, and has been since 3 months after it launched.  Google should merge it with Youtube (the perfectly good social network they already had) and be done with it.
• Miscellaneous: Vagrant, Chef, gvm, Github Pages, Jekyll, Markdown, npm, 

/Stream-of-consciousness

Ramping on a new project is fun!

Actually, it resembles lighting yourself on fire, running and jumping onto a moving train with jugs of water on it, only to discover the first car has flammable liquids, then the next car, then the next.

Restated: It’s never boring.

So, I’m collaborating with a team writing in Rails 4, and that team’s adopted the 12 Factor App religion. Great!  I’ve dabbled in heroku before, and it’s neat to see apps written that way from the first git init.

You’ve gotta love social scientists.

In the ongoing quest to squeeze every ounce of productivity from the burnout-destined drone age 20-to-40, they’re studying ways to measure collective intelligence.

Quotable quote:

Right now, the optimal size is probably somewhere between five and 10, but with the right collaboration tools, you could imagine having a group that kept getting more intelligent, up to 50, 100, or even 500 or 5,000 people. 

::sigh::

Okay, be proud: You’ve got your name on the company, and you’re the centerpiece of this spiffy article.  What you’re trying to do, though, it surmount human biology:  We can keep 7 +/- 2 ( that is, anywhere from 5 to 9) things in our active memory at any one time.  Whenever you go above that number, we forget.  Managing over that many relationships day-to-day simply creates overhead.

So, here we are 3 years later.  

In 2011, I saw my name on a weird spot of an organization chart, 3 levels up from where it had been.  I was reporting to a Director (soon to be a Vice President) and my title was ‘Architect’.

I went through all the phases of grief:

• Shock: “Wow, look at all this stuff I need to understand!  I can do anything I want…”
• Anger: “I’ve just butted heads with most everyone in power at my company.  I can’t do anything I want.”
• Bargaining: “Maybe I can balance all this crap with things I like to do.  I can do something I want.”
• Acceptance: “There’s an huge pile of work.  I’m spread paper thin. I can do a little bit of what I want.”

During that time, I expected to live at all levels:  High-level strategy, designing new systems, coding, support/sustainment, etc.  I felt excited, because we needed help in all those places, and I thought I could do it all.

Way back in 2004, I wrote a short review of Tate’s Bitter Java

Basically, when this book appeared, Java was ~8 years old, and was at the peak of its hype cycle.   Embraced by both the enterprise software world (okay, IBM) and the nascent open source community, Java was the golden hammer, fit for any problem.

Except, it wasn’t.

People who could program, but who weren’t familiar with domain requirements began writing Enterprise Software, and they began making a mess of it.  My own company had to write-off about $7.4 million on a “failed software project” back in 2003.  Suddenly, the C-levels stopped saying “Maybe we should rewrite our stuff in Java.”  Historians term such retrenchment the Thermidorian Reaction, predictable after every revolution.  For us in the industry, it was the heart of the doldrums between the Y2K largesse and the onslaught of Web 2.0.

There’s been much discussion lately on the web about the dismal # of women choosing Computer Science.  I thought I’d go straight to the source and ask, you know, a woman, who did not choose CS.

My wife.

Her theory on gender imbalance in CS.  (I had to transcribe as quickly as I could, and I’m not sure I quite caught the spirit of it all)

It’s stupid.  You don’t make anything tangible.  When I think of Computer Science, I think of greasy gamer nerds who want show off for their greasy gamer nerd friends.  

So, Zappos announced that they’re moving their whole 1500 person organization to ‘Holacracy’.  Why?  Ironically, because of an autocratic decision by the CEO:

Last fall, while exploring ways to scale Zappos without letting bureaucracy set in, Hsieh met Brian Robertson, the founder of the management consultancy HolacracyOne. 

Ah, this is classic:  The CEO gets sold some snakeoil, the troops have to drink it.  So, what is ‘holacracy’.  Is it like ‘democracy,’ ’theocracy,’ and other terms that’ve been with us since antiquity? Nope. Some guy invented it out of whole cloth.

So, I broke down and took one of the online courses offered at my work on Project Management basics.  I kept hearing domain language from managers, former project managers, and true project managers from our other (non-software) function.  I wanted some info on their thoughts and methodology.

So, during that, I had a light-bulb moment:  Agile software has no project managers.

Seriously.  Back-up and read that sentence.  They don’t exist, and if that gives you the heebie-jeebies, keep reading.  If you have agile and project managers, then you’re doing it wrong, at least as nearly as I can tell.