eben's ruby blog

[enrubyastick]

How I Learned to Stop Worrying & Love the CoffeeScript

Author's Note: I took about a six-month break from code-blogging there. Unintentional. I had a new job, but that's not much of an excuse. Time to get back on-track.

It is a fact universally acknowledged that JavaScript is sort of terrible. And yet between Angular, Ember and Node (to name just a few, in alphabetical order) it's also pretty clearly the way forward, or at least an inescapable facet of the future of the web.

Make no mistake: I'm glad I learned Rails first. I'm working with Rails right now, and being paid for the privilege. Rails's star may be waning, but it's not about to disappear off the map. It's role is simply changing, at the moment; it remains the right tool for some jobs. And for other jobs there are different, better tools.

Through no one's fault but my own, I left Launch Academy with an inadequate understanding of JavaScript. I had friends in my cohort who applied themselves to the study of the bracket and the semicolon (and built some pretty nifty toys in the process) but I was too far in the weeds -- or so I thought at the time -- to even consider taking on a second language.

And then I got into my current position, which involves being a full-stack developer in several senses of the term. I control the horizontal, I control the vertical, and if I get stuck on a particularly nettlesome bit of front-end development, I have no one to turn to but myself. Which is, of course, a bald-faced lie -- I'm in near-constant touch with my friends and teachers from the Launch community. Many of whom have proved very helpful at getting me un-stuck.

What has proved equally helpful is CoffeeScript.

CoffeeScript, for the uninitiated, is JavaScript. There's more to it than that, but the fundamental and most important truth of the matter is: it's just another way of writing JavaScript. A better way, some would argue (myself among them.) CoffeeScript enabled me to leverage the patterns I had already learned and write idiomatic code that behaved (more-or-less) the way I expected.

And in that 'more-or-less', I found myself learning all manner of things about JavaScript. Concepts as simple as declaring variables, which had eluded or puzzled me when I was looking at them on top of learning Ruby, were illuminated by the tools that CoffeeScript provided. Even things as basic as looking over its documentation and seeing how the idiomatic concepts were ultimately rendered as JavaScript became a useful didactic on how things were actually being accomplished.

So now I write CoffeeScript. It serves my client-side needs for my Rails app at work. And through its lens, I am backing my way into understanding JavaScript, and even writing JS first, when the occasion calls for it (which it does less frequently than you might think.)

In a funny way, this might never have happened if I'd started in on it while I was still at Launch. Certainly I didn't encounter any strong proponents of CoffeeScript there. It seemed to be regarded as something of a crutch (a viewpoint I don't entirely disagree with) and a curiosity. This in spite of the fact that it's been part of Rails since version 3.1.

Gradually, however, I am becoming my own best advocate for learning CoffeeScript. I've always been brassy and opinionated, but there's nothing like having a soupcon of real-world, rubber-meets-the-road professional experience to make people pay a lot more attention to what you think. Which only makes sense, really. But that's where I've landed, for the moment: CoffeeScript is a great tool for teaching people who are already learning Ruby/Rails the things they'll need to get started with JavaScript.

And if you already know some JavaScript, and waved off CoffeeScript because you thought (or someone told you) it was nothing but a dumbed-down version? Look again. You might just be surprised.

[enrubyastick]

On Motivation & GitHub

Never underestimate the importance of momentum.

I came down with a severe headcold this past weekend. On the one hand that's good timing; I couldn't have afforded to be as thoroughly out of commission as I was during the cohort, so if I had to get sick this winter, that was the time.

On the other hand, though, it took the wind right out of my sails. Launch Academy is really good about instilling a diligent mentality in all of us. 'Always be coding' is an oft-repeated mantra. And it's easy to understand why: we learn a lot, in a very short period of time. If you don't keep using it, don't continuously reinforce it, it's only too easy for it to slip away.

There's more to it than that, at least for me. I have become a big fan of the so-called Seinfeld Strategy (as advocated by Charlie McDonnell, among others.) It's a fairly simple idea, not at all new, and it can be summarized thusly: don't break the chain.

Do something you want to do. Do it every day. And take note of it. The more days in a row that you do it, the easier it will become -- and the more compelled you'll feel to keep it rolling, and not break the chain. Momentum, as I mentioned at the top of the page.

At least one git commit a day seemed like a reasonable bare minimum to me. An easy chain to start, and an important one to keep me always coding. And hey, would you look at that: if you push those commits to GitHub, it will keep track of the chain for you.

... Or so I thought.

Turns out, GitHub only counts commits towards your streak if they are pushed to master (or whatever your default branch happens to be.)

I ran into this exception head-first while working on my current project. I had all of the basic functionality up and going; the next piece I wanted to do was a fairly major undertaking.

So, in keeping with my standard workflow, I checked out a feature branch and got to work. And at the end of the day, the feature wasn't done yet. So I didn't merge it; just pushed it, as it was on its own feature branch, to GitHub, and figured that I had logged my commit for the day.

Except I hadn't. If you look at my GitHub profile right now, my line of green isn't exactly unbroken. Just the opposite. And all because I hadn't been pushing to master.

So what's a budding coder to do? Change my workflow? Seems drastic. Ignore GitHub's nicely built-in feature and track the chain on my own? Impossible (the ignoring part, anyway. My compulsive brain won't let me.) Take this as a sign that the feature is too big, and I should break it down into smaller pieces to develop? ... Possibly.

I haven't settled yet. But I know something today that I didn't know yesterday. And that's another important chain I'm keeping in mind.

UPDATE: Apparently, if you subsequently merge the feature branch to master, and push the merged master up to GitHub, the commits get counted on the days they were made. So the chain is broken until it isn't, retroactively. Weird.

[enthusiastick]

I can’t believe how far we’ve come.

[enrubyastick]

I will echo my own sentiments here, too.

[enrubyastick]

Quad Programming / Powers of Two

This week at Launch Academy we started our partner projects, which confusingly involve four-person teams. ‘Partner project’ is a misnomer, referring to the fact that it’s a project for one of the hiring partners, not a project I work on with a partner. But I digress.

I’m happy to say that my team hit the ground running. After reviewing our project brief, we decided that the optimal strategy was to get the MVP (that’s ‘minimum viable product’, yet another software term that’s exactly what it says on the tin) up and running as soon as possible, so that we can devote the bulk of our (extremely limited) time to refactoring the code and adding ‘nice to have’ features.

After sketching out an ER diagram, we further decided not to split up the team while developing this core functionality. Thus quad programming was born!

Relevant note: we have these lovely pair programming work stations here at Launch Academy Mission Control, with USB hook-ups for two keyboards and two mice per one big display. With the help of Screenhero, a terrific collaboration app, we turned two pair programming work stations into a single four-programmer hub.

Each of us took a turn driving while the other three navigated and brainstormed. The ideas and knowledge flowed freely; since the beginning of the week I’ve picked up several techniques I’d never seen before, and also buttressed my understanding of concepts to which I had some previous exposure. Rather than being the waste of time it might sound like, having four people working on a single, relatively simple problem proved extremely illuminating.

And, more to the point, it worked! We’re not quite at the MVP yet, but we’re close. And we received very positive feedback from our stakeholder about the code we’ve published so far, and the “maturity” of our approach.

Today the cohort changed gears to work on our Breakable Toys. But watch this space for further developments. Some time very soon this blog is going to start filling up with links to fully functional web-apps which I built (or contributed to.)

[enrubyastick]

Eureka Moments From The Outside In

It's been too long since I've written a blog post. Life as a launcher is crazy, and the days are just packed. There's an interesting effect, almost a time dilation, that takes place; when I was a kid who attended an (artsy, theater-y) summer camp, we used to joke that a camp day was like a week of normal life (and, correspondingly, a camp week was like a normal month.) The same feeling applies here. My last post is dated almost a month ago, but it feels like much, much longer.

Dan & Johnny have both been congratulating the cohort a bit lately. Partly it's just a sentimental time of year (New Year's and all that goes with it.) But it's also been a really important time for us on the path to becoming developers. As we've re-focused on Rails, I've been seeing every day just how far I've come. The Ruby fundamentals that I've learned come into play all the time in this context; at least when you're getting started, it seems like nine times out of ten the solution can be found within a plain ol' Ruby object.

Acceptance Testing has been another major revelation -- which is good because, at least according to Dan's excellently-drawn bullseye, I'm supposed to be spending a lot of time on it. For the longest time Unit Tests felt like busywork to me (and, I will guiltily admit, sometimes they still do.) It can be hard to see the value in writing the bare minimum of code to pass a test. And in Rails there's an added layer where I'm never quite sure whether the test I'm writing is actually worthwhile, or whether it's just testing something that ought to be baked in to Rails and therefore fundamentally reliable. (Side note: I know that my uncertainty on that point will likely clear in time; I've seen distinctions being drawn, and have a glimmer of understanding, but I haven't fully internalized it. Yet.)

But while Unit Tests focus on the nitty-gritty and sometimes get me lost amongst the trees, Acceptance Tests are high-level and all about the forest. They provide a clarity and direction I didn't even know that I was missing. The process is dead simple:

Figure out what you want a feature to be.

Articulate that understanding in the form of User Stories.

Break those User Stories down into granular Acceptance Criteria.

Turn the Stories & Criteria into an Acceptance Test.

And finally, Step 5 (this is the good bit.) If you have done Steps 1 through 4 correctly, when you run your automated test it will tell you what to do, in the form of relatively comprehensible error messages. Address the error, re-run the test, and keep at it until the test comes up green.

When the process is flowing correctly, I find myself writing the code I need to implement the feature -- only and exactly that code. No wasted motion, not one extraneous line. It feels amazing, and things can take shape ridiculously fast.

It's an exciting time. I mentioned at the top of the post that the days are just packed. Even so, I'm finding there aren't enough hours in them to do all the things I want to do. Oddly enough, it feels fantastic.

[enrubyastick]

TDD & Me

Here's a guilty confession for you: I'm a first draft kind of writer. Whatever the opposite of a perfectionist is. I don't dread revising. I just don't do it, unless it's absolutely necessary. I fly by the seat of my pants. And, for the most part, things tend to work out. When they don't it usually blows up in my face. But even when I get burned, I never learn. Sometimes I would rather tear things down and start from scratch then face going back through what I've already done.

It's a weakness, I know, and one I'm working to root out. Refactoring is a big part of coding. And I want to write good code. Clean code. Elegant code, even. These are my aspirations.

TDD is making me confront this problem head on, and right now it's absolutely kicking my ass. I know I'm not alone in this experience; I've heard all sorts of metaphors that describe it as something akin to running with weights on your ankles. You know it's slowing you down; you can't help but be aware, be conscious, of the drag. When I know what the next step is, my every instinct says to dive in and write the code. Writing a test first -- and then writing code to pass that test, rather than to serve the ultimate needs of the program -- feels like purposefully going in the wrong direction.

But, like running with ankle weights, it makes you better in the end. I like to joke with my mentor group about the aphorism that a good developer is a lazy developer. Maybe my weakness is secretly strength; maybe I can learn to be, like the boy in one of Heinlein's tales, Too Lazy To Fail. If doing it the TDD way means that it works right the first time -- if it builds refactoring into the process of coding the program, and thus decreases the overall number of times I'll have to work backwards -- it just might be worth it after all.

But you already knew that, of course.

[cybersect]

On TDD

But what’s the point of writing a test if the code hasn’t even been created, you ask? Why - that’s simple. It’s to get you thinking about what exactly you’re trying to do, and making sure you do the least amount possible to pass that test.

In rspec, we’d write something like ‘expect(calculator.new(2,2).add).to eql(4)’, before we even wrote the method add. That way, it informs your code by telling you exactly what you want returned (4, not a puts statement). With that in mind, you’d write the code for the method. Then continue on the the next test case.

Read More

[enrubyastick]

Writing the test first also helps you to avoid false positives by giving you confidence that you've written a good test. If you write a test before you've written any code and it gives you an error you didn't expect -- or worse still, passes outright -- then you know that you're not testing what you mean to be. Just in the same way that you rewrite the code until it passes (the "green" step) you must begin by rewriting the test until it fails (the "red" step.)

[enrubyastick]

Context Is Everything

It has been pointed out to me that the story of how I came to be here, at this particular juncture in my working life, is (at least mildly) interesting, and may be illuminating. I am, as of this writing, 31 years old. 9 years ago I received a Bachelor of Arts in History, with a focus on Medieval Islam. Since that time I have held a wide variety of jobs, dabbled in many fields. Just to name a few: I trained to be an insurance underwriter (though I left while still in training -- it wasn't for me.) I have driven a medical supply van. I have worked tech support in a phone bank for a well-known cloud backup company. I have written technical documentation for science/research robots.

And I have, for one brief shining period in '07-'08, worked in the web development industry. Let's take a quick trip in the Wayback Machine, shall we?

You may never have heard of Sconex, but it was a social network, organized around schools, aimed at the teenage demographic. Which is to say: Sconex was Facebook for high-schoolers before high-schoolers had Facebook. Having achieved a critical mass in popularity, Sconex was sold to Alloy Media + Marketing, and the original owners moved on to bigger and better things (all of this, I should note, happened before I entered the picture.)

As it was explained to me, Alloy considered Sconex to be a cow. At their direction, feature development for the site slowed to basically nil, while the original development team set to work designing an entirely new site -- one intended to be a star. They came up with a reasonably clever idea: a social contest site based around user-submitted content (photos, short videos, etc.) They called this new website SugarLoot -- and, near as I can tell, for every ten people who remember Sconex, there's maybe one who remembers the 'Loot.

This is, approximately, where I came in. SugarLoot was up and running and growing reasonably well; leveraging Alloy's marketing connections, they were running an increasing number of contests sponsored by third-string third parties (pet supply websites, straight-to-DVD movies, &c.) I heard about them from a friend, one of their main developers. I was looking for a job, and they had an opening in QA.

I was hired as their first QA employee. They were, I now understand, attempting to move towards Test-Driven Development. The notion was that I would start out writing manual test plans, but at the same time would teach myself how to write automated tests they could run under the hood. In the short-term, I spent a lot of time learning about the current workings of the site, playing rubber duck to the developers and discussing user-interface design and the specifications for upcoming features.

It was the happiest I've ever been in my professional life, before or since. I was engaged and invested in what I was doing, and for a little while, I thrived.

Alas, it was not to last. Savvy readers will note that I mentioned this took place in '07-'08 -- which is to say, it coincided with a certain financial crisis you may have heard of. In the summer of '08, SugarLoot downsized drastically. Sconex was shut down entirely. A couple of people survived the layoffs, but I wasn't one of them, and in short order I went from working at a job I truly loved to collecting unemployment and confronting prospects that seemed pretty bleak.

In many ways, the story of my journey to Launch Academy starts there. It's been a long process, finding my way back to web development. But ever since then, it's been in the back of my mind.

Fast forward to the summer of this year, five years after the fact. I'm returning from visiting my parents on Cape Cod, and have offered to drop my (Ivy-League graduate, more-successful-than-me) little sister a ride to the airport on my way back to Cambridge. She's recently transferred to a job in her company's offices in southern California, and is headed for a cross-country flight back to her new home.

We're chatting as we drive, the way that siblings do. And at some point the conversation turns to my job. I'm not unhappy, exactly, but I grouse, not for the first time, about how I wished I'd gotten my degree in Computer Science and not History. About how I wished I had more spare time, more bandwidth to devote to teaching myself -- there are lots of great resources, and my dream industry is full of self-taught programmers. But I have rent to pay, and a guy's gotta eat; good jobs are hard to come by, and I can't risk losing mine by cutting back to focus on something else. Especially something that might not pan out. If only there was some way, some magical way...

So how did I come to be here, at this particular juncture in my working life?

Simple. My sister turns to me, blinking, and says something to the effect of, "You know there are, like, developer bootcamps, right?"

[enrubyastick]

There's only one problem in development: logic errors and off-by-one errors.

A classic hacker joke brought to you by Dan Pickett.

[enrubyastick]

Thoughts On Finishing Alpha

This past week marks the end of Alpha, the first of five phases into which my Launch Academy experience is divided. In many ways it's been about review -- shoring up those fundamentals that will be important going forward. And I know exactly how much I've needed it. This has been a week of revelations, concepts grasped and principles comprehended that have eluded me up till now.

But in at least one instance, I got a bit ahead of myself.

Many of our recent assignments have dealt with the manipulation of data. Receiving it from user input, or reading it in from a CSV file or through an external API. Arrays and hashes, or arrays of hashes, or hashes whose values are arrays... it can get a little dizzying, honestly. It's required a fair amount of visualization (e.g. drawing it out on a whiteboard) to follow it all.

A couple of times, I found it expedient to have the same set of data in memory twice; the first to be a sort of master key, the second a copy to be processed and changed -- folded and manipulated and spindled to suit my will. The second time this cropped up as a potential solution to my problem, I was having real trouble getting it to work.

I created a hash that was a copy of the original easily enough, but somehow my wires were getting crossed. When I manipulated the values and stored them in the copy, I found them changed in the master as well. I tried it three different ways, until I was quite certain. It made no sense to me. And it still doesn't, exactly.

But thanks to my training, I knew how to look for the answers I needed. And that's when I discovered that the issue was, at least in part, object-oriented in nature. The copies I was making were so-called shallow copies. They duplicated the structure of the hash, but not the information being stored, which is why changes to one affected the other. I needed a deep copy to achieve complete duplication (and thus, true separation) into two distinct wholes.

I found out what I had to do. And I have a rough understanding of what I did to accomplish it. I'm hopeful that in Bravo I will deepen that understanding -- and come to grasp the same sorts of subtleties and nuances about these new concepts that I'm finally coming to grips with about the old.

[enrubyastick]

My Breakable Toy

I've been hesitant to discuss my ambition publicly, but now that it's part of an assignment I guess the time has come to throw my cap over the wall.

First, a bit of background: a Breakable Toy is exactly what it says on the tin. In the Launch Academy paradigm, it falls under the rubric of 'learning through play'. Which is just a fancy way of saying that making mistakes is an important part of the process, so it's a good idea to create for yourself a space where you don't mind making a mess and mucking things up a bit, because that's the whole point. Experimentation is a breakable toy's raison d'être -- it exists to be broken (and, hopefully, rebuilt.)

For my breakable toy, the end goal is a universal LARP character management system. Inspired by the likes of Dave Burbank's Steam & Cinders Condenser and the Witchwood Character Database, the idea is to make a one-stop shop where any LARP staff can configure a character database to handle all of what Dan calls "administrivia".

Many if not most of the games at which I play or staff simply don't have the resources to devote to setting up this sort of things for themselves. And so they use a slapdash mixture of whatever tools they have available-- Excel spreadsheets rife with macros, off-the-shelf message board software and even good old fashioned pen and paper. In short, it's a mess. And it's not very hard to see why; LARP budgets are always stretched thin. I have often described them as a labor of love; staffers burn themselves out giving everything they have to a game and still barely manage to keep the wheels on the wagon.

Where others see a problem, I see an opportunity -- and a perfect breakable toy. I can start small (say, with a new character creator for one game) and build outwards from there, adding features and functionality as my knowledge grows. Very little is required aside from basic arithmetic and the ability to manipulate strings and shuffle data around. And, perhaps most importantly, all of my data will be provided by the users themselves -- no need to go out into the wild to scrape from other sites, or interact with APIs. Just a nice quiet sandbox where I can feel free to wreak havoc.

I'm extremely eager (perhaps too eager) to get started. It's my second week at Launch Academy, and I still have only a rudimentary idea of how I would actually go about making this thing that I can envision so clearly in my mind's eye. And at every step in the process, my teachers have been illuminating for me how it's nowhere near as simple as I think. The knack, it seems, is learning to break the idea down into its component parts. And then break those parts down even further. To go from user stories, to acceptance criteria, to individual gobbets of business logic that will allow me to make my insubstantial notions into reality.

But it's comforting to know that I can make mistakes. That I'm supposed to make mistakes. That when I do finally start putting things together, I don't have to be afraid of tearing them apart again, if I think of something cleaner or more elegant, or if I just feel like I need the practice. I would love to come out the other side of this experience with something real, something I could put out into the world and invite my friends and associates to use. But even if I don't, I suspect I'll have something better: the tools I need to turn this or any other idea from a half-baked, back-of-the-napkin conjecture into a functioning web application.

[enrubyastick]

Reflections = Array.new(1, "week")

Here's an obvious truism for you: there are a lot of approaches to every problem.

Like many obvious truisms, when you unpack that statement, it turns out to have a number of fascinating implications. Over the course of the past week, it has been interesting to observe the way that it applies at every level of coding.

Take for example the very specific. Let's say I want to generate a new array, and put inside of it a single string. Off the top of my head I can think of three ways I might do that -- and that's before I even begin to consult the Ruby documentation.

More broadly speaking, as I have been working as part of a pair, or consulting with fellow launchers in my cohort, I often find that the same challenge is factored very differently by different people. As the challenges have increased in complexity, the number of possible components into which they can be broken down -- the number of atomic pieces of logic which might comprise an individual problem -- have increased like a fractal.

Not all of these possible solutions are correct, strictly speaking; they all aim to accomplish the same task, and some do so less elegantly than others, or require torturous conditional loops nested too deeply to be reasonably followed. And some, in the end, don't accomplish the task at all -- I've learned it's best to identify this at the outset, when possible. Best to work the problem through and be sure your solution can work before you start to write any code.

Still, even leaving those approaches aside, generally that leaves (at minimum) several "correct" solutions to a given challenge. Often these approaches are quite different to one another. On the one hand, this appeals to the right-brained liberal arts student in me; the truth resists simplicity, after all, and why should programming be any different. But it is different -- or so I had been led to believe. Coding is meant to be a science, or at least, a scientific endeavor. Like computers themselves, it is supposed to be logical.

I suspect perhaps it's down to Ruby being a so-called 4GL. It is a language abstracted away from machine logic to render it more digestible to our human brains, and that abstraction brought with it the ambiguity that allows for the splintering and diversity of approaches. Which might explain why I feel increasingly at home with Ruby the more conversant in it I become.

[enrubyastick]

Why Ruby & Other Questions

Michael Denomy gave a talk tonight at the Boston Ruby Group about (Re)Inventing Yourself, which is in many ways the whole point of the Launch Academy exercise. He made a lot of interesting points, but one in particular stuck in my mind, a question I found really thought-provoking:

'What brought you to Ruby?'

Or, to put it another way, why Ruby specifically? I was startled to realize I didn't immediately have an answer. While Ruby has a large and growing community, I think it's past the days where it can be called cutting edge. I'd be lying if I said that I didn't have doubts as to whether I'm paddling after a wave that has already crested -- getting started with something that's in use right now but that may be dwindling by the time my new career has picked up momentum.

In some ways Denomy's talk addressed these fears, of course. He emphasized that reinventing yourself is an ongoing process; in the technology world (and in development in particular), it has to be. (Side note: I am reminded of an ironic quip from the movie Primer, "You know what they do with engineers when they turn 40? They take them out and shoot them.") And the methodologies and philosophies I am studying hand-in-hand with Ruby will serve me even as I grow and potentially move on from Rails into new languages and new ideas.

A large part of his answer (and, I suspect, a large part of mine) grows out of that thinking. Ruby has a large and vibrant community, whose rapid growth has not diluted its ideals; they have embraced agile and test-driven development, with an emphasis on pair programming. At the end of the day, a language is just a language; there are many ways in which Ruby is elegant, but I am not drinking the Kool-Aid so much I don't acknowledge that there are some things it doesn't do especially well (or at least, I'm not drinking it yet.)

On first impressions, the Ruby community appeals to me: it seems young, dynamic, energetic -- and above all, helpful. And I thrive in that sort of environment. I am an inherently social creature, and something of a sensitive one at that. Supportive peers cheer me up and spur me on far more effectively than harsh criticism and competition ever have. I find figuring things out and arriving at solutions to be extremely satisfying, and I love the camaraderie when that joy and satisfaction is readily shared with the group.

That may not be the whole reason, but it's a place to start. Food for thought, anyway. It's a question worth revisiting:

'What brought you to Ruby?'

[enrubyastick]

An Invocation for Beginnings

[enrubyastick]

Taking Steps Is Easy (Standing Still Is Hard)

Much has been written, in the past few decades, about this simple, inescapable truth: computers do what you tell them to do. They do precisely, unquestioningly, what you tell them to do -- despite all of our instincts to anthropomorphize and engage in magical thinking, when a computer messes up it is (very nearly) always the instructions provided to it by a human being which are at fault. This is the so-called GIGO Principle (which stands for both the prosaic, 'Good Input = Good Output' and the significantly more telling idiom, 'garbage in, garbage out'.)

My experiences with coding thus far have been haphazard at best; I am an amateur, or else an avid hobbyist, who has picked up a few tricks out of necessity. I can set up a MySQL database and install Wordpress, or throw together some basic HTML with the occasional gobbet of PHP. When I visit with my parents they ask me to fix their computers, despite having three other children who are equally capable of doing what I invariably do to solve complex problems: Google it, and try things other people have suggested until one of them works.

What I have lacked, I like to imagine, is a foundation. When it comes to real programming, I have been feeding my brain on tech junk food, and as a result it is malnourished and weak. Garbage in, garbage out. But I have always imagined that, given a more wholesome repast (and the time to savor it), I would tuck in heartily and emerge stronger as a result. I have been, to strain this metaphor to its breaking point, hungry for real mental sustenance for what feels like a very long time.

This Monday, I start Launch Academy, a 10-week retraining program which will put that theory to the test. Though I've been occasionally anxious and queasy with anticipation, mostly I am excited and eager. I can't wait to get started.