About feedback

Feedback is an important tool as it gives invaluable information about you, the other person and the team. The goal is to improve his/her work as your own work as team lead.

Preparation

• Plan feedback rounds well in advance. Not only is it important to let the other party prepare, but also communicating the upcoming feedback rounds weeks in advance makes the team aware of the upcoming feedback rounds. It’s easier to create an impact with feedback where an example can be given of the behavior.
• Take enough time. I always plan 1h for each, although it’s not the plan to fill the entire hour. Typical feedback rounds take about 20min, but giving yourself the freedom to go into detail if necessary, makes the conversation open and not overhasty.
• Plan personal conversations. Sincere feedback is feedback done in small groups. For developers, I bring the project lead with me, since the project lead can give another perspective.
• Prepare yourself
• Ask the other to explicitly prepare themselves. Point the other party that a good preparation is necessary.
• It’s important to give both positive as negative feedback.

How to give efficient feedback

1. Describe behavior that can change
2. Use concrete examples that you have seen for yourself (preferred) or heard from.
3. Use the I-form. I noticed that…
4. Describe the effect the behavior had on yourself
5. Let the other respond
6. If relevant: ask for the desired behavior
7. Explore the background and/or solutions

Follow up

An important aspect of feedback is the follow up. Plan something a couple of weeks after the feedback and see how the feedback changed you or the one you gave feedback to.

Regards,
Andries

From the quick start:

Quick Start
 * Download the latest release from http://sourceforge.net/projects/statsvn/
 * Expand the zip file into some directory, e.g c:\statsvn
 * Check out a working copy of the desired SVN module into
 some directory, e.g. c:\myproject.
 * Change into that directory and type
 'svn log --xml -v > svn.log'
 * Change back to the c:\statsvn directory
 * type 'java -jar statsvn.jar c:\myproject\svn.log c:\myproject'
 * Open c:\statsvn\index.html in your web browser

Regards,
Andries

I’m finishing The Last Lecture, a book I advice to any and all. Truly a life changing experience. Following paragraph is a synthesis from a chapter.

1. Time must be explicitly managed, like money.
2. You can always change your plan, but only if you have one.
3. Learn to delegate.
4. Ask yourself: Are you spending your time on the right things. Prioritize and filter.
5. Develop a good file system. Order is efficient.
6. Rethink the telephone: do it either standing up or with a time pressure. Don’t spend your time with calling all the time.
7. Take time outs. Real timeouts without interruption.

Keep your inbox clean!

I’m a big fan of GTD. Especially when applied to organizing your inbox. I spend quite a lot of time reading and writing mails, taking action on them, etc. My Outlook client is open all the time.

Before I worked with GTD, my inbox was staggering, mails could not always be responded within appropriate times or actions got lost. It’s not very pro if you have to receive reminder-mails.

Now my best advice is to follow these simple rules (copy/paste from the Wikipedia article ):

• Start at the top (In case of mails, this would be the oldest mail)
• Deal with one item at a time.
• Never put anything back into ‘in’.
• If an item requires action:

• Do it (if it takes less than two minutes), OR
• Delegate it, OR
• Defer it.

• If an item does not require action:

• File it for reference, OR
• Throw it away, OR
• Incubate it for possible action later.

If it takes under two minutes to do something, it should be done immediately. The two-minute rule is a guideline, encompassing roughly the time it would take to formally defer the action.

My inbox is in the end of the day almost always empty. More importantly, the easy-respond mails get done very fast, which gives a much faster average time on processing the mail. It really does!

If you like to see more on GTD, start with the wikipedia page. Also the book by David Allen is very good, so I’ve been told.

Until the next,

Andries

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

Shorten the build cycle for developers

The length of the build-cycle is critical for developers.

Exploded development

With the release of JBoss Tools for eclipse, I finally managed to get a very good exploded development going on. I tested the beta 3 as well as the beta 4. In both cases, exploded wars didn’t function as I wanted. Didn’t remember quite what didn’t work, but with the the GA release, everything worked out fine.

The main benefit of exploded development is the powerful option to edit JSP files live! This is a serious advantage. Our team started out without this, but as the project exploded in size, the start-up time was increasing drastically. Would not ever want to do another project without this ability!

Another great benefit is the possibility for incremental publishing (standard behavior with the plug-in). Packing a war is something that can take half a minute or longer using eclipse, with incremental publishing only the changed files are submitted, resulting in mere seconds.

The last benefit is a faster start-up, since the server doesn’t have to unpack the war. Our war is about 45Mb large, which took 10-15 seconds to unpack.

There is one setback! When using this, there is a bug when you have breakpoints in eclipse. The breakpoints sometimes (and this is rather frequent, say 1 in 5) cause the server to start up really slow. And slow is like 1h to start… The workaround here is to restart the server and disable the breakpoints on start-up, enabling them once the server is started. It’s a common bug when you Google for it, so I’m confident this will get resolved soon.

Hot-code replacement

Learning how to use hot-code replacement can save some restarts of the server. With hot code replacement, you can alter any Java code, as long as you stay within the method where your breakpoint currently hangs. This is perfect for adjusting 1 line of code, since most bugs are exactly one small thing that was wrong.

There is a little more to it. Sometimes eclipse complains about the failure of the hot code replace. What we do is following: we let the thread run until it’s finished. Then we start the code again (refresh the page, submit a form…) and let it stop on the same breakpoint. Then we add 1 space and save it. This never fails!

No Hibernate Cache

Another great way to speedup the start time during development, is to disable the Hibernate cache (second level cache, query cache) during development. With a maven profile, this is done very easy.

We have about 25 classes that are non-strict read/write cached. This takes about 12 seconds to start-up, every class that is cached has it’s own thread started by Hibernate (I think this is for timeout of the cache).

No premature loading of cached items

Many applications start by eager fetching some data this is cached then. I believe this is completely useless in a development environment. Again with Maven this ain’t hard to set up.

A word about Spring configuration

One could argue that the Spring configuration could also be completely lazy. Indeed, this would be a tremendous start-up gain, in our 100 beans large project, it takes 20 seconds to set up the beans. It’s the single most time consuming event in our application start-up.

We don’t do this, since it posses a real danger. With lazily initiated beans you lose the dependency checks at start-up

Shorten the setup time

Setting up eclipse is something we needed to do quite a lot of times. When switching branches, when added dependencies etc.

We used to use the maven eclipse plug-in. Lately I found out that this plug-in is absolutely unnecessary. With the proper maven setup, the simple command mvn eclipse:eclipse does the trick. Actually you need two things:

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-eclipse-plugin</artifactId>
                <configuration>
                    <wtpversion>1.5</wtpversion>
                </configuration>
            </plugin>

Above is a plugin in the web module (pom.xml).

<jboss-web>
    <context-root>mistral</context-root>
</jboss-web>

Above is the content of the file webapp/WEB-INF/jboss-web.xml , which sets the context-root with jboss. If you don’t do this, it’ll default to the war filename.

Other optimizations

In order to have the best possible environment, other optimizations are in order. But I’ll keep those for my follow-up. Things that can be improved:

• Use of the continuous integration.
• A (good) project wiki
• How to manage multiple databases efficiently(database independence per developer)
• Office instant messaging

Conclusion

Pretty long post. There is a lot to say about development optimizations. My experience in it is that there is a lot to gain. There are some key concerns however:

• KISS, Keep It Simple Stupid.  An optimization should never be something that has to be explained. Optimizations are only good optimizations when they feel natural, they should also make things simpler almost never more complex.
• A very important one: a team should work all in the same manner. It’s too hard when multiple ways of developing have to be supported.
• Don’t be afraid to change your development manners. Sometimes a change can be a little investment, but large gains on longer terms.

As always, I’m open for debate and questions.

Regards,
Andries

In this blog I want to address the other side of the medal, namely a code review viewed as a developer. Code reviews are for the developers. So it’s important that you, as a developer, understand what is in the review and learn from it.

Why code review matter

Code review are a way to keep the quality of the code at a high. Finding bugs are the second most important thing a code review can accomplish. The most important benefit is when done right, a code review will deal with bugs before they are even written. By enforcing best practices (e.g. design patterns) and principles (Single Responsibility Principle, Liskov Substitution Principle, …) and also coding guidelines such as commenting every method, using describing method names, bugs will actually be avoided because the quality of the code is augmented!

It’s important for you, a developer, to realise that code reviews aren’t for discussing your bad code. See it more are an effort to increase the level of quality in the entire code.

The Cheat Sheet

One nice tip I came across is the use of a cheat sheet. At the start of the code review, all developers should bring a piece of paper. When discussing the review, each developer should write down an issue he/she would be able to write. As a developer, don’t focus on only the code you wrote, but ask yourself the following questions:

• Could I have made the same mistake?
• Did I know about the item, why is was wrong?
• Would I have noticed the code myself?

If you answered yes to any of these question, you should write down the issue on your cheat sheet.

The cheat sheet should be used every time you want to commit code. Take the cheat sheet (really read it) and check the code if something could be coded better. Having the cheat sheet will help you to not introduce items already covered by a code review. Reviewing the same bad code twice is a sign a developer hasn’t learned from the previous review.

Create a positive environment

When reviewing code it’s important to create a surrounding where it’s encouraged to discuss code, where it is a positive thing when code can be improved rather then pick on the one who wrote less then perfect code. As a developer you should keep this in mind as well. Nobody wants to write bad code, so don’t focus on the coder, focus on the code!

Don’t be afraid to discuss code. Sometimes it’s only after a couple of questions that code is really well understood. Sometimes reasons for particular code goes deeper then eyes at first see. A successful code review is a review where developers asked question about code.

Beware of the developer against the world syndrome. It’s normal to take pride on your code. Don’t let the pride come between your code and better code. It’s a learning experience, embrace it and swallow the pride when necessary. That one of the reasons code review are a group thing.

Refrain from negative comments or inappropriate comments. A good example is saying: I would never write that; Who wrote THIS? etc.

Semper paratus

Always be prepared. A great developer will have read the copy before entering the discussion, making the review go faster and the questions more intelligent. It’s just common sense to at least spend a few minutes preparing for any meeting, even internal code reviews.

Anyway, this blog is shorter then I would like. Although code reviews are really important, no matter what kind of project, learning from them is even more important. Take the review serious and you will be rewarded with some extra experience!

Feel free to post any comments about this blog.

Andries