Working 40 Hours in 3 Days? Possibilities for Making it Work

I've been thinking about different kinds of work schedules. I found this poll interesting:

http://boards.straightdope.com/sdmb/showthread.php?t=608388

Question: If you could choose your own work week hours

Responses:

5 hours, 42 minutes/day, 7 days a week		0	0%
6 hours, 40 minutes/day, 6 days a week		0	0%
8 hours/day, 5 consecutive days a week		10	12.35%
8 hours/day, 5 non-consecutive days a week		2	2.47%
10 hours/day, 4 consecutive days a week		32	39.51%
10 hours/day, 4 non-consecutive days a week		9	11.11%
13 hours, 20 minutes/day, 3 consecutive days a week		13	16.05%
13 hours, 20 minutes/day, 3 non-consecutive days a week		1	1.23%
20 hours/day, 2 consecutive days a week		0	0%
20 hours/day, 2 non-consecutive days a week		0	0%
40 consecutive hours a week		0	0%
40 varyingly distributed hours (i.e. something else)		11	13.58%
I'm retired		3	3.70%

So, is it really possible to do 3 straight days, 13.20 each, and then have 4 days off each week?

Of course, it is possible if you can swing it and really want to.

Some variations:

12:05 - 6:05 AM sleep
7:00 - 1:30 6.5 hours work
1:30 - 2:15 lunch
2:15 - 3:15 nap
3:15 - 6:45 3.5 hours work
6:45 - 8:45 dinner, socialize/family, exercise (whatever you want)
8:45 - 12:05 3 hours, 20 minutes work

Maybe you'd prefer to exercise from 2:15 to 3:15 instead of nap, and do an evening nap later before the last sprint, but whatever.

If you could get by on 6 hours nightly sleep PLUS the nap during the day or evening.

Or maybe you could try two 6:40 segments from 7 to 1:40 and 5:20 to midnight.

Alternative to three day: 3 big days, 1 tiny day

The more I think about it, the more I like the idea, in general, but 13:20 seems to push it a bit too far.

How about:

7:30 - 1:30 work (You can eat some snacks while working to tide you over before lunch; besides, isn't it said you should have small meals throughout the day anyway?)

1:30 - 6:00 free time. Eat, drink, visit friends, family, do errands, and take a nap after an earlyish dinner. Sleep from 5 to 6 to get your second wind ready.

6:00 - 12 work

This ends up at 12 hours. Or maybe you could handle 7:30 to 3:30, followed by 8 - 12. You get the picture.

The Numbers Game

After 3 days, it's 36 hours worked. On Thursday morning, you do 4 hours of review and preparation for the next week's worth of work.

But, the big benefit is now it's noon on Thursday, and you have 3 and a half days completely to yourself, your family and friends, and your own goals.

Lots of small excursions or even just local travels can be done in 3.5 days. 

Suppose you have 3 weeks off and 10 holidays. You probably still end up working something like 1,880 hours a year.

There are 8760 hours in a full year. Subtract 8 a day for sleep. You're still left with 5840.

So, you already have about 3960 to yourself. That's 100 more than twice 1,880!

The Trouble With Today's Work Environments

So, why is it so difficult these days to actually feel like you're not working all the time? Maybe it's because you actually are, in your brain.

It's not always possible to "just turn off" your brain when you're working on difficult, and interesting, problems to solve.

And, when you work in technology, sometimes a "schedule" like 9-5 is a ridiculous thing to even talk about. Creative problem solving work is not the same thing as assembling parts in a factory that have *already been creatively designed by someone else long ago and made into a formulaic process to follow*. It can, and should, be mentally exhausting work to create technological products and services properly.

Poorly designed technologies often result when people are completely burnt out and treated as if they belong in the long out-dated stereotypical factories of the 19th and 20th century.

Work Hard, Recover Harder

A lot of self-styled "rugged" or "progressive" companies adore the phrase "Work Hard, Play Hard", or something like that. Often this works out to something more like:

"We own this company, and you work for us, but we also like to have fun -- at least, the kind of fun that we deem to be fun, and therefore you also should deem to be fun. Therefore, when you are here, you will work hard, and we will inject our form of 'fun' into the day in order for you to see us as a company that also 'plays hard'."

Needless to say, this is misguided.

Daniel Pink's Drive and the Results Only Work Environment

Have you read Drive, by Daniel Pink? If not, have you heard what BestBuy's corporate office did? They turned themselves into what they call a ROWE, a results-only work environment. Here's more about the people who pioneered the concept:

http://www.gorowe.com/

Results-Only Work Environment goes beyond telework. It's a management strategy where employees are evaluated on performance, not presence. In a ROWE, people focus on results and only results – increasing  the  organization's performance while cultivating the right environment for people to manage all the demands in their lives...including work.

Think this is just a gimmick, that BestBuy is a fluke? Think again. How about these companies:

http://www.gorowe.com/about/clients/ 

Are they flukes too? Gap, Banana Republic, etc. 

Personal Summation

In the modern age, it's ridiculous to expect creative, skilled knowledge and information workers to want to work the "routines" of the 19th and 20th centuries. Obviously, companies like BestBuy Corporate, GAP, etc have found better ways of working and retaining talented thinkers and leaders.

Working 9 to 5 (or 7 to 5, or whatever) 5 days a week is not a badge of honor. It's often a curse, because many of us do not, cannot, simply be "present" for x number of hours and turn off our brains and attend to "the rest of life". We are goal and results-oriented, and want to create valuable results by working long hours that require intense concentration and attention to details that often get overlooked.

So, in a culture that, at large, has not yet adapted to the mental and creative demands of the 21st century, we must find ways to "put in our 40" creatively, and in a sustainable way.

For me, that definitely means giving a short at "4 10s", or even "3 12s and a 4".

Wish me luck.

Test

test

Leading Technical Teams is Not Like Managing an Assembly Line

Often times people who grew up in another era or time equate management with "task mastering". This is unfortunate when it comes to the management of software projects, because it's not an effective way to manage people, products, services, or projects.

I don't have much to say that has not been said better elsewhere on this subject.

Two good references are Mary Poppendieck's presentation named The Role of Leadership in Software Development:

http://www.youtube.com/watch?v=ypEMdjslEOI

And, Daniel Pink's book Drive: The Surprising Truth About What Motivates Us:

http://www.amazon.com/Drive-Surprising-Truth-About-Motivates/dp/0143145088

Sonatina I Progress, the Wisdom of Slowness in Music Practice, and Agile Songware Development

I've decided to mostly keep just one blog and start doing a better job with tags for separating out categories. In that spirit, this one is for my own tracking of piano progress. But, it will have some tangents with agile, anyway.

A few years ago when I decided I wanted to stop just toying with "Alfred's All in One Adult Beginner Course", I realized I needed to focus on one complete song, from end to end. I even joked with a coworker who I had helped introduce Scrum at a company with that I was going to work toward a "potentially performable songware increment", like Scrum's "potentially shippable software increment".

This absolutely worked for me. I focused on learning a relatively short song called "October", a song that features mostly piano, from the 1981 album of the same name by U2. I picked this because I remembered long ago wondering what I would have to do to play it if I actually knew how to play piano.

But, it also reminded me of my aunt Kara, because she had introduced U2's music to me when I was 10 years old in 1987 by handing me a copied tape of The Joshua Tree, complete with a photo-copied insert cover.

Kara was by this later time in 2008 ill with Lou Gehrig's disease. I wanted to be able to play the song someday for her. I soon became proficient enough with the song on my little electronic keyboard, and recorded it on MP3 and sent it to her. Later, after she passed away in early 2011, I performed the song at her memorial service, which was about a year ago now in June of 2011.

For me, someone who had only played a recorder in 2nd grade, to ever have imagined myself performing anything musical in front of people was a big confidence booster. I did not make any glaring mistakes either, which I was also happy about (phew!)

During the process of *learning how to play that first "playable song increment"*, there is no way a teacher would look at what I was doing and say my form was correct, or that my fingering was optimal.

I had one teacher as Little Five Points Music Center, Natia, who helped me get through that first song and started me on what has become a more "methodologically sound" approach to learning, which includes understanding reading music, understanding scales, intervals, chords, modes, etc.

But, again, in the beginning, I simply forced myself, note by note and measure by measure to figure out which keys to push down with the right hand and which to hold down with the left hand, and eventually when to push the pedal with my foot -- which I still don't have totally correct.

I have now been taking lessons with Charles Hutton, from Charles Hutton Piano Studio, for almost a year now after that first performance. He has helped me start from where I was to progress through playable "increments" of music that teach the fundamentals of scales, chords, inversions, and intervals. Each song has helped me to experience the important satisfaction of adding to my reportoire, or my "portfolio" if you will, while also learning about those musical theory concepts.

I would, as I am sure he would, still classify myself as an "Advanced Beginner". But, if you are the kind of learner, like I am, who cannot sit still, physically or mentally, without a combined practical and theoretical understanding, then I would definitely recommend Charles and his approach for learning.

Touching back on agile software, we know that Iteration is fundamental to Incremental delivery. That,is, one must build a software module in an iterative fashion. Iteration means approaching the analysis, design, development, deployment, and testing in repeated cycles. This is coupled with incrementalism, which means approaching the problem by breaking the large goal, the entire system, into smaller slices.

During each iteration, learning happens. This learning then feeds back into the next iterative step. This process cycles round and round and continues to pull in more and more incremental slices of the system as it goes. This process resembles the "Plan Do Check Act" approach, and even the basics of the "Scientific Method".

Given a piece of music, it is already replete with requirements! After all, the sheet music is staring you in the face. All you have to do is read that requirements document and just play it.

Of course, a software requirements document is rarely anywhere near as complete or unambiguous as a sheet of music is. No, not even close, and that is a subject for a different day.

It is actually highly possible for well trained, seasoned musicians, of course, to sit down in front of a piano and play directly from the sheet music the first time they see it. Sometimes in one sitting they can get it "right". Even then, they will rarely feel like they did it perfectly the first time, and will repeat it many times before feeling proficient.

I have been struggling to feel any real progress recently in learning new songs, partly due to lack of practice time, but partly due to gaps in my approach, which Charles has helped me to see and approach differently, and in fact much closer to the way I develop a software program anyway.

Here's how:

First, from reading Neil Miller's The Piano Lessons Book, I became convinced of the "Learn it Backwards" method, something Charles also said other teachers call "The Reverse Brick Laying Method".

This means take the last two measures of a song, learn those FIRST! Then, add measures backward toward the beginning.

Why? Well, when you start to play back what you have practiced this way, you start at what you more recently learned, and have played fewer times, and progress toward measures you have played more often.

Since you have played them fewer times, you are more likely to make a mistake on those, and will thus waste less time than if you were to always play back from the beginning and into less frequently practiced measures toward the end.

However, Charles helped me to start to logically segment pieces into phrases and groups of measures that flow well together. So, in my current piece, Sonatina I by Thomas Attwood, we have marked off measures 17 to 24 as a logical group.

Within that, we have:

17 to 18 Right Hand
19 to 20 RH
17 to 20 RH
21 to 22 RH
21 to 24 RH
17 to 24 RH

Then, same thing but with Left Hand, or bass.

And, then trying them with both left and right hands.

As you can tell, this is the epitome of an Iterative, and Incremental development process.

And, it is also an iterative and incremental analysis, design, and delivery method.

Here is how Charles has explained what should happen when practicing this way, and what it should feel like:

When playing 17 to 18, do it slowly enough to play the notes correctly, and with the correct fingering, ignoring the rhythm count for the moment.

Next, try it again, slightly faster.

If I make a mistake, then learning has not happened properly yet, and something is wrong. Stop the line. Correct it immediately. Go back.

But, wait, here is where we diverge from "Lean Manufacturing" and it's "stop the line" mantra you may recognize and move closer into agile software, at least the way I see agile.

As Charles explained it, helping me get past my reluctance to move further into more measures, you MUST move forward when still uncomfortable, and while still *making mistakes*.

That is: yes, stop and fix the measure, to a point. But, after correcting it to a sufficient degree, expand the surface area of practice. Move down to measures 19 and 20. If you flub on those, also stop and fix, but only to the point of basic comfort.

Then, cycle back (iterate) on measures 17 through 20.

Again, this iteration should procede slowly enough to get the notes correct the first time. But, next it should be played at a more uncomfortable, error-prone pace.

When making errors at this pace, seek to "pin point" where, and then "zoom in" on those points.

Are they transition points?

Are they fingering oddities or shifts?

Incorrect fingerings?

Incorrect timing? Held a note too long, not long enough?

The diagnosis will vary from "fracture" to fracture, now zoom in and correct it in *isolation*, or in collaboration with adjacent measures to assure smooth entry and exit.

According to Charles, doing this will NOT feel comfortable, and mistakes and fractures will happen. This is expected and good, and the remedy is the iterative process, the repeition, the cycle.

What mitigates against the failure besides the repitition? What ensures eventual success?

Well, quite simply: your own ears and others' ears. The expectation of correct playback is already encoded in our ears. We will know it when we hear it. Fair enough.

The parallel to software development here is more nuanced. We cannot know that a subsystem of function works by hearing or seeing it! Most of software happens below the user interface, and nobody ever sees or hears it.

This is why the test-driven, unit-test covered, and acceptance-test driven approaches to software are so important.

TODO: fnsh