My series of articles has been an exploration of how we grow small solutions into larger tools. Sometimes we discover new information or rethink our approach and need to change direction.

Each article had it's own problem to solve and built upon the ideas and solutions of the last:

I was talking to my friend Suzan about this series and she asked me "What is this about? What's the common thread?"

I had to think about it for a minute. This isn't really about background jobs.

It's about removing distractions.

Maintaining focus means removing distractions

When developers need to make decisions when building software, we need to decide what matters and what doesn't.

My main goal in the code we've been writing has been to create the ability to make decisions quickly.

We turned this:

process.call

into this:

process.later(:call)

and we were able to focus on the code we care about.

What matters here is what we don't need to do.

We don't need to rethink our code structure. We don't need to move code into a new background class.

As I wrote in the first article about building my background library:

If my main purpose in the code is to initialize SomeProcess and use the call method. The only decision I need to make is to either run it immediately, or run it later.

If my first instinct were to change a line of code to another type of implementation, another class for the background, another layer to fiddle with, I would pull every future reader of that code away from the purpose and toward that new thing.

When I or any future developer look at the code, I want them to read it and understand quickly. Adding in a later method is a device to let the reader know when something will occur without pulling them away to understand its implementation.

This decision to implement a later function is a compression of the idea of the background job. The words we choose should be good indicators of what to expect.

Our software can help or hinder communication.

Knowing which it does will help us build better software.

When a team member reads what we've written, will they understand the words we've chosen as a compression of our ideas into more managable forms?

Do we express our solutions like poetry and provide greater meaning with each word? Or do we attempt to express in strict terms the absolute definition and possible interpretations?

I find that my approach changes often.

Sometimes I want things to be absolutely explicit. I want bondaries and clear expression of all requirements leaving no uncertain terms about what needs to be done.

Other times I want a single word to be placed to give new meaning. I want others to read once and understand larger implications without great effort of digging into documentation and implementation details.

To make truly successful code, I need to share my goals and express my intent with others who will interact with it in the future.

Learn and do by focusing on what matters

When I began writing this series, I was focused on what really mattered to me: decisions and implementations getting in the way.

When I discover that some bit of code is taking too long to run, I want to get that code running well. That may mean rewriting it. Or that may mean diving into optimization techninques.

One simple technique to optimize it is to just run it in a separate process. As long as that's a valid solution, I want it to be as easy as possible. I just want to say later and be done.

Here's what I've learned:

Although I've written a library like ProcessLater three times now on several projects, I'm less interested in exactly how it was implemented previously and more interested in getting distractions out of the way.

That's it's whole purpose.

As I wrote each article explaining what I would do and why, I found I'd run into scenarios where the code just didn't quite work right.

I had to fiddle to get some of my argument setup to work properly. I'd forget to add a splat (*) to my argument name and be confused and a little bit worried that my entire article about why this is a good idea was just derailed and wasn't working at all.

Developing a library isn't a straight path. I inevitably need to stop and reconsider new information. But each stopping point is an opportunity to refocus on my goals and make sure I'm not getting caught up in technical trouble.

I ask myself if I'm achieving my goal and if there's a better way. Am I able to remove distractions or am I creating more?

With each team where I've approached solving this problem, my focus has been to talk about the code and what I want to do:

"If all I need to do is run it in the background, then I just want to type this..."

By having a conversation with others, I can express my desire to make my and their lives simpler. We all had a shared understanding of putting a process into the background, and we all had a desire to remove distractions.

In the end, the conversations we have tend to be focused on:

Whether or not we've chosen the right words to express the idea
"What if it worked this way..."

These conversations always lead to either better code, or a better shared understanding. We all learn new things.

Here's what I hope you've learned...

I hope that you take lessons from what you've built and turn around to provide a better experience for the others on your team.

I hope that you've looked at what code you've written and how you've done it, and have thought about how expressive the words are. How will others understand it? How will they want to use it to something the same or similar?

Lastly, I want to point you to this interview with Russ Olsen

Olsen reminds us to consider our emotions and ambitions:

"Technical people want to focus on technical issues: is this a good programming language, how fast will this workload run on that platform, [etc.] Fundamentally, a lot of what stands between us and what we want to do are human problems: issues of motivation, working together, how people cooperate," Olsen argues. When it comes to working together effectively, particularly in complex endeavors, human emotions and ambitions can complicate things -- even among geeks.

Building software is complicated. Building software with a team can be even more complicated, but with good communication and forethought, we can build even better tools together than we can alone.

Stay focused on your goals and reach out for new ideas and different perspectives from your team members. Start a new conversation with your team, hit reply, or reach out about working together with me.

Maintaining focus means removing distractions

When we share our understanding, we are free to be expressive

Learn and do by focusing on what matters