The Pursuit of Simplicity

Recently I read Seven Brief Lessons on Physics by Carlo Roveli. True to its title, the book is brief, and clocks in at a scant eighty-one pages. Its beauty is in the nearly poetic brevity and the expressive nature of the word choices the author (and translators) use. Unlike massive scientific tomes on particle physics I once attempted to read as a 12-year-old boy, Roveli’s book is written in a way I could have understood even as a young boy.

The book brought me a remembrance of the elasticity of young minds with its references to young physicists like Einstein, and his solving massive problems with simple solutions at a very young age. The book inspired me to write, and this is the result.

Fractal_tree_bbc

Anecdote Time

When I was a first-grade elementary school student, I recall having a tough time memorizing multiplication tables as students were taught to do at the time. Ever precocious, I wanted there to be some rhyme or reason, a pattern even, to the way we determined the values of these simple mathematical expressions. No, I was told, you just have to add the number you are multiplying by to itself the number of times the multiplier expresses.

For a young, and frankly lazy, Willy Munn, this was an annoyance at best for a number like one, two, and three; and completely unbearable for the silly number nine. You see, not being able to use a calculator or a multiplication table, and being required to show my work meant writing out nine addition problems just to “show my work” and get an acceptable grade.

My young brain started looking for a better way. It wanted to enable the laziness my heart so desired. It wanted to find a way for me to skip writing out these problems and allow me to go back to reading or playing with Lego blocks or watching the Superman movies I taped onto VHS from TV. I WANTED some rule as simple as “1 times anything is the number being multiplied” or “10 times anything is the number being multiplied with a 0 tacked onto the end”. I started to see patterns (we are talking about math after all, which is nothing without patterns). A solution for the ridiculously tedious number nine came first.

Looking at the following multiplication table, I unconsciously looked for patterns I could exploit. What patterns do you see?

1*9=9
2*9=18
3*9=27
4*9=36
5*9=45
6*9=54
7*9=63
8*9=72
9*9=81
10*9=90

I noticed the following in this approximate order:

Reversed Pairs of Numbers as Results
This was the first thing I noticed. 18 and 81, 27 and 72, and 36 and 63 all the results on opposite ends of the table form numeric palindromes. Even 09 and 90 technically work.

Everything Adds Up to Nine
Next, I realized that the first and second digit of every result always add up to 9. This seemed like something exploitable, and I saved the knowledge for later use.

First Digit Is The Number Being Multiplied By Minus One.
Eureka! I had a formula (even if I didn’t know that’s what it was called). I could take any number one through ten and subtract one from it for the first digit. Then I could subtract that number from nine to get the second digit. Simplicity itself!

I took my solution to Mrs. D, my first-grade teacher, for confirmation. I just knew she would be so happy and proud that I had found a better way to do multiplication by nines.

My youthful supposition couldn’t have been farther from the truth.

A study in human nature, being an interpretation with character analysis chart of Hoffman's master painting "Christ in the temple"; (1920)

Mrs. D. assured me that this was not the proper way to do the math and that I must write our all of my answers as she had taught. Needless to say, if young Willy Munn was a thing besides lazy, he was stubborn. I dug in my heels, so to speak. I refused to do this work stating that I would sooner die than do unnecessary work after I had found a better solution. Predictably, Mrs. D marched me right down to the principal’s office and demanded that he deal with my insubordination. She suggested corporal punishment if necessary.

The principal of my elementary school, Mr. F looked at me with kind, wise eyes, mostly gray hair, and just a quirk of a smile on the edge of his lips, and asked me to explain my method to him. I was nervous. I didn’t know what this corporal punishment was, but it sounded serious. With sweaty little palms and a mildly shaky voice, I explained my idea for the number nine. Mr. F asked some thoughtful questions and proved my hypothesis on the blackboard in his office. Then, to the joy of my young heart, he said the words I had so desired to hear from Mrs. D, “Willy, it looks like you’ve come up with a better way to solve this problem. At least for you.” Then the golden words of freedom, “Mrs. D, since this proves out, it shouldn’t be necessary for Willy to write out all of his multiplication solutions should it?” Mrs. D grudgingly agreed with her boss, although I’m fairly sure she held a cold, dark place in her heart for me for the rest of the year. In retrospect, maybe I shouldn’t have challenged her so directly, but I was 6 and thought the world revolved around me.

Mrs. D grudgingly agreed with her boss, although I’m fairly sure she held a cold, dark place in her heart for me for the rest of the year. In retrospect, I shouldn’t have challenged her the way I did, but I was six and thought the world revolved around me.

I went on to “discover” patterns for other simple multiplication problems that saved me a bit of time over the years, and even eventually memorized all the basic times tables. For several years, I got away with doing all of my math problems in my head and never showing my work. This irritated my teachers to no end and probably is what made learning manual Calculus feel like one of the most tedious tasks I’ve ever undertaken.

Many years later, while attending Southern Utah University, I learned additional math practices in my Discrete Mathematics class that used similar patterns and approaches to my early experimentation. Fun realization, that.

The Point (There Is One)

I knew, even as a youth, I had spent more time working on this solution than it would have taken just to write out the problems as I had been asked.

Today, I recognize my solution as less simple from the Mrs. D’s viewpoint. She was giving students one tried and true way of solving all multiplication problems. While it wasn’t easier for me to achieve my work, it was certainly simpler to teach. Just because there is a pattern or formula, doesn’t make a solution better based on that merit alone.

A fractal bacteria colony may BE simple once you understand it, but at first glance, it seems strange and complex.

fractal_bacteria_colony
Fractal Bacteria Colony

All anecdotes aside, the pursuit of better, simpler solutions is one that I’ve been chasing from a young age. It is the same pursuit of any scientist including the computer scientist. Let’s not forget this as we write code. Our ultimate goal should be the simpler solution because it will lead to better, more maintainable code. It will save time overall even if there is an opportunity cost up front.

We must remember that what is simpler from our particular point of view may not make sense from another’s perspective. A simple solution is only as good as our colleagues’ ability to grasp it.

Agile Teams Don’t Always Have Tech Leads, But When They Do…

I queued this post last year when I was a Technical Lead for an outstanding scrum team at HealthEquity. The role was new for me here, although I’ve had leadership roles at several companies over the years.

A Little Background

Our team consisted of six people who had never worked together directly. We not only found a way to meet the requirements of the project, but we also did it on time, on budget, with little overtime, and quite a lot of team fun.

At any rate, the team was very successful, and its success was noticed. It resulted in considerable renown for the team. Credit where it is due: the team’s success belongs to the entire team. My role certainly wasn’t more significant than any other. If anything, it was less important.

I’ve been asked by several people how we did it. My answer, as always, is that we have an awesome team. As a contributing member, I shared some of the load. Maybe my philosophy as a tech lead within the team helped as well. I’d like to think so.

agileTeamsDontAlways

My Tech Lead Philosophy

Top Tier Things To Not Forget

  • Principle #1: Respect the opinions of everyone. We are all professionals.
  • Principle #2: Make other team members’ jobs easier.
  • Principle #3: A tech lead isn’t the only person who has great ideas.

Also Good To Remember

  • Patience. Patience. Patience. Patience. Patience. Patience.
  • Give guidance by asking questions. It isn’t always possible, but it usually is.
  • Free team members to focus on sprint work by being the first point of contact.
    • I choose to address this by sitting at the entrance to our team area.
  • Encourage team members to learn by taking tasks that challenge them.
  • Take sprint tasks that don’t interest other team members when possible.

Probably Best Not To Do This Stuff…

  • Dictating solutions and stifling creativity.
  • Taking all the fun tasks for yourself.
  • Interrupting people unnecessarily.
  • Wheaton’s Law: Don’t Be A (Jerk).

————-

Obviously, I’m not perfect in any of these things. I do find that having the philosophy helps point me in the right direction. I hope it helps you as well.

Interested in technical leadership? Start by leading some coding katas for your team.

As always, write a comment below or hit me up on Twitter with questions or comments. Until next time.

Learn Like A Viking

My friend Ron Coulson (who I’ve known practically forever) has challenged himself to write a poem a day this year. He is well underway. This is #63 of 366, because, you know, leap year.

I’ll be the first to admit I’m no poet, but the subject matter here is near and dear to me — learning! I also enjoy a good metaphor and the Viking theme here is vivid and wonderful. Overall, it struck me as fantastic and I thought I’d like to share it with you all. Ron generously agreed. I hope you enjoy it as much as I did!

drinking-horn

Untitled

Let us devour knowledge in a way
That would make vikings cringe
Let’s gorge ourselves until we
Vomit certainties no one can dispute
Let truths drip from our chins
As the spittle of enlightenment
Lands in our opponents eyes
Raise your mugs, my friends
Then chug down life’s lessons
Until we are drunken sages
Then sleep
Then do it all again

-Ron Coulson (2016)

If these words have inspired you to learn, check out the new page I’ve added to the blog where I’m attempting to keep track of some of the best coding katas. Try one out. Let me know if you have favorite katas you’d like to see there.

Quotable Quotes: Henry Wadsworth Longfellow

maxresdefault

Today I had the pleasure of reading A Psalm Of Life by Henry Wadsworth Longfellow. The following is the last line:

Let us, then, be up and doing,
With a heart for any fate ;
Still achieving, still pursuing,
Learn to labor and to wait.

Recently, Richie Franklin shared this beautiful psalm by Longfellow with my writer support group. Regretfully, I couldn’t read it when he posted the poem, but I opened it in a browser tab for future perusal. I’m a terrible tab hoarder and will keep as many as 50 open at once.

Time passed, as time does, and soon at least a month had gone by — I know, I’m pathetically busy at times. Today I had a little more time on my hands than usual, and I started closing out ancient tabs by reading them or by deciding they weren’t important and killing them without wasting my time. I’m so glad I was able to be in the right state of mind to read and enjoy this beautiful work.

Much more eloquent than I could even aspire to be, Longfellow reminds us to be present in the present, work hard, be patient, and enjoy the fruits of our labors. Oh, and make the best of everything life has to offer.

Wonderful advice for this era of near-instant gratification.

This post brought to you by the most patient dog I’ve EVER SEEN:

giphyPatientDog

Interview/Hire Great Devs: Part 2

This is the 2nd and last post on hiring great developers. You should probably read Interview/Hire Great Devs: Part 1 if this topic interests you.

Fulfilling Expectations

Remember that the type of person you want to hire is going to expect around 3-4 hours total in the hiring process. If they feel that you don’t perform due diligence with them, their concern will be that you are not doing it with anyone else and that the team will suffer. Of course if the candidate doesn’t seem like a good fit at any point, cut them loose immediately and politely.

If your candidate made it this far, it’s time for…

Phase 3: In-Person Interviewing

Let Your Experts Do The Talking

Evil Nerd Genius
And now we all know the truth about German programmers…
They code in cuff links.

Next, have candidates interview on-site with your existing people for one to two hours (if you don’t want the whole team in there at once divide the time into 20-30 minute blocks). There are pros and cons to both approaches.

Be sure to communicate any overarching goals with your team. If this person is to fill a specific role, let them know so they can analyze the fit. If everyone you hire should be a continuous learner, make that clear. If you want someone who won’t be bored with tedious work, that should also be communicated. There are only two technical guidelines to stress.

Just.

Two.

  1. Long coding assignments should not be performed on a whiteboard.
  2. Long coding assignments should not be performed on a whiteboard.

There are plenty of decent alternatives to making a developer sweat about syntax and handwriting. Bring a laptop to the interview and pair program with them. Send them a coding assignment to complete on their own prior to the interview (time-boxed of course). This applies to anything longer than a fizz buzz-type problem.

Otherwise, let your experts ask whatever questions they believe are important. They are evil geniuses who want to unleash hell on your candidates, AND THEY SHOULD.  These should be some of the people you trust the most to help achieve your goals as an organization, they know the right questions to ask!

Afterward, get a quick thumbs-up count from your team and if it went well…

Perform A Leadership Review

Do an in-person with anyone your team doesn’t dislike. Probably 30 minutes or less. See if your impressions from the online/phone screenings seem to hold up. If you are considering this person for a role that may increase in responsibility, make sure to ask the right questions (including if they are interested in that sort of thing).
At this point, assuming success, proceed to…

The Final Phase: In-Person Closing

Sell, Sell, Sell (Be Obvious And Honest)

Allow 30 minutes to answer their questions and really sell them on the opportunity.

Sale! 50 Percent Off

What you have to offer is great, remember that! This is the company you chose to work for and continue to stick with. Even you you are having a bad day (we are all entitled occasionally) do not sell the opportunity short. Talk about the best parts of your job. Be enthusiastic. After all…

“Nothing great was ever achieved without enthusiasm.”

– Ralph Waldo Emerson

Be completely open and honest. Don’t conceal problems but don’t highlight them as anything other than what they truly are: opportunities to improve. Developers are optimists. We believe in change for the better and want to help it happen. Appeal to our desire to solve problems.

Eat Lunch

The candidate that makes it this far should have a very informal lunch with the team he will be working with so everyone can get a feel for interpersonal relations… it’s very difficult to get a feel for someone who is expecting trick technical/personal questions at any point and is on foreign territory. Lunch offsite is neutral territory and you can learn a lot about a person in that environment.

Lunch is a good habit to get into anyway. I like it.

It goes without saying that if you get to this point then you most likely have a keeper.

Make An Offer

Do this after lunch or do it the following day. You should know if this is the right person for the job or not. You have all the information. If the answer is no, tell your candidate as soon as you know.

The Offering

Negotiation is to be expected. However, in today’s competitive market, get your best offer out on the table as soon as possible.

NEVER try to undercut a programmer/developer/engineer/etc. It will not end well for you. The candidate maybe offended and walk, or worse, join the company and go though all the training and ramping-up and leave for a better opportunity in 6 months.

There are many, many jobs and too many online resources available to compare salaries and other benefits. If you aren’t sure you are being realistic, check out your competition on Glassdoor or general rates on Salary.com. Take this data to the powers that be and make a change if needed.

If there are other great reasons to work for the company, things that give you a competitive edge, highlight them. If you have a great environment for learning (see my posts on the subject here, here, and here) tout it! If you’ve hired well-known or respected developers, point candidates to their online presence on Github, LinkedIn, and Stack Overflow for verification. If you have stock options, great healthcare, or free/discounted products, talk about them.

You get the idea.

Conclusion

Overall, this is pretty similar to the process one employer used when convincing me to move to halfway across the country (for minimal pay increase, no stock options, etc.) and I had plenty of other opportunities. The overall process is proven and is common with really good shops that care about hiring the right people. Remember to always end the process after any stage as quickly and succinctly as possible. Do not get a reputation for wasting people’s time.

Image credits:
https://www.flickr.com/photos/mbiskoping/
https://www.flickr.com/photos/soulrush/
https://www.flickr.com/photos/liquidnight/