Category Archives: coding life

The Passionate Programmer

3 Replies

The Passionate Programmer A few years ago, right about the time I learned my job was to be outsourced, I remember seeing a book in the bookstore titled My Job Went to India. I assumed it was a parody of sorts and decided to resist the urge to pick it up.

It wasn’t until I read the introduction to The Passionate Programmer by Chad Fowler, that I realized it was the second edition of that same book, which had been subtitled “52 Ways to Save Your Job.” The title change is a good one, as it does a much better job of crystallizing the goal of this book.

The focus of The Passionate Programmer is how to have an exceptional career as a developer. It is written as several short essays on specific tips for creating a career in programming you can be passionate about, each followed by one or more specific suggestions for activities to follow through on what you’ve just read. In essence, this is What Color Is Your Parachute? for people who already know they want to be programmers.

While the driving force may be passion, the topics are very pragmatic. Fowler suggests you choose your market, invest in your product, execute on your plans, and market yourself. This follows from the major thesis, that you must treat your career as a product in and of itself. The passion comes from the desire to create a great product, and do what is necessary to make that product, ultimately yourself, successful.

An important point that’s treated as a side note – you have to want to be a great programmer. If you find that’s not what you want, maybe you should find a career you can be passionate about.

Fowler provides a road map for how to create a career you love on a daily basis while moving towards a future you are excited about. The topics range from how to find enjoyment in the drudge tasks you may hate, how to keep from falling behind the technology curve, how to decide when to take career risks, and how to become truly remarkable (not just good).

Most of the “Act On It” tasks are highly relevant and useful. Now that I have read the entire book, I plan to review the chapters that feel the most relevant and focus on one or two of the tasks a week.

While much of the advice provided the The Passionate Programmer is not new, I think this is a great resource for anybody who wants to have a career as a software developer that excites and inspires. Software is a great industry, full of brilliant people and complex problems to solve. That’s why I got into it. This book provides concrete ways I can keep that passion alive.

<a href=”http://www.amazon.com/gp/product/0976694018?ie=UTF8&tag=movithecurv-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0976694018″>My Job Went to India: 52 Ways to Save Your Job (Pragmatic Programmers)</a><img src=”http://www.assoc-amazon.com/e/ir?t=movithecurv-20&l=as2&o=1&a=0976694018″ width=”1″ height=”1″ border=”0″ alt=”" style=”border:none !important; margin:0px !important;” />

First actual case of bug being found

1 Reply

On September 9, 1947, the Harvard University Mark II Aiken Relay Calculator started having problems. The operators opened it up, and discovered a moth between the points of Relay #70, in Panel F. The moth was removed at taped into the log book with the comment “First actual case of bug being found.”

When told of the event, Grace Murray Hopper was reported to have quipped they were “debugging” the machine. There is plenty of evidence the term “bug” for a flaw in electronics had been around for decades before this event, this usage helped bring it into the modern popular terminology.

This is also the first introduction that many of us have to Rear Admiral Hopper, a truly remarkable woman. She wrote the first compiler for an electronic computer, A-0. She championed the idea that computer languages should be more like English instead of machine code. And she helped establish standards for testing systems and components.

The next time I have to debug a program written in a 3GL, I’ll take a moment to thank Grace Hopper for laying the groundwork that made it easier for me. Thank you, Amazing Grace!

How did you get started in software development?

1 Reply

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?

Food, Fun, and Networking: Seattle Girl Geek Dinners

3 Replies

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!

Why is Microsoft Excel so popular?

Leave a reply

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?

When to branch your code

1 Reply

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?