So, I gave a talk

On Tuesday, I gave my first talk ever in front of a technical crowd to the Developers of Athens. My topic was Scala and Lift. This wasn't my first time being in front of an audience, but it was my first time giving a primarily slide-driven presentation about some highly technical stuff. It was my first time speaking about Lift publicly.

Ultimately, I decided the presentation wasn't up to my (perhaps idealistic) standard. Having now had a few days to distill my thoughts a bit, I thought I'd share what I took away from the night.

Information Overload

Something I didn't realize before going into the evening is exactly how much ground I had attempted to cover. I had way too much on my schedule. As a result, I ended up confusing a good handful of people for most of the presentation.

I decided to dedicate most of my time talking about Lift's view-first architecture, something I considered the most novel concept compared to other frameworks. This resulted in a good number of people being confused for a good chunk of the presentation about whether Lift was a framework or a templating engine. So, I didn't do a great job of doing the Framework justice.

In retrospect, I should have thrown the idea of covering anything about Scala and giving code samples out the window. I just didn't have time, and I could have leveraged the additional minutes to actually discuss some other features.

Usage Data

I was pressed on usage data for both Scala and Lift at various points and I did not have it. That's an epic fail on my part.

With regard to Scala as a whole, the official Scala website does a better job of painting a picture of the kind of adoption Scala has seen than I could. You can read their blog post detailing enterprise companies using Scala and an article on the growth of popularity and usage.

With regard to Lift, this is something that the Lift community has discussed before (though I'm failing to find the thread), but we don't have any real good numbers (that I know of) on how much Lift is used. We have a handful of sites that rotate on our homepage, including Foursquare. But, unfortunately, I couldn't tell you how many sites out there are using Lift. As we make the push toward Lift 3, that's something we need to seriously think about how to measure accurately and communicate outward.

Offhand Remarks

So, I suck at summarizing my thoughts on things in an impromptu manner, it seems. Feeling the time crunch I was in I expressed two different opinions that both got me a bit of flak. It's no surprise both of these were during the part of the presentation I didn't care as much about (the Scala part).

The first was regarding typing. I made a remark that an audience member interpreted as unfair toward dynamically typed languages. I don't remember what my exact remark was (it may have legitimately started with "Static typing is better"). Exact words aside, I think my experience with Scala has taught me that when a type system is done right, it can greatly increase my confidence in the code that I'm writing without slowing me down or bloating up my test suite with cases such as return type checks. The audience member correctly pointed out in response that there are steps you can take to mitigate the risks of a dynamically typed languages, and that there are cases where static typing isn't as good of a fit as I portrayed.

The second was regarding Java. While discussing Scala's nature as a second-generation JVM language I made the offhand remark that Java was "on the way out," which is an opinion that I hold with qualification. I just expressed it with all those qualifications removed because they were completely irrelevant to the main topic (Lift). I immediately got about 10 WTF faces from the crowd, there were a few remarks back and forth that evening, and then I didn't think much of it. However, It ended up being the topic of conversation on the Meetup site the next day. I was really, really discouraged that there were audience members so unimpressed with the main topic of the presentation that a quip about Java was the main thing on their minds.

There's obviously a balance that I need to work on during a time crunch between reading from a script and shooting statements off the cuff faster than I can think them through or fully explain them.


Something that I severely underestimated in this little adventure was exactly how vulnerable you can feel when someone takes out their pitch fork to start criticizing you.

I don't know if it was a reasonable expectation, but I expected to feel about the same when receiving any criticism about my talk as I would criticism about a blog post. I've been writing long enough that I have a pretty tough exterior when it comes to self-evaluating how well I've communicated something. Yet the tone of the criticisms around my Java remark on the Meetup group the following day impacted me enough to make me seriously consider never presenting again.

The advice I got from pretty much everyone on this oscillated between "grow a thicker skin" and "why does that one guy matter that much anyway?" Both of which are completely valid. But if the goal of this post is to be honest about experience from my first time speaking (which it is) then omitting this would be a mistake. It was different for me when I got up in front of that crowd and then, after that, a member decided he disliked something about it.

The criticism of the audience apparently has the potential to be greater than the sum of its parts if you're not steeling yourself for it. I wasn't, and it slapped in the face as a result.

In Conclusion

At least one member of the audience has started playing with Scala since I walked off the floor, so I have hopes to see an addition to the Lift community from Athens at some point. Also, I'm going to publish my slides whenever I get the chance to clean them up. There were a bunch of slides at the end I didn't use and I think a few that were in the wrong order. I'm sure everyone remembers the "I wasn't expecting that slide to come next" dance that I did halfway through the talk.

This won't be the last time I give a talk. It'll probably be a spell before I do it again, but this was a goal I had for myself this year. And I accomplished it. So now, it's back to building, shipping, and writing things for awhile.

See you on the interwebs.

Economies of Scaling Back

A few of you who have followed me for awhile know that I'm a Christian. Part of my faith includes periodically reading things from other believers who have come before me. A few days back a contemporary Christian publication posted an excellent collection of quotes by Charles Spurgeon, a well respected Baptist preacher. There was one selection in particular that seemed to relate to me, especially as a member of today's technology industry. Spurgeon writes,

The way to do a great deal is to keep on doing a little. The way to do nothing at all is to be continually resolving that you will do everything.

Many of us are guilty of this: getting so excited by a new idea that we dive headlong into it without much regard for whether or not it's something we can actually commit time to. The result is project abandonment in most cases, which in the grand scheme of things isn't a huge problem. However, in the past six months I've experienced the extreme where a lot of little things - constantly stressing me out because they're not done yet - roll up into one big batch of burn out. And that, my friends, is a huge problem.

As a result, I've recently come to the point where I have had to acknowledge the following: I am a human. Before you discard this statement as obvious, let us consider what it means for a moment. Specifically this: that contrary to the fact that my brain spends a good chunk of time contorted into thinking like a computer, it does not in fact function like a computer. It needs long periods of rest to appropriately recharge. It won't work like every other brain out there in the world. It needs emotional and intellectual fuel to keep me healthy and creative, as opposed to being a mindless drone punching a clock. It is incredibly bad at multitasking on the average, as much as we would like to believe otherwise, and will likely to continue to get worse as I get older. Most of all, it needs much less stress than I've put on it in recent months and it needs more time with the family and friends, my time with whom is far more important than whatever I contribute to technology or society by running myself ragged.

Naturally I'm a problem solver, and this is nothing more than another problem. So, I say to myself, what's the solution? Well, there are two parts: the reactive and the proactive.

On the reactive side, it's a top priority to scale back the things I'm committed to. About a month ago I tweeted that I was interested in finding someone who can help spearhead the Georgia Open Data Project moving forward (see the tweet here). I've additionally canceled a few side projects that were lined up for Crazy Goat Creative, and have scaled back my role in Anchor Tab for awhile. As of today the two efforts I'm spending non-work time on are the Get Open Mentorship Initiative and Depend On. This has opened up a good amount of time for spontaneous events, reading, blogging, bike riding, and the like.

On the proactive side, I'm working on iterating on a weekly structure. Right now, it's formulated to the point of having a few mandatory things (e.g. full time job, time with my community) on the top half of the list, and then at the bottom having a section named "Pick 1" with Lift, Get Open, and Depend On listed. That should, ideally, leave plenty of unscheduled time to "go with the flow." Tonight that consisted of a Skype call with a friend who lives in another state and binging on old episodes of Covert Affairs.

But to be honest, the most proactive thing that I'm doing is accepting the fact that as much as I want to build all the amazing things I concoct that I am not someone who can eat, drink, and breathe code seven days a week and be happy. It's not how I have been designed to function, and trying to function that way is detrimental to me and everyone that relies on me to get things done. This means that I can't try to spearhead five side projects at once. It means that I shouldn't make any employment shifts where more than 40 hours of work per week would become the regular working hours. And, most of all, it means that whatever great things I have the privilege of doing in the seemingly short amount of time I'm here will almost certainly be done in little bits for a long while.

Coming to the above conclusions has been a long time in the making, and I will likely iterate on them in the months and years ahead. It's a painful process, especially when you have to cut back on things that you would really enjoy. But it's a process worth going through. Fortunately Spurgeon has some wisdom for us on that front as well:

There is hardship in everything except eating pancakes.

So, I implore you to take the opportunity to evaluate for yourself what boundaries you need to impose to prevent yourself from reaching burn out.

Then go eat some pancakes.

Re: Why you should take notes by hand — not on a laptop

Interesting article on the front page of Hacker News right now: "Why you should take notes by hand – not on a laptop" by Joseph Stromberg at Vox. I've generally favored taking notes by hand for the same reason they outline as the result of a study in the article. Specifically, that people taking notes on a laptop tend to do worse when questioned on the contents of those notes. There was, however, one interesting point I wanted to harp on:

But the crazy thing is that the many college students being distracted by their laptops are simultaneously paying tens of thousands of dollars for the privilege of doing so.

Something that is always in play in a classroom environment is the following: how much responsibility does the instructor have to be engaging and how much burden does the student have to stay engaged?

From my personal experience it's the case that the quality of lecture material in a class seems to decrease the larger the class gets. I don't think there's a causal relationship there. If I had to guess the actual cause would be because the larger classes are core curriculum and generally not things the professors are excited about teaching. But if a professor is utterly bored by the material they're teaching, students are going to be utterly bored watching them click through a PowerPoint slide that they're reading verbatim.

The insinuation by Vox above (at least as I understood it) is that the students are wasting money for something that is a privilege, which isn't a sentiment that I entirely agree with. For many careers a Bachelor's Degree is the new standard. It's a hoop, and one that's not always 100% relevant to your actual degree. The biggest assets I gained in my Computer Science degree aside from the letters I can put on my resume are the experience with theory of computation and the connections I made that allowed me to have a job all four years of school. I was, of course, a bit abnormal because I walked in knowing how to code. That doesn't change the fact that I had to sit through plenty of classes absolutely unrelated to my degree.

So, here's the question: are students wasting money or just getting ripped off so they can make a living?

Code schools have started popping up around the technology industry, and while acknowledging that they're not the same as a four year degree, operate under the hypothesis that you don't need the foundational elements to be an entry-level software engineer. They have effectively lowered the barrier to entry such that you can get some basic coding chops without breaking the bank. From what I've heard, they've been doing a pretty good job with it.

Assuming this trend continues, that code schools are able to churn out good, qualified, entry-level engineers in less time and for less money - the one is left to ask how valuable the core curriculum actually is to the student. It's normally one of the biggest stumbling blocks in acquiring all of the credits required in a four year degree, and a lot of my professors didn't particularly care for teaching the core classes. So, why is it something I paid for?

Gotchas: Loops in CoffeeScript are not closures

So I've decided I'm going to start writing about the various gotchas that I come across in this software engineering journey of mine. My hope is that these writings will get a decent page index and will bubble to the top of the search results the next time someone runs into the same issues I do. In today's edition of "things you don't expect languages to do" we're going to have a brief chat about CoffeeScript's for loops, and some gnarly behavior to be aware of if you aren't currently.

So, I started working with CoffeeScript around version 1.3.1. In this version, the contents of a for expression in CoffeeScript were wrapped in a JavaScript IIFE, or Immediately-Invoked Function Expression. In JavaScript, those are the things that look like this:

(function() {

In version 1.3.2, CoffeeScript removed the IIFE from their for loops. So, the end result of that change was that if you wrote the following loop in CoffeeScript:

things = ["a", "b", "c"]
for thing in things
  setTimeout () ->
    console.log thing
  , 10

You might expect to see the following output on your console:

> a
> b
> c

You would, in fact see:

> c
> c
> c

The reason is that by the time the console.log is evaluated, the value of thing is set to "c" because the actual console statement only executes after the loop has completed and "c" is the value thing had at the end of the loop. Head hurting yet?

If you follow along on this blog, I'm sure you've seen my mention of issues with my project that imports data from the Georgia General Assembly. Specifically imports were broken in strange ways. It turns out that for loops behaving in this manner were the entire reason for those issues. I didn't actually figure out what was going on until we ran into the issue at Elemica earlier this week, which resulted in me posting a bug on the coffee-script project. The net-net is that this is intended behavior.

As I noted in the GitHub ticket linked to above, this is particularly gnarly behavior when combined with jQuery, or really any other library that behaves in an asynchronous fashion. So, how do you get around this issue? do.

things = ["a", "b", "c"]
for thing in things
  do (thing) ->
    setTimeout () ->
      console.log thing
    , 10

This will essentially cause thing to be frozen, as you would have liked it have been in the first place. There's a proposal underway to consolidate this into one line in a future version of CoffeeScript to make it even cleaner.

Anyway, it's a Friday night and I just kind of spun this out as a quick "heads up" to all my fellow CoffeeScripters out there. If there are any errors, omissions, or unintended easter eggs in this post please let me know in the comments and I'll correct them. Hopefully you won't spend quite as much time as I did scratching you head over variables in for loops changing or behaving unexpectedly.

Lessons Learned from my First Hackathon

This weekend I participated in Atlanta Startup Weekend with the My Chef's Table team. We placed second and it was an excellent experience overall mostly because it's something very different from my normal operating mode. Given the choice I'd prefer to take my time with a product, so putting the artificial time limit of 2 days to build something gave me an opportunity to put myself outside my default mode of operation.

I thankfully avoided pulling any all-nighters this weekend (not even close), but I'm still exhausted. However, before I give into my desire to go to sleep and start my work week tomorrow I wanted to hammer out some quick thoughts, observations and lessons from what is essentially my first real hackathon (not counting college projects).

So, here we go in no partiuclar order:

  • On the technical end, you're building a demo, not a product.
  • Demos are probably best built outside-in. Get a solid design, frontend markup and CSS, and some JavaScript to simulate the existence of a backend. Only bother with a backend last so that if you need to spend extra time on things the judges see (markup / styles) you can drop the things they can't (a backend).
  • Angular JS isn't quite so easy to just drop into. I don't know whether or not it's because it's legitamately that complex or if their documentation isn't engineered well, but I seem to remember having a much easier time picking up Knockout which serves a very similar role.
  • Positive momentum is essential. It won't come on a Sunday afternoon. You have to already have it going starting Friday night.
  • Get some sleep. Deprivation is just as damaging to your productivity as everyone says.
  • The judges are going to ask how you plan to make money. Be prepared for that question.
  • The judges may also ask if it's legal to do what you want to do.
  • Murphy's law with regard to presentations is worse than it is with printers. Something will go wrong. The best thing you can do is not stress about it.
  • Murphy's law is also in effect with version control. Though just pushing everything straight to master is quicker there were a few cases where branches and PR's for sanity checks would have saved time / prevented unexpected WTFs.
  • The joy of talking in odd accents at arbitrary moments is not limited to just the people I work with.

And on that note, I'm calling it a night. Thanks to all the volunteers, organizers, and sponsors for ATLSW.