Great article in the Times Magazine last week. Here’s some video from “Jerry Seinfeld Intends to Die Standing Up“. As far as I’m concerned it a familiar theme. While creativity can flow regardless, the pro learns to work the craft. To get repeatable, high level results. Anyone can make a shot from mid court. It doesn’t make you Michael Jordan. You’re still a chimp in the dirt playing with sticks.
Show Us Your Production Code
Show Us Your Production Code — Alexander Zaytsev:
So, I hereby challenge the Ruby community: the next time you want to tell the world about the right way of doing things, start with showing your production code.
That’s right, the dreaded ‘production code’.
Don’t make up examples. Show us what you actually do.
For example, instead of using the notorious ‘create a record and send an email’ example, David could show a similar but more complex controller from Basecamp. A piece of code that actually made the team argue about the right way.
[A good thought. I hope I have the courage to do so next time.]
Larkfarm: Random Bits: Twitterless and Happy
Rather, it’s a simple reflection of one fact of life: the payoff from Twitter does not, for me, justify the time investment.
I’m coming up on 52 years old in less than two months. I’m acutely aware, in a fashion that was not true in my twenties, that everything I choose to do uses up some of my dwindling supply of hours on this earth. As life goes on, I find that this makes me ever pickier about what I’m willing to spend time on. Some things – like earning a living and supporting my kids – are simply not optional. But for many others, the question is simple: is this the most enjoyable and fulfilling thing that I could be doing with these hours?
[I hear that. Been in the back of my mind as far back as I can remember.]
Scripting News: Heat-seeking missiles.
Scripting News: Heat-seeking missiles.:
This stretch of beach was about 10 miles long, and except for a town in the middle of it, mostly empty. One morning I decided to take my swim via car. I drive a couple of miles south, on a stretch of beach that was totally empty. I laid out the towel, read for a while, then went for my swim. When I came back, there was another car parked right next to mine. The people were gone, so I couldn’t ask them why they chose that spot, when there were so many other places to stop that were totally secluded.
[Dave’s example is more extreme, but I find the same thing is true at the mall. I park far away from everyone. I’m rarely at a mall during its peak hours. I love walking. Yes, almost invariably when I return from my errand there’s rows of empty spaces, but someone parked right next to me. And sometimes so closely that I can’t get back in my car without climbing in on the passenger side. That’s crazy. I’ve considered printing up cards for the occasion so I can leave one on their windshield.]
Source: Scripting News
Page Weight Matters | Chris Zacharias
Page Weight Matters | Chris Zacharias:
When we plotted the data geographically and compared it to our total numbers broken out by region, there was a disproportionate increase in traffic from places like Southeast Asia, South America, Africa, and even remote regions of Siberia. Further investigation revealed that, in these places, the average page load time under Feather was over TWO MINUTES! This meant that a regular video page, at over a megabyte, was taking more than TWENTY MINUTES to load! This was the penalty incurred before the video stream even had a chance to show the first frame. Correspondingly, entire populations of people simply could not use YouTube because it took too long to see anything. Under Feather, despite it taking over two minutes to get to the first frame of video, watching a video actually became a real possibility. Over the week, word of Feather had spread in these areas and our numbers were completely skewed as a result. Large numbers of people who were previously unable to use YouTube before were suddenly able to.
Through Feather, I learned a valuable lesson about the state of the Internet throughout the rest of the world. Many of us are fortunate to live in high bandwidth regions, but there are still large portions of the world that do not. By keeping your client side code small and lightweight, you can literally open your product up to new markets.
[It’s easy to forget. Great story.]
Source: Luke Melia
Rebuilding
Anil Dash writes about rebuilding the web we lost. Step one is “Take responsibility and accept blame.”
This is a follow-up to his post The Web We Lost, which you should read first if you haven’t already.
[Go read. Now build.]
Source: inessential.com
The Best Gifts Are Not Things You Ask For
The Best Gifts Are Not Things You Ask For:
In 2004, I was perfectly happy not being a climber. I worked at the REI store in Phoenix and deflected all invitations to join my co-workers at the climbing gym. Then my brother piled a climbing rope he’d bought but never used into a box and put it under the Christmas tree at my parents’ house back in Iowa. When I opened it, I was nonplussed at best, and probably told him Thank You in the same tone I would have if he’d just gifted me an old toaster. I took the rope back to Phoenix and eventually went out climbing with some guys from work. I sucked. I was scared, had bad footwork, and was a bad listener.
But something was there. I had been treading water in life for a couple years, really without an identity. I stuck with climbing. Six years later, I got my first article published in Climbing magazine. A couple years after that, I stood on top of the Grand Teton with my buddy Chris, coiling another rope over my shoulders, my brother’s Christmas gift long retired. I don’t think either of us saw that one coming when I opened that box in 2004.
[On point. Ya never know what things will have the greatest effects. Be open minded. Give things a chance.]
On Human Technology
Brian David Johnson: Being More Human:
But as we near 2020, something different will happen. When computational power approaches zero, we will be able to turn anything into a computer. We can put computer intelligence into a water glass or your shirt or even your body. We no longer will ask ourselves: Can we do it? We will ask ourselves: What do we want to do?
I’m trying not to imagine a teaspoon of miniscule computer chips dissolved in my coffee.
[Is that what those little black things are? No wonder…]
Source: inessential.com
Kanban development oversimplified
When you place focus on how quickly you can get functionality done, and have the ability to measure just that, then the estimates don’t much matter. In fact, many using a Kanban approach have simply stopped estimating at all. Yes story sizes vary, but being able to give a wait time plus or minus a few days is sufficient for many organizations’ concerns.
Some do still estimate stories. Then use those estimates in conjunction with cycle time. Using a spreadsheet we can calculate the average cycle time for stories with a given estimate. If you do this, consider placing a handy chart next to your Kanban board showing estimate in one column, and wait times in adjacent columns. With this you’re answering the real question stakeholders are asking for when they get estimates: “when am I going to see this functionality in the software?”
If your stakeholders are like mine, they don’t want to know when they’re going to get this functionality, the want to know when they’re going to get all this functionality. I find that if I place stories into a spreadsheet with start and end dates, and calculate cycle time, if I select an arbitrary time period — say a two or three week time period — I can see how many stories where completed during this time period. For instance I might see the team finished 22 stories in 3 weeks — that’s about 7.3 stories per week. Given a backlog of 100 stories I can reasonably infer that it’ll take between 13 and 14 weeks (100/7.3). That’s yesterday’s weather for Kanban — at least the way I calculate it.
If I know that during three week time period there where 15 working days and that 5 developers worked the entire time, that’s 75 developer days. Knowing that lets me calculate the average number of developer days per story: 3.4 (75/22) — Which is darn close to pi — which makes me believe it has to be right. ;-) This number, 3.4, is what XP practitioners referred to as load factor.
Leaning hard away from doing anything at all
During the weekend Hill and I had a good chunk of time to talk about my health, and options. We are both currently leaning hard away from doing anything at all.
I know I’ve just said a mouthful.
We’re not trying to make a decision as much as we’re trying to let one emerge. As we think through the reality of the possible paths it’s hard to imagine signing up willingly for the misery of treatment in the face of lousy odds. I have a lot to say about this. I don’t quite have it well enough gathered in my head to write it down at the moment.
[Not doing is thought of as harder than doing. It would appear to not always be the case.]
