Jake Scruggs

Hearing that David Heinemeier Hansson had slammed microservices in his Rails Conf 2015 keynote was a bit disorienting as I was developing a microservice at the time. I leaned over to the other senior developer and said: “What’s his deal?” Toby Tripp, who had just watched the keynote, explained that when David’s team implemented microservices they had terrible trouble managing all the versions between 3 systems. “Isn’t that why we use a lookup call to get the URI-map?” I asked. “Yep” he said. “That and never remove a return key/value (pair), only add new ones until you can prove they are not used anymore” He added. I returned to adding in some caching to our service calls.  Later, I watched the video which is here: https://www.youtube.com/watch?v=oMlX9i9Icno David has a meandering style but he mostly discusses microservices between 43:00 and 52:00.  The “what’s in your backpack” stuff is all about his earlier zombie apocalypse metaphor that you...

Recently I re-tweeted this thought from Pete Holmes: top reasons for divorce. 1984: 1. financial problems. 2. religious differences. 2014: 1. constant inclusion in group texts. 2. no wifi. — Pete Holmes (@peteholmes) September 14, 2014 because I'm in the middle of a communication crisis.  I do "knowledge work" so it’s considered inappropriate to have a device constantly making little beeps and boops while the person next to me is working on some insane LibXML (you don’t wanna know) bug.  Programming requires extreme concentration and distractions are to be avoided.  The rub of it is that I’m “on call” if our software product bursts into flames.  Therefore, I must keep my phone in a mode capable of disturbing me so I don’t eat lunch, play ping-pong, or just code right through the disastrous failure of our software.  This used to be fine back when text messages were either: Time sensitive Important From one person In first two cases the beeps ...

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

This week we start off by throwing Jonathan into the deep end of pool where he pairs with an experienced developer on a 10 year old Java project that is the core of our signature product: Backstop.  Of course the company is called Backstop Solutions and so, in order to avoid confusion, we gave the project a different name for internal use:  Fund Butter.  The mystery of how such a terrible thing came to pass is revealed in this very episode. There’s no way we couldn’t discuss DHH’s Rails Conf declaration and blog post: “TDD is dead. Long live testing.” This, of course, leads to a discussion of our team’s test philosophy. You can find it on iTunes (search for Software Apprenticeship Podcast), any podcast app’s search function, Google, this temp page: https://itunes.apple.com/us/podcast/software-apprenticeship-podcast/id868371146 or use the RSS feed directly if your into that sort of thing: http://softwareapprenticeship.libsyn.com/rss Our panel (composed of Toby Trip...

In the summer of 2004 I did an apprenticeship of sorts at a place called Object Mentor.  At the time “Uncle” Bob Martin and his son Micah Martin were in leadership positions at the company and I somehow convinced them to let me work for free over the summer in exchange for teaching me software development. It wasn’t a very structured program, nothing like what Micah would later put together for 8th Light , but I was a pretty motivated learner.  I also had the advantage of coming from a teaching background so I knew how to learn. All this has been covered in daily detail, if you'd like to read more. After ten years of software experience I’m becoming a mentor to an apprentice and documenting the experience via podcast.  Backstop Solutions has graciously allowed me to pay our apprentice (the same rate we pay interns) as he is doing real work on a daily basis in addition to outside learning experiences.  From 9-5 he will be working on production code with 100% supe...

The number of software luminaries who sing the praises of “ Structure and Interpretation of Computer Programs ” (referred to as SICP) is such a long list that you might think only a crazy person would take issue with it. However, to ignore SICP’s problems and continue to blindly recommend it seems just as crazy. SICP was the textbook for MIT’s introductory programming class and was a bit of a departure from other into to computer science textbooks at the time.  Wikipedia sums it up nicely:  “Before SICP, the introductory courses were almost always filled with learning the details of some programming language, while SICP focuses on finding general patterns from specific problems and building software tools that embody each pattern.”  Which sounds awesome, but does essentially say that abstract principles will be introduced before the nuts and bolts of a language.  If you think about that for a minute, you may see where the problems will be. When I was training to be a...

My last commit to MetricFu was March 2...  of 2011.  So. much. shame. Since I am throwing in the towel and handing over leadership (perhaps to you), I thought I should explain why I've been such a terrible maintainer and why I'm walking away. Reasons: 1). MetricFu is a mess.  At some point, with all the submissions coming in, the architecture and testing got away from me.  Now it's pretty depressing to see crap code quality in an app that is supposed to be about good code quality.  I can not overstate how embarrassing and frustrating this is – mostly because it's my fault (I let in things I shouldn't have. Stupid feature blindness). 2). In 2008, when I created MetricFu, I was fascinated by metrics and now I'm not because I don't need the tools to see the problems anymore.  Metrics made me better but now I'm leaving them behind:  Selfish. 3). I'm not a consultant at the moment so the exploratory nature of MetricFu isn't very useful t...