Whenever I go to interviews, there is one area where I always bomb: the programming stories. These are the stories of “obstacles” I have overcome, “problems of scale” that I solved, “interesting” programs or algorithms. I am no good at telling stories, probably because I’m no good at on-the-spot recollection. I’m nervous enough as it is, and now they want to hear an interesting, compelling story about my work life? Scary, I know.

One of the more common approaches interviewers take with this question is to focus it on specific technologies. They want to know what you’ve done that applies to the languages and technologies that they know.

So I’m going to list a few of my stories here categorized by language/technology, for posterity mostly, but also to help anybody else out who has had trouble listing their accomplishments on the spot.

Javascript

The Project:

Tables. Datagrids. Spreadsheets. Everybody needs to build something like this at some point in their programming careers. I had to build a student grading spreadsheet recently (June 2011) at NYU. There were some weird custom calculations in the spreadsheet I was replicating, and I was told that the spreadsheet changes year to year. Great. So this will make teachers’ lives easier while making my life hell each year as they start sending piecemeal update requests every year (and multiple times in between I’m sure).

My solution was to build a revisioning form-builder which generates a spreadsheet view for the graders to enter values. It made sense for me to build it from scratch since we have a customized PEAR-based framework, and all the PHP & Javascript DataGrid solutions were either overkill or would be harder to implement than a custom-made Table-based spreadsheet.

The Problem:

It was imperative that the columns be resizable. Name fields need to be bigger than grade fields, and the table can have unlimited columns, therefore there is no single optimal sizing algorithm. Plus, these people are used to resizing columns, which means if I can enable that function I don’t have to worry about doing anything too fancy with a column width algorithm.

Unfortunately, nobody seems to have thought of a super-simple column-resizing plugin for jQuery. It was either über-datagrid or nothing. I did however find a fantastic little javascript snippet at a russian website which offered a script which did exactly the two things I needed: simple column resizing from any <th> field and callbacks with the column widths accessible (though not easy to find in that spaghetti code).

The Solution:

While technically I could just import that .js file and call its methods ad-hoc, I decided that using the base code I could create my own jQuery plugin. I’ve been in the process of moving each of the methods into the plugin itself, as well as tinkering with how the callback with the column widths array is delivered. Currently, you have to bind a function to the onchange event of the table you are changing the column of, and it feels like there should be an easier way to do this.

Code available at https://github.com/workwithnano/jquery-resizeColumns

Objective-C

The Project:

Silent Shout, a “note-passing” app for iPhones.

Our ideal workflow had the “options” page be the first page a user sees, and one that they return to often, so it had to be easy-to-understand, fun, and fast. In it, a user selects what “font” they want to use, what background the text should display against, and what “style” of presentation they want (their text can scroll like a marquee or fill the screen).

We decided that making the options hyper-visual would be the best way to go. There would be three rows of options that could be swiped left or right to select the desired option. The user would hit the “Next” button at the bottom right to move on, and their option choices would be stored for future use.

The Problem:

This was my first UIKit app, and as resourceful as I am, I couldn’t find any UIKit objects that would help me out here. This type of option-selecting mechanism had never been done before! Yikes.

The Solution:

With the help of StackOverflow, I managed to discover some helpful “photo-swipe” code snippets which made for a great starting point in my journey.

Ultimately, I created a UIView subclass which when fed an array of images & descriptions, would generate a swipe-able options menu that would store its current selection in the app’s preferences to be used in the “Shout” mode.

Code available at https://github.com/workwithnano/silent_shout

CSS

The Project:

http://elfpond.com. A single-page site dedicated to a wonderful musical performance in my basement. Yes, one of my most memorable undergraduate evenings took place in a basement. Many of them did, in fact.

The Problem:

We were pretty excited about the possibility of exploiting some awesome CSS3 stuff. Especially drop shadows. We felt it was high time that we take advantage of the box-shadow property, something which would make our lives much easier. The thing was, we were using a very strict grid, and if we wanted our shadows to extend past the boundaries of a box aligned within the grid, it’s not like we could just apply a background-image to it. It would get cut off by the box! We’d have to put boxes within boxes and rejigger the grid to accommodate the oversized shadows, and our lives would just be terrible.

box-shadow to the rescue! It could extend past the boundaries of a box, no problem.

Oh wait, problem. When we implemented these huge shadows to these huge video boxes, scrolling the page became an exercise in patience. Patience is one thing we “web builders” know our users aren’t expected to have much of.

The Solution:

Back to background images, of course! But how to implement? Well, I realized we already had “boxes within boxes”, since each video box would be one element within a larger “section” box (also contained in that “section” box were mini-menus and descriptions and such). Then I also realized that in each “section” box, there was only a need for a single large drop-shadow.

So, I realized, since we were using a very strict grid which guaranteed vertical and horizontal positions for each element, I could reliably place a drop shadow image as a background image in the “section” box, positioned directly behind the video box. Scrolling was now unbelievably faster, which was pretty important since you weren’t going to get very far if you couldn’t scroll down.

This post was graciously edited by Marc Ubaldi

The day after my good friend Greg proposed the idea for Teacher Hub to me, I was sure we had a hit on our hands. 7 months, 1354 lines of code, and one “pivot” later, I called it quits and moved on.

Chronologically, from the beginning

Greg’s wife is an “early-stage” teacher (a few years in), and given the horrendous job-security that newly minted New Jersey teachers have currently, she’s dealt with having to teach entirely new classes year after year. All new classes => all new needs. New classroom supplies (largely teacher-purchased or teacher-subsidized), new curriculums to learn (and inevitably update), and possibly a new school to get used to.

Her itch: wouldn’t life be better if there were an online destination where all those things could be found easily and cheaply? It would be a place where teachers could trade, barter, sell, or share their wares, skills, and advice. A place where teachers could meet other teachers from their area. A place where teachers could write about their experiences — the good, the bad, and the ugly.

A “Teacher Hub,” you could call it.

I loved it. It seemed like a real need in an interesting industry. And I was desperate to step into the startup ring once more (my first startup, back in 2006, was a movie social network called Reel Critics that never launched).

Start coding, talking, coding, talking

First thing I did was start coding the boilerplate and basic multi-column layout. I had been simply writing new SQL code and the occasional unordered list for the past year, and was just excited for an excuse to build something from scratch.

We scheduled weekly meetings to keep things on track (keep on what track? we hadn’t laid any tracks at all), which one of us usually showed up late for. I was 37signals-crazy, shoving all my clients and projects into Basecamp, writing roadmaps in Writeboard, tracking life tasks in Ta-da List. So of course, our meetings were in Campfire. Text-only. So the rate of conversation-to-useful-work was diminished for us by the very nature of our communication medium.

One of our first goals was to get Greg up-to-speed on programming. We weren’t sure how much he could contribute code-wise, but I was hoping to get one more person coding. The last time I was the only coder on a large-ish project, I got tired after a few months. Nobody to talk to and pump me up creates a tough gig.

Let’s get something out of the way. If you’re starting a startup and someone wants to teach themselves programming in the process, don’t expect good results. This is not a knock on those people. My advice is to look at the priorities of the business and the priorities of the person. If either of those points away from a need or desire to be a programmer, then this could be a waste of time for everybody and for the business. There’s a school of thought that if you have a startup idea, you should teach yourself to code, or that everybody in the startup should be able to code, but the fact remains that there is a lot of stuff that needs to be done at a startup, and if someone’s motivations aren’t conducive to programming, don’t get hung up on that. Do something that you can do already, and do it now.

So those first few months, while I was still living in Venezuela (Greg was in New Jersey), we’d spend our time doing the following: coding, setting up Greg’s RoR dev setup, setting up the staging server on my Media Temple VPS, talking about doing research on the industry of teacher-oriented websites, doing some nominal research on said industry, and debating with gusto about the financial aspects to our business model.

Let’s Align our Interests

All of this meeting stuff was an attempt to align our interests to the goal of building Teacher Hub. We were trying to get on the same page so that we could work on the same thing (programming our Minimum Viable Product), but our differing skill sets kept us drifting apart throughout the week and then struggling to re-align our interests and goals during our weekly meetings:

Instead of what we were doing, we probably should have specialized in what we were each capable of already, keeping our end-goal in sight and on the same page, but not concerning ourselves with making sure we were both contributing the same things in the same amount as each other:

Next time on “Startup Gone Wrong”…

We’re only 2 months in, and Edyta and I are about to realize that Venezuela is just not going to work out. Find out what happens to Teacher Hub (and my programming life) as we start our journey back to the USA.

This post was graciously edited by Marc Ubaldi

Around my internet1, there’s been a recent meme concerning dedication to starting your own business. It’s not unique to our time, but over the past week it feels like everything I read, watch, or listen to is talking to me about the need to devote yourself fully to whatever it is that you believe your business to be, otherwise it will likely never get done.

Dan Benjamin and Merlin Mann talked about it on the latest episode of their podcast Back to Work, Jim Coudal implored us to build your beer cozies today, and… those are the only two I can remember right now, but it feels like I’ve been pestered with these messages for the past week non-stop.

Listening to these smart, successful exemplars in my industry, I realized that I had essentially followed their advice. I spent all of 2010 as a full-time self-employed freelance programmer, and now, in 2011, I work a “corporate” job while relegating projects of passion to my off-hours. What happened?

Some backstory:

When I finished my Master’s degree (you don’t have to call me “Master” if you don’t want to) at the end of 2009, I knew exactly what I was going to do. I was going to take my 2 current freelance (programming) clients, find a few more, and eventually hire employees and sit back while they make me lots of money. I was even going to expedite the “retire on a tropical beach” part of it by setting up my business in Porlamar, Venezuela. By my back-of-the-napkin calculations, between my current meager freelance income and Edyta’s doctoral scholarship, we would live quite comfortably in relative solitude and peace in the tropics, given the expat-favoring pricing in Venezuela.

The plan was to stay there for 1 year. We lasted 3 months.

Then, 6 months after we moved back to the U.S., I was looking for a “normal” job.

What happened? Why?

Well, our general reason for leaving Venezuela was that we couldn’t get a reliable internet connection — a vital tool in both of our fields of work.

But in general, I found that while many of the aspects of freelancing were empowering, other aspects were putting my brain’s anxiety receptors on high alert. You’ve heard about the empowering aspects already — no boss, working on what you want, etc. — so I’m only going to explain how the empowering aspects lost out (for the time being) to the anxiety-inducing aspects.

• I loathed searching for new clients. I would stare for hours at the 37signals gig board (defunct) and the Authentic Jobs freelance listings, thinking to myself that I couldn’t possibly sell myself as capable of doing those jobs. Or maybe the jobs had weak descriptions, making me wonder if the clients would be flaky.
• Lonely. That’s what I felt while working in my home office on sites with no designers or programmers other than me. When we moved to New York, I had no excuse not to put myself out there at hackathons or conferences, but I convinced myself that sitting at home working was time better spent.
• Once you’re locked in at an hourly rate, it’s hard to raise your rate. I had almost 30 hours per week of work to do, but I was still charging my cheap college-student rates to my most trusted clients. Not a good thing when you consider my lack of new clients.
• You still have to find time to do the things you love. Despite having the luxury of setting all my own hours, I still found that I had to make time for my projects of passion outside of client-work time. If you’re not working on your startup full-time, then you’re just not working on your startup full-time. Not much different than working a “normal” job and coming home to startup work.

Overall, these things (and other, less explainable things) contributed to my anxiety over running my own business. And this doesn’t even get into the anxiety of an exciting startup project turning sour (another post, another time).

So I suppose this is where I put in a little warning to all the would-be self-employers out there. Be as aware as you can be. Which is probably not enough. You can do it if that’s your goal. But the alternatives are not so bad, if you ask me.

This post was graciously edited by Marc Ubaldi