In this post I’ll share some of the lessons I’ve learned to efficiently use the time that was given to us. I’ll try to prioritize and put the more important ones on top.

Set goals

It’s a biggie, one should stop and really answer the question: What do I want to accomplish? I use a great tool for this: FreeMind. It’s a mind mapper that really works for me (Helping by reporting bugs btw).

If you set goals, one can work efficiently in the right direction. If you just follow your gut feeling, you’ll change more directions then socks. Keeping clear goals allows you to set milestones into your life. Reaching milestones are from my experience, the ultimate thrill. Goals can be very long term, but try and pinpoint milestones, no more then a handful, that are within reach.

Of course milestones and goals will change. But since you made a rational decision about setting a goal, it’s harder to toss it away later. There is an investment in a goal already, that you just don’t want to lose.

Let’s look at an example: imaging you want to learn how to learn to cook (is one of my goals btw). Since you don’t know how to cook, the first milestone is easy. Get an easy cookbook. Get good cooking gear (What’s that? Finding out is also a milestone) . Decide what kind of cooking interests you, etc etc.

Plan out your days

Eisenhower once said: Plans are worthless, but planning is everything.

Don’t waste time doing nothing, instead plan out what you will do. Don’t over plan, but at least firmly lay down what should be done in the day. Once plans are made, it’s easier to finish everything. Less distractions (what to do next?) means more effective time used.

Prioritize

Learning how to prioritize, prevents important tasks not being done. Doing the most important right away (when appropriate) is a very efficient way to get things done. Don’t waste time doing very lower priority items, while important stuff needs to be addressed.

Another related item: make time available. This is not easy, sometimes to get something done, something has to be discarded. Wanting to do everything, or worse wanting to do a little bit of everything, is the perfect formula of actually doing nothing at all. I made time to finish this also, it was ‘done’ for weeks now but hadn’t reviewed it.

Organize tasks

Tasks should be organized. Keep a to-do list, keep track of items in progress. Keep a good schedule. Tasks should have a finish. Clean room isn’t a real task. When is a room clean? Better would be: pick up clothes, clear dust and make the bed. For IT related tasks, keep following in mind: SMART.

Learn to sleep less.

I used to sleep 8h straight, every day. After a couple of months of training, this can be reduced easily (at least of me) into a 5h nap. A couple of hours extra daytime is the difference between doing nothing but work all day, and having some time to do something you like.

A couple of tips to start sleeping less:

• Go to bed and get up on a tight schedule during the week. It really helps to train your body to start sleep right after you go to bed. Getting up also gets easier when it’s on the same time every day. Don’t snooze half an hour, cause it’s just teasing and it’s very inefficient.
• Don’t start skimping an hour of sleep. Start small, like 10min. Get into a rythme getting to bed at a regular hour. After you are used to the shorter sleep time, stay up another 10-15min. Again wait until you are adjusted before reducing the sleep any further.
• Don’t work during those extra hours of daytime! Instead spent time on yourself. Do something you didn’t have time before. Read a book, watch a movie or have sex. Do something you feel is a bonus on your day. Trust me, it’s really import to keep the sleep from setting in. Once you are doing this for a some time, you can work from time to time, since you don’t feel tired before you normal sleep time.
• Don’t under sleep. I tried going below 5h15min/day but I felt bad during the day. I wouldn’t die at that rate, but I didn’t enjoy myself. Don’t under sleep!
• Caffeine is your best friend!

As always, feedback is appreciated!

Regards,
Andries

Now, again six months later, Gutsy Gibbon is here. I’ve seen numerous developers write that Ubuntu is a great development environment, so again I went for it.

First Impression

7.10 is slick! After 1 minute I managed to get the flashy desktop graphics to work on ATi (just needed to apt-get xserver-xgl) and got my wireless working with WPA without any configuration. Excellent.

Installing eclipse, java 6, filezilla took me just under an hour (long download). Installing maven was a breeze when following the read-me. I must say, it just works. The recent year Ubuntu has received a enormous momentum, which drives the community like never seen before. When searching for an arbitrary problem, every Google hit actually came with solid solutions. Admitted, I don’t compare with many other vendors, but Ubuntu is really easy!

Feeling when coding

Coding in ubuntu gives a slightly different look and feel, especially in eclipse. Firstly, eclipse starts faster on my machine on Ubuntu. Also the screen anti aliased all the way, which provides a soothing feeling to the eyes. The only negative side effect I found, was the slightly larger font in the package explorer. This was in previous Ubuntu versions as well and I think it has more to do with eclipse on Linux.

Anyway, normally I’m a Linux basher, but the truth has to be told. Ubuntu would made it as my home-brew development machine. Didn’t see that coming. I’m sure that once I understand Ubuntu better and better, I’ll even like it better and better. Windows I know by hart, Linux I’m practically a total newbie. It’s refreshing!

But…

On a project I’m still going to advertise Windows. Although I have absolutely not found ANY bugs in Gutsy Gibbon, I still don’t trust it like Windows. The years of absolute surrender to it, makes it hard to really trust anything else.

If any operating system will break through the Window monopoly, I’m absolutely certain it’ll be Ubuntu. The easy, the graphics, the repository are UNMATCHED, even by Windows. Wow. That hurt

As always, I’m open for debate!

Greetings,
Andries

Update 23/12: I have been experimenting with Hardy Heron, the alpha 2 release of the latest Ubuntu. Surprisingly, maven2 is now available on Synaptic. Excellent job Canonical! Only thing missing now is eclipse 3.3 to complete the picture.

First off, a small apology. I’ve read the book in Dutch, and he uses terms that I can only translate so and so.

MTQ

MTQ stands for Material, Time and Quality. Every thing you do can be mapped into these 3 parts. The material you are making, the time it took for making it and the quality of the finished product. It’s important that there is a great dynamic between the three. If you change 1 of them, at least another one needs to compensate. The sum is constant. Think about it. If you are nearing a deadline and have a unit of work to do, you can do three things. First is to produce less, second is to take longer and last is finishing with less quality then you would deliver normally.

His most important point on this subject was that the relation between the three exists. Always. There is no such thing as work faster during a period of time. Working faster generally means less quality. Period.

I see MTQ as a measure of efficiency. A good senior developer will produce the same material as a junior developer, but in less time and better quality.

Translating this into best practices, is to realise deadlines are not flexible without taking into consideration of the MTQ theory. Quality is probably the most abstract term, which reflects into less bugs, more maintainable code and better documentation.

Strategy and Tactics

A strategy is a road-map with certain goals. Goals could be learning a technology, get promoted into a certain function, learn a new skill… The goals are generally a long time further into the future.

A tactic is a certain action you will take, that gets you closer to a certain goal. The tactic fits in your strategy.

Translating this into java development is setting milestones into your release plan. Milestones are important strategies, and taking the hardest part first (if possible) is generally a good starting point for choosing the milestones. See the milestones as your strategy, as where specific implementation details are your tactics. Examples of such tactics could be choosing the right technology, using frameworks, and so on.

Side-notes he made are following:

• Strategies that change a lot, aren’t strategies at all: Change can be important but requires are decisive reason and good reasoning.
• Asking why a lot, make good strategics from tacticians. Asking why to yourself forces you to think things through, see bigger pictures and learn more understanding.

Decision Making

Even as developer, we need to make choices every day. We have to determine which the best approach is to resolve a certain problem, which implementation would be best, how we can refactor something and so on. Not to mention higher level decision making, like overseeing development, finding wrong implementation before they become problematic.

To make our decision making efficient, we need to direct the process. Kasparov states that you need to learn to make decisions and give pointers on how you should. Let’s solve a simple problem: decide the best bugfix.
Start off by giving yourself some time to spin up some possible solutions, brainstorm in your mind to provide even the most idiot solution. Search for at least 3 alternatives, let the imagination thrive! Now, depending on the amount of alternatives you’ve found, pick the 2-3 most promising and examining them. Think steps ahead. Ask yourself following questions for each alternative:

• If I change my code like this, where will my behavior change in other code? And if I change other code that was affected, will these changes affect even more code? (See the steps ahead coming?).
• Is my proposed fix easy to maintain, will I need to document a lot?
• Can I do better? How?

After questioning yourself, pick the best choice. Now, this may seem to take long, but you will be awarded following:

• Receive confidence in your code. Writing code in confidence makes you a better programmer (and makes it more fun).
• Be able to see bugs BEFORE they are written. No explanation needed here, does it.
• Write cleaner, better and more maintainable code. Your code will be smart, just like you.

See habits and deal with them

This one is something I do a lot as well. Coders tend to have certain habits, good and bad. A habit I tend to have is to dive into code straight away (Bad Bad Bad…). Other habits could be forgetting to write tests, commenting code and forget to remove it, writing idiot comments or none at all, choosing dubious names and so on. The point is, we should self-evaluate and see these bad habits. Knowing yourself is being a better person.

Everyone has a bad habit, when identified you should deal with it. Force yourself to write tests, hang a big post-it on the screen to never forget it. Personally I’ve make myself write halve the code in my mind before actually starting to write.

One of my favourites was that I knew about 5 shortcuts in Eclipse until 6 months. Identified this as a bad habit, printed the cheat sheet and forced myself to use them. When I didn’t , I deleted my piece of code I had generated and did it again by the shortcut. 6 months later I know like 50 shortcuts in eclipse, which owns. The downside is now with Eclipse Europe, they changed some of them (alt+enter for one), which is frustrating…

Game Stages

• Opening Game: In opening games you use a repertoire to setup the board. Openings are predetermined setups of the board. You can reflect this to use what you know, when starting a new project. Or better yet: use what works. Don’t reinvent the wheel. There are a lot of common best practices to be used when starting up a new project.
• The middle game: Here is where developing matters. Building up the application up to the next release. Nice play where one should overcome possible dangers and problems. No predetermined path can be found, as every chess game is unique (and so is every application), one will have to deal with the problems as they arrive.
• The endgame: Here the amount creativity drops to a bare minimum. See this as the final days before a release. Only a very limited path to success is available. Here we need to focus on what needs to be done.

The advantage of the attacker.

Attacking problems before they are too big is better then to wait until a problem is blocking. Attackers are in advantage because less code is dependent on the problem, making the solution simpler.

Final thoughts

I do admit, this is a limited snapshot of the book. I’ve filtered the stuff out that actually could be mapped into java development. Some topics he wrote about were a big stretch to get into the Java world . Anyway, I’ve tried on the best parts and I hope you enjoyed it.

More about the book

Do I recommend this book? Yes! Although it’s not the best book I’ve read in it’s branch, it’s definitely worth reading. I enjoyed mapping my mind to his, seeing how stuff he encountered could and did reflect on me. In the end, I became a wiser person, something I strive for at the moment.

It changed my perspective on certain topic, I especially liked the part about the MTQ and the decision making progress. Also the end of the book, which deals less about chess and more about dealing with yourself, was an eye opener on a lot of topics.