Javaddicts

I’ve been using my own adaptation of die Hipster PDA for quite some time now, and I gotta say, it’s convenient enough to not get in my way, but serves me well as a list of things I gotta do. It’s also small enough to take it everywhere with me. I’ve had my ups and downs with Gettings Things Done. At first I started using an electronic version with VoodooPad, inspired by Mister Charlie, to keep my lists. That’s why I bought it in the first place. Synchronisation to my iPod is a nice feature, but it’s only one-way. You can access your lists, but they’re not living. Adding new actions or projects requires a computer which is good enough for some people, but I tend to prefer paper for this. Having to use my iBook for synchronising my lists is not really convenient, and I tend to lose focus.

So I tried the D\*I\*Y Planner templates with a brace-style approach, like the original Hipster PDA. But handling the sheets of paper was a hassle, so I looked for something more convenient. Then Jeff Torgerson posted his adaptation of the Hipster PDA to the 43 Folders Google Group. Since I like Moleskines too, it seemed like a worthwhile approach. I tried it with a Moleskine Reporter Notebook, and it feeled like a perfect fit. My adaptation looks like this. The templates are taped to the pages in the back of the notebook, the front is for notes, and the tabs are for (you can guess it) easier navigation.

One thing was missing though. The D\*I\*Y Planner templates come along in different types. Next action lists, project templates, waiting lists, you name it. You might wanna check them out, by the way. The project templates are a good start. There’s one template for every project. But since I tend to have several different projects that don’t need such a large template, I came up with a slightly modified version of the action lists, a project list. A simple one-line project list and one with two lines per project. Feel free to use them.

Though I’m usually not a big fan of Dilbert, this comic strip hit the nail on the head: Agile programming doesn’t just mean doing more work with fewer people.

Via pragmatically.net.

Learning is an important part of life. Even after school/college/university, it never stops. In 2 years of my life as a professional I learned more than in 5 years of university. That shouldn’t come as a big surprise for most people having a job, but it came as one for me. But there’s a difference. When you’re studying at college or the uni, professors tend to tell you what they know (if what they tell you is actually worth a penny is a different story). In professional life, it’s up to you to learn. If you don’t learn, you won’t improve your skills, and therefore, your net-worth won’t increase, and you’ll be stuck, stuck at a certain job, in a certain position, without much changing for you. If you stop learning at all, you won’t be a good investment for your company anymore. That might sound harsh, but that’s the way it is. Some people manage to stay around like that for a long time. The bigger the company, the bigger the chance that you’re gonna meet someone like them. So learning is an investment. It’s an investment in yourself. The time you can put into learning will pay off in the future, not necessarily with a bigger salary, but with more confidality, professionalism, raised productivity, you get the idea.

So what should you learn? That’s the most important question of them all. It’s not easy to conclude what might be important for you in the future. You can’t and you won’t know everything, and you won’t need to. You can learn a new programming language, play with that tool you always liked, or just look at your own weaknesses. There is enough to learn. I tend to focus on my personal weaknesses, and on stuff that I witnessed in my projects. The last part is very important. A lot of projects go along, fail, never come to an end, or succeed with anybody ever questioning why. That’s too bad, because a lot can go wrong, or can be done wrongly during a project. A solution to a problem turned out to be a big problem by itself, someone made a bad decision, your manager did something your whole team never really liked, or a new tool turned out to be a huge waste of money without having any positive impact on the project (think UML, not your everyday text editor). The list is endless. I recently started reminiscing on the last two years of my life, professionally of course. The personal stuff too, but that’s a different story. I brainstormed the project I was involved with, the tools we used, the kinds of communication, how the team worked together, what I did wrong, what someone else did wrong, the way the project was lead, the technologies used, and their impact on productivity. Once I started, my paper sheet soon didn’t offer enough space for the ideas that popped into my head. Brainstorming is a cool tool for recollecting thoughts, since your brain follows the associations you draw and soon new stuff comes up that was somehow related to what you just jotted down.

After I got the feeling that I captured most of it, I started putting them together as notes and to explicitely shape the lessons I learned from the specific experience. It’s important to not only point out the lesson learned, but to name the reasons that lead you to your conclusions. Writing “EJB is unproductive” is the one thing. Figuring out why is the other, and definitely the more difficult task. It has to be more like: “EJB is unproductive, because of the longish deployment cycles, because of the huge overhead of the container, and because it enforces programming boundaries that restrict me in the way I normally develop software”. I tend to go up the levels of abstraction from specific technologies to more generic conclusions like: “Pick your technologies wisely. Choosing the wrong technologies for whatever reasons (because it’s cool, state-of-the-art, expensive, everybody else uses it) can have devastating consequences on the project.” Now that might be obvious, but it’s just to give you an idea.

That brings me to the next important thing with learning: Critically analyze what you read an hear. This might sound familiar to those who read “The Pragmatic Programmer”. But the idea is exactly what you need to do. Look at things objectively and in terms of you and your project. Choosing a tool, because it’s cool, is the wrong way to look for a solution to a problem. The tool has to fulfill a need you have, it must be the solution to a problem. But that sentence is true for a lot more. If you look critically at things you witnessed, mistakes you made yourself, you’ll learn a lot more than just ignoring it with the all too common attitude, that it surely won’t happen again in the future. I met people from both sides of the story. Some tend to ignore mistakes or problems, although they do them again over and over. They don’t critically reflect on themself, they don’t reflect on the project, and the people they’re involved with. Either they’re too lazy, ignorant, not aware of the problem, or it’s simply too painful to analyse a problem. The latter is a common syndrome, especially with a manager that caused a project to fail, but doesn’t want to come out as the root cause for the failure. Mistakes and problems will be silently ignored and, to nobody’s surprise, will be made again. That’s why it’s important to not only learn from your own mistakes or successes, but from the people around you as well.
I’ve seen all of these different types in action, and it wasn’t a pleasure to look at. But I learned one thing from that experience, and that’s exactly what I’m writing about: Learn your lessons!

Books are another important source for learning. The best books that I’ve read and that have taught me the most were books that told me how and why something works. This includes books like “Ship It!” and “The Art of Project Management”, and of course “The Pragmatic Programmer” that draw on actual experiences and on stuff that did or did not work in people’s professional lives. Since I noticed that a lot off what I read gets lost somewhere in the neural depth of brain I started taking notes about specific lessons learned from books as well. I tend to keep them short, since I can always get back to the corresponding book to go more into detail.

How should you do it? That’s up to you. I have a Moleskine at hand everywhere I go, and when on my computer, I fire up my trusty VoodooPad to collect the next lesson. Having something to write at hand is important, because your personal conclusion to a problem might come at the most unexpected moments. I collect the lessons electronically, because I only want to learn them once.

It doesn’t matter how you do it, it’s only important that you do it. Learn! Improve your skills, your knowledge, and your net-weight. It will definitely pay off in the long run (I was going to write “in the end”, but maybe it won’t pay off anymore then ;).

With the end of last week I worked for the 19 days straight for about 10-11 hours a day including weekends. Nothing special in our industry. Everyone did it or still does it. I love my job, but the fact that I didn’t really get to see my home, my girlfriend and my friends during that time, got me thinking about what value working overtime actually delivers.

Don’t get me wrong, I’m not saying that working overtime is bad. If I’m really into a task, then I like to finish it before I get home. If the solution is within reach, then screw those 2 hours that I stay longer. At least that nasty bug/cute feature/cool algorithm is finally done. If a customer is waiting for an important patch, because your software somehow (these bugs come along in mysterious ways ;) screwed up his daily business, there’s not much of a choice. But, as always, the coin has head and tail.

During the time I thought about this some main points came up: exhaustion, productivity vs. steadily decreasing concentration, frustration and the death march factor.

* Exhaustion

This might be the first sign you run over. Not getting a lot of rest or working too many hours a day for a longer time will definitely lead to exhaustion. Exhaustion certainly isn’t a good feeling. Sure, you can crank up your caffeine intake, but will it have any effect in the long run? Caffeine only has temporary effects. It can stir up your concentration for a few hours (or less, depending on just how exhausted you are), then you’ll go back to that espresso machine to get more of that precious juice that brings the life back into you. Some people I know drink coffee like water. I’ve had that experience to some level, and I hated it. I usually have 2 to 3 latte a day, but I easily added another 2 during the last days. And I definitely hate keeping my concentration up with caffeine. Some nights of good night sleep will most likely have a better effect on your overall concentration than the temporary push of a coffee (as good as it might taste ;).

In the end exhaustion directly affects your work. If you’re tired, you won’t have enough concentration to solve the simplest issues. Not doing anything about it won’t make it better. If you’re exhausted, go home early, take a nice hot and steamy bath, and go to bed early. Simple, yet refreshing.

* Productivity vs. lost concentration

What does working overtime really bring? Does doing it provide any additional value for the employer? To the outside it might look as if the employee is willing to work more to complete her tasks, but isn’t the loss of concentration causing loss of efficiency, because the employee is actually making more mistakes? It’s definitely questionable in the long run. Working week after week, weekend after weekend certainly doesn’t bring value for anyone. Employees are getting more and more tired and make more and more mistakes, so that the software will either be buggier in the end. This will either lead to a longer testing phase or to unsatisfied customers. Is this really what an employer could want? Hardly believable.

This issue is sometimes easily overlooked by management (or so one could believe). It’s easy to tell your employees they have to give 120% for the next n weeks (n being an infinitive number usually greater than 1). But the repercussions can be huge. But it’s two-fold. The best solution isn’t to work overtime at all, either. A developer should understand the pressure her manager has. A manager has some quite different problems than she has. He has to report to his manager, or, in smaller companies, directly to the stakeholders. They’re interest is to get the project out the door as soon as possible to satisfy their customers and create good revenue to satisfy their bosses, the shareholders. So there’s the chain of responsibility that definitely has to be taken into account. A developer should at least know the pressure his boss has. This puts some things definitely into perspective. But that’s a different issue. It’s just important to not just dismiss working overtime. Both parties have to find a solution that satisfies all involved parties, each one holding one to their standpoint will only lead to frustration and a bad team atmosphere. A good manager knows this and knows what he can demand from his team. A good team, on the other hand, knows what it can deliver under which circumstances. But if a project is late, then it should be honestly and openly talked about the potential solutions. If working overtime won’t help, then other (more or less drastic) measures must be taken into account.

* Frustration

Working overtime endlessly doesn’t only exhaust, it stirs up frustration, especially if you spend time with code/framework/tools that tend to cause trouble (I’m thinking of InstallShield here, because it caused me a lot of trouble in the last weeks, but you name it, Hibernate and JBoss are good examples here, too).

The thing with frustration is that it works like a spiral. There’s a new problem, and the frustration rises. More frustration causes more mistakes and therefore, more problems. This is especially true, if you’re the only one working late in the evening or during weekends. That causes even more frustration.

Frustration brings another problem. It blinds the view from the real problem (be it the conclusion that either the problem lies somewhere else, or the fact that the frustration reached a level too high to work effectively). There’s a problem to which the solution might be so simple that it’s actually very easy to overlook it. It happened to me much too often during the last 2 weeks. There’s the productivity/error ratio again. A small error might just cause you several hours of cursing and swearing and trying the most complex solutions to a problem that, in the end, will turn out to be a simple one. In the end, it’s very questionable, if working overtime for several weeks really is for anyone’s benefit. It should be in the employer’s best interest to have an eye on her employees’ working time. It’s honorable, if someone works 10 to 12 hours a day without complaining, but that might either cause trouble for the employer in the form of bugs caused by low concentration, or it could as well mean that she who works long days, has problems structuring her work. Both problems can be solved, but it might be that she can’t handle them by herself.

Rising frustration causes easy blame of problems to someone/something else. If you’re frustrated, it’s easy to say that it’s only Joe’s fault, because you have to sit here and fix his code, and he’s off for the weekend with his wife and the kids. It’s quite easy, because Joe isn’t here, so he can bear your blame without a problem. Being frustrated tends to cause looking for the easy view on specific situations. There’s problem A that causes feeling A (frustration), but since you’re alone in the company there’s actually feeling B which might be anger. You’re mad at your colleagues for not being here with you, however unreasonable it might be, because maybe they can’t help you at all. I’ve gotten more aware of this over the last months during the normal work week, but during those long hours during the weekend it’s easy to forget that feeling A is the actual reason you’re upset. This is called the Satir model, where a feeling B hides another feeling A, although feeling A is the actual cause for your current mood. Dealing with feeling A might be a lot easier than with feeling B. Saying to your colleagues that you’re mad at them, because you felt that they let you down, might have bigger repercussions than just screaming at the sky to get that frustration out in the open without hurting anyone.

The last issue that comes to mind with regard to frustration are doubts. Reasonable and unreasonable doubts. The more frustrated you are the more you doubt everything, everyone and everything else. Including yourself. You doubt that you can finish your task on time. You doubt that the rest of the company really cares that you’re working your ass off. You doubt that the tool you chose really was the best one for the job. You even doubt that this job is the right thing for you. I believe in nothing really, but I learned that it’s important to believe in yourself. Having doubts in yourself is the worst that could possibly happen. If you start to doubt your own skills, then you can pretty much pack and go home, because if you don’t get your act together pretty soon, the task at hand won’t be done on time, that’s for sure. Having doubts is quite natural, but if you doubt that a task can’t be done on time for reasons A and B, then you better talk to your manager about it. If your doubts seem unreasonable, do everything to get them out of your head. Go for a walk, get some fresh air, do whatever it takes.

* The [death march](http://www.amazon.com/exec/obidos/ASIN/013143635X/javaddicts-20) factor.

A famous influence on working overtime. Very common during the dot-com days (it is still today, but it was far more common back then). It’s not a direct consequence concerning working overtime, but it definitely has a huge influence on the effects of doing so. Everyone had a common goal and was working their asses off to reach that goal. The reasons might be different, be it a simply unachievable deadline that everyone wants to reach for whatever cost, a boss that just wants everyone to work all day/night/weekend to reach a goal that everyone thinks it is from another world, or a team that just wants to create something very cool together, and everyone has the highest possible motivation to get it done. The different kinds of death marches have different outcomes with regard to productivity and motivation. If there’s a goal that everyone agreed on, and everyone gave her commitment to reach that goal, then it’s a totally different situation than the one with Mr. Bossman who just wants everyone to work all day and night so that if the team doesn’t reach his illusionary goals he can easily blame it on them. The former team certainly has a different motivation than the latter. Reaching a goal together with everybody wanting to do it will benefit everyone in the team, because everyone motivates each other. Everyone reminds everyone of their goal every day. Mr. Bossman just reminds everyone that the deadline must be reached, or else. The exhaustion factor might exist in both teams, but the frustration factor wiil certainly have a bigger influence on Mr. Bossman’s team. Which team would you rather be on?

So what’s the solution? Hard to say, I didn’t came up with any, yet (if you did, let me know). Avoiding working overtime isn’t always an option, but it’s important to keep an eye on your own physical und psychological shape, and to draw the right conclusions at the right time. So I’m not saying you shouldn’t do it, but you should think about why you’re doing it and for how long you’re able to keep doing it. Sure, this is something one has to learn, but what isn’t? After all, it’s at least always appropriate to ask the simple question: Is it really worth it?