How Much Time Do You Spend Developing/Writing Code?

[Sterling Crapser]

I have a separate thread regarding my job. But I wanted to ask this question by itself as it seems unrelated to the other discussion. Let me preface by saying I have always thought of software/application development as spending a lot of time in front of a computer writing code. The code is being written based on requirements that either you or a business analyst has gathered and organized for you to use as a sort of blueprint for what is wanted.

In my current job I have spent maybe 5% of my time doing actual coding in the past 6 or 7 years. The rest of the time is spent doing other IT related tasks and chores. This might be anything from setting up and testing automated FTP transfers with clients (working with other departments to get this done), documenting the details of RPC calls to the mainframe, handling problems users may have with production software, performing software tweaks and setting up testing and documentation for change control and a host of other things. The last "big" piece of work I did was rewrite an algorithm for encrypting passwords to handle stronger password requirements.

So as Java developers, how much of your time on the job is spent developing and writing code if I may ask?

Thanks

[Bear Bibeault]

All of that is part of being a software developer. Someone who spends 100% of their time cranking out code to someone else's design, is not a developer, but a code monkey.

So as Java developers, how much of your time on the job is spent developing and writing code if I may ask?

I'm not a Java developer; I'm a software developer. No developer should of themselves as a xyz developer, where xyz is simply the current tool of choice.

Besides that, I'm also a web developer, so Java is only one language in my arsenal of tools, along with JavaScript, HTML, CSS, and so on (and including, for one legacy product, ugh, XSLT). I also spend a fair amount of time in Illustrator and Photoshop.

Head-down coding time, versus other tasks, testing, documentation and so on? Probably about your 5% estimate. Maybe.

[Jeanne Boyarsky]

I'm thinking maybe 10% coding. In a variety of languages like Bear. I've done Java, Groovy, SQL, HTML and UNIX shell scripting in the past week. I regularly use JavaScript although not in the past week.

The rest of the time is planning, designing, documenting, mentoring, troubleshooting, etc.

[Jayesh A Lalwani]

First of all, testing and documenting is "coding" A piece of code is not complete until it's fully tested and documented. Whatever you do to get your code complete is coding. If jumping on one leg while scratching your ear helps you complete your code, then jumping on one leg and scratching your ear is coding. Coding doesn't mean that you are only working on code that will result in a deployable artifact . Any tools/tests/documents that you work on to get there is code. By that measure, Bear is probably doing more that 5% coding. I am guessing it's 25-50%, but probably Bear knows that much better than I do ;)

Secondly, amount of time spent coding is a bell curve function against experience. So, please take into account who is replying to you. Bear and Jeanne are at the far ends of the curve. People with the least experience spent the same amount of time coding as the people as the people with the most experience. Someone who is trying to break into the field will probably code in bits and pieces in breaks in their "day job", just like an enterprise architect with 30 years of experience might code in bits and pieces between meetings. People who have just passed out of college will be coding 50% of the time, while spending 50% of their time learning, just like people in lead positions will be coding 50% of the time while spending 50% of their time teaching. People who are mid to senior level devs would be expected to spend a significant amount of the time contributing directly to the project as an individual.

I know the above paragraph is an oversimplification. God knows, our lives are way more complicated than that. The general trend in the industry is that when you are relatively junior, you are not expected to be the rockstar. However, after you have 5-10 years of experience, you are expected to start banging out lots of code on your own. You will spend some time collaborating with people, but the expectation is that you are a code producing machine. You are what they call an "individual contributor" Once you reach a point where you gain maturity in your skills,you will be expected to be responsible for the contribution of the entire team. AT this point, you will start spending more and more time collaborating.

[Bear Bibeault]

Jayesh A Lalwani wrote:By that measure, Bear is probably doing more that 5% coding. I am guessing it's 25-50%, but probably Bear knows that much better than I do ;)

Correct -- that's why I qualified it with "head-down". I guess my point about all that "other stuff" being part of coding was kinda lost, with Jeanne putting better than I.

[Jeanne Boyarsky]

I only consider coding to be writing code (or junit tests). I don't consider manual testing to be coding although it is certainly important. I do consider all the activities I mentioned to be part of development. But that's the whole "developer vs code monkey" thing that Bear alluded to.

Good point about the experience curve Jayesh. I don't consider myself to be at the far end of the curve (I graduated college 12 years ago.) But I suppose that is because the curve looks like this:
http://upload.wikimedia.org/wikipedia/commons/thumb/8/8a/Long_tail.svg/320px-Long_tail.svg.png


One interesting aspect is that I code so much more efficiently than I used to. So that 10% is WAY more than the "average" developer who spends a higher percentage of time coding/typing.

[Sterling Crapser]

Thanks for what you have written so far. I'm asking this question mainly because I appear to have been living in a cave for the past decade and am now experiencing a rather intense epiphany. I come from a work-life that has always been well structured and defined. I knew my job and where it fit in the big picture. I rely heavily on standards, protocol and process flow. But in the past 10 years things have begun to increasingly not make sense to me.

Now I learn it's no longer about doing things a "right" way. All people care about is results and whatever it takes to get them. I'm not sure if this is wise for humanity in the long run but I guess I need to learn how to do it. I would like to hear more feedback from others as this has been a real eye-opener so far.

[Jayesh A Lalwani]

It's still about doing things the right way. However, as a software engineer, you need to understand what the right way is, not just follow a path that other people show you. You are not a foot soldier who gets trained on a job, and does the job until he finishes his tour. You are a ninja/jedi/special ops whose primary concern is the success of the mission. It's less about following everything by the book. It's more about turning yourself to be the book.

[Sterling Crapser]

Jayesh A Lalwani wrote:It's still about doing things the right way. However, as a software engineer, you need to understand what the right way is, not just follow a path that other people show you. You are not a foot soldier who gets trained on a job, and does the job until he finishes his tour. You are a ninja/jedi/special ops whose primary concern is the success of the mission. It's less about following everything by the book. It's more about turning yourself to be the book.

Everything you wrote fits like a glove with what I have been going through when I say things have progressively not made sense to me. I kept looking for that role where I performed my part in the assembly line of getting a project done. I experienced the workplace as chaotic instead of orderly and found myself repeatedly surprised by how people would respond with indifference when I would bring up the lack of consistency in how things were being accomplished. It got to the point where I felt it pointless to learn anything about the job environment because in a very short time the rules would change. Often, what was priority depended on who you were talking to. The old cliché of too many chiefs and not enough Indians would frequently come to mind. This atmosphere would often lead to situations where people would end up confusing each other when things went wrong. And I would look at it all and could actually see how the approach being used was a big part of how the problem was created. I would sometimes use the famous baseball joke by Abbott and Costello (Who's on First, What's on Second, I Don't Know's on Third).

I don't mean to sound so critical but maybe a few others have had experiences on the job like this and wondered if they were the only ones.

But at the same time I must say after reading some of your replies here...I'm experiencing a sense of new found freedom. Like I can strike out and write my own story so to speak. It's all up to me really. I know that sounds kind of corny but it's real. And that's worth something I think.

[chris webster]

IMO, "developing code" includes all the things mentioned above - typing code into the machine, building and running unit tests, creating data, understanding the business process, designing/modelling code and data structures, researching tools/APIs etc, and above all thinking (what Clojure-creator Rich Hickey calls Hammock Driven Development). I'm in a relatively junior developer role these days, so if you include all those tasks I spend maybe 50% of my time "developing code", and much of the rest of my time dealing with email or in meetings etc (I work for the government...). Right now, I'm working from home for a few days, where I am free of meetings, have more scope to filter email etc, and I'm spending maybe 75% of my time on tasks that I would class as development, which is great!

I think there are plenty of sweatshops in the industry where the "typing code" task is left to large numbers of cheap but inexperienced "coding monkeys", who do nothing else and are supposed to follow detailed designs etc provided by fewer, more expensive designers/architects etc. From what I've seen, this assembly-line model is horribly ineffective in most areas of software development and is hard to reconcile with the demands of Agile methods, iterative development and evolving requirements and so on. The pressure on the coding monkeys to climb the ladder in order to earn more (or avoid being part of the 10-20% who might get fired every year) means that pretty soon you can have the situation where some former coding monkeys have climbed into design roles, but lack the breadth and depth of experience to perform these roles adequately, while the current coding monkeys are now being given strict instructions by people who don't really have much more of a clue than they do. A kind of GIGO waterfall approach.

At the other extreme, you can have organisations that noisily claim to embrace Agile methods, but don't actually implement any of the processes or the discipline to make those methods work (and I think Agile needs ruthless discipline to allow you to make the most of the freedoms it can offer). This can lead to the kind of chaos you describe - stuff changes all the time (which happens anyway) but nobody's taking ownership of those changes or taking responsibility for filtering them, iterations drift because people keep shoving extra work in, design/testing get squeezed because managers only count coding as "development", and so on.

But I guess any large group of primates is perfectly capable of generating chaos, regardless of their software development methodologies!

Anyway, I hope you will be encouraged to explore new avenues for your career, and don't get too fixated on "Java or else" as there are lots of other interesting areas to explore where you might find less competition from the industrial-scale Java factories and where your years of experience might help you to hit the ground running. Best of luck!

[Henry Wong]

Sterling Crapser wrote:
Everything you wrote fits like a glove with what I have been going through when I say things have progressively not made sense to me. I kept looking for that role where I performed my part in the assembly line of getting a project done. I experienced the workplace as chaotic instead of orderly and found myself repeatedly surprised by how people would respond with indifference when I would bring up the lack of consistency in how things were being accomplished. It got to the point where I felt it pointless to learn anything about the job environment because in a very short time the rules would change. Often, what was priority depended on who you were talking to. The old cliché of too many chiefs and not enough Indians would frequently come to mind. This atmosphere would often lead to situations where people would end up confusing each other when things went wrong. And I would look at it all and could actually see how the approach being used was a big part of how the problem was created. I would sometimes use the famous baseball joke by Abbott and Costello (Who's on First, What's on Second, I Don't Know's on Third).

I don't mean to sound so critical but maybe a few others have had experiences on the job like this and wondered if they were the only ones.

But at the same time I must say after reading some of your replies here...I'm experiencing a sense of new found freedom. Like I can strike out and write my own story so to speak. It's all up to me really. I know that sounds kind of corny but it's real. And that's worth something I think.

<rant>
On the topic of the assembly line, only because you brought it up... I think the concept of the assembly line, as in the Henry Ford era are gone in the way of the dinosaur. I am not saying that the assembly line doesn't exist. It still very much exists, and is much more efficient these days. I am saying however, that the basic concept of the assembly line is inhumane -- and luckily, is being fixed. Imagine spending 40 years screwing in the same bolt over and over again -- you will go crazy. These days, people are cross trained, along different areas on the line. They learn more. They get rotated around the line. They see more of the overall picture. They also develop a preference of where on the line that they like more. And as for the areas on the line where it is so tedious, that very few people want to work in -- well, that's where the robots come in.

I disagree with your point that it is "pointless to learn anything about the job environment because in a very short time the rules would change". Learning is what keeps the mind thinking, and needed to keep you sane.


Also, I will bring this up, even though you didn't... I really hate it when people use the idiom that "you can't teach an old dog new tricks". It is simply not true. And it is very likely used to justify agism. I have been doing programming for 25+ years, and I have been constantly learning during these years. And yes, I have spent time learning technologies that I only used on one project. What is wrong with that?
</rant>

Henry

[Sterling Crapser]

Henry,
Thank you for your feedback. I agree with what you point out in all respects. My post was a description of my experiences and how I felt about them over the past 10 years working for the same company. In spite of them, for some reason I continued to be mesmerized by the idea the things that didn't make sense to me would eventually be resolved somehow. I kept holding out for that day when it would all "click".

Well, that day has come...right here on this forum talking to all of you! I'm having a rather intense epiphany about my worldview of the software development industry. I am an old dog and I do want to learn new tricks. Right now I'm just recovering from the shock and self-realization that I have been in some sort of trance about how everything is supposed to be done for a very long time!

[Sterling Crapser]

I thought I would include a short description of how I currently experience my job as it applies to Java development. I don't know it if will be of any use to others but who knows? I know my posts here probably sound a bit "out there". But I assure you I'm not trying to be weird on purpose. In many ways I find this all just as weird myself.

Our company has just completed switching over to Windows 7. As such, I had to install Weblogic11g on my workstation and set up the project that contains the code I'm working on. I have never done this. The setup on my previous Windows XP box was done by someone with experience in these things last fall. He let me look over his shoulder and I asked questions but it was in no way a learning experience.

I was given a Word document with screen shots to install Weblogic11g. It took me a week of struggling with failed installs and asking others for help before it was discovered the instructions were abbreviated and intended for experienced developers. Once that was discovered, the installation proceeded okay until it was time to set up a Weblogic Server and "deploy the project". Again, I'm drawing a complete blank on this stuff. I ask others who sit at my desk and make it come together. I ask what they are doing but it's obvious to me there are way too many screens and settings for this to be learned while someone is troubleshooting a setup. I asked them how they learned and they said they found YouTube videos and just copied the steps until it became second nature. I asked if they know why they have to do the steps they have memorized...do they understand the meaning and purpose of why they are necessary and important. They said no. All of this culminated this afternoon.

This is what drives me nuts. I don't know what I'm doing and I'm relying on people who have a blind understanding of what must be done (what they are doing). To me, this is not how to learn anything...it's crazy. I feel like I've awakened in a Twilight Zone episode. And this is not software development in my opinion.

[chris webster]

Welcome to my world, Sterling!

I started back on a Java project about 6 months ago, after several years of doing other stuff, and spent weeks setting up my basic development environment. We were using Rational Team Concert (RTC) for source control, which was new to everybody, so that was one small world of pain. We were using Liferay portal server, which was new to most of us, so there's another mid-sized asteroid of pain. We were using Eclipse with various RTC plugins, which introduced extra pebbles of pain. And we were running the application on JBoss (a Java EE server similar to WebLogic), which also has its own quirks and pain-points. We were also using Spring, which is another world of config pain in itself. And because the project was moving fast, and the RTC and Liferay platforms were shifting quite a lot as we discovered/fixed problems with these unfamiliar tools, we had to keep re-jigging our configurations every week or two.

All of this meant that I spent a large proportion of my time in the early weeks just fighting/fixing set-up problems. My colleagues were very helpful, but as experienced Java developers, each of them seemed to have their own distinctive solutions, so I could take advice from Dev A on one problem, but his advice wouldn't be compatible with Dev B's solution to a different problem.

Eventually, one of the senior developers managed to put together a (fairly) standard configuration for everybody to use. Which meant we all had to change our own configs yet again, with predictable consequences.

I wasn't a complete newbie - I'd used Java, Eclipse and JBoss (as well as WebLogic) before - but wiring them all together with these extra components (Liferay and RTC) in the context of a fast-moving project with multiple configurations for devs/testing etc was a total nightmare. Once all this stuff settled down, actually coding in Java was easy by comparison! I've worked on Java EE projects before, and I still can't shake the feeling that working in Java-land is like having to build your own car every morning before you can drive to work and actually get on with the stuff that needs doing.

I guess you just have to find your own way around these issues - asking colleagues, reading docs, working through tutorials or videos in your own time if necessary. And practice, lots of practice. But from what I've seen, these problems are pretty common and many smarter people than me have commented on the excessive complexity of the enterprise Java platform. If you need an antidote to persuade yourself that there is another way, try Rich Hickey's famous talk on Simple Made Easy.

As for me, the sad thing is that just as I'd finally got a stable working environment and was starting to become productive again, I was offered a place on a different project using cool new big data technologies, which I just could not refuse. So I'll need to keep my Java ticking over until I can return to mainstream Java development, and hope that by then they've managed to encapsulate all that config hell into a nice simple Maven or Gradle script!

[Sterling Crapser]

Thanks for sharing Chris. At least I don't feel like the Lone Ranger. I find these experiences we have both described rather incredible to be honest. It makes me wonder how we ever made it to the moon (and I'm not joking). I have often said to people where I work, "If we were on a battlefield right now we probably would already be dead." There's just no collaboration, cooperation, working in concert, developing a process to manage variables...nothing! It's a very bizarre experience to find yourself in and it really plays with your head when you realize you're not in some surreal dream.

I have repeatedly found myself scratching my head and wondering why people talk to me about the various technologies used by our company as if I already know everything about them. I also sit in meetings sometimes and watch people nod their heads about technologies being discussed as if they are quite familiar with them when I know for a fact they are clueless. I write all this stuff off as technology changing so fast nobody can keep up with it or if they do, they pretty much don't have much of a life anywhere else. I'm pretty honest on the job and when I don't know something I say so. This usually draws gasps from my coworkers with nudges and urgings for me to not say such things. It's all pretty funny actually and I'm not trying to be cruel here as I know this is serious for a lot of people.

[Sterling Crapser]

I've been rolling things around in my head these past few days and have a question. I see some replies talking about having a "toolset" to draw upon as needed. I can see the value of that analogy having once been a machinist and also the owner of quite a few handtools myself. But software is not like picking up an unfamiliar tool and quickly getting a feel for its balance, ease of use, and application to some kind of material for which it was made. Software is incredibly nuanced and much of what you need to know is discovered by putting the software in the context of an application. This way, things you would not ordinarily be exposed to suddenly start coming out of the woodwork so to speak. Multiply this by the number of software technologies you need to become familiar with and I think you get my drift.

So given that, how do you learn the software quickly without structured learning (classwork) or a company giving you the time to play around with how to use it for their purposes?

[chris webster]

I think sometimes we forget that "the perfect is the enemy of the good". When you're trying to learn something new, it can be easy to get bogged down in details, when sometimes it might be useful at that stage in your learning to just carry on and get a better grasp of the bigger picture instead of being blocked by some small bug.

Also, programming languages are mostly very similar in many ways, and much of your knowledge in one language or tool will be transferable to another, e.g. OO principles from Java will often be applicable to other OO languages, databases all do similar things, and many web application frameworks are very similar to each other. So if you're trying to build your first web app with a new framework/language, don't get lost in the details of the HTTP protocol, just get somethIng simple working, then come back and refine it later. Pick an area you want to explore, start trying new stuff out, keep playing with it and breaking it, and keep fixing it.

Don't waste time waiting for some ideal structured formal learning opportunity. These days, thanks to Coursera, online tutorials, Youtube videos, blogs etc there are far more informal learning opportunities than ever before. For example, in the last 2 years I learned the basics of 5 new programming languages thanks to a mixture of online study and working at home in my spare time. Of course, this shallow knowledge is just enough to be dangerous inthe real world, but it has allowed me to get some hands-on work in one of those languages (Python) in my current project and I'll be working with another (Scala) over the next few months. Unlike a lot of people around here, I'm no software engineering genius: my background is in modern languages, where one of the most useful skills to learn is how to be a good learner, so I'm just trying to make up for lost time and apply a similar approach to my flagging ITcareer. My advice, FWIW, is to keep learning something new whenever the opportunity arises, and with a bit of luck you may find this generates new opportunities as well.

Finally, do some reading on how other people approach these questions. A couple of books I found useful and encouraging were:

The Productive Programmer by Neal Ford
The Career Programmer by Chris Duncan

[Sterling Crapser]

Thank you Chris. I will be exploring all your suggestions. I think this is a very important type of discussion to have. Not only am I in the thick of it so to speak but I also find the whole "how does one go about this software learning" to be fascinating. I know it has a lot to do with individual personality and that's a big step towards finding what works best. In my case, I think I have identified things that worked well for me in other situations but are actually a hindrance with learning software. I'm one of those people who likes to have everything laid out and understood before I begin. Unlike many people, if I buy something that must be assembled, I read the instructions first...inventory the parts to make sure nothing is missing...get the correct tools if they aren't provided...that sort of thing. I used to drive a coworker nuts when I was younger because every time he had a problem with what he was doing I would first ask if he read the instructions. Usually he had not.

Anyway, I can see the value of getting the big picture without getting bogged down in learning all the fine points (details). Another approach I'm thinking of is focusing only on what's relevant to the job at hand and building out from there. I think I did this with PowerBuilder because I can tell you honestly that even after 16 years there are things in PowerBuilder I still do not understand simply because I never had to use them. A perfect example is the crosstab datawindow object. Never needed it. I have a vague idea of what it is but that's as far as I go.

Currently with Java and Eclipse, I'm having this experience where it seems every turn I take I must stop and solve a mystery. What's this? Why is it important? How is it relevant to what I'm currently doing? How do I implement it? It doesn't matter how small it is. If it's there, it's in my way and I need to understand and ingest it before I can move on. I guess I wonder if others have this hurdle to deal with and how they either deal with it or avoid it.

[chris webster]

Sterling Crapser wrote:Unlike many people, if I buy something that must be assembled, I read the instructions first...inventory the parts to make sure nothing is missing...get the correct tools if they aren't provided...that sort of thing...

That's just crazy talk!

Sterling Crapser wrote:Currently with Java and Eclipse, I'm having this experience where it seems every turn I take I must stop and solve a mystery...

Not sure how much Eclipse you've done, but these video tutorials might help - they refer to an older version of Eclipse but the core features haven't changed much.

[Sterling Crapser]

Thanks once more Chris. I actually have those tutorials and they are good. Very good.

Not sure what you mean by my description of assembling something being crazy talk. I do lay everything out first before starting something. And this does get under some folks skin. But I can't help it...it's who I am.

[Jeanne Boyarsky]

Sterling Crapser wrote:Not sure what you mean by my description of assembling something being crazy talk. I do lay everything out first before starting something.

He's just joking. I lay everything out before I start too. If I'm missing a part, I want to know before I start!

[chris webster]

Jeanne Boyarsky wrote:

Sterling Crapser wrote:Not sure what you mean by my description of assembling something being crazy talk. I do lay everything out first before starting something.

He's just joking. I lay everything out before I start too. If I'm missing a part, I want to know before I start!

Yes, sorry if that was unclear. And I do the same thing too. I tell myself it's because I'm a logical methodical worker, but mostly it's because I'm really crap at practical tasks, so I need all the help I can give myself not to screw things up.

[Henry Wong]

chris webster wrote:
Yes, sorry if that was unclear. And I do the same thing too. I tell myself it's because I'm a logical methodical worker, but mostly it's because I'm really crap at practical tasks, so I need all the help I can give myself not to screw things up.

To be fair, it is a common (arguably classical) joke reference. ie. Men don't read instructions. They wind up with "spare parts" when putting stuff together. Etc.

I guess in certain parts of the world, it is not as common. Oh well.

Henry

[Sterling Crapser]

LOL. Thanks folks. This is really giving me a good laugh. All my life people have been surprised that I don't fit the usual mold of a typical male. I read instructions! I ask for directions! I admit when I'm wrong! etc.

[chris webster]

Henry Wong wrote:[... Men don't read instructions. They wind up with "spare parts" when putting stuff together. Etc.

Yeah? Maybe I'm deliberately collecting all those leftover IKEA parts to build a glider...!

[Paul Clapham]

I'm a man. And I read instructions. And I have found that one of my lesser-known talents is the ability to find multiple meanings in instructions and to choose the wrong one. Which makes reading the instructions not as useful as you might think.