What are you trying to do?

One of the most useful phrases I know is “What are you trying to do?”. I use it a lot when I am helping folks learn. I use it a lot with myself when I’m feeling overwhelmed. It serves as a general purpose reminder to step away from whatever yak I am currently shaving and get a bit of perspective on my current problem.

With New Programmers

I often ask this question when helping new Rubyists. They will come to a meetup and ask a question like “Why is five divided by two equal to two?” Many folks will mumble something about integer division. Maybe someone will tell them to make it 5 / 2.0. If the next question is “How do I write a for each loop in Ruby?” good mentors/teachers will realize there’s likely more going on here than meets the eye and asks “What are you trying to do?”. When you ask this question, you have the opportunity to help someone level up. Perhaps their code looked like this:

scores = [5, 1, 3, 4]
answer = 0

for s in scores
  answer = answer + s
end

average = answer / 4.0

By asking about their end goals and looking at the code, you can tailor your response to their actual problem. In this case, I would start by teaching +=, to_f, and iteration using blocks.

scores = [5, 1, 3, 4]
answer = 0

scores.each do |s|
  answer += s
end

average /= scores.length.to_f

A bit more chatting and teaching would hopefully get you to a canonical solution using inject. Alternatively, if this is Rails you can just use the average function which is even simpler.

scores = [5, 1, 3, 4]
average = scores.inject(&:+) / scores.length.to_f
product.average(:scores)

When I was learning Ruby, I got super frustrated with this question. Not because it wasn’t helpful. I learned a ton as someone helped my unravel my stack of assumptions. What frustrated me was when it took me a while to remember the high-level answer. Someone would ask “what are you trying to do?” and I would respond with “add up a set of values, I just told you that!” I would frequently become so bogged down in my assumptions about how code should work and what was or wasn’t in the standard library that I would lose sight of the end goal. However, eventually, I realized that stepping back and being open as people dug me out of my rabbit hole made me a better developer.

How I Apply This Today

I still rabbit hole and yak shave a lot. I’m less likely to do it with code, but it turns out there’s plenty of places to get lost and get in your own way.

Have you ever written or read requirements or specs that are full of things like “add a widget column to the database” and “Create a new controller to track widget sales.” While technical requirements are great, I have found that without the actual user stories, the “what were trying to do,” my code isn’t as good. I add complexity where it isn’t needed and don’t put in flexibility where it is necessary. Having the big picture makes making choices that benefit the user and maintain the whole system much easier.

The other place I ask myself “What are you trying to do?” is prioritizing and triaging all the little stuff that piles up every day. Before the new year, I was feeling a bit overwhelmed at work. I had many tasks I felt like I needed to do. I reached out to a co-worker for some mentoring and started the conversation by saying “how the heck do I do it all?” He came back with, “What are your goals?” I didn’t have a clear answer. So we spent our time figuring that out. It felt very similar to all my experiences when learning Ruby. I thought I was asking the right question, but there was a better approach to my problem.

I remind myself to remember the big picture often. I refer to my goals often when I’m preparing a talk. When I’m reading email or planning my work for the week, I think about how things fit into the big picture. Often stuff that seems important can be dropped once you take a step back. Moreover, if I’m totally honest, I’ve caught myself thinking “What am I trying to do?” while arguing with a partner. The value of taking a step back and examining your goals is pretty universal.