As a programmer, I’ve witnessed peers moaning about working-overtime or being pushed by schedule, such as these. Utopia is coding at home with beer aside, pets/kids occasionally interrupt you with their cuteness, but where are your boss and peers in this territory – if you want be a cathedral guy instead of making a living in the bazaar as a vendor, you can’t go through without them. Certainly, working like that won’t maximize your employer’s profits and can’t cooperate with teammates effectively. So that situation is unreachable, we still have to go to office, but at least there’s a way to make yourself really comfortable in office and your employer get the maximum output from you. But how? I happen to have some shower thoughts the other day regarding this.
Consensuses
We need to make some consensus before making a bargain.
First, programmer’s effective input is not measurable, not by working time, not by code-lines. Unlike manufacturing industry, in which qualified parts built by a worker in a unit time is measurable, building software is always a non-linear work, fixing one critical bug may need as much time as writing ten ‘qualified’ features which passed all unit tests and integrational tests, but would fail the stress test, and of course can require as less time as typing several characters if it’s obvious, to someone – I’m not emphasizing this because this example is focus on the diversity of bugs themselves, so programmers’ diversity is not the point.
Second the output is not measurable either, a software is nothing if there’s no user, or user find it hard to use. Even if we don’t consider the money a software can make, or the productivity a software can improve, as metric, just use the software metrics, like story points in the agile context, it is not measurable too. We all experienced two similar stories bidding the same points, but actually the first implemented one values much than the first one, as you know copy&paste constitute most of the most programmer’s activity.
Bearing these in mind, then, from the manager/employer’s perspective, how does he knows his management job is well done, or how is he get the best of his employers? I don’t think there’s any way, person varies with person, if you can not measure their productivity, just believe they are professional(how to ensure this is another topic and is HR’s duty which is answered when he get the offer), and ensure them are productive. If I were a boss, what I would like to is to just make programmers being in a vigorous state, both mental & physical.
Mentally vigorous
It dictates communication in a proper extent. Communicating with others would help you to recognize your issue-to-handle more clearly, but too much of this would blur your focus, make you not-so-targeted – not to mention occupying your time.
Reading an internet post, raising an issue or service request, talking to peers or join a meeting are all kinds of communicating.
It also demand you to distribute your mental activity reasonably. By distribute reasonably, I mean you might need some music or non work chat when you have worked for long time(say longer than 4 four), as long as there’s meal break and coffee break, this would be a problem, the only constraint it brings is not to work over-time heavily and constantly. But it has another meaning which is often ignored, that is even you have 6 hour code time, if it’s broken down into many piecies, I mean divided by meetings, peer-communications, coffee break or internet surfing, it won’t make ‘mental vigorous’ too, with experience, you at least need a block of 1.5 - 2 hours’ time to solve real-challenging problems.
Physical health
I mean cervical/lumbar spondylosis. The 10 tips to prevent lumbar spondylosis or such things always mention don’t keep sitting in 1 hour, walk every 1 hour or so. I’m suggesting this too, actually this didn’t conflict with the 2 hour block you need to solve real-challenge, you can keep thinking of the same issue with this break. And for other breaks outside the 2 hour, talk with peers or go for coffee is surely OK.
Programmer’s daily time distribution
In common sense, to make you productive, yourself or your manager would give you a list of things-to-do, daily or weekly. Books tell you do so too, but as a mental job, things-to-do didn’t always get done even if you assign enough time to it. As I mentioned, inevitable breaks (for mental and physical healthy) and communications didn’t list in your things-to-do, but they actually effect if you can get things done with fixed time. For not-so-competent tasks, you might need more communication. For boring-tasks, you might breaking more, consciously or not. And also for improvement, you need spend time learning, as an employee, you need spend time to meet executive’s requirement, daily task can easily fail if you count in all these. If you log your time by actual items like communication, break, coding, learning&documenting, instead of business items, problems get more clear.
But unfortunately managers often focus the latter, i.e. today you spend 4 hour on issue1, and 4 hour on issue2, why they are not improving? Not until you and your employers start to care about your first log, i.e. daily time distribution(DTD), would the programmer’s life more easier.
What profile does most of the programmer’s DTD look like actually concretize the so called corporational culture. I feel satisfied with my productivity recently, and I think my DTD is reasonable, I’ll give it here:
| item | time(h) |
|---|---|
| communication | 3 |
| break | 1.5 |
| coding | 2 |
| learning&documenting | 2 |
If goes into detail, communication includes peer-communication(work and non-work, email or non-email) or searching for internet for solving a problem(like SF), and also for meetings(mostly not-related with your task-to-do today), so actually it not always help you finish your task; break includes coffee break, toilet, table-football, and surfing internet; coding include write code, and miscellaneous tasks like download ide plugin, checking api(in internet or not) but not include things searching SF; learning and documenting include reading-book/posts not directly related with your task in hand, write summary, or log time in JIRA, or write post in Confluence.
It can vary among programmer and production phase, say if not so competent with your current task, you need to learn more, and non-lead programmer can have more time learning. But in general, I say it could profile the corporational culture. Some “performance-targeted” company use story points or features-finished to measure a programmer, this would elongate the code time, and squeezing others, especially learning and break. Some “performance-targeted” company judge programmer with there sounding, thus making unnecessary communication time long. Even not to extent of squeezing physiologic break time, at least it could break the mental vigor. I’m not senior programmer, just 5 years experience with several companies, I never meet any company whose HR/manager would like to survey/query programmer’s DTD, so that they can introspect how they can help programmer to improve productivity. I’m not try to be sensational and union the programmer’s party to do something, but employer does have to discard the one-sided view of software engineering, either just accept it’s a chaos and hence only measure programmer with final result or regard it an analog of manufacturing and hence don’t respect programmer’s job as mental work. It would bring WIN-WIN if employer and programmer start to know DTD and its means.