How much time do you spend writing code?

Question

Hello all, as a junior developer I am curious to know: How much time do you spend actually writing code? As a bonus, what kind of code (e.g. scripting, OO, functional, db, etc), and what kind of industry.

Personally, I've noticed that almost 90% of what the developers at my company do is maintenance, administration and other non-code writing activities. Is this normal? Most of us got into this to develop, yet it seems like so little of what we do is that.

Are we in an age where there are so many libraries, utilities and helper applications (e.g. WYSIWYG visual editors) that the sweaty, Mountain Dew filled evenings of yore are no more?

Thanks in advance.

Answer 1

I never write code. I simply will it into existence.

Answer 2

It depends -

I have some developers who spend nearly all of their work-time writing code. I try to manage them directly so this is the case. They are happier, I am happier (since they're more productive), and things work more smoothly overall.

I have other developers who work better and who have other skills than writing code. I often have them do other work - whether its administrative, etc.

However, at some point, I recommend realizing that writing code includes maintenance, documentation, and other non-pure-code writing activities. I will not hire a dev. who refuses to maintain their own code - or who grumbles about documentation.

The time for pure code for the sake of code isn't necessarily at work. The programmers who I have always admired write code in their free time, and this is the time where they write code purely for the love of writing code, and tend to have little to no other activities. Programming professionally includes other activities.

I personally only write code probably 30-40% of the time, at this point. Most of my other time is spent in management and administration. When I do write code, it's typically OO or functional in nature, in a scientific analysis and visualization field.

As for the libraries question (which seems like a separate question) - more libraries, at this point, often means more work, not less. It's very tough to keep up with the pace that the world is changing. This means doing a lot of "coding" out of work, for fun, just to stay current.

-- Edit --

This question actually made me think - and one thing that came to mind:

It seems like the tone of the question is suggesting that not writing code 100% of the time is a bad thing. Meetings, administration, maintenance, and all of the "other" work that happens around writing code is important, too. I recognize that some companies manage their developers very poorly, and I'm not necessarily talking about those (which I refuse to do any work with if I can avoid it). I'm talking about a normal, reasonably healthy working environment. In a "normal" or "good" atmosphere, there is great value in the other activities.

For example, I regularly teach our software's end users. There is absolutely no code writing involved, but it's some of the most productive time I have in terms of developing and furthering our software. It teaches me how and where the end users of our software are struggling, and helps me think of new ways to continually improve.

There is a lot more to programming than the act of sitting down and typing. Time spent outside of the code, whether in meetings, trainings, adminstration, and particularly maintenance, help to illustrate the problems in your software. Illustrating the problems is the first step in the innovation of new solutions.

I highly recommend learning to appreciate the time spent doing other activities. As I mentioned originally, you can always code for fun, and that's incredibly rewarding and valuable. The time doing "other work" is valuable, and shouldn't be discounted.

Answer 3

Depends on how far into the project we are

1) At startup 30% time on coding

2) Once design/architecture/iteration 0 in place 50% code

3) After first code drop 30% code, 20% maintenance

4) After first (full) release 10% code, 50% maintenance

5) Repeat

Answer 4

I'm a manager and so don't get to write code much. The rule of thumb we use, which turns out to be amazingly accurate, is that our teams will spend 30% of their time in meetings and unplanned work. That puts an upper bound on time that can be used for coding. If you consider fixing bugs, design, and the physical act of coding all to be "writing code" which I do, then 70% of their time may be utilized on such activities.

Answer 5

50% on a good day - and I'm claiming everything possible as "coding." Between meetings, phone calls, random questions from team, random questions from non-team, the list of time wasters goes on and on and on!

Mountain Dew filled evenings or days definitely exist though. Fun code that I just can't tear myself away from or tracking down a bug that scares the h*ll out of me...seems like it happens just often enough to keep me on my toes.

Answer 6

Define coding ;)

Actually typing on the computer? I'd have to say less than two hours a day or so.

Actually grinding the problems? Easily seven or eight hours a day, quite often during those mandatory meetings. Also, quite often I spend as much time working with a whiteboard or even pen and paper as I do typing and debuggning.

I'm working on a pretty research-intensive site though, building advanced math libraries primarily for embedded systems. I don't have to bother much about UI coding (other than some demos) which, I suppose, significantly reduces the complexity of my daily work.

Answer 7

In hours:

time_coding = 24 - 
(time_sleeping + 
time_spent_answering_so_questions + 
time_eating + 
time_being_a_dad)

Works out to approximately 9 hours per day.

if (coder & IS_ME)
  works_weekends = true;

... and about 63 hours per week.

Answer 8

"Coding" is only a stage of the Software Development process and should never take up more than half the time spent developing the project as a whole for all the developers in the project.

The important point here is that at most firms, the development team is divided up into different roles where the manager will rarely code, but will oversee all the different parts of the development process such as code reviews and team collaboration, while a junior developer will often just be responsible for individual coding projects at any given time (whether they're development, testing, or maintenance) and will not need to worry about interacting with the client or business-side of the company.

As far as my own experiences, I've worked as a Java Developer for an Investment Bank on Wall Street and the managers in my team spent almost no time coding because they spent all of their time interacting with the business-end of the company figuring out exactly what they are looking for to generate more profits and to run more efficiently. The senior programmers would then formulate the plan for the various programs or modules that they would then begin coding together with the Junior Developers. The Junior and Senior developers spend a large amount of their time coding (majority of their day), but the seniors would often work on the more complex and obscure programming areas themselves.

If your question is regarding the collective hours of the development team as a whole, it strongly depends on the design pattern that the teams uses. Using the widely-used Waterfall design pattern as an example, a developer begins with specifying the requirements of the project together with the client, then the software is blueprinted and "designed" using UML diagrams or etc and only then comes the "construction" aka "Coding." After that the developers will integrate the new software with the other pre-existing modules in a QA environment and test the entire system using Regression Testing and possibly one of the many automated testing packages (especially if there's a complicated UI in place, in which case they should test for input problems such as mouse gestures and the like). It's extremely important to test the Memory and Resource Footprint of the process, even though it seems to be the new trend to make software as bloated as possible (Always clean up your objects when your done with them!). After the software has been tested ok, then comes the "Installation" of the software in a Production environment and obviously the "Maintenance" will always be necessary.

Just to point out, many experts hold that design patterns such as Agile and Extreme Programming have a smaller debugging phase because it is a test-driven process to start with.

Answer 9

Hmm, I was about to submit this at Time spent writing effective code? when that suddenly was closed. I was hoping it would be re-opened but apparently I still need to get used to the way Stack Overflow is moderated. :-(

Anway, as for time spent writing effective code, or: time effectively spent writing code:

You may recall some recent research: Freedom to surf: workers more productive if allowed to use the internet for leisure. Conclusion:

“People who do surf the Internet for fun at work - within a reasonable limit of less than 20% of their total time in the office - are more productive by about 9% than those who don’t”

Maybe the part "those who don't" (rather than, for example, "those who limit this to a few minutes") explains this conclusion. Because, to be honest: I don't understand this "reasonable" value of 20%. I've never worked on projects that would require me to do the same work for hours. There's always a design to be made, an implementation to be coded, some tests to be written, documentation to be completed, or when concentration fails me: some code clean up to be done, or some emails to be answered.

Having said that, and as I feel each of the above tasks needs a different type of concentration: I truly feel that people can (learn to) organise their job to work effectively almost every hour of the day...