Noel Rappin Writes Here


More Lessons Learned

MeNoel Rappin1 Comment

Last year, when Obtiva was purchased by Groupon, I wrote a "what I learned" post talking about things I thought I came to understand about software projects after working on a bunch of them. Now that I've moved on from Groupon, I started to think about what, if anything, I learned while I was there.

I keep coming back to three different things -- this is a more personal set of lessons than the last batch, so maybe they'll be less generally useful. Maybe not, though. Think of it as a little long-term career management advice.

These are all things that I think I kind of knew going in, but there's knowing something and knowing something, know what I mean?

Also -- nothing here is meant to say anything against Groupon Engineering -- I freely admit that what I'm talking about are issues of me managing my life and time.

Coding is the Input to Everything I Do

I like coding. (I thought I'd start with something controversial…) I like it a lot. That said, I've never been the guy who needed hours more coding in his week above and beyond work. For most of my professional career, my personal projects have been writing projects. And while I love to continually learn new things, it's been a long time since I felt the need to forgo sleep to do so.

Groupon was the first time in my professional career where coding was not a primary responsibility -- my primary responsibility was organizing training. And I'll stipulate that I went into it eyes open. It sounded pretty good. No coding project deadlines, and I love to teach. A room of students who have to listen to me sounds good.

At first, I was actively building the curriculum, that was pretty good. Then there was less curriculum work to, and in for reasons that I don't really need to detail, the things asked of me became a lot more administrative. The point is that as I got further away from everyday coding, I felt like I got less good at all kinds of things that I want to be good at. I didn't have interesting problems to blog about, I wasn't learning new things as much. I felt less credibility as a teacher and speaker as I got a little removed from practice. Combine this with my occasional tendency toward impostor's syndrome, and things got less fun quickly.

There were options available to me at Groupon that I chose not to take for reasons good and bad. The main point for me is that by the time I realized what I was losing, it was hard for me to feel like I could get it back. The point for you, I guess, is to be confident in knowing what you like to do and what parts of your work are satisfying. Know what you need to have as your inputs to be successful over the long term.

Big Companies are not Small Companies.

I know, duh.

I've joked for years about "big company problems" vs. "small company problems". In a small company you have to maintain the CI server yourself. In a big company, there's a whole IT department, but it takes you six months to requisition a CI server. (True story, at Motorola. Also they told me the CI server was causing too much network traffic, and did I have to run it after every checkin.)

There are two structural issues at big companies that have tended to drive me batty. The first -- that people are often making decisions about other people who they don't know and only have a dim idea of what they do -- was not a major issue for me at Groupon. The second -- that big companies tend to encourage people to specialize -- decidedly was.

I want this post to be about me, not about them. So here's a related story: when I first entered the job market, I wound up with two serious offers, salary identical. One of them was at Nokia, for an R&D department in Boston where I would have done usability research tangentially related to what I had been doing as a grad student. The other was what we'd now call a small web consulting shop, 12 people or so separated between two cities. I'd never done any web programming. They had done only a little bit more (they thought of themselves as documentary filmmakers by trade). When I went for my interview, the CEO of the company was vacuuming the floor of their 2-person Boston office.

Obviously I went with the tiny company, which even as I type this sounds kind of insane. And while I'd love to say something self-serving about how I picked the job that scared me, I don't think that's true (both jobs scared me). I do think, though, that I was excited by the prospect of doing a lot of different things. Which I did, the job turned out to be a kind of immersion in the entire lifecycle of software projects in the way that pouring ice water on somebody's head is kind of a way to get their attention.

Ever since, I've been happiest when I've been able to do all kinds of different things on a regular basis. Big companies, of course, tend to specialize because they need to, and because they can. Once you have 200 developers, suddenly you can spare somebody to be full-time in charge of improving training. (Well, almost full-time…) Which sounded great, for a while, but then, see point #1. I flatter myself that I do a lot of things well, and whether that's true or not, I still want to try to do a lot of things.

Introversion and local maxima

This one is a little tricky and it's really a personal anti-pattern.

Look, I'm in introvert in the classic definition. Every time I've taken a Myers-Briggs test, I bury the needle for I and N. On a day to day basis, one thing this means is that, while I usually like my co-workers (and my Obtiva/Groupon collegues are an outstanding group of people), I'll often choose, say, eating at my desk over going up to a group in the lunchroom and joining up with a group of people.

On a related note, for most of my last six to nine months or so at Groupon I was a team of one. Then the person I reported to left, and I wasn't even reporting to anybody else in Chicago. I swear this is true -- I was literally sitting in a corner with nobody on my two orthognal sides. I'm saying I was a little isolated. I'm also saying that of course I could have handled it better. That's part of my point -- one thing I learned is that what seemed like the best thing to do on a day to day basis, ended up being isolating in the long term. I would be able to go large chunks of a day without interacting with co-workers. Even a staggering introvert like myself has limits.

What does it mean?

Dunno. Just being a self-indulgent blogger. I expect most of you to read this, roll your eyes and say "Duh."

I do know that I've spent most of my six weeks at Table XI coding and helping run a small web project. I know it feels great even when it gets weird. It feels like I'm using muscles that got a little rusty. (I'd have some technical blog posts for you, but I'm backed up with the book. Coming, I promise.

Table XI provides lunch in house every day, which makes it a lot easier to actually talk to co-workers. Which is good. (I realize this lunch thing sounds totally insane to a significant percentage of you. I'm okay with that.) During my first week, I had a meeting where we planned out what kinds of things would happen as part of my first few months. One of my cards was "do something new". I don't know exactly what yet, but it's important to me to keep moving forward.

Thanks for listening, I hope you will, to paraphrase Tom Lehrer, find this valuable in bizzarre set of circumstances some day.

What's Up?

MeNoel RappinComment

Oh yeah, things happening…

Got A New Job, Got A New Office

First off, I’ve started a new job as a Senior Developer and Agile Coach at Table XI, putting me back in the realm of small, Chicago-based consulting companies. Very exited, Table XI seems like a great place so far. Hoping to do new things, challenge myself, and learn.

Book Update

Most importantly, you can still buy it.

It’s going slowly but steadily, thanks for asking. I’m determined to start releasing weekly even if it means that I cut off the book in mid-sentence. Hoping that will start next Monday. The remaining Backbone chapter is something like 1/3 to 2/5 done.

Next up, Ember. I was already placed on a blog post of Ember.js resources, which is quite flatteringly optimistic given that the Ember stuff doesn’t technically exist yet. A couple of members of the Ember team have reached out and offered some technical assistance, all of which is very nice, and motivating, and terrifying.

Anyway, the Ember stuff is going to be interesting because, first off, Ember is still a rapidly moving target. I had hoped they’d have locked down a 1.0 API by now, but given the comments made on the recent JS Jabber podcast, it looks like we still have some movement coming. Also, it seems as though the nature of Ember implies a more complex example to really show it off. Still hopeful that I’ll be able to start pushing out Ember content in December, though.


The video from WindyCityRails is now up, as well as the slides from the evolutionary decendent of the talk from RailsConf — the RailsConf video should be up in a couple of days. There’s a blog post in progress exploring the common theme of those talks, as well as a couple of speakers at SCNA who came at similar themes.


JavaScript, Me, self promotionNoel RappinComment

Here’s what I’ve got.

2 chapters introducing jQuery and Jasmine via a walkthrough of a simple piece of JavaScript functionality.

1 need to convert all my text from its current proprietary format to something more Markdown based.

1 genuinely silly conceit tying together the application that gets built in the book. And I mean that in the best way. It should be silly, there’s no reason not to be bold. There is even a twist ending. I think.

1 slightly dusty self-publishing tool chain that converts a directory of markdown files into HTML, with syntax colored code. It’s possible that there’s a better library for some of the features these days.

1 chapter on converting that simple piece of jQuery into various patterns of JavaScript object. I quite like this one, actually.

1 website, which is currently hosted by WordPress – at one point, I had to abandon the site that actually sold stuff, and WordPress was easy. I think I’ll need to upgrade that a bit.

1 Intro chapter covering JavaScript basics and the Chrome developer tools. Not sure if this is at the right level for the audience I expect.

1 Prince XML license for converting said HTML files into PDF. No idea if that’s still the best tool for the job. Or even if my license is current.

1 chapter on building a marginally complex auto complete widget in jQuery and Jasmine. I like this example.

1 copy of most of the book’s JavaScript code in CoffeeScript. Not sure when I thought this was the right idea for the book, beyond an excuse to use CoffeeScript.

1 chapter on jQuery and Ajax.

0 toolchains for generating epub and mobi files. I know I can find this.

1 case of impostor’s syndrome, not helped by rereading the harsh review of Rails Test Prescriptions on Amazon. That was dumb, why would I do that?

1 chapter on using JSON. As far as I can remember, this chapter never went to edit.

3 people who mentioned on Twitter that they’d buy a self-published book. Don’t worry, I won’t hold you to it.

1 plan for writing 2 or three chapters on Backbone.js

5 people who reviewed the last version who I feel should get free copies when this comes out. It’s not their fault.

4 viewings of Ze Frank’s “Invocation for Beginnings”

So. Ready to go. Watch this space.

A Brief Announcement About A Book

JavaScript, Me, self promotionNoel RappinComment

So… The JavaScript book that I had contracted to do with Pragmatic will no longer be published by them.

I need to be careful as I write about this. I don’t want to be defensive – I’m proud of the work I did, and I like the book I was working on. But I don’t want to be negative either. Everybody that I worked with at Pragmatic was generous with their time and sincere in their enthusiasm for the project. Sometimes it doesn’t work out, despite the best intentions.

I haven’t spoken about this project publicly in a while because it was so up in the air. And also because I’m not sure what to say about it without sounding whiny or mean. And also because I was afraid of jinxing things, which is obviously less of an issue now.

Since November, the book has been in review and I’ve gone through a few cycles with Pragmatic trying to get things just right. The issues had more to do with the structure and presentation of the material then of the content or writing itself. I’m not completely sure what happened, but I think it’s fair to say that the book I was writing did not match the book they wanted in some way or another.

Anyway, that’s all water under the bridge. I have full rights to the text I’ve already produced. Self-publishing is clearly an option, though the phrase “sunk costs” keeps echoing in my head. It’s hard to resist the irony of starting with a Pragmatic contract and moving to self-publishing after having done it the other way around with Rails Test Prescriptions. I’m hoping to blog more – in addition to being a time sink, not being able to write about this book was kind of getting in my head about any blogging.

Thanks for listening, and watch this space for further announcements. I was excited about this project, and while this is disappointing, I’ll be excited about it again in a few days. Thanks to the people I worked with at Pragmatic for the shot, and thanks to all the people who have been supportive of this project.

Coming Soon: Getting Things Done In JavaScript

Books, Jasmine, JavaScript, MeNoel Rappin5 Comments

Okay, the blog has been very quiet for the last month or so. Please be polite and pretend you noticed. I’ve alluded online to a new book one or two places and now I think it’s far enough along that I can mention it in public without being too scared.

Let’s do this Q&A style, call it an infrequently asked question list…

Q: What’s the new book?

A: Great question. The working title is Getting Things Done In JavaScript. That may not be the final title. My proposed titles, Enough JavaScript to Get By and JavaScript for People who Hate JavaScript were (rightly) deemed unsuitable.

Q: Okay. That’s the title. What’s the book?

A: Here are some excerpts from my proposal:

  • The intended audience are developers used to doing back-end development, probably but not necessarily in Rails, who are increasingly asked to move functionality to the client, and are not familiar with the best JavaScript tools available for the job.

  • This book is aimed at developers who are explicitly working on front ends for web applications and looking for guidance on how to approach the simple parts first and the complex parts as needed. In my head, this is triangulated with three non-JavaScript books that I think are around that level: Beck’s Smalltalk Best Practice Patterns, Olsen’s Eloquent Ruby, and Valim’s Crafting Rails Applications.

  • Everything is test-driven. This book will contain more Jasmine than a Disney princess convention.

Does that help? Put another way, it’s the JavaScript book I wanted to hand our last apprentice when he asked for a good guide to JavaScript. Another way I’ve described the audience is people who have poked at JavaScript a few years ago, just got back into it, and aren’t quite sure why everything is an anonymous function these days. I’ve also called it JavaScript: An Idiosyncratic Guide, as in the thing you use after you have the information in the definitive guide.

Q: Why a book on JavaScript?

A: Because I was a guy who poked at JavaScript a few years ago, just got back into it, and wasn’t quite sure why everything is an anonymous function these days…

Well, that’s part of it. I felt like it was an area where I had something to offer, and where I could leverage the time that I had spent getting back into the latest and greatest JavaScript tools and make it easier for others to do the same.

Q: When can I buy it?

A: The initial draft is maybe 1/3 done. Ish. The hope is to get it available in beta sometime in November, and given the schedule that Pragmatic likes for books these days, to have the final come out something like January. That’s still an aggressive schedule, and I’m probably just a smidge behind, but I have a decent idea where I want it to go, and I’m making steady progress.

Q: What’s actually in the book?

A: The outline is still a bit in flux, but the basic idea is to take a pure server-side application and bit-by-bit move features to the client-side in a slow and not-even-a-single-tiny-bit-contrived way. The JavaScript topics are largely focused on creating what passes for objects, so there’s discussion of the object model, functions and scope, and the like – it’s not (at least at the moment) a tutorial on the basics of JavaScript. There’s a lot of jQuery, and a lot of Jasmine, and there will also be jQuery UI, jQuery Mobile, and Backbone.

That’s the story. Coming soon to a theater near you. Hope you like it.

What I Learned

Me, ProjectsNoel Rappin9 Comments

As you may have heard, Obtiva got bought by Groupon. I’ve been traveling a bunch, so this coming week is my first full week in the Groupon office post-transition. And, well, someday maybe I’ll write retrospectively about Obtiva, but today isn’t that day. I’ll probably write about what I’m going to be doing at Groupon, but today isn’t that day, either.

Instead, I realized that month marks four years since I left Motorola and became a Rails consultant. In that time, I worked, for some definition of worked, on over a dozen projects and probably watched at least another dozen from down the hall.

I must have learned something, right?

I finished out this post, so I guess that means that yes, I do think I learned something. Here are a dozen or so oversimplified, fortune cookie-esque things that I think I learned in the last four years. Some of these are probably blog posts in their own right, which I may get to one of these days.

  • It’s a hallmark of successful engineering teams that they understand that if you do not need to make a decision, then you need to not make a decision. That’s sometimes called “preserving ambiguity”, and I remember from back in my days studying engineering education that it’s a hallmark of successful engineering teams across disciplines.

  • One reason why preserving ambiguity is necessary is that if you get too concrete too soon, then early decisions have a kind of gravity that makes it hard to escape them even when it’s best to explore the problem space more fully. A couple of times in the last four years, clients have come in with polished visual designs, and even if the layout and structure doesn’t work at all from a functionality or usability standpoint, it’s hard to escape the concreteness of the design to find a better design or a better definition of the project.

  • There’s very little that damages a team dynamic more quickly than trying to measure and compare individual contributions. (Technically, I learned this one at Motorola, but it still applies…) On a larger project, measuring subteam contributions also qualifies as problematic.

  • One thing you absolutely must have when coming out of your initial project meetings is a list of things that are not part of your project. Again, a common client pattern was trying to be the “YouTube of X” and the “Facebook of X” and the “Twitter of x”. Pick something to do well and do it well.

  • You can’t escape the software triangle, of scope, budget, and schedule. Keeping a project on track means saying “this is out of scope”, or “okay, we can do this, but that means something else needs to move out of scope”.

  • Hiring is so, so important. I once heard it said that the secret weakness of Agile was that one sociopath could ruin an entire project. That doesn’t mean “just hire your friends”, but it does mean that being able to work as part of a team is important.

  • If the business/management team and the development team trust each other, than almost any process works. If they don’t, almost nothing can fix it. One advantage of Agile methods is they provide a lot of quick, easy, and early opportunities for each side to show trustworthiness. (There’s definitely a longer post in this one…)

  • Because, ultimately, for a lot of our clients, working with developers is like going to the mechanic. When the mechanics say that the fitzelgurbber has been gazorgenplatzed, and it’s 500 bucks, do you trust them? Why or why not? How do you apply that back to your day job?

  • The development team’s job in an Agile project is to honestly estimate the cost of things, it’s the business team’s job to honestly estimate the value. Don’t cross those streams. It’s bad.

  • Agile is about managing change, not continuous change. If anybody on your project tries to justify a change with something like “we’re agile, we can change anything whenever we want”, run for the hills.

  • I didn’t say this, but I remember hearing it a few years ago. The right amount of process is just a little bit less process than you need. In other words, the slight chaos from too little process is much preferable to the overhead of too much process.

  • Look, I’ll admit that those of us that identify as software craftsmen sometimes get overly precious with our naming conventions and of course delivering business value is the number one priority. That said, if you are on a project and are being told to do less than your best work for the good of the project (by not testing, or by incurring too much technical debt), that should at the very least be alarming.

  • Pair programming has more overhead than is often acknowledged in Agile literature. I find that, especially on a small team, keeping a pair in sync time-wise is very hard. That said, I don’t have a better solution for code review yet.

Can’t wait to see what I learn this year. A lot of new stuff for me, should be interesting.

Bill James, Sabermetrics, and You, or At Least Me

Books, MeNoel Rappin2 Comments

I was a nerdy kid.

I suppose that isn’t much of a surprise, given how I turned out. But in those pre-computer days, I was nerdy about math and baseball. I was the kind of kid that kept a daily log of my batting statistics in the recess kickball games.

So you can imagine my surprise and happiness when this image appeared in Sports Illustrated, in May 1981. I was ten:

Bill James in Sports Illustrated

The man in the foreground is Bill James, who would soon go on to be one of the most influential baseball writers of the last thirty years. At the time, though, he was self-publishing his baseball book to a small but fiercely loyal group of fans, one of whom actually wrote the SI article.

In the background, on the scoreboard, was one of James’ inventions – a formula called Runs Created that purported to be the most accurate way to measure a baseball player’s contributions.

Okay, I’m getting carried away. The relevant point is that I was dazzled enough by the original article to start looking for James’ annual book once he started getting published and distributed nationally. As I said, I was young, and the books cost like seven dollars of my own money, so this was kind of a big deal.

I got lucky in my choice of baseball writers. Not only was James iconoclastic and funny, but he was very good at explaining his methods. And I don’t mean that he was good at explaining the math – James is the first to admit that he is no mathematician (admittedly joking, he once described the “standard deviation” of batting average as “about what your standard deviant would hit”). James’ skill was in explaining why he did his experiments in a particular way. In a very real way, the most important things I learned about how science works were from reading Bill James.

In, I think, the first book of James’ that I read, he responds to criticism of earlier work:

“Journalists start with the answer… [Sabermetrics] starts with the question”

Sabermetrics, by the way, was the word that James coined for the search for objective knowledge about baseball – “saber” from SABR, the Society for American Baseball Research".

In other words, where a journalist would start with “Derek Jeter should be in the Hall of Fame”, James would start with “Should Derek Jeter be in the Hall of Fame?”, and not in the lazy-local-news-headline way where you know from the question where the answer is. More likely, James would start with “What kind of player is in the Hall of Fame? Does Derek Jeter meet that standard?”

I suspect that this distinction is obvious to most of you reading this (though it’s easy to find places in our public discourse where nobody seems to understand it.) But it was a big deal to 12-year-old me.

Later, I remember an epic dismantling of the phrase “Pitching is 75% of Baseball”, starting with wondering what that even meant, and then going one by one through the things that would be implied of that statement was true, determining that none of them actually were, and eventually concluding that even the baseball traditionalists who were fondest of the claim didn’t act in any way consistent with actually believing it. I can still quote large chunks of that one.

Some quotes didn’t really become meaningful to me until I started writing myself:

“One of the operating assumptions of this book is that you either own McMillan’s Baseball Encyclopedia or don’t care what it has to say. In either case, you don’t need me to tell you what an outfielder’s assist totals are”

I’ve used some variant of that comment for every book I’ve written (though it didn’t always make into the final version). I’ve also used in when reviewing books. It’s a really useful way to think about your audience, to realize that you can assume knowledge of or disinterest in certain information.

Another quote that was big with me when I used to read academic papers all the time, but that I also keep in mind when I write.

“This isn’t a bull session, this is science. I only write like it’s a bull session because I don’t like how scientists write”

James is always been a little cranky on the subjects of professionalism and expertise, which he sees as often being used as nothing barriers to keep out the riff-raff.

“When you write something it is either true or false and being an expert or not being an expert has nothing to do with it”

What’s really stuck with me, though is the way James went about seeking more objective knowledge. The process was simple.

  • Ask a question.

  • Determine something that is observable that would be true if the answer to the question is true.

  • Use small, empirical measurements. James is the king of quick-and-dirty measurements that favor ease of calculation and understanding over multi-digit precision.

  • Compare similar items that differ in one aspect. In the mid 80-s James was more excited about a method to measure how similar two players were than almost anything else, because it allowed him to create controlled studies.

  • Follow the data. You probably won’t learn what you expect. Respect the data and respect its limitations.

If you are interested in James’ baseball work, the best introduction right now is probably the Historical Baseball Abstract, which is an overview of both his statistical methods and his historical interests. A more biographical look at his effects can be found in Moneyball, by Michael Lewis, which is about how the Oakland A’s applied James-style methods to actually win games. It’s a great non-fiction narrative, and Lewis is, as far as I can tell, unusually factually accurate.

James’ most recent book is Popular Crime, which is not about baseball, but rather a historical overview of crime stories that become pop-culture touchstones, and also the books that have been written about them. It’s cranky, scattershot, obsessive, and hard to put down.

Red Buttons, The Uncanny Valley, And BDD Workshops

MeNoel Rappin1 Comment

I want to tell you about LoneStar RubyConf and how my session went and all that, but first I want to tell you this seemingly unrelated story.

Once upon a time, my Senior undergraduate project was an educational software tool I built to teach fractions to elementary school students. (To give you the time frame here, it was written in Visual Basic 1 on Windows 3, and I had to ship my own desktop to the school to ensure that they’d have something I could run it on. Also, I travelled to the school via dinosaur.) Anyway, the metaphor for the program was slices of pizza, and at the beginning of the game, the student saw an uncut pizza on the screen. Times being what they were, I was using the VB graph library to draw the “pizzas”, so a new pizza was represented by a red 3D pie chart, which means it basically looked like a red cylinder.

The first student sits down and starts clicking on the pizza like there’s no tomorrow. I immediately realize that the red cylinder that I had set up to be a pizza looked like a huge red button right in the middle of the screen. I couldn’t possibly have given it more focus – honestly, it looked like it might launch missiles or something. And I know, that even though I had never thought of it in that way, that every student is going to do the same thing and that I’m going to spend my day telling people not to click on the pizza. Which is what happened. And I felt like an idiot – how could I not have seen it before?

Which brings us to my workshop at LSRC, “Correctness is only a side effect: Improving your life with BDD”. Here was the plan:

  • I wanted the workshop to have kind of a code retreat kind of flavor, where the attendees would be able to focus on the pure process without regard for real-world constraints.

  • The idea was that there would be a hands-on code problem, some discussion of how that was done via BDD based on the student’s concerns, then some prepared material based on the topic.

  • The extended example was some kind of restaurant recommendation system, where each restaurant would have a score based on, at first, just ratings, then cuisine, price, location, and so on. The plan was to build up an increasingly complicated score function than show the process of using BDD to refactor it to it’s own scoring engine.

Well, that didn’t work out. Some of it did. The prepared material was decent – I’ve used a lot of it before. A couple of other things happened, of which the most interesting was how the attendees interacted with the problem.

I started by presenting the problem and mentioning that we were going to be focusing on testing a score method, because that was where the interesting logic to test was going to be. We walked through the failing test for initial conditions, did the method returning a literal to make the test pass, forcing a dynamic method with another failing test. So far, it seems to be going smoothly from my point of view. This was quite an advanced group of students – often when I do these workshops at regional conferences, the attendees are on the newer side, but this group was experienced, knowledgable, and already largely bought into the idea of BDD. (Based on earlier experiences, I had pitched the material maybe a little to beginnery for the crowd, causing me to worry if I was presenting any useful information to them at all).

Soon it’s time to break out for the first hands-on example, which is adding some new features to the score function. And the conversation went something like this: (I’m compressing this a bit for dramatic effect…)

Me: And the task is to make recommendations based on cuisine and price. You can do this by filtering a list of restaurants, or, I’d recommend trying to do it by modifying the score function.

Clever Attendee: How do we store the list of restaurants?

Me: Oh. Um. I don’t really care. In a real system the framework would manage that. You can explicitly pass an array of restaurants if you want, or just test the score function for a single restaurant.

Clever Attendee: Okay. But how should I store the list of restaurants?

Which was my red button moment. Of course somebody coming to this problem for the first time would want to know how things were stored. Of course a person who didn’t know what I had planned for the rest of the day would worry about that.

And I realized that I had landed in the uncanny valley of example problems – close enough to realistic for people to care about practical concerns, but not specified enough for those concerns to be nicely handled. And I missed it because I was fixated on how I would test the score method.

We worked through it, though, and even did another round of examples using mock objects to fake out a location service. Still, we weren’t able to get anywhere near my plan of building up a complex system via BDD. Again – my fault for not getting the example right – the attendees were all great.

Ironically, I think I could have gotten away with it if the example was in print, where I would been able to just work through the changes in the score example.

Toward the end of the day, I kind of got the feeling that everybody, including me, was a little frustrated, so I just came out and said it. “I think the prepared material has been fine, but I don’t think the example has really worked. Would anybody mind trying a more abstract, code kata-like problem via BDD as the last example.” Everybody pretty much unanimously picked the abstract example, and so we pivoted to the abstract problem that I wrote for Ruby Learning a little bit ago. People seemed to work on that enthusiastically.

In the end, I think I provided value for everybody that was there, many attendees said nice things. But I’m annoyed with myself that I wasn’t able to deliver everything I wanted to.

Lessons for next time:

  • For this workshop, it seems likely that a well-specified but abstract problem is going to be better than a less-specified but nominally real-world problem. I think if I did this next time, we’d build up a simple game.

  • The content of any workshop like this is always dependent on the attendees needs. As the presenter, I have to be paying attention to how people seem to be doing. As the attendee, you should feel free to let the presenter know what you are hoping to get out of the session and if it’s working for you.

So, thanks to those of you that came out – you were great, I hope you learned something, and I appreciate they way you helped me improve my teaching skills. But I really hope you learned useful stuff, too.

Old Stuff

MeNoel RappinComment

With respect to this request to link to early web stuff, I think the oldest HTML page I coded that's still online is my Georgia Tech home page, circa 1997-8. Note the creative use of ugly nested tables. I don't think that any of my earlier web stuff has survived... no, wait, one other thing. The site dates to, I think 1997, it can't be much earlier because it has a broken Java applet (which was basically just a fancy animated gif). The articles are from a few years earlier though. Again, ugly table layout. While I'm here, I should mention that one of the articles on this page was maybe the only thing I've ever written that got forwarded around online without attribution....

Most of my early real web-app work has been eroded from time and traffic, but there are some embarrassing stories there. My first real web app, written in ColdFusion in 1998-9 we served from a server conveniently stored underneath my desk, and initially used the production server for development. It wasn't for quite a few months that we had a separate server for production. Or, to put it another way, I think we scored a solid zero on the Joel Test. Luckily for me and my clients, I've learned better since then.