14 April 2012

The Diaries Continue

My employer, or to be more specific the department I am working for, is hiring senior Java developers. This is a rare opportunity as usually IT related jobs move from high-wage economies to places where wages are lower. So people keep asking me how am I doing. Here is an update of my diaries. As usual all my writing is fictional and has no resemblance to any real people or companies.

I've got a new friendFinding a Friend
In August I made sort-of a friend. He is from another team and our teams are not related, but we share the same version control repository. By accident I saw some crazy things in his changes so I mailed him. After a nice discussion he started reviewing my changes and sent me an email whenever he spotted something that looked suspicious. In the same way I have annoyed people all over my own team with their code, so no one hesitates to send me a note whenever I misspell something. Sweet Revenge Huh.

Consequences of Diaries
A few days after I had published my first diary, my boss approached me and asked me about it. I was frightened. Had I gone too far and pissed someone off? I checked the blog post several times to make sure it was neither aggressive nor diminishing. My fear was unfounded. As I had been wearing my own shirts with my URL code-cop.org on it, a colleague had visited my blog and read it. He was concerned because my writing seemed depressed. So my manager took me aside to confirm that I was still the right person for the job and that he had no doubts about me. It was good to know that someone cared about me, especially at the beginning of a new job.

How to Order a Book
After buying a book about some technology being used in the current project I asked my manager for a refund. I used to ask for a refund of book expenses. It was not about the money but more about a gesture of my manager that he or she appreciated and supported me reading technical books on my personal time. Unfortunately, during most of my jobs, I was not supported and my requests were rejected with ridiculous excuses. So eventually I stopped asking. Refreshed by the new job I did ask my new manager without expecting much. Again he surprised me. First he checked how to fill the form for a refund, then he helped me, in person, to fill it. Later he kept me updated about the state of the approval process without even me asking. That made me feel supported like never before.

Error Handling
It turned out that our application had serious problems in its error handling. Pieces of code like
catch (Throwable t) {
   throw new Error(t.getMessage());
}
or my favourite code snippet to throw all exceptions,
for (Throwable exception : exceptionList) {
   throw exception;
}
were not uncommon. And I am not talking about the 636 empty catch blocks placed throughout the application.

Strong Language
Nevertheless things went well. The crappy code did not improve on its own but we grew a team and started cleaning up the mess. I kept finding awful heresies of code which had been freshly perpetrated and did not hesitate to point them out. 12 A Once a particular change made be very unhappy - well not only unhappy, but it made me sick. It contained everything you would not like to see in your code, for example strange boolean expressions like if (isChanged == true) instead of if (isChanged), useless field names like _dpL, magic numbers, large amounts of commented code, long lines mindlessly formatted and even more problems. I spent an entire hour summing up the problems and proposing ways to fix them. I contained myself but I might not have been particularly polite. Afterwards I had a chat with the developer to make sure that he was neither insulted nor angry with me and everything looked fine. But the next day my manager showed me an email, he received from the developer complaining about my strong language that had made him feel uncomfortable. (Strong language is a markedly or unwarrantedly forcible or vehement manner of expression or choice of words.) I admit that I am direct and I understand that do not and wrong might be considered strong language by certain people, but I have also strong opinions about what you just do not do in your code and when some functionality is in the wrong place. He should consider himself lucky that I did not follow Alberto Savoia's Management Approach.

CV Wizard
We are a service organization and every employee is asked to enter his or her curriculum vitae into an internal database. When a proposal for a customer is prepared, sales people browse this database and choose suitable people for the project. Although I was on an active project the reminder emails of the CV wizard kept pestering me. After a month I gave in and started to fill in my data. It looked easy but was not. For each passed project I had to figure out my role, my tasks, responsibilities, contributions and accomplishments. "I created code, it was clean and worked" did not quite fulfil these requirements. Additionally I had to choose my words carefully as the CV was supposed to help sales people and should communicate "I deliver client value" at least in every third sentence. It took me 11 hours to finish my CV but in the end I liked the result. I have never known I did so many great things ;-)

Incoming Changes
Missile CommandI used to review incoming changes. I did not do formal reviews, just browsed through the changes before accepting them, read the descriptions and had a look at the differences if I felt like it. Some day in November I stopped doing that as it was pointless. Usually I managed to read three or four changes before I fired up my email client and started writing about the given architecture, coupling, separation of concerns or similar things. It just took too much time, therefore I could not afford to spend several hours each day on informal code reviews. So I had to "trust" my colleagues instead.

Learning Plans
To get to know the company, new hires were supposed to work through special learning plans each consisting of several hours online presentations about various topics related to the company's policies, workplace habits and offerings. End of November I finished the first one. Finally I started getting an idea what the company was all about.

Goodbye Eclipse
In the middle of December I wrote my last piece of code. Caring about the overall product, development process and architecture I (was) moved more and more into backlog definition, sprint planning, setting up the development infrastructure, code reviews and acting as team lead. I spent most of my time attending meetings and writing emails. It makes me unhappy.

Desk Sharing
I do not like desk sharing. Setting up my keyboard and aligning my monitor each day is just a waste of time. Further most of the screens are so dirty that I need two cleaning pads to wipe them. It looks like I am the only person caring for clean screens in my area of the building. With the beginning of January things got worse. The company started a big project and lots of new people were joining. The office got crowded and - in the end - was running out of space. Some colleagues started working from home several days a week. While working from home may be desirable under certain circumstances, it was not helping us at all. Informal communication stopped happening and the team started falling apart. As a late worker it made my life especially difficult. When I arrived at the office most desks were already occupied. There was no way I could sit near my team (or at least what was left of it). Well, almost no way. I chose to sit on a coffee table in a break area next to my team for several weeks. That situation really annoyed me. Since 2005 I have been working with two screens all the time, even at home, and suddenly I was downgraded to using a small Laptop screen and no proper place to sit.

No Time to Write Unit Tests
As I said before, there were several teams developing a family of applications and sharing the same version control repository. There was no separation of these applications and the teams were connected and somehow depending on one another. I was always happy to spread the idea of clean code and did not stop inside my team. A colleague from a smaller, recently introduced application showed interest in raising the quality of his work. He asked me for help to introduce unit tests into his development work and I was more than eager to help him. He is smart and understands the concepts. Short after that he started writing useful tests. Unfortunately things did not go well and in the end he was forced by his team lead to abandon writing unit tests. Of course the team lead did not tell him to stop writing tests. He just asked my colleague to get more done and that he should not even implement the requirements completely, just implement the happy path of as many features as possible. That made me angry and depressed at the same time.

Resource Action
Last month I overheard my manager talking about a serious situation in the company's US branch. It was about some 'resource action'. I did not understand what it was about and did not care, US was far away. At least it was far away until I opened the intra-net page the next day. I guy that I knew was affected by the resource action (read layoff) and had been axed. I was shocked because Robi B. was no ordinary employee, rather one of the more dedicated ones. We did not share any work but I kept noticing his posts and comments all over the place. Well, probably not all over the place, as "this place" was huge, but at least in the areas that mattered to me. Recognizing him as a community builder and enthusiastic individual, I got in touch. Robi believed in innovation and organized Hackday beside his regular work. (Hackday was a community of people engaged in creating new tools and brainstorming great ideas about how to make their work lives better. For more information follow @hackday.) Robi had been with the company for almost 15 years and had started several innovative projects.

2 comments:

Pat said...

Are you sure that you're at the right place right now? If you love coding, do it! Don't get stuck in this organisational stuff: Management is not the only way to a career!

Besides: I worked for a long time for another big company. Leafing my comfortable position there and joining a smaller one gave me my fun at work back - and fun at work is more important than status and payment (at least, if one can effort).

Peter Kofler said...

Pat, you are right. I do love coding and the organisational stuff is killing me. I agree with you in the long run, but here are still some achievements to unlock, so I will stay for a while.

Regarding smaller companies - I really favour large projects, say with around 1M LoCs, as smaller code bases are just "too easy" to work with.