Programming

Bill Higgins wrote something that resonates with me:

We began bootstrapping the Admin Web UI in September and I thought we’d made good progress in such a short amount of time. Erich didn’t seem so impressed with what he saw. I was a bit frustrated by this because I thought Erich was being unreasonable – we’d made good progress for the short amount of time we’d been working on it. But after a few more minutes of chatting, I realized that there was simply a mismatch in what we were evaluating. I was evaluating the state of the Admin Web UI vs. the resources (time and people) we’d had to work on it; Erich was evaluating the state of the Admin Web UI vs. his vision of what an awesome Admin Web UI should look like.

I can relate. To Erich Gamma more than Bill.

At work I am sharply critical of what we do. For every app we work on, I have in mind something far better than what we end up releasing. I want us to do an amazing job and naively believe we can.

Quality isn't Job One. Being totally fucking amazing is Job One.

After a recent user acceptance test of an application we’re working on, I was dismayed by how fragile the app felt. It just isn’t as good as I know it can be. In contrast, the development supervisor was thrilled because, like Bill Higgins, he was evaluating the state of the app versus resources available — and mostly because it was indeed better than it had been 6 weeks earlier.

Bill’s insight is a good one, to recognize the need to think in terms of both “current vs. previous” and “current vs. ideal.” I spend most of my time worrying about “current vs. ideal,” (worse: my ideal, which is a damn brutal standard). A healthy dose of celebrating progress would good for me. Without a good, hard look at a just-completed iteration, I don’t get that sense of progress so am likely to be drawn into a morass of despair. Likewise, the less despondent among my team could do well to get a sense of where we sit in relation to where we need to be, to help inspire and keep the work interesting.

It’s important to take time as a team (and individually!) to reflect on what you’ve done. Not only is it an obvious opportunity to learn from successes and failures, it can be help keep up morale. But as time pressures loom, it’s easy to let that time slip. Don’t.

del.icio.us links

links for 2008-02-11

del.icio.us links

links for 2008-02-08

Security

RSnake speaking to Twin Cities OWASP

Robert Hansen, aka RSnake, whom you might know from his insight on web application security over at ha.ckers.org or perhaps his book on cross-site scripting, will be speaking at our local OWASP chapter on Monday. It promises to be good.

Pre-registration is encouraged to give some idea of how many to expect — the venue for last month’s meeting had to be moved because so many people registered.

Update: Hansen appears on today’s Future Tense.

del.icio.us links

links for 2008-02-07

del.icio.us links

links for 2008-02-06

del.icio.us links

links for 2008-02-05

del.icio.us links

links for 2008-02-04

del.icio.us links

links for 2008-02-03

del.icio.us links

links for 2008-02-02

« Prev - Next »