This is the first part of the ninth article from the series "Tips from The Clean Coder". Here we gathered and summarized the main tips from the ninth chapter.
Eight hours is a remarkably short period of time. As a professional, you expect that you will use this precious time as efficiently and effectively as possible. What strategy can you use to ensure that you don't waste the little time you have? How can you effectively manage your time?
Meetings
The next time you are in a meeting, calculate the costs per hour, considering salaries, benefits, facilities costs, and so forth. You may be amazed.
There are two truths about meeting.
- Meetings are necessary.
- Meetings are huge time wasters.
Professionals are aware of the high cost of meetings. They are also aware that their own time is precious, they have code to write and schedules to meet. Therefore, they actively resist attending meetings that don't have an immediate and significant benefit.
Declining
You don't have to attend every meeting to which you are invited. You need to use your time wisely. So be very careful about which meetings you attend and which you politely refuse.
The person inviting you to a meeting is not responsible for managing your time. Only you can do that. So when you receive a meeting invitation, don't accept unless it is a meeting for which your participation is immediately and significantly necessary to the job you are doing now.
Leaving
Meetings don't always go as planned. When the meeting gets boring, leave.
Clearly you should not storm out of a meeting exclaiming "This is boring!". There's no need to be rude. You can simply ask, at an opportune moment, if your presence is still necessary.
The important thing to realize is that remaining in a meeting that has become a waste of time for you, and to which you can no longer significantly contribute, is unprofessional. You have an obligation to wisely spend your employer's time and money, so it is not unprofessional to choose an appropriate moment to negotiate your exit.
Have an agenda and a goal
To use the participants' time wisely, the meeting should have a clear agenda, with time for each topic and stated goal.
Make sure you know what discussions are on the table, how much time is allowed for them, and what goal is to be achieved.
If you find that the agenda has been high-jacked or abandoned, you should request that the new topic be tabled and the agenda be followed. If this doesn't happen, you should politely leave when possible.
Stand-up meetings
These meetings are part of the Agile canon. Each participant takes a turn to answer three questions:
- What did I do yesterday?
- Whats am I going to do today?
- What's in my way?
Each question should require no more than twenty seconds, so each participant should require no more than one minute.
Iteration planning meetings
These are the most difficult meetings in the Agile canon to do well. Done poorly, they take far too much time.
They are meant to select the backlog items that will be executed in the next iteration. Estimates should already be done for the candidate items. Assessment of business value should already be done. In really good organizations the acceptance/component tests will already be written, or at least sketched out.
The meeting should proceed quickly with each candidate backlog item being briefly discussed and then either selected or rejected. No more than five or ten minutes should be spent on any given item. If a longer discussion is needed. It should be scheduled for another time with a subset of the team.
My rule of thumb is that the meeting should take no more than 5% of the total time in the iterations. So for a one-week iteration (forty hours), the meeting should be over within two hours.
Iteration retrospective and demo
These meetings are conducted at the end of each iteration. Team members discuss what went right and what end wrong. Stakeholders see a demo of the newly working features. These meetings can be badly abused and can soak up a lot of time, so schedule them 45 minutes before quitting time on the last day of the iteration.
Allocate no more than 20 minutes for retrospective and 25 minutes for the demo. Remember, it's only been a week or two so there shouldn't be all that much to talk about.
Arguments/disagreements
Technical disagreements tend to go off into the stratosphere. Each party has all kinds of justifications for their position but seldom any data. Without data, any argument that doesn't forge agreement within a few minutes (somewhere between five and thirty) simply won't ever forge an agreement. The only thing to do is to go get some data.
How do you get the data you need to settle a disagreement? Sometimes you can run experiments, or do some simulation or modeling. But sometimes the best alternative is to simply flip a coin to choose one of the two paths in question.
Beware of meetings that are really just a venue to vent a disagreement and to gather support for one side or the other. And avoid those where only one of the argues is presenting.
If an argument must truly be settled, then ask each of the arguers to present their case to the team in five minutes or less. Then have the team vote.
Top comments (0)