Email has for many become the curse of today’s paperless office. They pile up faster than you can process them. The fact that many emails are impossible to understand, or completely pointless, doesn’t help.

This post lists five principles that will help you write more effective emails that benefit both you and the reader.

Paired with effective filtering and inbox management you stand a much better chance of persevering on the email battlefield.

As I begun my new job, I moved to Gmail from Outlook. I also upped my daily email barrage.

Zero Inbox suddenly became very relevant again.

Setting up Gmail, I hade these three goals in mind:

1. Keep the inbox to zero while still using it as a dashboard for things to keep track of.
2. The ability to send emails to myself as reminders (imho, better than using a secondary todo application).
3. Make processing information as easy as possible

And this is the prize we’re after:

Ever wondered why some people seem to get more work done, and in less time, too?

Ever found yourself sitting at the desk with work piling up and 100+ emails in the inbox, not knowing where to start?

This series will help you get underway to become more productive and get work done in time for Friday night at the local pub.

Communicating is inevitable at work, and good communication skills are key to happiness and success.

Only one thing is more difficult than being good at giving constructive criticism: being good at receiving it.

Being able to say no is not always easy either. Have you ever accepted a deadline or yielded on a time estimate although you know it’s impossible?

Here are three techniques/mnemonic rules that can help you communicate more efficiently.

In an attempt to ride the wave of backronyms like INVEST in your user stories and DEEP product backlogs (though they are now supposedly DEEO ;-)), here's my rule to create task lists for doers.

I am childishly pleased with the backronym, but I'm pretty sure it's not foolproof: can you think of other characteristics that make a good task list? Let me know! Anyhow, here goes…

Nothing is more annoying than unproductive meetings. Some things irritate me in particular: people answering phone calls, people working on their laptops, and off-topic discussions.

You would think it goes without saying that you don’t do these things in meetings. However, it doesn’t seem to be so natural. Hmm… Come to think of it, I might be guilty of the last one myself occasionally.

This is the fourth post in a series about hidden project changes: things that affect scope but are easily overlooked. The topic for this post is third party APIs.

You often have to rely on third parties to finish a project. Having a dependency on third party code is a big commitment though, and you should consider it carefully.

If you have no choice but to use a certain API (perhaps it is a requirement by the customer or the only one available) reviewing it is especially important to provide accurate time estimates and properly analyze associated risks.

There are better ways to read log files than scrolling hundreds of lines in a terminal window.

Using standard tools in Linux, logging becomes effective and simple. In addition, the tools are versatile and worthwhile to master.

I considered structuring this post based on the tools, but a lot of good resources with that approach already exist. Instead, I have outlined the article based on three scenarios when reading logs: runtime parsing, post-parsing and post-processing of log files.

Commenting code is by some considered a code smell or anti-pattern in itself: code should be self explanatory. I agree that a lot of comments could have been left out in the first place. I think comments serve a purpose though, used in the right way. However, here are three ways not to use comments in code.

Working for a small company has a lot of benefits. It is easier to make your voice heard and get recognition for your work. Smaller companies sometimes take better care of their employees and offer benefits not available in larger corporations. Most of all, though, it’s a lot of fun!

Working in a startup is also associated with greater uncertainty. If the company is in a decisive period and management fails to make the right decisions, your job security is jeopardized.

Here are five things that you should ponder before accepting a job offer from a startup or small IT company.

In a previous post, I discussed how to conduct effective meetings. However, if you repeatedly find yourself in inefficient meetings, you need strategies to deal with it.

Although this can be difficult, obviously you should first try to change the meetings culture of your company. In the meanwhile, or as a last resort, consider the following four ways to deal with ineffective meetings.

Amidst the myriad of books out there, here are five I find worthwhile for all developers. These books do not cover a specific language or technique. Instead they provide a broader spectrum of good advice. If I had to pick one of them, it would definitely be The Pragmatic Programmer – From Journeyman to Master. This book offers some great insights into what the programming profession is really all about, and how to excel as a developer.

An efficient system for keeping track of things to do is a must have for anyone with a busy life. In this post, I describe my  Getting Things Done (GTD) setup in Remember The Milk (RTM).

I can think of at least four requirements for a working task management system (read: a system I actually stick with and use):

• It needs to be very simple, if not idiot proof (call it self insight).
• It needs to be flexible and extendable.
• It needs to be accessible from just about anywhere.
• I don’t want to be bothered by stuff not relevant just now.

Have you ever found yourself in a room with people discussing the internal test server’s footer size, or some other similarly insignificant detail? Making things worse, did you go to the meeting because you thought you were finally going to make a decision about that business proposition that could make or break the company?

When you start on a new assignment and land in a new environment, it is easy to feel a bit lost and confused. As a consultant, especially, you feel an obligation to contribute right from the start, and bring value to the team immediately. Easier said than done! Here are some advice that might help.