![]() |
![]() |
I'm sort of over my funk, thanks for asking. Sort of. Today was a better day, didn't have to fight an unplanned IT fire, and was able to bear down and get some stuff done ahead of deadline (that always feels good). And had two different calls with customers planning large multisite systems, really interesting (and that always feels good).
So, an update on my weird disaster (wherein my Kestrel road bike was nearly destroyed by a coat hanger)... RoadRunner Velo have completed the repair (!) and claim it all went swimmingly, and have mailed it back to Westlake Cyclery, where it is being reassembled. I should have it in rideable condition tomorrow! Now that's a reason to feel happy, right? I will be very interested to see 1) how well the repair turned out, and 2) whether I still like my old Kestrel, after having ridden various other brand new cool spiffy bikes in the meantime.
Ever since I began linking my blog posts into Facebook I've been spending more time there, and although it isn't the time-sink for me that it [apparently] is for others, I do enjoy it. In a few cases I've reconnected with old friends, and that's cool, and in others have become closer to friends I was connected with, and that's cool. Some friends post a lot of pictures, especially old ones, and that's really cool. But one badness is that everyone seems to have more friends than I do! Maybe I have a lot of friends which aren't on Facebook (well that's definitely true) and maybe I don't connect with everyone I've ever known (that's also definitely true). But still, I do feel a little sad, like I'm missing out somehow :)
Jeff Atwood discusses paying down your technical debt. The general idea is that as you build software, you accumulate inefficiencies due to design trade-offs and have to go back and fix them later. It is an interesting concept; for me the idea is to have a sufficiently good design that you never accumulate too much debt. Going back to rewrite stuff due to architecture is usually a bad sign (doing it because of changing customer needs is different, or put another way, better understanding of customer needs). I find most of the time people have to go back and fix stuff is because of performance, and a lot of the time that's because they used the wrong tools in an effort to deliver functionality faster.
|
![]() ![]() |