While trying to explain to a friend what I actually do all day, I came up with this summary of our conversation:
This of course not counting coffee, lunch, and snack breaks.
Enjoy the blog? I would love you to subscribe!
Performance Optimizations in C#: 10 Best Practices (exclusive article)
Performance Optimizations in C#: 10 Best Practices (exclusive article)
Want to become an expert problem fixer? Check out a chapter from my book Practical Debugging for .NET Developers
While I completely agree that the “100% write code” is a fallacy (alas, all to common), I have some serious concerns about the breakdown of the other time – seems to be a fairly large number of anti-patterns exposed..
I agree about the anti-patterns David, but I’m not describing an optimal breakdown here at all.
Your average company is functioning sub optimally at best.
I personally worked at companies with useless meetings, build problems and problems with preparing development environments.
There are also many problems with the process between QA, Development and Product management which result in wasted time. Time wasted figuring out the bug from the description, time wasted from figuring out the requirement, time wasted from a lacking Requirement description and so on.
Michael – thanks for the response. My point is that when posting numerical information (such as your pie chart) the numbers should be based on some source material (ideally with that “source” being clearly identified. Based on the text before the graph, the apparent source is your personal and current breakdown….
There are also issues with the summarizations. Let’s look at a simple example “meaningful meetings” vs “useless meetings”.
Were the useless ones truly useless (both from a potential and actual standpoint) when viewed overall for a given meeting or was it your involvement in a given meeting what was used for the distinction?
Now your graph shows a combined 15% which would be 1hr 12 minutes per day average (6 hours per week). This may be high or low. For example a Scrum team running 4 week (20 working day) sprints may have up to 12.5 hours in a given week of prescribed meetings [to reach this figure I used a mid-week Sprint Start, and looked at the week where a sprint transition occurred].
I could use other examples, both from the graph and/or from your reply.
The thing with this breakdown is that it’s very company dependent, team dependent and role dependent. I’ve had very different breakdowns in different companies and in different individual roles.
So the source here is a kind of “average” breakdown from my personal experience. (I understand it can’t be clear from the post since I didn’t really explain it)
Let’s take the meetings you brought as an example.
In one company I worked for, we practiced agile development (not strict Scrum). We had about 8 hours worth of meetings a week for each developer. But the company I work for now is much smaller, without Agile practices and we have just 1.5 hours worth of meetings a week.
The useless meetings I meant it was useless from the perspective as a developer (I didn’t make it clear, I know). The meeting wasn’t necessary useless as a whole.
On an after thought, it’s hard to claim any meeting as useless, since you can gain a lot from any meeting. Knowledge of other developments, making friends and contacts with other employees, adding your own input that benefits others. But a lot of these meetings sure seemed useless at the time.
I actually read it as being tongue-in-cheek, and was going to comment that the mount of time trying to work out what the &^%&^% is going on should be larger!
Do you mean debugging?
hey i spend 59% of time in reading news