5k race training week 8

Losing weight steadily since I started really watching my points and training for the 5k. It fluctuates a lot but it averages to about a little more than a lb a week. It seems like with all the running I should be losing more - but this is a lifestyle change, 5-6 months is not so long a time frame to reach my goal weight in a healthy and maintainable manner. I don't feel hungry or tired all the time as I would if I tried to do a crash diet - certainly if I did a crash diet I would not have enough energy to do all the running. I keep thinking about reaching my goal weight and all the changes that will happen in my life when that time comes 5-6 months from now.

Feel good about the running, I accidentally did 5.25 miles due to incorrect mapquest statistics. That was not such a big deal, I also had my best time for 4 miles on Sunday. The race is towards the end of next week. I'm going to run this afternoon and time my 3 mile run.

Weight ranges

I'm at 192 right now - still fat. I'm 5'11" by the way. Still working on losing the weight, hope to be back to my ideal weight by Christmas.

I've been thinking - at least for someone with my body type, weight goes something like this:

190 and above, especially over 195 lb - fat, ugly and borderline obese, thick neck, man tits and big belly - you look fat no matter what you wear unless you want to buy a whole new wardrobe in XL and XXL.

180 to 190 lb - You look presentable, but don't kid yourself that you are 'skinny'. You look ok with clothes on but don't think that you can take your shirt off credibly on the beach. You wear L shirts, M shirts still look tight and stupid on you.

175 to 180 lb - Borderline nice physique. Probably what I've been the majority of my life. You can start wearing size M shirts credibly.

165 to 175 lb - This should be your ideal weight. You look good with clothes on or off, you look great with a shirt off or in a tank top. Libido and energy level is great. You wear size M shirts and they look great on you, waist is around 30-31. You should stay in this range for life.

Great quote, probably my favorite

"There is nothing like a dream to create the future."
Victor Hugo (1802 - 1885)

Still training - 5k week 7

Still training. I repeated week 6 4 weeks in a row.

Back at work. I did 45 mins on the elliptical this morning and feel pretty good. Still kind of mulling over the results of my blood tests yesterday:

red blood cell count ok, white blood cell count ok, basically no anemia, no diabetes, testosterone level ok, thyroid ok (so basically I can't blame my inability to lose weight on my metabolism).

The one glaring thing is my high cholesterol - level is 245, ldl level is 165. Overall level should be under 200, ldl level should be beneath 160. My Dr. tells me that 250 used to be the cut off point for high cholesterol, so I'm right on the border - so I won't need to go on any cholesterol drugs like lipitor, but I need to keep watching my diet and continue with the running. I think when I hit 10 percent, or goal, my cholesterol will be about normal.

Back from vacation as well - I thought I had gained 4 lbs when I got back but I weighed myself this morning and I lost the extra weight, it was probably water. Running is going well I'm able to run 4 miles without stopping, times are good. Only 2-3 weeks to go til my 5k race.

The Case Against Overtime

really good article at the Caffeinated Coder's blog

The Case Against Overtime
Posted April 6, 2008

I remember reading the eXtreme Programming Core Practices several years ago and smirking when I got to the practice that called for regular 40 hour work weeks for programmers.

Like many of my fellow developers, I saw overtime as a geek badge of honor and felt pride at having enough stamina to regularly work 60-80 hours a week on my death march project.

Although I occasionally received half-hearted warnings from management to slow my pace down in order to avoid burn-out, the underlying message from above was clearly that my willingness to work long hours made me an exemplary employee and that overtime was one of the surest paths to professional growth and advancement.

While I may have agreed with the XP practice of capping the work week at 40 hours in theory, my traditional geek machismo prevented me from accepting it as anything other than a naive and idealistic goal that would probably never be gain widespread acceptance in corporate America.

That was then.

Now, when given a choice, I rarely opt to work overtime for my employer (at least not directly according to my task list). I would never hesitate to work extra hours prior to a release or due to unexpected production problems, but I now view anything more frequent than that as a serious problem and even as a potential reason to start looking for another job.

Why the dramatic change in attitude?

Here are some reasons that finally caused me to stop seeing overtime as a heroic effort and start seeing it as a destructive practice that is a sign of a seriously broken process within an IT organization.

1. Lost Opportunity Costs in Professional Growth - Once I completed a handful of large projects in my career, the opportunities I saw for professional growth started coming more and more from external sources outside of my job. While I still learn plenty during the day by observing my co-workers and attempting to solve common problems in novel ways, I often feel that my skills grow faster outside of work through reading, writing, presenting, social networking, and pet projects. It is sometimes tempting to spend 10 extra hours a week clearing the items from my daily TO DO list, but I believe that I am accomplishing much more for my professional career by devoting those hours to catching up on my RSS feeds, working my way through my tech book reading list, or exploring new programming languages instead.
2. Increased Professional Risk from Lack of Diversification - Everyone knows that diversification is the key to managing financial risk, but few people seem to apply this principal to their professional careers. Most developer shops are relatively limited when it comes to the number of technologies and problem domains they deal with. If you want to diversify your resume without job hopping every year, then it makes sense to actively seek out technology experiences that are different from the ones you use in your day job. By this reasoning, working overtime will increase your professional risk by reinforcing skills you already have whereas working on open source or pet projects that require you to learn new skills will mitigate your professional risk and make you more marketable should you ever decide to leave your current job.
3. Decreased Professional Passion - To paraphrase Jean-Paul Boodhoo, the best fuel for professional growth is always a developer’s joy and passion for his or her craft. I find it much easier to sustain this passion when I am allowed free reign to follow my curiosity. Work doesn’t usually allow for this type of unstructured exploration, but free time does.
4. Lost Productivity - Overtime work is highly susceptible to the law of diminishing returns. Spending long hours on the same tasks in a high stress environment leads to fatigue, which in turn leads to producing poorer quality work at a slower pace. When you factor in the time it takes to find and fix bugs and design flaws produced by overly tired developers, the net gain for twenty hours a week of overtime probably drops down to only a few hours while at the same time greatly increasing the risk to the project. Overtime just doesn’t yield the results promised by management Gantt Charts which provide an oversimplified view of the software development process by only measuring the quantity of the hours spent on tasks without also taking into consideration the quality of the time.
5. Poor Code Quality - Besides being more likely to miss obvious errors, developers who are under pressure and fatigued are far more likely to cut corners and engage in shallow thinking when it comes to design solutions. Besides driving up the long term cost of a project by making it more difficult to maintain, code quality issues can put the whole project or even business at risk by introducing critical errors and undermining customer confidence and loyalty.
6. Lost Personal Revenue - If you are a salaried employee and your are concerned with maximizing your personal income, then you should read this post by Max Pool where he points out that you are almost always financially better off to focus your time across multiple revenue streams rather than allowing your time to be sucked up by one job through excessive overtime.
7. The Usual Personal Reasons - These are all the usual things that workaholics neglect until it is too late, such as family, friends, health, and entertainment. Although I think they are among the most important reasons, many of us seem to have blind spots when it comes to these issues due to cultural biases so I chose to focus on other more novel arguments about overtime in this post instead. Nevertheless, these are some of the most compelling reasons to question any work schedule that consistently includes overtime.

If you are convinced about the evils of chronic overtime but don’t know how to break out of your current overtime cycle at work, then meditate on the following two concepts:

1. Time Should Be Fixed, but Features Should Always Be in Flux - If a customer went into a store and put more items in their shopping cart than they had money for, then they would reasonably expect to have to put a few items back while checking out. This is exactly how it should work in software, but the reality is often that customers naturally have a very difficult time connecting their feature requests to a real cost because IT departments have traditionally been so willing to hide the extra cost through overtime. Agile iteration planning and planning poker does a great job of addressing this issue by having developers assign a relative point cost to each feature, tracking an average velocity of points completed each week, and then only allowing customers to choose enough features to equal the velocity points in any given iteration. Besides providing a much more realistic expectation of what can be accomplished in an iteration, this approach emphasizes that developer time is a fixed resource and that feature requests must be variable based on continual assessment and reprioritization.
2. A Large Number of Proposed Project Features are Unnecessary and even Harmful to the Project - It is amazing how many "must-have" features suddenly become unimportant when a project is time-boxed and resource-boxed in an effective way. I’ve actually seen overall product quality and customer satisfaction increase in these circumstances because it helps focus stakeholders on what is essential about a project and aids them in more easily spotting bloatware features that would otherwise delay implementation, increase cost, and hinder usability without returning discernible value.

Sometimes you just can’t change the way your processes work or management thinks, but you can always change your own attitude by resisting self-imposed or peer pressure to work overtime. I’m guessing that the majority of overtime is not officially mandated, but rather manipulated through subtle peer pressure. If that is the case, just say no.

If your goal is constantly to maximize your own professional growth, then you’ll be surprised at how much respect you can still win without playing the overtime game. For example, who do you think is going to get noticed more, someone who closes a few more issue in the bug tracking system, or someone who is able to introduce a new concept, process, tool, or technology to the group because of work done in their spare time?

In conclusion, the next time the opportunity for overtime arises, ask yourself if you are really maximizing your professional growth or if you are just focusing too much on short term job goals and not enough on long term career goals .

5k training week 6 pt 1

I supposedly have a race 8/7 in Millenium Park. I've been training a *lot*, I'm sore and hungry all the time, but I can feel that it's getting easier. I did my 4 mile run on Saturday - my route was south on Lake Shore, past Belmont and back. I was able to run this without stopping for a long time and I wasn't that winded. I did feel a lot of soreness in my calves and ankles the next day however. I will be repeating week 6 training for the next 2 weeks, then resume the scheduled training. Holiday weekend, my diet was horrible as I was eating a lot of barbecue type goodies. I'll be going back to my regular diet of organic greens and such this week.