How To Retrieve Your Phone From Behind The Washer

While this blog can be a bit all over the place, I do try to write mostly about topics where I am not the primary focus of attention. I hope to draw you in with the way I express ideas through my writing style, not through personal stories about my life. However, something happened to me yesterday that was just too ridiculous not to share.

The Accident

It all started because I had some clothes in the dryer that needed drying. I began to approach the dryer from the other side of my apartment while simultaneously checking the latest news on my phone.

While the rest of this experience is burned vividly into my brain, what happened next is all a blur to me. Somehow, before starting the dryer or putting my phone away, I bobbled my phone. And despite spending a large portion of my youth catching baseballs approaching speeds of 90 mph, I dropped it. Unfortunately, my baseball fundamentals decided to kick in at that very moment. Just like coach taught, I kept that bad boy in front of me. It bounced off my hand, into the wall, and slid down behind my washing machine.

Washing machine
My washing machine and the pit of despair.

I quickly donned my headlamp and grabbed my magnetic flashlight. As I peered over the top of the machine I could see my phone leaning up against the wall behind it. Then I stuck the flashlight to the back of the washer because I knew I would need lots of light for what would come next.

Magnetic flashlight
My magnetic flashlight.

At this point, I was still optimistic. A little irritated perhaps, but this seemed like it would be a minor inconvenience at most. As you probably have already guessed, I was dead wrong.

The Retrieval

Naturally, my first approach was to reach behind the washer with my hand and just grab the phone. Unfortunately, my arm wouldn’t even reach half way down the side, even with me laying on top of the machine and reaching over the back. In addition to that, the washer and the dryer are nestled into an alcove, making maneuvering around the side impossible.

At this point I had a choice to make. One option was to start moving the machines out of the way. There were a few problems with that approach. These machines are old, heavy, and wedged into that alcove pretty tightly. While I was able to slide the washer forward slightly, moving it enough to reach the phone was another matter entirely. I’m sure it was possible to shuffle these beasts around, but it seemed like a lot of time consuming hard work. I wasn’t too keen on it given that I was all by myself and I have to be a little extra cautious with my bad knee right now. I also didn’t want to risk unhooking any of the pipes.

Option two was to come up with a clever solution to my problem. This seemed like less work. Admittedly, it also seemed like more fun, so that might have influenced my decision making process. I will let you judge if I made the right call.

Idea #1: Slip Knot

My first approach was to fashion together a slip knot with some cordage I had lying around. See the demonstration below:

After following an online tutorial on how to do this, I carefully lowered my slip knot over the back of the washer to my helpless phone languishing in the depths below. It took me awhile to get the cord lined up with my phone because of the labyrinth of pipes and tubes I had to work around. When I finally got the loop up against the edge of the phone I realized I just didn’t have enough leverage to put it exactly where I wanted it. Any time I tried to pull the knot tight the loop popped off the end of the phone. The loop needed to be placed closer to the middle of the phone. What I really needed was another tool to lift the edge of the phone slightly off the ground.

Idea #2: Slip Knot + Tape Measure
Tape Measure
The tape measure.

A tape measure seemed like the best tool available to me. It had all the properties I was looking for. It was sturdy, yet flexible enough to work in a confined space, and also had the little metal protrusion at the end which I could wedge underneath my phone. The idea seemed promising in theory. In practice, however, it was less than ideal. I was able to lift up the phone with the end of the tape measure, but I didn’t account for the increased difficulty in lining up the slip knot with one hand while using the other to keep the tape measure steady. Perhaps having another person to help would have made this plan succeed, but with that option off the table, I decided to move on to the next idea.

Idea #3: Slip Knot + Tape Measure + Duct Tape
Duct Tape
The Great Equalizer.

Ahhh duct tape. The ideal solution for nothing, but an adequate solution for everything. Surely this potent combination would lead me to the promised land, right? My plan this time was to tape the end of the slip knot to the end of the tape measure like shown in the picture below. This would eliminate my problem of trying to line up both tools with separate hands. Unfortunately, adding the duct tape was a double edged sword. Now the dulled edge of the tape measure couldn’t get underneath the phone anymore.

Slip knot plus tape measure retrieval device
Slip Knot + Tape Measure Retrieval Device

Admittedly, I was a bit frustrated at this point. In hindsight I could have tried taping the loop in a way so that the metal protrusion of the tape measure was still exposed. I didn’t think of that though. Instead I moved on to my next idea.

Idea #4: Golf Putter + Card Board + Duct Tape + Slip Knot

The tape measure was out. Those things are already annoying when you use them properly, and I had had enough of its stubborn floppiness. It was time to bring out the big guns.

I grabbed my golf putter, a piece of card board, and some duct tape. Then I went to work. I used the piece of card board and duct tape to create a small platform underneath the head of the putter. Then I put some more duct tape on the bottom of this platform, with the sticky side exposed. The end result was a giant stamp that would hopefully stick to my phone.

Putter stamp retrieval device
Putter Stamp.

It took some deft maneuvering to get the putter all the way to my phone. It was definitely less nimble than the measuring tape when navigating through the pipes, and I paid the price for it. On the way down, I accidentally knocked off the flashlight which I had stuck to the back of the washer. Now I had two items to retrieve. Sitting there awkwardly on top of the washer, I started to question if I had made a grave mistake.

Nevertheless, I persisted.

The putter head was right next to the phone, and I began to experiment. I pressed the duct tape to the surface of the phone, and lifted up. To my great delight, it worked! The duct tape could only maintain its grip on the phone for a moment before letting it drop to the ground, but that was a much better result than I was getting with the tape measure. Time to bring back the slip knot. I carefully lowered it to the ground once again. Working these two tools in tandem I was able to lift the phone and tighten the knot around it. It was only a matter of time now.

Using all the concentration I had, I carefully moved the precariously positioned phone up against the side of the dryer, slid the putter and knot up the wall in unison, and snatched my phone back before it could drop again!

There was much rejoicing (By me, that is. Unfortunately there was no witness for my moment of glory). The flashlight followed soon after using a similar technique, but it was much easier because I was able to use the flashlight’s magnet to stick it back on the dryer again.

Conclusion

I try to wrap up my posts with tidy endings, but I have to admit, I’m having a really hard time coming up with any sort of moral to this story. So I’ll just leave you with a quote from the late great Arnold Palmer that, oddly enough, seems to fit the situation. Although I think he meant it in a different way than I do.

“Putting is like wisdom – partly a natural gift and partly the accumulation of experience.”

Arnold Palmer

As always, if you are enjoying the ideas I’ve presented or you think I’m crazy and want to tell me why I’m wrong, go ahead and subscribe to stay up to date with all the latest content.

Big Little Lies Season 1 Reviewed

Big Little Lies Season 1 Review

My girlfriend and I recently watched the first season of this show and thoroughly enjoyed it. “Big Little Lies” is adapted from a book by Liane Moriarty, which I hear is excellent, but have yet to read. The story revolves primarily around a group of wealthy women of Monterey, California, their families, and the complicated relationships between them. All of these women have young children that go to school together.

HBO put together a very solid cast, and the acting is top notch. The characters are interesting and well-developed, and to top it all off is a murder that ties all of their stories together in a very satisfying way. The show foreshadows a murder in the very first episode, but we do not know who the victim or the perpetrator is. More clues emerge as the story progresses and we get to know our characters better. While the murder keeps things moving forward, it is at its heart a character driven show that revolves around three main characters.

Characters

First, we have Madeline, played by Reese Witherspoon. Reese plays the same type of character she plays in almost every movie (Legally Blonde, Sweet Home Alabama, Walk the Line), and she does so to perfection. Madeline is funny, sassy, strong-willed, and assertive. She is the mother of two children from an earlier marriage with Nathan (James Tupper). One of her children is a first grader and the other is an angsty teenager. She remarried with Ed (Adam Scott), and their relationship is stable but contains elements of jealousy and is lacking in passion.

Next, we have the soft-spoken Celeste, played by Nicole Kidman. Celeste is a retired lawyer with twin sons, and she is long time friends with Madeline. She is married to Perry (Alexander SkarsgĂ„rd), and their marriage looks blissful on the surface. However, a more violent side of Perry’s nature begins to reveal itself as the season progresses.

Finally, we have Jane, played by Shailene Woodley. She is an independent single mother who displays a high degree of self-awareness. Jane is new in town, and her background is shrouded in mystery. She is quickly befriended by Madeline (who is always in everyone’s business) and Celeste. Jane has a son, but the father is not in the picture.

As season one of “Big Little Lies” unfolds we learn more about these characters and their struggles. It turns out a few little lies can have some big consequences. It all culminates in a way that is equally surprising and satisfying. The central theme I took away after watching season one was the idea that shared values can bring people together despite their petty differences.

Things I Liked:
  • Great character development.
  • Reese Witherspoon’s character is very funny.
  • Solid acting all around.
  • Not too predictable.
Things I Hated:
  • There is a pretty large plot hole around the big murder reveal that I found difficult to overlook.
  • Despite acting in various roles since the 90’s, Adam Scott will forever be Ben from Parks and Rec to me. It’s jarring for me to see him in any other role. Not his fault, but it is what it is.
All in all:
Thumbs Up For Big Little Lies Season 1

As always, if you are enjoying the ideas I’ve presented or you think I’m crazy and want to tell me why I’m wrong, go ahead and subscribe to stay up to date with all the latest content.

This post contains affiliate links, meaning, if you click through and make a purchase or sign up for a program, I may earn a commission. This is at no additional cost to you.

You and I – Ingrid Michaelson (Song Cover)

song cover music note

My girlfriend and I sang a cover of the song “You and I”, originally performed by Ingrid Michaelson. Hope you enjoy!

As always, if you are enjoying the ideas I’ve presented or you think I’m crazy and want to tell me why I’m wrong, go ahead and subscribe to stay up to date with all the latest content.

This post contains affiliate links, meaning, if you click through and buy something, I may earn a commission. This is at no additional cost to you.

On Single-Issue Voting

Horses with blinders as an analogy for single-issue voters

In my last post I made the case for why being pro-life is the morally correct position to take. My friend Daniel incorporated my post into his own thoughts about a another related topic: single-issue voting. We got to talking, and I then I got to thinking. Is being a single-issue voter a good or a bad thing?

What does it mean to be a single-issue voter?

My gut-level reaction is
it depends on what the term “single-issue voter” means. One possible definition is somebody who puts on blinders and only casts his vote based on what is being said about a single issue. This seems like an obviously bad approach to politics. Another possible definition is somebody who pays attention to what each party is saying about a range of different issues, understands the trade-offs being made by each, and then still makes a decision that is influenced very heavily by a single issue. I think this can be a good way to approach politics, and is the definition I’ll be discussing for the rest of this article.

A moral imperative

In certain situations it could be considered morally imperative to be a single-issue voter. Building on the analogy used in my previous post, who could argue with 20/20 hindsight that the abolition of slavery wasn’t worthy of single-issue voting? Or voting against the Nazis when they were coming to power? The key ingredient here is an awareness and understanding of the times. Assuming you have full confidence in your opinion on the issue itself, the biggest factor you will have to wrestle with is all the other positions you are also implicitly casting your vote for. The net benefit/harm of the policies each party stands for should weigh into your decision.

Let’s take the abortion issue as an example. It’s hard to imagine another issue today that would be a better candidate for justifying single-issue voting. The merits and drawbacks of different policies can often be endlessly debated without a clear consensus emerging about their effects. But with today’s abortion policies, we are allowing the direct termination of innocent lives for the sake of convenience. We couldn’t even get a ban after 20 weeks through the Senate, and it included exceptions for the life of the mother and for rape or incest. That is appalling. Personally, it’s very difficult for me to cast a vote without the huge weight of this factor disproportionately influencing my decision making. If you are against this piece of legislation, I frankly do not care what you think the minimum wage should be.

Maintaining awareness

Now let’s say, for the sake of discussion, that all of a sudden the pro-life party started campaigning on hauling a certain group of people off to Nazi style concentration camps. Well now the case for single-issue voting on the abortion issue has been weakened quite a bit, to say the least. The situation has changed and now the calculation must be performed again. No matter how grave the issue, single-issue voting should be accompanied by a continuous reevaluation of the political landscape.

Conclusion

In short, I don’t think single-issue voting should be your standard operating procedure. But if you arrive there after some deep thinking, there is a chance you might just be on the right side of history.

As always, if you are enjoying the ideas I’ve presented or you think I’m crazy and want to tell me why I’m wrong, go ahead and subscribe to stay up to date with all the latest content.

Software Estimates Are Hard

Hopefully we are better than this…

I suck at software estimates. And I bet you do too. So many software projects get delivered late. I am getting better at them, but it is going to take time. Let us consider a few reasons why they are so challenging.

Not Enough Time

This is a problem that is often overlooked. Worse still, managers often do not understand that this a problem in the first place. There seems to be this idea in some of their heads that developers know how they are going to solve the problem as soon as it is given to them.

The reality is that developers are often given tasks so poorly defined that they barely even understand what the problem is. They have to dig through unfamiliar code. What snares lie in wait for them there only God knows. Even after digging though that code and hounding people for better requirements, they only have a faint idea of how they are going to approach the problem. And the approach will likely change tomorrow.

So if a meeting gets called to introduce a brand new project and get a rough estimate of how long it would take, that estimate is going to be wrong. It is just guess work at that point. Coming up with a reasonably accurate estimate takes work, and steps cannot be skipped.

Sometimes we don’t even have time for that’s what she said jokes.
Not Breaking Things Down

This is such a simple concept, yet I am guilty of neglecting it all the time. How many of these lines do you catch yourself saying?

Ummm it would maybe take a sprint or two?
I should have that done in a few days.
I don’t see it taking more than a week.

You can hear the underlying message. The person uttering phrases like these has not broken down the development task at all. Does this developer know which methods he is going to write? How the different components will interact with each other? How the code behaves today? What automated tests need to be written? The only effective way I’ve found to produce reasonable software estimates is to estimate small things and add them together. The bigger the task is the worse we are at estimating it because by its very nature we are omitting important details. It is much easier to accurately estimate “Write a method that checks if a string is a guid”, than it is to accurately estimate “Write a point of sale system”. The further you can break down your tasks the better off you will be.

Forgetting About Other Stuff

We are all more than our jobs. We have a life outside of work, and sometimes we forget about that when we are making our estimates. Vacations and doctor’s appointments should be considered. If you are a leader on your team you also need to consider how your absence will affect the more junior members of your team. Will you need to leave more concrete direction for them? How much time will that take? You also need to think about what a typical work week looks like for you. The truth is, on any given day we often find ourselves working on just about everything except what we thought we were going to. Those disruptions and urgent requests can be really unpredictable, but they must be considered in order to produce realistic estimates.

How can we get better?

The first step in getting better at software estimates is to communicate well with your manager or product owner. Ask for some time to come up with an estimate. You probably won’t get as much time as you want, but it is way better to put a little thought into your estimate than to put in no thought at all. This is crucial because you can’t break down the task instantaneously. This step must happen for any other advice here to be helpful. With this accomplished you can begin to plan the work and start uncovering the time consuming tasks that are currently shrouded by the veil of your ignorance. If you can identify these up front you are really helping yourself out. That is really the key to it all: gathering more information about the future. The more information you have the more accurate your estimation will likely be.

It is really a shame my manager won’t let me make my estimates after the project is complete. I would be perfectly accurate!

How A Web Application Works: An Epic Tale of Courage and Sacrifice

how a web application works featured image

The smell of blood fills the air. At Camp Client, the battle rages on. The Empire of Users have been relentless in their assault against the Browser Alliance. While the Chrome and Firefox Battalions have been handling the swarm with commendable bravery, the Internet Explorer Battalion is suffering heavy casualties. Leadership is sorely lacking. As pressure from the Users mounts, the regiment desperately needs instruction and supplies from Server Headquarters so that a swift response can be made.

Unfortunately, the geography of the surrounding countryside impedes communication efforts. Server Headquarters is not far away, but it is situated on the other side of the deep, dark Internet Chasm. The only way across is a narrow, rickety collection of rope and wood called the HTTP Bridge. This bridge is unstable, goes through a wall of fire, and is really only useful for sending messages and a handful of supplies back and forth. But it is an extremely important and strategic link. Without it, communication would be lost as would any hope of victory.

A young squire is sent with a request in hand across the bridge to bring word of the camp’s needs to Server Headquarters. The journey is not for the faint of heart, but when you’re a grunt you have no choice but to be courageous. After making the perilous journey across the chasm he presents the request to Officer Web Server.

Officer Web Server has the noble task of accepting requests as they come across the bridge and delivering them to the right people. However, he is a little socially awkward, and most of the time he gets his charismatic best friend, Officer Application Server, to do the heavy lifting.

Officer Application Server rubs shoulders with all of the Java Generals, and knows which ones he should pass on the requests to. Sometimes this dynamic duo has trouble finding the correct general, but that is usually only because the request was lacking in information. The communication protocol has been well established, so you can hardly blame them for throwing out bad requests from careless soldiers. When these two are given a message that is not malformed they are a shining example of discipline and reliability. Luckily for the Browser Alliance, the message they receive from the young squire is crystal clear. They deliver the message to the correct Java General with great haste.

Now the Java Generals did not rise to their station in life by accident. They are smart, capable planners with deeply strategic minds. They are intelligent, but also wise. Few of these generals make any decisions without first consulting the Great Oracleℱ. Only then will they decide what to provide their men back at Camp Client. After ending their session with the wise old master they know what they must do. Unfortunately, details are not their strong suit and they tend to be a little verbose. If they were the ones who had to communicate the message and package up the supplies the war would surely be lost.

Fortunately, this is what Officer Template Engine was born to do. He knows what the Java General wants to say and communicates this information articulately. He drafts the final response and gathers the supplies that get delivered back to Officer Web Server and sent with another poor young squire across the HTTP Bridge.

Camp Client is overjoyed upon receiving the response. Much needed supplies of HTML, CSS, JavaScript, and memes have been brought to the front lines. The soldiers survey the bounty that lies before them. “Just wait until those Users see this”, one combat veteran remarks with satisfaction. The other soldiers nod in agreement. They will live to fight another day. Many soldiers have been lost in this great war, and many more will be cut down before it is over. Though their names may change, the legend of their bravery will never fade away. This same story will be played out again and again as long as good men stand against the forces of darkness.

Getting Bit By BigDecimal

I recently wrote some Java code to a port an existing feature into a newer architecture. In a nutshell, what this code did was take a fixed total price and recalculate what the unit price and discount should be at different quantities. Being the well meaning, responsible developer that I am, I decided to refactor the logic to make it easier to read for the next poor sap who would have to come behind me. As is so often the case, that poor sap turned out to be me.

One of the things I decided to do was put the data in a real object. Like much of the data in the legacy application that I battle with on a daily basis, this data was “Stringly typed”. The whole app is littered with List<String>, Map<String,String>, and the abomination of desolation that is the List<Map<String,String>>. This code was no better, and half the logic was just converting between Strings and BigDecimal objects. So I decided to be the hero that Gotham deserves and replaced these horrid beasts with real data types and real objects.

I confidently released my code into production. Unfortunately, I also released a bug into production. In the original implementation, an error was thrown if the amount was less than $0.01, but not if the unit price was $0.00. In my buggy implementation, an error was being thrown when the unit price was $0.00. I was confused. I was presented with the holy grail of unchanging, well-defined requirements. All I had to do was make the code do what it did before. How could this happen? After digging into the code the problem was obvious. I had gotten bit by BigDecimal.

First, the fix. I had to replace the red line with the green line like so :

At first this had me scratching my head. Why didn’t zero equal zero? Well, according to the documentation , the equals() method considers two BigDecimal objects equal only if they are equal in value and scale. The compareTo() method, on the other hand, will not consider scale when evaluating equality.

Luckily the fix was simple, but I was frustrated that I didn’t catch it before release. The problem reminded me of a few valuable lessons in crafting software.

The first is to read the manual. I’m a big believer in writing self-documenting code and using comments sparingly to document ideas that you can’t express in code. However, if you are going to use code that somebody else wrote, you better know what it does. In my case that was the Java standard library, but the same principle applies to any third-party dependencies that you are leveraging. Unlike most closed source internal software, major libraries and frameworks have nice documentation that is kept up to date. Reading the documentation for those libraries is how you learn to use them effectively. On top of that, read the code itself.

The second is to write automated tests. I didn’t do it because I was working with legacy code and it would have been a pain in the butt. I should have done it anyway.

The third is that building software is rarely as simple as it seems. Doing it professionally for a few years will pound humility into you pretty quickly. Still, as you see the same problems repeated over and over, it is easy to become cocky. The devil is in the details, and we often stumble over the simplest stuff because we don’t pay close enough attention. On many occasions I have seen large, risky projects released with a few minor bugs and small projects released with SLA violations and data loss. I think this is because we do a better job of testing and code reviewing when we feel the risk is high. We would do well to remember this phenomenon when we begin to think we are God’s gift to programming.