I’ve had a lot of thought and conversation lately about how to stay motivated.  The fact is that we’re all human, and we all have ups and downs.  Even if your super-motivated about doing something one day, the next day you might not be.  I know I’ve had a lot of personal experiences where I get on a kick for a couple days, hammer out some code, then someone says “eh, that sucks”.  It’s a total downer!  Well, here are a few tactics you can try to stay motivated.

• Don’t listen to what other people say about your stuff, unless it will help make it better or point out an obvious flaw.
• Remember that if someone has feedback, that usually means you need to do something.
• If you work on something a while and become disinterested, keep what you’ve done around.  Who knows, you may pick it up and continue working on it several months down the road.
• Finish things through to completion

I think the last point is the most important.  As software developers, we become distracted very easily.  Often times we become to entranced by every new technology and every different way to do things that we don’t ever get a finished product.  The old tale that “an application is never finished” has put a bad taste in my mouth since the first time I heard it.  While there’s always room for improvement, finishing and releasing a product, and setting milestones for future work to be done is vital.  Working in bigger companies we sometimes forget that — that’s why there are project managers, product managers, etc etc.  We could learn a thing or two from those guys and apply it to our own side projects.

Aside from the “setting goals” part, most of the work happens within a very small timeframe.  It’s called being “in the zone”.  That’s the programmers time when you are completely focused on the task at hand, and cannot be distracted by anything.  This is the most important time to keep programming.  If you have to stay up all night, then  do it.  Here’s what Joel Spolsky (who I normally read for entertainment, not how to do my job – for another post… but this is good) has to say about being “in the zone”:

“Here’s the trouble. We all know that knowledge workers work best by getting into “flow”, also known as being “in the zone”, where they are fully concentrated on their work and fully tuned out of their environment. They lose track of time and produce great stuff through absolute concentration. This is when they get all of their productive work done. Writers, programmers, scientists, and even basketball players will tell you about being in the zone.

The trouble is, getting into “the zone” is not easy. When you try to measure it, it looks like it takes an average of 15 minutes to start working at maximum productivity. Sometimes, if you’re tired or have already done a lot of creative work that day, you just can’t get into the zone and you spend the rest of your work day fiddling around, reading the web, playing Tetris.”

If you only have time once a week to get “in the zone”, then plan it.  Turn off your cell phone, close your IMs, tell your wife you love her and won’t see her for bit, and set the expectation that, for example, every Thursday night you’ll be hacking away and completely unavailable.  Try to know what “business decisions”, or functionality you want to include beforehand.  I think about it when I’m trying to get to sleep at night, taking a shower, eating breakfast, whatever.  I try to write down what I think of the next chance I get.  But when it come to getting it done, that’s when that night of being alone is vital.

This was kind of a hacked out, not-completely-thought-out thought, I will hopefully try to organize it a bit better and follow up in another blog post, but this is just what I’ve been thinking about.  As always, your opinions and insights are appreciated, whether it’s through email or a comment.

developer, motivation, thoughts

I’ve been thinking lately about what makes a good software engineer, how to spot a good one, and how to help yourself become better.  This is what I came up with…

Distributed systems, enterprise-class, J2EE, loosely coupled, SOA, multi-tier, Agile, iterative development

I hear those words a lot.  Anyone could claim they have knowledge of them, but does that really matter?  A good majority of resumes and tons of job postings list them, but that says absolutely nothing about the competence of the individual.  Stop asking for these qualifications and stop putting them on your resume, they don’t mean anything.  Don’t put a goal toward becoming competent in these technologies, you will only fail at being a software engineer.

What about experience?

Yes, experience is important.  But what kind of experience?  Years?  Places work?  Size of the company worked?  Projects completed?  I wish I could come up with the equation, but I’m afraid I can’t.

The important part is to actually have something to show for your work.  Rather than saying “6+ years experience as a software developer in the e-commerce industry”, how about, “Designed and constructed a number of technologies powering the <company> shopping cart, order pipeline, customer self service, and product detail pages.”  Does that say a specific technology used?  No, but that doesn’t matter.  What you’ve done is said that you have done stuff what people want done.

So how do I know when I’m innovative?

Chances are you’re not innovate.  Sure, you’ve probably “architected a solution to meet business needs and delivered on time”, or “developed a framework to simplify development of Rich Internet Applications”, but what that really means is that you’ve “drawn an inheritance diagram, wrote the code and it works”, and “probably recreated a framework that already exists in the technology I’m using, and it’s still not as good”.  Ouch, that hurts doesn’t it.

Have no fear, these are things that are expected as a developer grows.  The hard part is breaking out of that and doing something that actually contributes value.  Let me give you an example.  Recently, Bespin, a web-based collaborative code editor has been in the news.  This is a very simple example of how to be innovative.  Although the project only appeals to a small amount of people, it suits a need that wasn’t there before.

It’s important to remember that projects like Bespin don’t appear out of this air.  It takes time to design and implement a solution (and we’re not talking just a few minutes whiteboarding either).  I’m not going to go into the details of how to create a solution like this, but if you don’t know and haven’t experienced it first-hand (you can’t tie your name to it), then you’re not innovative.

I’m not trying to hurt your feelings — I’m actually eating my own words as I type, but what I’m trying to say is that the characteristics of a great software developer focuses on what you’ve done, not how you’ve done it.  Just find something that interests you, stick and it, and you’d be surprised how far it will take you.

developer, j2ee, motivational, software engineer