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.

Hartbleed and You: Nontechnical Summary

If you work at a technology company and have seen a lot of ragged faces today on whoever is responsible for your company's security, there's a good chance that CVE-2014-0160 is to blame. Better known as The Heartbleed Bug, this security vulnerability is a bug in an application called OpenSSL that is the centerpiece for a lot of the secure communication that happens on the internet.

I thought it'd be helpful to put something out there quick and dirty bullet-point summary for the non technical users, so you can understand what's going on, how it affects you, and what you can do to protect yourself. So, here's we go:

  • Heartbleed is a bug in software used to secure a lot of communications on the internet, including those you make to websites like Google, Facebook, your bank, your VPN connection to work, etc.
     
  • As a result of this bug, someone could read information off of the computer providing that service (e.g. your bank's web server). They could also access a particular piece of information that gives them access to read all communication in the future, too. This piece of information is called the private key.
     
  • As a result of this discovery, two things are happening across the internet. First, servers are being upgraded with new versions of the relevant software to eradicate the bug. Second, system admins are generating new private keys and certificates to go with them. Once these are in place, it means that if some malicious person obtained a private key, that it will no longer do them any good. New communications will use a new key.
     
  • Various websites will be advising you on how you should protect yourself. Some will advise you change your password. Two factor authentication - where to login you're required to have your password and a code generated on your phone - will protect you even more. Evaluate what changes you need to make on a case-by-case basis.

So, there you go. That's your quick summary of what's been going on in Internet land for the past 24 hours. As a side note, Anchor Tab's servers were all upgraded last night shortly after I found out about the bug. I'm currently generating a new SSL certificate for the site, and hope to have it in place in the next few hours.

Now go give your nearest system administrator a hug.