I want to thank everyone for their great outpouring of sorrow and commiseration when they heard I had reached my 30th birthday. I guess I have to start "acting my age" and "knowing better," or something like that.
Anyway, thanks to everyone who sent a card.
(-:
One of the things that's been on my mind recently has been optimizing my work life so that I can either spend less time doing the same stuff or accomplish more in the same amount of time.
In the back of my head has always been Joel's test, and in my feed reader the other day, I found a similar list; the humorously titled "Your Doing it Wrong if..." I had to laugh hard at the fourth entry on that list, as I have written my own database abstraction layer (hereafter DAL). I have all sorts of excuses for why it was written at the time, but I must say that after using it for almost three years, I think that using another (preferably open source) layer is the best idea. I've come to realize (and have read in several places) that you shouldn't write something that is not your core business. If you're selling stuffed bunnies online, don't write your own shopping cart. Buy one or use something like ZenCart or Magento. Of course, if your business is the shopping cart (like, oh, Amazon), then go right ahead.
Anyway, I was talking about DALs with a friend today, and he mentioned this blog post, which speaks out against these layers. The post rails against them as a method of keeping software database independent. I agree with him that that is not a good reason by itself to use a DAL, but it got me to thinking about why I use one.
My answer to that question comes from Mr. Code Complete himself, Steve McConnel. He's quoted on a Coding Horror post as saying:
Nobody is really smart enough to program computers. Fully understanding an average program requires an almost limitless capacity to absorb details and an equal capacity to comprehend them all at the same time. The way you focus your intelligence is more important than how much intelligence you have.
At the 1972 Turing Award lecture, Edsger Dijkstra delivered a paper titled “The Humble Programmer.” He argued that most of programming is an attempt to compensate for the strictly limited size of our skulls. The people who are best at programming are the people who realize how small their brains are. They are humble. The people who are the worst at programming are the people who refuse to accept the fact that their brains aren’t equal to the task. Their egos keep them from being great programmers. The more you learn to compensate for your small brain, the better a programmer you’ll be. The more humble you are, the faster you’ll improve.
The purpose of many good programming practices is to reduce the load on your gray cells. You might think that the high road would be to develop better mental abilities so you wouldn't need these programming crutches. You might think that a programmer who uses mental crutches is taking the low road. Empirically, however, it's been shown that humble programmers who compensate for their fallibilities write code that's easier for themselves and others to understand and that has fewer errors. The real low road is the road of errors and delayed schedules.
The best reason to use a DAL (or any abstraction, for that matter) is outlined above: to encapsulate a set of functionality (data persistence) and then remove it from the front of the programmers mind. This frees the mind to concentrate on higher level concerns like (hopefully) the core business logic. Of course, DALs tend to grow and morph until they become bloated and try to accomplish less important tasks (like database independence), but the real benefit of using them is to write less code and when you write less code, you will naturally create fewer bugs. I don't want to avoid SQL because I hate it or can't use it, but rather because it is unnecessary to always have it in the front of my mind.
Of course, using or not using DALs should never be a hard and fast rule. If your application only persists to one table (or a few), or has very tight memory requirements, or uses gypsy midgets, feel free to skip a DAL.
And, as always, these are strong opinions, weakly held.
Good luck.
As evidenced by my runnerplus page, I've reached one of my goals for 2008: I ran 500 miles. It happened right after the last long training run before the marathon. I definitely didn't expect to hit this milestone so soon in the year, but training for a marathon and logging more than 30 miles a week certainly got me there.
And speaking of the marathon, it was a lot of fun. We finished in 5:15:42, which is almost an hour and a half lower than my previous time. The weather definitely contributed to the better performance. The sun came out during the second half, but the ocean breeze kept temperatures down. Sara and I are already talking about doing it again next year.
One thing I noticed about training this time around is the sheer amount of energy and determination it takes to train. We started back in early January with little two or three mile loops and peaked in April with 147.4 total miles (almost 5 a day). May was particularly difficult because we started doing our weekday runs in the morning. It was great to run in the pre-dawn hours, but by 1 or 2 in the afternoon, our energy level was zilch. It was hard to concentrate at work and make it those last few hours. The weekend runs were almost a rite of passage. We'd get up as early as possible and then after two, three or four hours of running, we'd "lay low" the rest of the day. It was all we could do. Now that I look back on it, what really got us through was each other. It always seemed that when I didn't want to run at all, Sara was right there encouraging me and when she couldn't take another mile I was ready to go. I can remember toward the end of each successive long run cries of "you can do it" or "up and over" getting us through.
After all that, the marathon didn't seem so daunting in the days leading up to June first. However, we certainly hit the wall at mile 19 or so. As we pushed through we noticed more and more the shirts of other runners with Bible verses written on the back. One that stuck out was Philippians 4:13. Sara kept saying it over and over again, and our strength returned as we came through the other side. By the time we saw our family again at mile 24 we were running strong and knew we could finish well. In all my life, I've never felt anything like turning that last corner and seeing the finish line. We kicked hard and ran past the crowd with our hands in the air.
We're planning on running two more events this year; the America's Finest City Half Marathon and the San Jose Rock and Roll Half Marathon.
As far as mileage goes, I'm now up over 540 and who knows how far I'll run by the end of the year.
The recommendation I've heard most is that you should learn a new programming language once a year. I'm thinking my next one should be a functional language, like Erlang or Haskell.
I saw a Haskell snip today on Slick or Slack, and it definitely piqued my interest.
What Ruby on Rails is to web programming,
and Capistrano is to deployment,
now Castanaut is to screencasts:
#!/usr/bin/env castanaut plugin "safari" plugin "mousepose" plugin "ishowu" launch "Mousepose" launch "Safari", at(20, 40, 1024, 768) url "http://gadgets.inventivelabs.com.au" ishowu_set_region at(4, 24, 1056, 800) ishowu_start_recording while_saying " Tabulate is a bookmarklet developed by Inventive Labs. You use it to open links on a web page. It's meant for iPhones, but we'll demonstrate it in Safari 3. " do move to(240, 72) tripleclick type "http://gadgets.inventivelabs.com.au/tabulate" hit Enter pause 2 end
So cool.
I was handling a customer support request today and it read something like this:
I changed a setting and now I get an error. What's wrong?
My knee-jerk reaction was to think, "Well, then what was the error?!?" You see, I'm a problem solver. I love to dismantle things and figure out why something isn't working properly. To me, the first step toward the solution is to figure out what the problem is. So my first attempt at formulating a response went something like this:
Here's how to figure out what the error was. Come back when you've done this minimal amount of work.
Ooooh, snarky.
Before I hit 'Send Reply', I took a bit of time to explain the situation to a co-worker and made the point that figuring out the problem is a vital first step to working toward a solution and that there are common ways of discovering what a particular error is (logging, debug flags, etc.). I also stated that these problem solving tactics are learned best by experience as opposed to reading or hearing about them.
Then, my mind came up with this question: "Was I ever not a good problem solver?" That question suddenly humbled me and gave me a new perspective on the whole situation. I changed my response to first validate that the way the customer was changing the setting was correct and that the error was indeed an unexpected result. I went on to explain how to figure out what the error was and that I'd help them figure out what was going on.
You see, snarkiness is fun, but it's rarely edifying for the snarkee.
I don't post this to boast of my humility. In fact, I'm quite embarrassed about the way that I initially reacted. It's my hope that this will remind you to always remember that you were once the student.
With insight into why people don't read manuals and why features sell products:
http://www.codinghorror.com/blog/archives/001048.html
Also:
http://www.jnd.org/dn.mss/simplicity_is_highly.html
http://www.joelonsoftware.com/uibook/chapters/fog0000000062.html
From the Norman essay:
Logic and reason, I have to keep explaining, are wonderful virtues, but they are irrelevant in describing human behavior. Trying to prove a point through intelligent, reasonable argumentation is what I call the "engineer’s fallacy." (Also, the "economist’s fallacy.") We have to design for the way people really behave, not as engineers or economists would prefer them to behave.
I find myself re-learning this again and again.
For while now I've wanted to put a computer in the kitchen. Here begins the process of actually realizing that goal.
Why would I want a PC in the kitchen? Here are a few reasons why such a computer would be convenient:
What components are needed for a PC in the kitchen?
First off, the box. Ideally, the computer would sit inside one of the cabinets, and so therefore would need to be as small and low heat as possible. It would also need to have enough horsepower to show full-screen video and run more than one application at once. It needs to support a touch screen as well as a USB keyboard and mouse. Since I don't want to run a network cable across my condo, wireless networking is also a requirement.
Here are some possible candidates:
Now on to the screen. Only touch screens are being considered for this project, because several of the applications would depend on the keyboard playing second fiddle to the finger stylus. The screen must be small, but able to afford a decent resolution (1024 x something). Here are the candidates:
I'll definitely need to do more research before I select anything, but I wanted to get something out there first.
Next time, it's peripherals and operating systems.
As promised earlier, here are the goals I have set before myself to complete by the end of 2008:
Run 500 miles - Yup, that's right. I plan on running five hundred miles this year. I've often called myself a running rhinocerous in comparison to my gazelle of a wife, but my last run (a half marathon in San Jose) helped me to finally get over the "less than totally enjoyable" experience I had during my first marathon and consider long distance running a sport I can do.
Plus, I received a Nike+ kit for Christmas. I'm quite enjoying all the statistics and graphs that can be generated from this little accelerometer. I gleefully race to my computer after each run to upload my data and check on my progress. As one friend put it, it turns running into a video game. I've joined the Runner+ community, an offshoot of the official Nike+ site that's a little lighter on flash and allows more control over your data. My profile page is here, and I plan on adding a stats section to the side bar at some point. I started the year off a little slow, but this week I should set myself back on pace to make 500 by December 31st.
Run a marathon and a half marathon - There's no way I can keep up running unless I have some larger goal to work toward. Sara and I have registered for the San Diego Rock and Roll Marathon on June 1st. It'll be her fifth and my second, and we're both hoping it'll be a better experience than the first one we ran together (90+ degrees on hot L.A. asphalt). We'll probably do the San Jose Rock & Roll again in October so this goal is pretty much planned for. All that's left is the training.
Write one blog post each week - I really enjoy writing. I like finding just the right word to express each idea. I pore over my prose like a gardener, tenderly cultivating it until each sentence and paragraph flows just right and the thought that's in my head comes through as clearly as possible. The only problem is, I don't do it enough. Good writing takes discipline. It means sitting down and making it your primary task. Therefore, I commit to writing at least one blog post a week. Something more than a funny picture or a witty link. It should be me sharing a part of myself in written form.
There are many other ways I want to improve myself (becoming more organized, reading for fun more, carving time out for my personal programming projects, etc.), but this will have to do as far as measurable goals.
What are some of your goals for 2008?
