alt
February 2nd, 2010

by Pavel Cheshmedjiev


Let’s define reporting skill as a set of similar reporting skills from regular daily reporting, through providing status information, to detailed descriptions of the tasks or just proactive communication to show presence. Reporting skill is one of the most valuable soft skills that a typical software engineer could ever acquire. How important they are will be a topic in some of the next papers, for now we can assume that they are surely in the top 3. We all know what are the claimed corporate benefits, especially in the fashionable agile project management practices. We also know what are the benefits for the engineer – comprehensive daily reporting makes good impression before the management and is one of the main factors for measuring one’s progress. In general we should state clearly – in corporate envioronment proper reporting is much more important for someone’s professional growth than knowing and using latest Java frameworks, design patterns and best coding practices.

It is not that I never tried this skill – I really tried to report and be proactive in the soft skills sense. I tried many times, in many different environments, every time more and more motivated. Unfortunately – without noticeable success. Nevertheless each time satisfied and happy with the progress itself, not the way this progress was acknowledged.

My first reporting failure was in the outsourcing company where I started real software development and continued happily about 7 years. In the very beginnig we reported directly on demand and had some weekly reports where we could explain with a few words what we did. After some years we were acquired by a bigger company, where more dynamic reporting was needed. A few months later while I had many serious development tasks in a very delicate moment I was escalated to my lead engineer that the management had no idea of my progress. They missed mainly proactive mails and stuff like this. In fact I really prefered to concentrate on my work and have it done in the best possible way. This time for the first time I learned one of the most important principles – It doesn’t matter what you do, it does matter what others think you do. In fact I’m very thankfuk to my lead engineer that fully understood my hard skills nature and helped me a lot.

Next reporting failure was a sound one because of the strict discipline and corporate culture in my next company – one of world software leaders. I had to do daily reports, we had different reminders, guides how to do it, automated mails and even human email warnings as last phase. In the beginning I reported kind of regularly, then a bit more rarely and finally I found myself with the human email warning, alerting that is it is the very deadline to prepare my daily reportings for the last two months. What I was doing at that moment – I had digged into some deep source and been doing some irritating reverse engineering activities, due to absolutely undocumented project. I really wanted to skip the reporting part and in the same time to have the last task there – so I put “Code Inspections” for 40 days. I’ll skip the details but it appeared that the normal code inspection time for such period was exactly 4 hours ! Epic fail, resulting with many jokes, respect in the hard skills society and a new signing title “Code Inspector”.

The text is getting bigger, resembling a soft skilled one, so I will only mention about the other big failures and try to summarize briefly. Next time I beated the department “no report” record in one of the telecom leaders in Eastern Europe. My manager entered into the room and tried to make sure that I’ll try to report, at least because of the other colleagues. He also showed respect of my record, because only he had achieved similar results.

Finally I had a recent report summary of 3.5 hours in my current company, where about 500 hours were expected. I was too smart to mention the CTO that we shouldn’t expect that the project burndown chart is absolutely correct because we must assume that not all developers had resolved their numoreous SCRUM tasks. He thought for a while and checked my report summary … a moment of discomfort, disgrace and dis*.

The good thing is that without any exceptions I’ve worked with and reported to very knowledgeable people, hard skillers by nature and never had real problems with my reporting skill and unwillingness for fake proactive behaviour. Nevertheless I always claim that reporting is really needed, but a suitable approach can solve serious issues. What are these issues and what causes them will be one of the next no-soft-skills topics.

Thanks for your time.

Let’s define reporting skill as a set of similar reporting skills from regular daily reporting, through providing status
information, to detailed descriptions of the tasks or just proactive communication to show presence. Reporting skill is
one of the most valuable soft skills that a typical software engineer could ever acquire. How important they are will be a
topic in some of the next papers, for now we can assume that they are surely in the top 3. We all know what are the
claimed corporate benefits, especially in the fashionable agile project management practices. We also know what are the
benefits for the engineer – comprehensive daily reporting makes good impression before the management and is one of the
main factors for measuring one’s progress. In general we should state clearly – in corporate envioronment proper reporting
is much more important for someone’s professional growth than knowing and using latest Java frameworks, design patterns
and best coding practices.
It is not that I never tried this skill – I really tried to report and be proactive in the soft skills sense. I tried many
times, in many different environments, every time more and more motivated. Unfortunately – without noticeable success.
Nevertheless each time satisfied and happy with the progress itself, not the way this progress was acknowledged.
My first reporting failure was in the outsourcing company where I started real software development and continued happily
about 7 years. In the very beginnig we reported directly on demand and had some weekly reports where we could explain with
a few words what we did. After some years we were acquired by a bigger company, where more dynamic reporting was needed. A
few months later while I had many serious development tasks in a very delicate moment I was escalated to my lead engineer
that the management had no idea of my progress. They missed mainly proactive mails and stuff like this. In fact I really
prefered to concentrate on my work and have it done in the best possible way. This time for the first time I learned one
of the most important principles – It doesn’t matter what you do, it does matter what others think you do. In fact I’m
very thankfuk to my lead engineer that fully understood my hard skills nature and helped me a lot.
Next reporting failure was a sound one because of the strict discipline and corporate culture in my next company – one of
world software leaders. I had to do daily reports, we had different reminders, guides how to do it, automated mails and
even human email warnings as last phase. In the beginning I reported kind of regularly, then a bit more rarely and finally
I found myself with the human email warning, alerting that is it is the very deadline to prepare my daily reportings for
the last two months. What I was doing at that moment – I had digged into some deep source and been doing some irritating
reverse engineering activities, due to absolutely undocumented project. I really wanted to skip the reporting part and in
the same time to have the last task there – so I put “Code Inspections” for 40 days. I’ll skip the details but it appeared
that the normal code inspection time for such period was exactly 4 hours ! Epic fail, resulting with many jokes, respect
in the hard skills society and a new signing title “Code Inspector”.
The paper is getting longer, resembling a soft skilled one, so I will only mention about the other big failures and try to
summarize briefly. Next time I beated the department “no report” record in one of the telecom leaders in Eestern Europe.
My manager entered into the room and made sure that I’ll try to report, mainly because of the other colleagues.He also
showed respect of my record, because only he had achieved similar results.
Finally I had a recent report summary of 3.5 hours in my current company, where about 500 hours were expected. I was too
smart to mention the CTO that we shouldn’t expect that the project burndown chart is absolutely correct because we should
assume that not all developers had resolved their numoreous SCRUM tasks. He thought for a while and checked my report
summary … a moment of discomfort and
The good thing is that without any exceptions I’ve worked with and reported to very knowledgeable people, hard skillers by
nature and never had real problems with my reporting skill. Nevertheless I always claim that reporting is really needed,
but a suitable approach can solve serious issues. What are these issues and what causes them will be one of the next
no-soft-skills topics.
Thanks for your time,
Pafka

4 Responses to “ Reporting skills ”

  1. ivko3 says:

    People in the industry have thought about the hard-skill oriented persons like you, Pafka. There is this great plugin for Eclipse called Mylyn. It has connectors to all the great reporting (and not only) frameworks (Bugzilla, JIRA, Trac, etc.). Apart from all the great features that can keep you focused only on the class and resource files that you work on, it calculates your progress automatically for you. And it costs one button click for you to send the data accumulated by Mylyn to the report server.

    There are cooler mylyn-based plugins and tools that go even further. For example last week I went through this article:

    http://eclipse.dzone.com/articles/mastering-eclipse-toolset

    Unfortunately these goodies are for small companies or for simple project reporting. In big companies like the second one from your list you cannot go without the coarse granular reporting, which usually takes one minute per week (you don’t need to go in too much detail about this). However for day-to-day reporting manually writing your even one-pager report is an overkill.

    Disrespect, Mr. Inspector! :-)

  2. pafka says:

    That’s great Ivko, I’ll try to integrate it with Jira. I should check such support for other tools. The real reporting problem is with the proactive reporting and behaviour, it’s hard to integrate :-)

  3. Madeleine says:

    Hеllo eveгyonе, it’s my first go to see at this web site, and piece of writing is actually fruitful for me, keep up posting these types of articles or reviews.

Leave a Reply

CAPTCHA Image
*


five × = 10