Finding and hiring talented people is by far the hardest and most important part of my job. I’ve had great and terrible success with almost every approach.
One of my favorite “Texts from Xcode”.
Writing software is a lot like building things with Legos; the really cool part is you get to invent/mold/create many of the Legos you’ll use to build your thing.
If you create them wisely, everything fits together neatly and you have a lovely creation you can build upon and adapt in the future.
If you create them foolishly you can still mash them together to create your thing, but it will be a real bear the next time you need to make an adjustment to it.
I’ve updated GameTonight to show the time of the event. This is also included in the JSON API and Status Board output. No guarantees that the event times are correct, but they are faithfully represented from the data feed.
This is something that I put off for three years because I was having all sorts of weirdness with time calculations on my local machine vs. the server GameTonight is running on. Thanks to Joe and his
incessant nagging constant encouragement, I slogged through the necessary debugging this morning and finally got things set.
I know enough to know that whenever you’re working with dates and times, you want to do everything in GMT then convert out to a local timezone as a very last step. I also know that you probably want your app code to run in GMT rather than looking at the server’s timezone.
In trying to be careful about doing these things right, I learned a bunch of things that didn’t work. Ultimately the issue was with how
date() do or do not use the timezone declared for the app vs. the server’s timezone.
Pro tip: use these in pairs (
gmmktime() goes with
mktime() goes with
date()) and create useful logging functions to test their output on various machines/servers. Or not, your mileage may vary.
This weekend, Luis wrote about his information diet1 in the wake of Google Reader’s impending closure. While reading his post, I thought about my own feed reading pattern.
I hear lots of people say that Twitter has replaced feed reading for them. I don’t think that works for me, for several reasons:
- I like having a casual relationship with Twitter. I don’t want to feel like I have to read everything in my stream for fear of missing something. On days like today when I have meetings all afternoon, I will completely ignore Twitter.
- I don’t want certain stuff in my Twitter feed. There are news sources that I like to skim (then mark all as read) in my feed reader that I don’t want in my Twitter feed. Twitter is still personal to me. Most of the people I follow are folks I am friends with.2 Twitter is an intentional distraction for me and I don’t want it to be more than that.
- Feed reading is great for following sites that post infrequently, but have great stuff. This morning’s post by Charles Miller is a great example. In many ways, it’s the best tool I’ve found for what I really want: following interesting people.3
I haven’t made a choice for my next feed reader server-side service yet, but I am happy with Reeder for iOS and Mac so I’m likely to stay with something it is compatible with. At the moment this means Feedbin, but I’m also considering self-hosting something. I’d love an Open Source parsing/crawling back-end that implemented Google Reader’s API; plus Reeder adding support for setting a custom API endpoint URL.
Whatever solution I end up going with, feed reading isn’t going to leave my daily workflow anytime soon.
This is really cool – I’d love to see it for more pitchers.
Hadn’t thought of programming this way before but I completely agree. One big example for me is with legal contracts. Thinking of them as “this part does this, this part does that” makes them much easier to understand and negotiate.
One of the things I enjoy most is incorporating a good idea from one language/project/etc. into another (obviously, you need exposure to other languages/projects/ideas to do this). You can see examples of this in the code I’ve written that interacts with WordPress and how it’s adopted more of an MVC style over time.