- To get the URI-map (A map of how to call the service for all resources)
- Actually make the call (Using the above map)
- What? There’s a 3? Yup, that second call could return another URI-map
- It could continue
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.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.
— Pete Holmes (@peteholmes) September 14, 2014
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:
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.
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
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.
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.
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 Tripp, Matt Pyra, Eric Johnson, Jonathan Howden, and I) meander through quite a few topics. Here’s a breakdown by time of the various topics:
01:27 Backstop’s 2 day bug bash
02:00 The apprentice has to tackle a 10 year old Java program
06:22 “Everything needs to have an ID if you’re going to make it Hibernate-y” - Jake “super technical” Scruggs
08:21 Why we call Backstop “Fund Butter” within the company
10:50 The apprentice encounters Selenium
12:42 Troubles with regression/integration testing through the web browser.
13:43 “Unit Testing is Dead” - DHH
20:00 Pairing all the time vs code review
21:51 Toby talks about the Hill Air Force Base pair programming study mentioned here: http://www.informit.com/articles/article.aspx?p=29410
26:40 The Wall of Awesome - Backstop’s way for employee’s to recognize and thank other employees
47:21 The anti-college movement
49:36 The “Expose your ignorance” apprenticeship pattern with examples/confessions from Jonathan, Jake, and Toby
51:14 The C3 project comes up with near 100% frequency when >= 2 die hard XP'ers are in the same room.
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% supervision as he will always be pairing with an experienced developer. It’s a six month program with 2 month check-ins.
The apprentice, Jonathan Howden, knows that should he fail to meet expectations we may end our relationship at 2, 4, or 6 months. This is a bit scary, but if Backstop is going to be taking a chance on an un-credentialed employee we, as a company, need to be able mitigate the risk of such a person polluting our codebase. It is therefore our responsibility to provide constant feedback to the apprentice so that he will know exactly what is needed to succeed. So far he’s been doing great: He just finished his 3rd week of apprenticeship so we just recorded our third podcast and will be on a weekly schedule. Assuming he survives the six month apprenticeship, Jonathan will be offered a full time job at a damn good starting salary. Interested in such a job right now? Check out https://careers.backstopsolutions.com/
In the first episode, Jonathan talks quite a bit about Dev Bootcamp (DBC). I’ve known, worked with, and read the book of one of the founders so it seemed natural to reach out to Dave Hoover and DBC to help Backstop find its first apprentice. We asked their “fairy job mother” to spread the word that we were looking for apprentices and ten applied. They were all given coding homework challenges which were evaluated code review style with the whole InvestorBridge team allowed to attend. We judged three submissions good enough to warrant an in-person interview. Jonathan made it through this gauntlet and was rewarded with a brand new, much longer, gauntlet. Of learning. Look, there's no way not to make this sound hokey as we're trying to do a good thing here.
On a weekly basis I hope to capture what an apprenticeship is from the inside and perhaps provide some value to proto-developers and prospective mentor companies who may be wondering what this “apprenticeship” business is all about. Changing careers is, like it or not, the future. I did it in 2004 and I hope Jonathan will too in 2014.
Software Apprenticeship Podcast:
iTunes Page: https://itunes.apple.com/us/podcast/software-apprenticeship-podcast/id868371146?mt=2
RSS feed: http://softwareapprenticeship.libsyn.com/rss
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 teacher I took a bunch of education courses. I got good grades but when I got into the classroom to actually teach I flailed around just trying to keep the class under control and mostly forgot to apply the principles I had learned. The knowledge was in my head, but it floated, disconnected, from anything in particular. When I learned these ideas I had no teaching experience, and so, nowhere to place these abstract principles.
SICP’s first chapter explains the basic form of Scheme (a Lisp), some basic operators (+, -, *, /, etc), defining/calling a function, different ways a compiler might evaluate code, and conditionals over the course of a few short pages. That’s a bit much to swallow all at once, especially the comparative evaluation stuff but that should be easily sorted out with some examples. Right? Well, that’s not really SICP’s thing. SICP will give you a few trivial examples and then toss you right into the deep end. Then first 2 problems for the reader are pretty easy, but it’s the 3rd that will let you know what yer in for: “Define a procedure that takes three numbers as arguments and returns the sum of the squares of the two larger numbers.” Which seems pretty easy until you realize there are no variables. You’ll need to figure out an algorithm that can take 3 numbers and, without any intermediate state storage, return the 2 biggest numbers in such a way that you can sum their squares. I’ll be real honest here, after about 30 min of trying to do this (I have zero functional background so I’m a complete novice here) I gave up and tracked down the answer online. Of course the answer was simple and concise and made me feel like a chump. Which is fine, but not really what I was expecting in the first chapter, let alone the 3rd problem of the entire book.
But that’s what SICP is all about -- challenging problems. The rest of the chapter introduces Newton’s method for square/cube roots and lexical scoping just for fun. Chapter 2 is recursion vs iteration in terms of execution speed, resource usage, and transforming from one to the other. Logarithmic, linear, and exponential growth are dealt with in a few paragraphs and then we’re off to Exponentiation, Greatest Common Divisors, Primality, and implementing Fermat's Little Theorem for probabilistic prime determination. My favorite question from chapter 2 asks the reader to formulate an inductive proof that Fib(n) is the closet integer to ((golden ratio)^n)/5.
Which brings me to another criticism of SICP: It assumes a familiarity with math that most people just don’t have. A first year MIT student would probably be swimming in math classes so the book assumes that knowledge on the readers part. Abstract programming principles can be very difficult to find examples for so I’m sympathetic to the plight of the authors, but when you just go straight at math you’re explaining an abstract thing with another abstract thing.
There’s a certain sort of person who gets excited by complicated abstract but internally consistent logic with no real connection to the concrete. In my experience as a physics teacher, these students do exist but are very rare. Most people need a bit of connection to something tangible in order to have the ideas connect in their brain.
What then is my point about SICP? Simply that its explanations are overly terse and its problems are large steps past what little is explained. In light of those things I have recommendations for those who attempt to work through it.