From what you've described, you're like most people -- mananaging multiple competing tasks isn't something that comes naturally to everyone. There are plenty of tricks for keeping track of them, the easiest of which is to just keep a written record of everything that needs to be done.

For large projects, where there are multiple people involved in development, you can place the items in a ticket tracking system, like bugzilla, or trac.

For tasks specifically on you, you can just keep a book. I've seen different techniques, from keeping a list on a whiteboard (benefit -- other people can glance in and see how loaded you are), or keeping a daily notebook (each morning, copy down everything that wasn't crossed out from the day before, and cross out items as they get done. benefit -- you have a daily reminder of what's outstanding).

Sometimes, you just have to learn when to say you're overloaded, and be willing to pass off issues to someone else. It's taken me many, many years to be willing to pass on responsibilies to other people, as it's kinda like admitting defeat and asking for help, and sometimes it requires more work when you have to clean up after their work or if they keep asking you questions about it, but if you work with other skilled people, it's not so bad.

Also, you mention that you make sure that everything gets done, and gets done properly, which is a good trait, but you have to be sure that you're really sure what's required, and what's just something that you want -- I have a few outstanding projects that I made a major number of modifications that would benefit users, but I went to add a few more things that were more complicated than I thought they would be, and got sidetracking, which results in no one benefiting from my earlier changes, as I didn't commit my changes at the right time, and I'd have to spend more time trying to sort things out.

If you've been doing the same basic thing for a few years, you might've outgrown your position, and it's time to move on, and find new opportunies for learning, but depending on your personality, it might be better to go to something where you have skills, but aren't an expert, so you can keep learning new things. (these days, I'm most likely to take a job based on the other people I'd work with, than anything else .. okay, and a non-crappy commute)

Try to figure out what you like doing, and what skills you need to develop to best do it. In your case, if you really like developing stuff, you might prefer to develop your organization skills, rather than trying to find a job that avoids the problem. (of course, if you don't like development, then sure, go and find something else)

You might also look into the concept 'life hacking', which is trying to streamline things, and deal better with interuptions, but I'm not sure what the best resources are for it.

You might also look into the concept 'life hacking', which is trying to streamline things, and deal better with interuptions, but I'm not sure what the best resources are for it.

Hmm, Google reports a few items ..

• http://www.lifehacker.com/ which appears to a site that helps you get things organized;
• http://www.lifehack.org/ a similar site, but more advice oriented and less 'product' oriented'
• Some interesting links on this page including one about 'sleep hacking' which I found intriguing -- most likely because I agree 100%
• There's even one on hacking your grocery list, also a neat read.

These are interesting diversions, but I think I'm more interested in looking for testing/operations/support answers rather than try to fix my slightly cracked development approach.

Alex / talexb / Toronto

"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Bleah.

Sleep hacking is NOT about hacking in your sleep. :-(

Stupid deceptive titles. :-(

What mix of development, testing, operations and support is your job?

Mostly development/testing (personally these days I don't think you can be a good developer without being a pretty good tester too). Very little operations/support stuff now - for which I thank my lucky stars :-)

What resources can you recommend, so that I can continue looking for enlightenment?

If you're interested into moving into testing full time I'd give the following a once over:

http://www.testdriven.com

General blog/portal/aggregator site on testing

http://www.testingeducation.org/BBST/

Nice online tutorials/lectures on testing

Lessons Learned in Software Testing: A Context Driven Approach, Cem Kaner, James Bach, Brett Pettichord

Very readable book on software testing in general. A collection of hundreds of good practices and tips.

This is not really an answer to your question, but after reading your post I can't help but think that maybe you should try out test-driven development, and see whether that improves your job satisfaction as a developer. I don't know exactly why you feel you're not efficient (enough) as a developer, but for me TDD cancels out many of my personal failings which would otherwise hamper my development work (like procrastination in the face of a big task, indecisiveness on what to do next, over-engineering a project rather than starting it, and more). This is not what TDD is about primarily of course, it's foremost a design methodology, but these are nice side effects which make my work more enjoyable and productive. Maybe it'll do the same for you? And if not, at least it's a step in the right direction towards full-time testing.

As an aside, one of the links adrianh gives in his post lead me to a blog-entry which has got to be one of the best articles on TDD-related topics I've read recently.

What about chromatic's book? Perl Testing: A Developer's Notebook

While it's a jolly good book for people who need an introduction to automated testing with Perl, it's not a good introduction to testing as a career.

I wouldn't recommend it for this purpose any more than I would recommend Learning Perl for somebody considering programming as a career :-)

Plese read Effective Methods for Software Testing, 2nd Edition William E. Perry

This may be an artifact of my view on how testing should be done in an organisation, but I didn't think this was a very good book myself. I'm pretty much in agreement with this review.

In fact support and test roles are good ways to get a handle on certain aspects of development. However I do see the appeal of the problem solving and more use for soft skills. Maybe a client facing development role would give you the same experiance.

From a Perl point of view I think there is of course Test::Simple for unit testing and LWP/HTTP::Recorder etc for automated web app testing.

This strikes me as unusual, usually the support and testing guys want to get into development not the other way around.

Quite. I'm thinking my path would be more in terms of operations (speccing new equipment reqirements, network design, bandwidth needed, monitoring, maintenance) and in terms of QA and release control (automated testing, random testing, continuity, focus groups).

For example, when Scott Cook of Intuit was building Quicken, he (or one of his guys) would plonk themselves down beside amateur testers and watch how they used the software. Every time the tester ran into a problem, the programmers would be told where the problem was, and to simplify or clarify the interface.

I guess I'm getting to the point where I can say, "Development? Yeah, done that.", and be able to move on to the next thing. The most obvious step to me right now is Operations and Support.

Alex / talexb / Toronto

"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds