Jake Scruggs

writes ruby/wears crazy shirts

Episode 4 “Time to Exercise!” is out right now! Search for it on your favorite podcast app or check out our free temp website here: http://softwareapprenticeship.libsyn.com

With 4 weeks under his belt (plus 9 weeks of Dev Bootcamp) our apprentice, Jonathan Howden, continues his quest to become an enterprise software developer at an amazingly rapid pace.  Can a dedicated man become a good developer without a college degree?  Tune in and find out (spoiler: he’s doing well but it’s intense) 

Topics this week:

  • Doing push-ups to break up the lethargy of coding
  • Migrating from Authlogic to Devise/Warden and the perils of using a framework’s column in the database for activation.
  • Why senior programmers avoid becoming mentors
  • Rails’ Asset Pipeline  
  • The usual screwing around and one censored F-bomb (sorry - it was me).

Yesterday we all sat in a room and reviewed Jon’s chess code (his outside of work coding project).  I’ll try to put up a more detailed article about it soon, but in brief it went well.  It’s fun to watch a junior developer try to encode all the crazy logic of chess while keeping the code clean, tested, and understandable.  Other than making the classic mistake of mocking/stubbing the very object he was testing, Jon has some pretty readable code that will “mostly” let 2 people play chess against each other.

Episode 5’s in the can (on the SSD?) and we’re recording episode 6 later today with Dave Hoover, co-founder of Dev Bootcamp.  Jonathan attended Chicago’s DBC in September of 2013 so Dave will get to check in with how Jon is doing in the “wild.”  Also, Dave and I worked at both ThoughtWorks and Obtiva together so it should be quite an interesting conversation.

I really wanted this to be a weekly podcast but here we are at the end of the 9th week and only recording our 6th ep.  Now that we’ve been through the recording and editing  process a few times it should be easier to stick to a weekly schedule.  Even if we weren’t recording the conversation I would still have a weekly wrap up with members of the team and the apprentice — it is a very nice way to sum up the week and lessons learned.  It's sort of a weekly, recorded, low stakes retrospective.



The views and opinions expressed here are my own and don’t necessarily represent positions, strategies, or opinions of Backstop Solutions Group.

The views and opinions expressed here are my own and don’t necessarily represent positions, strategies, or opinions of Backstop Solutions Group.

Recently we released episode 3 of the Software Apprenticeship Podcast but had to pull it back for re-editing because of some problems with how developers talk to each other.  Developers are not kind to ANY code.  Even our own.  Especially our own.  Sitting next to a dev while he or she discusses the code they are working on can be a shocking experience.  Words like “Crap,” “Junk”, “Garbage” and many worse are used often.  A lot of this type of talk was on episode 3 and when someone at Backstop (who’s job it is to protect us from ourselves and comments taken out of context) heard it they asked us to edit the podcast to take out some of the more offensive comments. This is why episode 3 sometimes fades into music and then comes back mid-conversation.  Sorry about that.

I don’t know where I first heard the definition of developer as “Whiny Optimist” but it is uncannily accurate.  We developers are forever complaining about previously written code.  Code is awful. Code is crap.  Code is the worst spaghetti wrapped around horse manure we’ve ever seen. 

And yet…

We couldn’t go on if we thought we’d have to live out our lives fighting the very thing we create.  There is this optimism about future code.  It  will be bright and shiny.  The next project to re-write the is going to make everything better.  So much better…  The code will be pristine and new features slide in like rum into coke.  Ponies and rainbows are coming.

Also…

Every year I get better at what I do, so even code I thought wonderful 3 years ago can be “crap” to me today.  I look back and see a developer who didn’t keep orthogonal concepts separate who coupled code that should not be coupled and I am sad.  I regret my past inefficiencies and curse them.

But…

How bad is this code really?  Backstop’s code is rigorously tested many times automatically before being poured over by humans.  Any code change in my product gets tested first on my machine (by automated tests) then on another “Build Server” (which runs the tests I was supposed to run and a bunch more), then another series of “Regression Servers” will run some even longer regression tests that literally use the app as our customers do.  If it passes all that then we’ll have our Quality Assurance people go over it again to make sure the machines haven’t missed anything.  The last thing the Q.A. people do is write a new automated regression test to make sure this functionality doesn’t break in the future.

What the heck are we complaining about then?  The software works!  It helps many people make a lot of money, it makes the company money, and is a leader in the industry.  We developers are, in some ways, a bunch of ungrateful jerks.

Let me see if I can explain why.  Writing software that solves hard problems is hard.  Duh. There are only so many people who can do it and we struggle through.  Writing software that solves hard problems and can continue to accept new features easily is the HOLY GRAIL of software development.  Rarely has it been done even though every company claims their code is the “best in the industry.”  If you were to get your hands on the unedited version of episode 3 you would hear a lot of developers complain how we wish we had written code in the past that could be easily changed today.  We might even call such code “garbage” but what does “garbage” really mean?  In our app it has come to mean code that works, is well tested, but resists change more than we would like.  We are whining about having to do more work.  If only our past selves had properly separated the concerns more, if only there was more time for refactoring.  But some day we will reach that shining castle on the hill.  And there will be ponies and rainbows for all.