I know, I know, there's no such thing as a typical day, but I'm looking for averages. I've posted this discussion to many groups & have gotten an extraordinary response to it.
I've asked permission from the responders to use their comments in the article, but I feel that any paraphrasing I'd do would not preserve the character & helpful attitudes of the respondents, so I'm going to include the entire discussions from all the groups. Even though my comments in several of the groups are the same, I'm going to include them also to preserve the flow of the discussions.
The C++ Developers Group contributed this:
Comments (30)
-
Michael Litvin
Software Team Leader at Camtek
Let's say that "average" programmer usually able to write new code up to 6 hours a day, but after few weeks of such intensive work , productivity drops down... It is good time to give him few old bugs to fix or some new technology to learn... BTW, "bad" programmer will write code up to 8 hours a day and you will need add some more hours for rewriting or removing all his "products".
-
Ray Almonte, PMP®.
Engineering Software Project Manager at ITW Bldg Components Group
Thanks Michael. That agrees with my own experience. I'm wondering if there is a knowledge base out there with a large set of data on programming efficiency. Otherwise I'll be relying on the sample I get from responses such as yours. I've posted this discussion to multiple groups in hopes of increasing my sample size. I also agree on the burnout syndrome. We try to break up the monotony, but after a while even the switch to bug fixes gets old.
-
Mohamed Azmathulla
System Architect / Senior Software Engineer
I would say, 4 to 5 hours in write code and up to 2 hours in requirement gathering/analysis/learning & design and 1 ~ 2 hours for phone calls / meetings in a day.
-
Ray Almonte, PMP®.
Engineering Software Project Manager at ITW Bldg Components Group
Thanks Mohammed, that means you are spending 6-7 hours/day in development work & 1-2 hours/day doing other things. Do you usually work an 8 hour day? If you do, could I average your hours to 6.5 hours/day spent doing development & 1.5 hours/day doing other things?
-
Steve Huston
Networked application veteran, expert in TCP/IP, ACE, AMQP/Qpid
I concur with the previous responses of about 5 hours "coding" time per day max over time; you can push it higher for short periods. For more info, you m ay want to see if the Software Engineering Institute at Carnegie Mellon University (http://www.sei.cmu.edu/ ) has that sort of data. Good luck.
-
Ray Almonte, PMP®.
Engineering Software Project Manager at ITW Bldg Components Group
Thanks Steve. Good idea, I'll ask my contacts at SEI if they have data they can share.
-
John Phillips
Research Professional
McConnell's "Code Complete" has a lot of study references on this sort of thing, but generally I think they run close to where you are seeing already.
John -
Dave Mikesell
Independent Contractor
Amount of time spent coding in an 8 hour day isn't a necessarily a measure of efficiency, though, is it? It seems to be more a measure of activity or "busyness". It depends on how much you get done in the hours you spend coding. What takes some programmers 8 hours might take others only 1 hour.
What would be more valuable, IMO, would be some kind of velocity measurement, like the number of user stories (or requirements or use cases) implemented in X amount of hours. -
Dan Hestand
Lead Software Systems Engineer at The MITRE Corporation
I'm going to go out on a limb and say that the answer depends on how you define 'programming.' If you mean the physical act of sitting in front of a screen pounding out code, then I suspect the answer is probably around 50% of a given day but can vary from day to day and probably averages out to 30% over a year's time. If instead, you mean the act of creating software, which includes meetings, requirements, documenting things, doing research, unit testing, debugging, talking to colleagues (on relevant things), answering emails, actual code writing, and even just sitting back with eyes closed working through solutions mentally, then I would suggest that the percentage is probably higher, say around 75-80% of most days and probably varies little from day to day.
COCOMO and other estimation methods assumed an average programmer could produce ~15 lines of executable code/day (at least several years back that was the assumption). Agile methods may actually deliver more but there is also non-coding overhead involved in those methods, too. I can manually write over 1000 lines/day but some days I may also rip out more than that and other days I may write nothing at all. Add the effect of massive amounts of code that can be automatically generated and the perceived productivity can vary widely depending on exactly what I'm doing. So I think the real answer lies in what your view of 'programming' consists.
<> -
Stanislaw Bartkowski
Software developer at IBM
As far as I know it is expected that tester spends 4 hours a day executing tests and this number is taken to plan and measure testing efficiency. The next 4 hours he/she spends talking, discussing, writing test cases, reviewing, verifying fixes etc.
With respect to developers this time is like 5/6 hours, meaning pure coding.
But as Dan noticed it depends heavily what you define by "testing" or "developing / programming".
Based on my personal experience it varies. Sometimes you are coding like a mad writing hundreds of lines of code but one has to remember it was preceded by days/weeks/months researching, analyzing, reading, discussing, designing, making proof of concepts etc. -
Ray Almonte, PMP®.
Engineering Software Project Manager at ITW Bldg Components Group
Thanks all. I include requirements gathering & elucidation, design, coding, unit testing, code review, etc... all as part of the development time. For testers, I would include all the time spent on writing test cases, reviewing, verifying fixes etc.. & any discussion related to the tests the tester is working on. I'm not sure the software product makes that much difference to the percentage of time an average developer spends in development as opposed to non task related meetings, extraneous phone calls & e-mails, lost time due to interruptions, etc... Even defining programming broadly, I'm still getting responses indicating 6-6.5 hrs out of 8 seems to be the norm. I'm not making any judgements about this, I think that unless you get deep into the creative process & lose track of time, any development after the 75% mark may not be productive in any case.
-
Anil Das
Software Engineer - Site Reliability at Google
-
William J Robblee
Owner at Asea Software LLC
My two cents. I like the estimate of 4-6 actual hours spent developing, exclusive of the aura of mundane tasks that go with coding, requirements, docs, test/debug, etc.. But the issue of efficiency depends on the task. Some days the code just seems to pour out and others in takes hours to get a small bit of code developed.
-
Dave Mikesell
Independent Contractor
If I were a PM, I'd also take into account the state of the code after the day's work. Has it been vetted with a battery of automated unit tests, or merely "thrown over the wall" at the testing team? If the latter, it will likely require more work than if it was the former.
-
John LaValley
Lead Application Development Analyst
I'd like to add one other possible consideration. Sometimes the average may depend on position/role. Consider your generic "contractor" role - in some cases they are expected to simply sit and pound out code all day long. They are given a design and have to implement/test it. Their "other" tasks are greatly minimized. If you compare that to say a senior level programmer/analyst employee of the company, then they may have a lot more distractions that are part of their role. Reports to management, reviews for junior designers, code reviews for your contractors, etc.
In addition, I'd reconsider your 8 hour day. Once again, that may be appropriate for some roles, but, personally, a 9 hour day seems more realistic. -
Daniel House
Computer Software Consultant and Professional
Some experts estimate that if a developer predicts that the job will take X days, you should double it, because the developer is assuming they will actually get to work the full X days, without interruption. I recommend "Peopleware" by DeMarco and Lister, and "The Mythical Man Month" by Brooks.
I can easily sit and code-test-debug for 40 hours a week for months indefinitely without burn out. That's because I enjoy it. For 2 to 3 months I can manage 50 hours a week. I'll refuse to even try more than 50. On the other hand, I consider myself lucky to be allowed to spend 30% of my time on the fun stuff.
I like your point about " I think that unless you get deep into the creative process & lose track of time ..." but I'd finish the sentence with "... it isn't really programming" or maybe "... it just isn't fun any more". :) My idea of a good day on the job is one where I am surprised to find out it is time to go home. -
Debkumar Mondal
Associate Project at Cognizant Technology Solutions
In India,with my experience i would rather say, It highly depends on company size (how big the company is in all respect). I stared with small level Indian IT company, where I used to write 8-10 hours coding and there unit testing was not that much inp.There I had never written any unit test stubs for my code. I never checked code coverage. Only if the testers finds any functional bug, then I had to fix that. So, bug fixing (re-writing code) was also very minimum.
But when I moved into kyocera, there I had to write code for about 5-6 hours daily,Including Unit test stubs. If I divide the entire time frame of development, it would come 30% for implementing feature, 40 -50 % covering negative scenarios and rest on writing Unit test stubs. -
Troy Torgerson
Information Technology Software Engineer
Hmmm. If you are looking for averages, you have to be specific about the length of time you are looking at. I agree with some of the others where there are days where you are cranking out code all day long and then there are days you never even enter the editor.
Just to throw another consideration into the mix. Imagine a company who wants to cut costs as much as possible, so they cut staff and pile additional responsibilities on the remaining few. For example, instead of just being a developer, you now have a full time job of being the QA department as well. (And no, I am not talking about the debugging you do on your own code.) Writing test plans, executing them, documenting the success or failure. Now throw on that maybe having to be part of a help desk and take problem calls. Throw on that maybe having to troubleshoot the network, be a DBA and a sysadmin, and document your progress for management. Now consider that many people still consider multi-tasking a good way to run things, so lets say you have multiple projects to manage/develop at the same time. Throw on that deadlines based on whimsy and not resources.
Days will become longer. . . productivity less. . .
A quick look at job postings will prove out my "fictional" company. Too many companies are looking for Superman because they don't want to pay for Clark, Lois and Jimmy. IT seems to be going in a direction that will ultimately produce burnout and less productivity.
Does this sound familiar or am I imagining things? -
Ray Almonte, PMP®.
Engineering Software Project Manager at ITW Bldg Components Group
It does sound familiar. In fact, I think it's more the norm than the exception.
-
Dan Hestand
Lead Software Systems Engineer at The MITRE Corporation
It's interesting to me that while there is advocacy for "doing software right," there is little actual movement towards that in many organizations. I often wonder if the notion of time-to-market is part of the problem. I perceive that there are times when we (collective we) are told that if we don't hit the market at such and such a time, then we will have missed the window of opportunity. But if we hit that window with crap, then the window of opportunity might as well have not existed.
I agree with just about everything said so far. When I'm "in the zone", I can go for weeks pounding out code 12 hours a day (I usually work 12-15 hours/day anyway) and then have an entire week where I may not use the computer for anything other than web-surfing (research) and keeping up with emails. It doesn't mean I'm less productive, it's just that I'm productive in a different way.
One other thought on this topic; the efficiency of any developer is also highly dependent upon how confident that person is in their abilities and how closely aligned the task is with the person's abilities. Inefficiencies can arise because a developer may be working on something that they are not entirely comfortable with and will thus spend more time asking questions and trying to get some increase in confidence. These inefficiencies are natural since no single developer knows everything. They should however, be accounted for when planning and scheduling.
Comments (4)
-
Alec Clews
Experienced IT consultant focused on improving software process for agile business delivery
It depends on the individual and the circumstances. In my experience it can vary between 30 mins and 6 hours. I would suggest (simplistically) that the major factors are:
* Is there actually appropriate coding work to do? Are other tasks more relevant currently?
* Is there energy to do it?
* Are there the process and self discipline to be productive? (internal issues)
* Does the developer have the skills, support and tools to be productive? (external factors)
Notice that I use the world developer, not programmer. A developer does more than cut code all day -- and all 'programmers' should in fact be developers. -
Ray Almonte, PMP®.
Engineering Software Project Manager at ITW Bldg Components Group
Thanks Alex, I include requirements gathering & ellucidation, design, coding, unit testing, code review, & research devoted to the task, etc... all as programming time. In my experience this comes to ~ 6 out of 8 hours per day on average.Do you do Scrum? If so, would you consider the 5 minute daily scrum as programming time or other?
-
Gary Gack
Owner, Process-Fusion.net and Professional Training & Coaching Consultant
longer term planning for larger projects generally assume 70% effective availability - 5.6 hours per day
-
Ray Almonte, PMP®.
Engineering Software Project Manager at ITW Bldg Components Group
Thanks Gary, I've attended a few of your webinars, especially on Scrum & agile & have gotten good information from all of them. I've posted this question to multiple groups & have gotten consensus for 70 - 80 percent of time devoted to development activities. I plan on posting an article on this topic since it has spawned large discussions in several groups. With Alec's & your permission, I may use some of this discussion in the article. Proper accreditation will be given to all.
Comments (5)
-
James Smith
Independent Computer Software Professional
This depends a lot on the type of organization you're working for. In general it's always about getting the requirements and breaking them down into manageable parts. I think this takes up most of the time in the form of meetings and developing design documents. If the development team is using the same tools and libraries over and over again the coding process is probably streamlined and less complicated.
After the design phase of a project I can get about 7 hours of coding in, but I like working overtime because it's quiet after business hours so, it really doesn't matter. -
Ray Almonte, PMP®.
Engineering Software Project Manager at ITW Bldg Components Group
Thanks James, I include requirements gathering & ellucidation, design, unit testing, code review, etc... all as part of the development time. The other time would be for non task related e-mail, phone calls, non task related meetings ( e.g. HR briefings, birthday celebrations, etc..), & any time not spent on task related activities. If your 7 hours is part of a day in which you work overtime, you probably still fit the 6-6.5 out of 8 hours which is the most common response.
-
David Young
Computational Chemist
There was a study published a few years back (can't remember where) that found that on average programmers only spend 35% of their time actually writing code. This is probably averaged between peak productivity times and design/roll out phases where little coding is being done.
-
Ray Almonte, PMP®.
Engineering Software Project Manager at ITW Bldg Components Group
Thanks David & James, you & all the responders in other groups have given me great food for thought. I'm going to post an article on this topic & I'd like permission ot use some of this discussion in it. I will of course give credit to every one who has been a contributor to this discussion.
-
Rakesh Sharma
Senior Software Engineer at Aricent
It depends a lot on type of work division, Like If all team members who are working in that project are working under same roof then probably the meeting and discussion time is less and if some are sitting at one office and other are at over-seas office, then alot of effort is consumed in telephonic and desktop sharing meetings.
Apart from this there are almost 40% of time in whole week wasted in e-mail, phone calls, non task related meetings ( e.g. HR briefings, birthday celebrations, etc..),
Comments (21)
-
Dustin Horne
Project Manager at Information Analytics
You need to specify what type of programmers. Are these programmers doing work for clients or are they doing internal projects? Are they developing custom client applications or are they working on proprietary SaaS applications? What is the average size of hte project they are working on? How many other projects are in the project queue? Are they working as a team or individually? Is it new development of updates? If updates, is it updates to their own work or someone else's? How well documented is it? What technology is being used? How responsive is the client if it is client development?
These variables all make a huge difference in programmer productivity. I think it would be best if you described a detailed scenario or you won't get any accurate answers. -
Ray Almonte, PMP®.
Engineering Software Project Manager at ITW Bldg Components Group
Wow. Thanks Dustin.
We develop shrink wrapped software in support of residential & light commercial component construction. We have both internal ( our Engineering Department) & external ( component manufacturing) customers. We have CAD, Engineering, Database & Production elements to the software.
Most developers are involved in both maintenance & new development projects, most of which include Input, Engineering, Database & Output specialists. The program is highly interactive & graphic. There is extensive user documentation, & many specifications documents. There's not much internal program documentation. We have a mix of very experienced programmers & newbies, ss well as a mix of new & legacy code.
We're mostly C++, but C# is a growing part of the program. The database has migrated from proprietary to Access to SQL Server.
Requests for changes to the program are usually sales & customer driven unless Building Code or Industry Standards change, which results in Engineering Department driven changes.
We have a huge backlog of both large & medium projects & smaller customer requests. So for developers, there's little or no down time.
I include requirements gathering & elucidation, design, testing, etc... all as part of the development time, not just coding, so I'm not sure the software product makes that much difference to the percentage of time an average developer spends in development as opposed to meetings, extraneous phone calls, lost time due to interruptions & such.
I find that client software development may require more hours than 8 hrs per day, but I'm not sure the percentage of time spent in development as opposed to other things is all that different for different kinds of software development. I could be wrong on that because I've worked mostly in Software Applications Development for the last 30+ years. -
Geoff Feldman
"Hands-on" Software Architect and Senior Developer
This is an impossible question because it really varies with the phase of the project. I would also say that the more time programmers get clear on what they are doing up front, the faster the actual programming and the less time it takes.
I think some people who have been around the computer industry for awhile may tend to think of the efficiencies of new languages such as C# as sort of magic. It isn't. First comes efficiency from not dealing with C++ things like memory allocation but the real efficiency comes from the large framework of objects that are there to use. Lego blocks if you will that need only be stuck together and not carved from scratch. The next efficiency comes from internal object reuse, objects created that solve a common problem in your enterprise and can extend the framework for further reuse.
This efficiency comes from knowing what is in that bag of already made lego blocks (objects) and time to define the new ones for your own business and document them well enough to be reused.
Code does not have to be documented the same way as in the old days. If there are good code standards followed then the code really can be self documenting to some degree. The test though is whether a developer of equal skill can pick up code someone else wrote and really comprehend it. I think documentation then shifts from flows to relationships more.
Efficiency is lost when there are changes that were not expected. This is especially unfortunate when they could have been expected, just nobody troubled themselves to think it through first.
I find that having an uninterrupted run to actually write code is important. It takes focus and thought and interruptions can force the developer to start the thought process again. An interrupt of a minute can have an effect of ten or twenty minutes for this reason. Also, I find I cause more bugs in relation to interrupts, something I forgot yet proceeded anyway.
What is really key is that the organization itself has to have the discipline to get the most efficiency from its developers. This means working the plan thoroughly in advance, providing the developers with a "clean well lighted place", not interrupting them when questions and insights can be stacked up for later and so forth.
Back to the original point, a great deal has to do with the project phase. -
Sam Botha
at Synthesis Software Technologies (Pty) Ltd
I concur whole heartedly with what Geoff is saying and would like to emphasize how important it is for the enterprise to extract the maximum from it's dev teams. In smaller "SWAT"-type teams where the architect/designer/developer takes care of the whole development process all the way from specification to installation, training and first-line support the development time for such teams are radically different from a team that only has software as an output. Once you add client support and context switching between multiple projects on a day one can find pure development time g.ets lost fast
-
Ray Almonte, PMP®.
Engineering Software Project Manager at ITW Bldg Components Group
Thanks all. I had forgotten the loss of time due to context switching. It's worse than interruptions because it affects 2 tasks instead of just one. I still feel that ~ 75% of a developer's time is spent in development, including requirements gathering, research, design, coding, unit testing, code review, etc... & the other 25% is spent in non task related activities. I've posted this to many groups & most of the responses fall close to this range for developers who are not wearing other hats. For the rest of us, the more reponsibilites you have, the less time is spent in pure development.
-
Sam Botha
at Synthesis Software Technologies (Pty) Ltd
I would be interested to know what the ratio would be between "pure" devs and "multiple-hat-wearing" devs ..... I would think the ratio is slowly but surely edging upwards for the latter ...
-
Geoff Feldman
"Hands-on" Software Architect and Senior Developer
Sam, this is also very true. I think there is a tendency to hire less competent and therefore presumably less competent developers. There is a cost for having developers in that they all to some extent have to intercommunicate. If there are too many finding their way or trying to understand, this becomes a drag on efficiency. Better to have fewer but really good and driven ones.
-
Christopher Reed
ASP.NET/FoxPro/SQL Server/Crystal Reports Developer
Ray,
Have you considered using agile within your development environment? I used to be rather skeptical about the agile/scrum process, but I am now a believer mainly because if it is implemented correctly, it puts a lot of requirements on the team as a whole and the team themselves deal with the productivity issues to ensure that they can meet their iteration goals, thus being efficient.
Note that efficiency doesn't necessarily mean that you pump out good code in the shortest amount of time. In some instances, you might be more efficient by spending more time on testing than coding, depending on where you're at in your development cycle. Agile should also compensate for your junior developers. (I prefer to use the term "junior" instead of "incompetent" because many of these developers don't know any better, whether they realize or not. Granted, there are incompetent developers, but these are the ones who should know better and don't which is what makes them incompetent.) -
Jonathan Cogley
CEO, Thycotic Software Ltd
As @Ray mentioned, agile methods can increase productivity enormously. We practice Pair Programming and have done so for several years. I can confidently say that we get as close as is probably possible to 8 hours of pure programming per day. The developers work as a team on their tasks for the sprint and by working together (same workstation) they stay focused on the end goal. We also strictly limit developers to one project at a time to avoid any context switching cost.
Also I second the comment from @Geoff that great developers are the best. The productivity of a great developer can be 2-3x or more than a regular developer. -
Geoff Feldman
"Hands-on" Software Architect and Senior Developer
Agile means absolutely nothing at all if the organizations is not signed up to it (or whatever other process you choose). I am not skeptical about the agile process but it's cult like and modern buzz word nature helps to drive organizational development.
I believe that if any process is followed well and fully by the surrounding organization, it will work. There is much about Agile that is better but this fundamental need for the organization to not look as programmers as a bunch of people who do stuff that is the most crucial.
In my consulting practice I have also seen many organizations that will tell you that they are all doing agile but they confuse this with not planning or being flexible which it is not. So when someone tells me "we are agile" ... I have questions and I'm looking for a process definition.
Junior people are often not incompetent. Incompetent is a different word and I use it as it applies. Senior people can be incompetent. -
Geoff Feldman
"Hands-on" Software Architect and Senior Developer
Yes Jonathan ... in addition to the 2-3x more productive is the fact that a great developer though commanding the higher salary uses the same floor space, health insurance, computer equipment and other overhead as much as one that is a drag on the team. The business efficiencies are greater still.
Nothing is worse than sitting through a meeting where people who have no clue are going round and round about things that are not productive. At least having fewer people in the room will add to efficiency by reducing discussion time. I apologize for this rather cynical thought but it has some truth to it. -
Ray Almonte, PMP®.
Engineering Software Project Manager at ITW Bldg Components Group
We are fairly agile. We follow the manifesto. We use more than 1 methodology but all are iterative. We tailor the methodology to the project.
I'm not implying that devoting 6-6.5hrs out of 8 to development efforts on average is good or bad, I'm just verifying that is is reality. I'm not looking at the quality of the code or the acceptability of the finished product, that's another discussion.
I'm just gathering statistics on development effort vs time available. We gather our own metrics here, it's just that senior management doesn't always realize that creative efforts can not be treated the same as mechanical production.
Our department metrics are right at 75%, but that includes all developers including the many hatters ( or is that mad hatters), which implies that for pure developers, the number is better than 75%. For us it's ~ 80% which gives 6.5 hrs / 8 hr day on average.
I must say that this is one of the most responsive groups, but this topic is gathering responses in a lot of the groups that are not solely devoted to jobs discussions, so there must be interest & need for data on this.
All the responses have been interesting & useful & much appreciated & show the willingness to contribute to the group. I'd also be interested in knowing how many shops gather data on this. -
Lance Parkington
Jobseeker (formerly SOFTWARE ENGINEER) at Home
I'm not sure programming efficiency can reduced to numbers of hours spent coding. Over 30 years working on software I'd found on average that less than 10% of the time is spent coding. Most time (90%) goes on producing artificats (eg requirements documents, designs, tests) and meetings many of which take excessive periods of time.
-
Ray Almonte, PMP®.
Engineering Software Project Manager at ITW Bldg Components Group
Thanks to all of you, you & all the responders in other groups have given me great food for thought. I'm going to post an article on this topic & I'd like permission ot use some of this discussion in it. I will of course give credit to every one who has been a contributor to this discussion.
-
Dustin Horne
Project Manager at Information Analytics
not a problem with me.
-
Geoff Feldman
"Hands-on" Software Architect and Senior Developer
No problem with me either.
-
Sam Botha
at Synthesis Software Technologies (Pty) Ltd
This comment was deleted by the author
-
Robert McClean
Information Technology and Services Professional
I used to say a developer got 4 days work out of every 5, and a team leader got 3 out of 5. By assigning one of the team by rota to handle "interruptions" like requests for help from sales, support and engineering, we were able to maintain this pretty well. The person on "interruption duty" got around 1 day out of 5. We allocated 0.25 days out of 5 to "blue sky thinking" so that we had a forum to discuss and test our own research ideas, thus helping to keep focus for the rest of the week.
This was a team of 4 developers and 1 manager (me) working for a software house. -
Deon Burger
Data Intelligence Manager at Fonesure
HI We spend about an hour or so documenting work for clients, ghostdoc takes care of some regular doc. However, the documentation created is used to better estimate task complexity and time required to complete. Posting questions and reporting progress on a co-wide chat facility encourages "volunteered" assistance of short duration, thus reducing the need for formal meets.
-
Rick Kiessig
Systems Architect and author of "Ultra-Fast ASP.NET"
> On a typical 8 hour day, how many hours do programmers spend programming as opposed to other required/necessary activities.
It depends heavily on the specifics of your environment. The software process you're using, in particular, has a huge impact. In the companies I've worked with, the answer varies from about an hour a day to eight hours or more.
However, "efficiency" is much more than just what fraction of time developers spend programming. By using the right process and by approaching software problems in the right way, some developers can get five to ten times as much productive work done in a given amount of time as those who don't. In fact, this is precisely the trap that many companies fell into with offshoring: "inexpensive" offshore developers often end up putting in lots and lots of hours, but get very little done in the process.
My view is that it is a manager's responsibility to help ensure that their team is efficient -- and there are many aspects to that job. Things like: making sure the best tools are being used, establishing and maintaining enough communication while minimizing interrupts, coordinating ongoing training and mentoring, leveraging code reviews, establishing and maintaining a sound software process and selling it to upper management when needed, managing schedules and deliverables to maintain reasonable expectations from a developer perspective, establishing an environment that supports high-quality products, etc. All of those factors have a direct impact on developer efficiency.
No comments:
Post a Comment