Work Sucks If We Let It

Its been a complicated week with several triumphs. But my colleagues are not so happy. I'm referred to the Hedonic Treadmill. wikipedia

aphorisms

You are what you do.

Solve system problems with systems, not people.

No good deed goes unpunished.

.

I work for a growing business. That means for some people the reward will be in equity. So be it. But learning to be happy in this environment leads to rewards too.

Thursday, 3:30pm. I get a message: what would it take to convert my application from A to B? When do you need it? I ask. End of day tomorrow.

I had considered making B before. I'd written a list of nine thing that would have to be done. I summarize those as three things, each vague, but useful to check-off progress. I respond: if we could do 1 & 2 today, then we could invest the time to do 3 satisfactorily tomorrow. Let's do it.

We schedule status meeting. 9am, noon, 3pm, online at 4:30. Each comes and goes with less done than hoped but with more clear direction forward. All left undone will be forgotten.

Everyone promised more time than they had. Why do we do that? Wishful thinking? But everyone did something needing done and maybe not anticipated. We all take what there is there and move forward.

Friday, 4pm comes and goes. B is in production. Kudos are passed. I suggest beers but put-off work must be done. So is this a good day? Damn right it is. You just have to know them when you see them.

My application addresses problems. Its existence makes the problems more visible, more interesting even. With this comes requests for variations.

The short timeframe meant that there would be little room for original work. I'd been refactoring and parametrizing so that would have to be the basis for revision.

I made one mistake that consumed an hour. My built-in tracing showed irrational paths. How could that be? I resorted to commenting out whole blocks of code to divide and conquer. I had tricked myself with a clever way to write a case statement.

prob = rand(100) return alpha() if (prob -= 30) < 0 return beta() if (prob -= 20) < 0 return delta() if (prob -= 15) < 0 return gamma() if (prob -= 10) < 0

I'd chosen this form to make the constants easily recognized proportions of the whole. The more classically nested version made interpreting the decision flow harder.

But, I had forgotten the return statements that stop the checking with the first success. Although difficult to find, the only reward was to be moving again. Little to be learn here except the tiniest bump in skill.

Computer programming is filled with many similar difficulties. The way to find lasting value is to remember what problems you are solving and cheerfully deal with the difficulties along the way.