Moving the Curve

Michael Eaton asks: how did you get started in software development, and I’m answering.

How old were you when you started programming? I’m another late bloomer. I remember having access to an early edition Macintosh for a short period when I was 13 or so, but it didn’t take. I didn’t really start programming until after I made my first web pages (I don’t count HTML as programming, sorry) and wanted to add some functionality to them. That would have been when I was 24 or so.

How did you get started in programming? I like to tease my father that he could have saved a lot of money if he’d encouraged me when I first asked for a computer (shortly after the aforementioned school Macintosh). Instead I ended up getting a degree in International Politics and starting down the researcher path. Then one day I realized I was having more fun maintaining and modifying the FoxPro relational database that went along with the research than doing the research itself. I eventually decided to switch careers, first into web site design (it was all the rage in 1994!) and then into development.

What was your first language? The first language I had any proficiency in was Perl. I had the great luck to be friends with Nat Torkington and got him a short gig helping out at the Web 1.0 site I was writing HTML for. He inspired me to look into the language and discover what it could do.

What was the first real program you wrote? The first useful program I can remember was an overtime tracking system, written in Perl with an Informix backend. I still shudder at the memory of the sorts of loops I wrote.

What languages have you used since you started programming? Professionally, I’ve written code in Perl, Java, JavaScript, Visual Basic, PHP and C#. I went back to school to get a Computer Information Systems degree, and learned Pascal, C, and C++ in the process, although I don’t think I can claim to have ever used those specific languages outside class. I’ve played a bit with Ruby on Rails and I’m trying to carve out more personal time to learn Haskell this year.

What was your first professional programming gig? I lucked into a position as the developer for a tech support intranet at Adaptec, which became a proper programming position as I developed the skills.

If you knew then what you know now, would you have started programming? Yes, and earlier, and with more rigor.

If there is one thing you learned along the way that you would tell new developers, what would it be? Write more code. There’s no substitute for writing code and seeing what it does. Just like anything else, it’s practice that makes you better.

When I first started, I suffered from perfectionists disease, which often lead to the dreaded paralysis by analysis. I wanted to write the most elegant code possible. But I didn’t have the skill and experience yet to know how to write that code, and ironically held myself back a bit by not just writing code and seeing what worked and what doesn’t, and why.

These days, I write code at the drop of a hat. My folders are chock full of 5 and 10 line classes that do nothing but verify my understanding of basic concepts in the language. If I have a question, I write a program first to see if I can answer it. And then I truly understand how the language works. The result is I write better code.

What’s the most fun you’ve ever had … programming? Completely refactoring an existing program. We had a Perl program that let customers submit tech support tickets into our tracking system. It was a typical example of spaghetti code, most of which I’d inherited and then made worse through my youthful bumbling. I had enough downtime that I could slowly work through the program, end to end. It was a great feeling of satisfaction, evidence of how I was learning. It wasn’t the most sophisticated program I’ve written, but it’s one of the most successful. As far as I know, that program is still in production, 10 years later.

So, how did you get started in programming?

I first heard about Girl Geek Dinners a while ago, and thought it sounded like a great idea. I sent an email to the original organizers, and soon heard back. They had also just heard from Liz Morgan, another woman in the Seattle area, and suggested we join forces to organize a local group.

And so we’re inviting all local technical women to join us for the First Seattle Girl Geek Dinner, to be held June 24th at the Microsoft Campus in Redmond. There will be food and beverages, and hopefully a lot of fun!

Please check out our site, let us know if you’d like to come by signing up, and help us spread the word!

Today we had a brainstorming meeting with the business analyst for one of our major clients. We pitched a wireframe for a workflow addition to the application.

The analyst was excited. This fell in line with a meeting she’d had earlier. The main decision there was to replace a large portion of the UI with Microsoft Excel templates. Users don’t like the UI and want to just use the Excel spreadsheets they already have for passing data back and forth.

One of my co-workers sighed, “Users just like Excel. It’s got to be the most successful product ever.”

I’ve seen this repeatedly. I’m tasked to build a web-based UI to automate
business processes. Once it goes live, I find out users don’t want to use the UI — and always seem to wish they could just use Excel instead. And businesses seem unwilling to force users to use the custom application that seemed so important six months to a year before.

There’s certainly a requirements gathering and design problem that’s usually fundamental to causing this problem. There’s frequently also a training problem once the application is launched.

But why is it always Excel that people want to hang on to? Why is it so useful that it seems to drive a huge portion of business processes in companies large and small?

I think a large part of its appeal is the low barrier to entry - it’s pretty easy to create a simple spreadsheet. It’s easy to learn the basics of how to add fields and other simple functions. And it’s easier to format than Word. All this despite a fairly unintuitive UI.

What can we learn from the high use of Excel? What can we apply from those lessons to our own applications?

This article on Making Small Commits lead me to think about when to commit and when to branch a code base.

Branching is the black art of version control, and anyone who has tried it at least once has probably had the nightmare that arises from having to merge code back in.

It’s an art worth learning, however. Sometimes you’re working on a feature, or a refactor, that’s significant enough that you can’t risk partial checkins.

Now, for context, I’m a big believer in frequent checkins. Beyond the advice in the linked article, I tend to check in almost any change. Add a method? Check it in. Add a single unit test? Check it in. Version Control is my brain and my undo. I’d rather revert a version or 10, but be confident, than realize I need to go back about halfway through my current rewrite.

Given I like, and in fact need, to check in often, I feel I probably need to use branching more often, as well. An recent example was work we started for a client. Right after integrating the first elements of the new features, the client changed the current request. Entirely. However we were stuck deep enough in a combination of new elements not yet finished and concurrent refactoring that it became easier to comment out large sections of code than refactor. If we’d just branched the new feature set, and continued maintenance on the trunk version, we would have saved ourselves frustration - and the risk that comes from half-finished features that probably won’t ever make it to the top of the backlog again!

What is your philosophy on branching your code base?