When being tasked with a problem (assuming we vaguely understand it properly), we know in a matter of seconds whether or not we are excited by the task. Typically, we do not like performing tasks we have done in the past, and we do not enjoy anything boilerplate (i.e. the stuff that has to get done, but no one wants to do it). However, for any project to be successful, it is apparent that there will be both types of work. Inevitably, you will be tasked with both types and you should approach them both with the same excitement. What I mean is, if you’re bored, you have just identified a problem which you can transform into something more interesting.
What exactly is “boring”?
Tasks become “boring” after you understand and repeat them. There are certain tasks that become boring simply because they are a lot of work and you’re not learning anything new in performing them. More concretely, consider writing a red-black tree implementation (read: you really shouldn’t do this unless you’re Robert Sedgewick). Anyone who has a had a basic undergraduate data structures class is intimately familiar with red-black trees (and likely many other types of trees) by now. The problem is, we know there is a lot of subtlety to implementing such a data structure and it turns into a lot of work to make sure you’ve done it correctly (so we use a well-tested library, of course). Similarly, any sort of setup and/or installation can quickly become monotonous the n-th time you perform it.
The “boring” stuff is scaffolding and plumbing. In general, scaffolding and plumbing (i.e. all the connections and glue on a project) are absolutely necessary to have any real system. Whether your problem is setting up a JAX-RS stack or rolling your own configuration reader, these are necessary components to your software; after all, if there is no way to communicate and transport data, your exciting algorithms aren’t all that valuable. Though these tasks are not often difficult, per se, they are typically time consuming. When it feels like you’re sitting on a time-sink, it’s easy to become frustrated since you know you could be doing some more “useful” or interesting.
NOTE: We often tend to define “useful” as interesting when it comes to working on tasks. However, although it’s not always the most exciting task, no one can deny that setting up your application scaffolding is incredibly important and, in fact, vital for project success.
Prolonged tasks typically become boring. We’ve all been there. There is that one item we thought would take no more than 1– maybe 2– days tops. 1 or 2 weeks later, we’re staring at the same problem. This happens for various reasons, but it typically stems from someone’s (not necessarily your own) lack of understanding of the problem. Consequently, since most of us software engineers have a mild form of ADHD, tasks which persist for this duration tend to lose our focus.
So how do I deal with this?
For understood tasks. Now that you understand the problem, this is where you write a library to do the job (if it’s a software problem). If it’s another task, try to find another way to repackage your work and distribute it to make this task trivial in the future. On the other hand, if the issue is related to some sort of process, then this is a perfect time to write a script or some sort of automation to perform this task for you. Share it with your friends and they’ll be glad (read: they don’t like doing this work either)!
For the plumbing. Again, you should understand the problem, but this time it’s not just the familiarity with the problem that makes it unpalatable. Instead, it’s the arduous amount of work it takes to set a system up. Congratulations, you just identified a problem. Specifically, if you’ve done this more than once, this problem likely exists across the industry. Here is your chance to write-up that new framework to solve the general problem and put this and many similar issues to bed once and for all. I mean, you did check already that no such framework exists for this task, right?
For the tasks with an extended expiration. As I mentioned before, these typically happens due to some fundamental misunderstanding about what work is to be completed. As long as the task description doesn’t read, “Complete <software project name here>,” tasks really should be on the order of days and not weeks. If the problem statement is too broad, it was initially misunderstood and not properly broken down. If the scope is frequently changing, this is often a deeper misunderstanding by the person/people requesting the work (i.e. typically a flaw in business logic). In these case you should try to work with whoever you need to such that the scope is sufficiently refined to be described as actionable items. Finally, if neither of these is the case, you may simply be ill-equipped to solve this problem. However, do not fret! Take this as an opportunity to make something happen; you now have the chance to step back from the problem (which we established has become uninteresting) and determine what it is you don’t understand (ask for help if necessary). Once you have identified your knowledge gap, use this opportunity to fill it and learn more. By the time you get back to the original task, you will understand how to better complete it and (hopefully) can knock it out quickly.
We all have to perform work which is not always as glamorous as creating a flashy UI or implementing a cool machine learning algorithm. That said, it doesn’t mean you can’t take away something new from each experience. Don’t let the task itself dictate the kind of personal value you will receive in completing it. Instead, if something is interesting take that as a gift. Likewise, if something is uninteresting, find a way to make it interesting.comments powered by Disqus