Agile Zone is brought to you in partnership with:

Mitch Pronschinske is a Senior Content Analyst at DZone. That means he writes and searches for the finest developer content in the land so that you don't have to. He often eats peanut butter and bananas, likes to make his own ringtones, enjoys card and board games, and is married to an underwear model. Mitch is a DZone Zone Leader and has posted 2574 posts at DZone. You can read more from them at their website. View Full User Profile

AskDZ: How Do You Motivate Yourself on Development Projects?

09.25.2013
| 16949 views |
  • submit to reddit

We all experience times in our day-to-day work where we get frustrated, side-tracked, or burnt out.  Everyone has their own way of dealing with these obstacles and getting themselves back on track, otherwise you'd lose your job, I imagine...

What personal tactics do you have that help re-motivate you during various development tasks?

Comments

Peter Lawrey replied on Wed, 2013/09/25 - 2:59pm

I find that being frustrated, or burnt out, comes from working under pressure for too long.  The way I deal with this is to try to find the issues which are likely to be a problem as early in a project as possible.  This places the most pressure at the start of the project and by the end, it should be an anti-climax.

Being side tracked is a harder problem.  Not all projects you work on are as stimulating or interesting as you would like and getting side tracked is all too easy.  The way I deal with this is to be aware this is happening and limit it.  I allow myself to be side tracked provided it doesn't slow down my work, or if that doesn't appear to work, take a short break and go for a walk, and come back to your work fresh.  

Treat being side tracked as a sign you will need to make extra effort to manage your focus.

Duncan Brown replied on Wed, 2013/10/30 - 3:39pm

Here are some of the tactics I employ when combating burn-out and frustration:
  • Tactic #1: A classic: Walk away for a few minutes.  An hour.  A day.  Whatever you can spare (this is why scheduling should always include such allowances).  During that time, do your utmost not to think about the work/problem/whatever.  Preferably, do something fun or enjoyable.  Coming back with fresh eyes (and a fresh head) can yield some good results as far as motivation and avoiding burnout goes.  This is why a lot of modern companies will have game rooms or the like, though my personal favourites are going for a walk, napping, and reading.
  • Tactic #2: If you have the authority (and the manpower/bandwidth), delegate.  Or, at least see about having colleagues give you a hand.  There is no single worse feeling than being alone on a huge project/problem, and there is no greater drain on your energy and motivation than being in the situation.  It's remarkable what teamwork and a combined effort can produce as far as attitude alone, not to mention actual productivity.
  • Tactic #3: If no one is available to help, at least see about finding a friend or colleague who will listen to your concerns.  (Ok, in other words, find someone who will listen to you moan and complain.)  Getting some things off your chest can provide just enough catharsis to move on with whatever work you're doing.  But it does go without saying that the recipient of your speech should be willing, and have the time.
  • Tactic #4: Be proactive.  Avoid the burnouts.  If you know the project is going to be long and/or tedious, nothing beats a really solid plan of attack.  The best project managers (as well as developers) break up the project not just into manageable chunks, but into as finely-grained pieces as possible.  It's one thing to look at a planning board and see, "Implement polyglot persistence mechanism" and quite another to see "Install transaction manager," "Configure transaction manager for the following DBs: ...," "Install these DBs: ...," "Update these classes in the data layer: ...," etc.  Note: Whether it's the PM or a senior software engineer/developer getting granular, spending the time to develop a proper plan can avoid a lot of confusion and burnout, while giving the team a clear sense of focus which is crucial to any development effort.
  • Tactic #5: Accept the fact that, in spite of how awesome you are at your job, you are still just one person.  That doesn't mean you can shrug off work and responsibility; it just means that accepting your own limitations and that there are so many hours in the day can go a long way to making sure your attitude stays in good shape.  It also means that you don't let yourself feel like you're drowning and personally/solely responsible for a project's success.  I know this one took me a long time to come around on, but accepting that I can only do so much, and that even the best-laid plans can go afoul, has made me more effective, less prone to burning out, and, quite frankly, happier.

As far as being sidetracked goes, it's inevitable, but as Peter Lawrey stated, being aware of it and limiting it is a great way to manage being sidetracked.  This kind of falls in line with Tactic #1.  Some of the other tactics listed can also be applied to being sidetracked, too!

Mitch Pronschinske replied on Wed, 2013/09/25 - 3:45pm

I'd also like to include some wisdom from the great Joss Whedon that applies to this question, in my opinion.  One of his techinques for keeping himself super-productive is 'eating dessert first'

In practical terms, this means that you should think about a part of a project that you're excited about or that you just had a good idea for and work on that.  Do the fun stuff first and let that momentum carry you through.

Sometimes you can't always do this, because there is usually an order to the steps you have to take in the development process, but hopefully you can think of the most interesting line of code that you're supposed to write right now and start with that.


Scott Westfall replied on Wed, 2013/09/25 - 4:29pm

I find that I am motivated by challenges. If the nature of the work isn't stimulating, then I can take pride in the manner in which I accomplish it. For example, when there isn't a sufficient technical challenge, I can define challenges related to writing exceptionally clean, easy-to-understand code. Or I can set a challenge for completing the task more quickly. How many sports are based on that one score?

I like a variety of things to work on in one day. When I'm losing my zeal for a task, I like to be able to switch to something else. I find I can then return to the earlier task and attack with renewed vigor. Sherlock Holmes used this approach when he was stumped. He'd turn to his chemistry and reagents, working to find a way to reliably detect the presence of blood. I can't find the quote, but I'll paraphrase it as, "Nothing so refreshes the mind as working hard on something else."

Finally, I like to keep in mind the context of my work: there is customer waiting for this and a company depending on me to deliver it. Rick Ross, the CEO at DZone, was telling me that he read recently that motivation is strongly tied to the creation of meaning. I find meaning in delivering excellent products to my customers and creating value for my company.

John Sonmez replied on Wed, 2013/09/25 - 9:49pm

I actually try to push-through-the-pain in order to get over a typical burnout type of situation.

I know this seems a little counter intuitive, but I've found that motivation waxes and wanes and that sometimes you are just not going to feel motivated no matter what you do.

In those cases I fall back to deciding that I want my mind and not my emotions to decide how I live my life, so I force myself to push through and complete the task I set out to do.

Sometimes this is quite painful, but I often find that when I feel like I can't go on, but manage to do it anyway, I find that on the other side of the wall of struggle there was a refreshing pool of new motivation and purpose.

Early in life I would set out to do things and get 90% done with them, because I would eventually get tired of those things and decide to chase something new.  I found that this method of chasing dreams never got me anywhere and that I was putting forth much wasted effort.

In the past 5 or so years, I've adopted a completely different viewpoint where starting what I finish is the highest priority and I've seen much greater successes.

darryl west replied on Thu, 2013/09/26 - 8:41am

A trick that authors use when writing a book is to "park on the downhill" before ending the day.  What this means is that towards the end of the day, stop coding and start planning what you will do tomorrow.  write a few tests without any implementation.   do some mindless configurations so when you arrive at work the next day, you can start being productive right away.  

just like starting your car, even if your battery is dead... (assuming you know how to pop the clutch--god I'm old...)

Allen Coin replied on Thu, 2013/09/26 - 9:17am in response to: darryl west

Interesting perspective, Darryl. I find that there are a lot of parallels between when programmers talk about the process of programming and when writers talk about the process of writing. Hemingway said:

You write until you come to a place where you still have your juice and know what will happen next and you stop and try to live through until the next day when you hit it again.

You change one word, "write," to "code" and you've got yourself some pithy advice for programmers.

Mahdi Yusuf replied on Thu, 2013/09/26 - 10:01am

Extreme Focus. 

1. Turn off the phone. Zero distractions. 

2. Make a list, a realistic one. 

3 .Plan of attack to tackle the list. 

4. Do the list. 

Honestly all it comes down to. Everything else is just a trick to change your normal behaviour, why not just modify your normal behaviour. Discipline. 

John Sonmez replied on Thu, 2013/09/26 - 10:31am in response to: Mahdi Yusuf

Fantastic.  Simple, but so correct.

Charalampos Pap... replied on Fri, 2013/09/27 - 1:34pm

 personal approach: if you cant concentrate on it you are working on the wrong project.

Lund Wolfe replied on Sun, 2013/09/29 - 2:01pm in response to: darryl west

That's excellent advice.  We dread something because it is big and undefined.

Start defining it and take baby steps starting at the beginning.  Just take the time to prepare for the first/next step and then you will be ready, if not completely willing, to actually do it and make progress each day.

Don't burn out.  Limit your time/effort, or find some way to make it interesting or satisfy your values/objectives as a developer.

Saif Khan replied on Thu, 2013/10/03 - 1:07am

Great Guys!!!!

Every reply is great. But the more you read through the post the more things gets meaning full or OOfull. 

I will say plan and only take what you can do for the day or week or month. For me week is a better approach.

Jean Said replied on Fri, 2013/10/04 - 2:55am

When a project demotivates me, I spent some time on alternate tasks. Refactoring, IC maintenance, and/or mandatory long active (powerwalking) pauses.

Then I resume work with a fresher mind.

Robert Lauer replied on Fri, 2013/10/04 - 9:33am in response to: darryl west

... sounds like Kent Beck's advice "always stop with a red test" (from "TDD by example").

darryl west replied on Fri, 2013/10/04 - 8:39pm in response to: Robert Lauer

our company policy is 1) check all work in at the end of the day (preferably multiple times during the day), and 2) never check in broken code--all tests must pass (the full suite).

what I do is create "pending" tests to help get me started in the morning.  this is easy using mocha (don't implement the callback) and by using @Ignore or @PendingImplementation in junit4.

so in the morning, I update the code to get changes from the EU & Asia then run the tests to see where to start.  then, I get coffee... 

Abhijeet Dalal replied on Sat, 2013/10/05 - 1:19am

  • My way to motivate myself is to constantly finding ways of improving my development. This helps me not get bored and frustrated by daily activities.
  • Keep talking to people whom I know are very good at development, this way I get good ideas and my interest in development stays on.
  • I always try to challenge myself to put down the most optimized code on first go. Though I have never achieved that till today and always end up re-factoring the code multiple times.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.