Hi All,
I've been working as an engineer professionally for 15 years for a number of different companies. My question is how do you stay motivated at work? I can generally be easily motivated if I'm working on design, but that seems to be about 5% of my actual work hours. Most of my work seems to end up being fixing problems in existing poorly designed projects.
I'd love to hear some feedback from the other members out there.
Thank you, Fred
I asked something similar recently.
http://stackoverflow.com/questions/238265/how-do-you-stay-motivated-on-long-projects
I find out about cool stuff we're doing (maps mashup, graph searching, shortest-distance and area greographic searches) and make sure I get to work on it. If I don't hear about any of that, I think up something cool (optimizing javascript across the platform, javascript library maintenance) and sell it so I can work on it.
Try to find some aspect of the problem you're working on that interests you, and approach the problem from that angle. Sometimes, this is really hard.
Unfortunately, not all programming/design tasks are equally interesting. If you find that most of the time you get the dull stuff, it might be time to look for a new job.
1) Find projects that are more interesting.
2) Figure out how to abstract what you're doing to fix existing designs so you can solve a higher-level, more challenging problem. I'm guessing that at least some of those projects have been or will be started while you're around. By moving into a mentoring / leadership / teaching role, you can help people not make those mistakes in the first place. You could also train people on how to rapidly fix the problems. You might also come up with a set of refactoring tools to automate it.
Work in s field you find interesting to begin with. It's one of the great things about software, you can find work in just about any field. Personally I've found that working in competitive fields helps, since there is pressure to continually improve and not stagnate. If you're truly bored it may be time to take the risk of going and doing something you haven't done before :)
Keep a journal of everything you accomplish. Don't just log design accomplishments, but also write down every fire you put out in someone else's project. Go back over it periodically (maybe with your boss) and see where you're spending your time, and if that's really where your company gets the best value.
Also, make sure you only need to fix each problem once. Automate tests as soon as you fix something. Nothing (to me) is more demotivating than fixing the same problem repeatedly.
Keep a good work/life balance. Work to live, don't live to work!
I've always found the hardest thing to manage was to allow enough time to live, too much temptation to get home and carry on coding.
Allocate yourself regular time off and you'll find yourself far more keen to get back to the problem after some down time. When you allocate the time make sure you keep to it and don't give in to temptation! :)
About fixing bad designs: I found design pretty motivating when I tried to analyze each bug as far back as I could ("Why was this designed this way", "what were the tradeoffs", "why didn't the guy who wrote this consider that case", etc.). A lot can be learnt from even a small bug, and that kind of analysis can help finding better, more general fixes.
I was just thinking about that myself.
I usually make a list of things to do for the project I'm currently working on and I notice that if I work too much on one of them I get really bored, especially if I haven't progressed in a while on one. If that happens I switch over to one of the other "to-dos", and eventually I figure out how to solve both because my subconscious works on the other one.
This keeps me motivated because each one feels like a small victory.
A better question might be "what is your inner motivation?" to answer first, and then it might be easier to answer your first question.
Have children and talk to them. Explain what you do, why it's important, why it's amazingly cool, that even the "boring" work is important for projects that are important to people all over the world. Keep in mind that, while they're totally impressed, you're also paying the mortgage, keeping your kids fed and so forth.
Honestly, my kids are a huge part of my motivation. Our "Bring a Child to Work" day is in April and my kids are already excited to see all the cool stuff that happens at our facility.
Obviously, your mileage may vary. I do recommend structuring your career such that your kids brag about what you do for a living. It makes me happy, anyway.... :-)
I overcame this problem today by giving myself persmission to write a small utility for part of my job. The priority is low enough that it wasn't worth my time to write it, but it was fun, motivating, and rewarding even if I couldn't cost-justify it.
Pick a small task that just outside what you should be doing, spend an hour or two on it to give you that feeling of accomplishment, fun, and success, and then go back to the normal work.
One of the reasons, I'm convinced, why Google has their 20% time.
Learn how to do automated testing. The most interesting development in the legacy environment is empowering change/evolution of existing system.
Be so good that it doesn't matter if you're doing what you're supposed to be doing, and then spend a lot of time doing whatever interests you most.
My suggestion is to know your strengths and use them. StrengthsFinder 2.0 is one way to find those strengths.
You can be motivated helping other people. You can ask your boss to let you help other teams and projects on the design phase.
I agree with you in that I too am much more motivated towards design tasks than towards investigating and fixing someone else's bugs. It's enough of a motivation gap that I am noticeably more productive when I am working on design work.
I have narrowed that motivation gap somewhat by changing how I approach the "maintenance tasks" that I get assigned. Most of the maintenance work, as you mentioned, stems from poor design and/or shoddy implementation. Instead of finding the problem and hacking something together that seems to fix the previously-hacked-together code, I try to read and understand the faulty code and its surroundings and see if I can design a better solution. This engages the more-motivated design portion of my brain while still accomplishing the task I was assigned. Often times, this approach has uncovered additional problems that could turn into future bugs or has lead to performance/usability improvements due to my new implementation being planned and designed instead of simply cobbled together. This approach is more involved than simply implementing a quick-n-dirty bugfix, but (for me at least) changing the nature of the task at hand to something I enjoy more yields a significant enough productivity boost to warrant the extra work involved.
The downside is that sometimes project management can be strict about "don't alter working code" rules. If your manager is the type who would send you an angry email if you so much as changed the name of a variable in working code, then this approach will probably not work for you.
As an unintended benefit, doing something like this helps advertise your design and planning skills and might lead towards more design-oriented assignments coming your way.