Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am interested to gain a better insight about the possible reasons of personal inefficiency as programmers (and only in programming) due to – simply - our own errors (because we are humans – well, almost all of us).

I am not interested in how much we are productive or in how many adjustements the customer asks for when the work is done, but where and how each of us spend that part of its time in tasks that are unproductive and there is no one to blame except ourselves. Excluding ego - feeding and / or self – gratification, what I am trying to get (for all of us) is: what are the common issues eating our time; insight on reasons for that issues; identify simple way for us, personally (not delegating actions to other or our organizations), to correct our own problems.

Please, do not think in academic terms but aim at the opportunity to compare our daily experiences and understand what are and how we try to fix our personal deficiencies.

If you are interested to respond to this post, please:

  • integrate the list if you see something important (or obvious) missing;
  • highlight or name honestly your first issue tellng the way you try to address and solve your issue acting on yourself and yourself only in a sort of "continuous quality improving"

My criteria for accepting the answer is: choose the best solution (feasibility and utility) to fix one (or more) of the problems of the list. Of course, selecting an error is not a vote on our skills: maybe we are hyper professional programmers and we lose ten minutes only every year or we are terribly inefficient, losing a couple of days a week: reasons for inefficiency could be really the same - but in a different scale.

A possible list:

  • Plain error in the names (variables, functions).
  • Inability to see the obvious in your code. Misreading. Lack of concentration.
  • Trying to use a technology you have not mastered.
  • Errors with data types.
  • Time required to understand your previous code or your documentation.
  • Trying to do something more than requested because you enjoy it
  • Using solutions more complicated than required because you enjoy it.
  • Plain logical errors.
  • Errors due to your fault in communications.
  • Distraction

My first personal issue: "Trying to use a technology you do not master." I have to use daily several technologies and I often need to spend significant time correcting code because my assumptions were plainly wrong. Reasons for this: production needs put high pressure and make difficult to find the time to learn.

I try to address this reading technical books - as many as I can - even if this actually consumes a lot of time.

share

migration rejected from stackoverflow.com Dec 16 '13 at 6:42

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as too broad by gnat, GlenH7, MichaelT, Bart van Ingen Schenau, Doc Brown Dec 16 '13 at 6:42

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

17  
Source of (programmer) inefficiency? Spending to much time on Stack Overflow ;) –  Tony Feb 4 '11 at 12:14
    
@Tony - you beat me to that! –  Tim Post Feb 4 '11 at 12:16
2  
@Tim, you need to practice some more being on StackOverflow. –  user1249 Feb 4 '11 at 12:23
1  
Perhaps you could expand on how precisely you are measuring efficiency? In economic terms efficiency is expressed as work performed/effort expended. The question is how are you measuring work and effort? –  Berin Loritsch Feb 4 '11 at 12:49
    
@Berin: of course, measuring time in reworking or debugging compared to the overall time to complete. I use timetracking tools to keep an exact record of time spent on different tasks –  Daniel Feb 4 '11 at 12:57

7 Answers 7

up vote 21 down vote accepted

My first personal issue: "Trying to use a technology you do not master."

That's not "inefficiency" at all.

That's "learning".

You're calling it the wrong thing and you're thinking about it the wrong way.

I often need to spend significant time correcting code because my assumptions were plainly wrong.

Correct. That's called "learning"

production needs put high pressure and make difficult to find the time to learn.

That's called "a bad organization". Learning takes time and costs money.

Calling it "inefficiency" is a bad thing to do. Trying to skip over the learning means that bad or potentially bad code gets written. Learning reduces risk and (in the long run) reduces cost and complexity.

share
    
ineffieciency versus learning - that is true for yourself, but what about from the companies point of view? –  jmo21 Feb 4 '11 at 12:55
2  
@james: When the company doesn't see it as learning, they create poor software. At the very least, they create risks which stem directly from improper use of technology. –  S.Lott Feb 4 '11 at 13:12
    
@SLott I totally agree, but there are too many techies who want to upgrade something for the sake of it when it is not necessary for a specific product. Use the new tech on the next thing. –  jmo21 Feb 4 '11 at 13:42
    
@james: "too many techies who want to upgrade something for the sake of it"? How is that relevant to the question posed above? –  S.Lott Feb 4 '11 at 14:09
    
@SLott - it is a tangent from your point about learning. –  jmo21 Feb 4 '11 at 14:24

You'll have to define how you are measuring efficiency to get a better answer (work performed / effort expended). The reason I bring that up is that there are a number of things that developers involve themselves in that are short term investments in long term goals. For example, the process of learning a new technology, programming language, etc. may reduce the short term efficiency but yield greater long term efficiency (i.e. expanding the window of evaluation from a month to a year for example).

That said there are some things that never help. The worst working environment I had was due to insufficient office space. We had four people per office, and that was before we got moved to a big room with 20+ people in it. Imagine trying to do any job as one team (the majority in the room) would loudly collaborate. Earphones were not enough to isolate myself. Others are:

  • Random interruptions from my train of thought. As Brooks put it, programming is "pure thought stuff", interrupting a programmer deep in thought forces them to dump what they are thinking about and rebuild the context after you leave. In my experience it takes about 20 minutes to get back to full efficiency.
  • Incessant meetings throughout the day. We need large enough chunks of time to get through our work--multiple meetings a day will kill productivity.
  • Splitting efforts between multiple projects. It requires time to perform the context switch between projects--even if they are using the same technologies. It's the individual requirements for the project that matter here, not the platform. Worst case: splitting a day in half between one project in the morning and one in the afternoon--both with a daily status meeting.
  • Never being allowed to refactor or clean up existing code. While every programmer has their own idea of design purity, there are some things in legacy code that just make it miserable for all who work on it. It got that way over time, and it will take time to fix it. In these cases it is much better to perform small easily reversible code cleanups than it is to scrap and rewrite the whole thing.

However, I think that there are some activities that are necessary that some people would argue lowers efficiency while I would argue that they raise efficiency:

  • Writing unit tests. It increases the up front effort expended; however, when done correctly it will prevent a large enough amount of rework needed to fix bugs later on. In short this is a short term investment in a longer term goal (releasing stable software).
  • Learning new technologies. The lessons learned in the process can cause the developer to be more efficient with the technologies they already know. Also, it might be that those new technologies enable you to include features that would have been infeasible otherwise--giving you a competitive edge.
  • Rewriting poorly written libraries. The threshold I use for this is when rewriting the library would take less time than adding a new feature to it. NOTE: I did not say rewriting a whole application. An example would be a templated label printing library from a project a long time ago. The legacy code was written in C++, but in the style of C. It incorporated a finite state machine that spanned 5 classes with all static methods and 3 DLLs. When I was tasked to do something with the library that was very different from the assumptions built in to that library, I did the math. I told my manager that it would take me less time to make it properly object oriented than it would to monkey patch the library. He agreed with the time table I proposed, and the end result was 1 DLL and just the right amount of objects. Future modifications took far less time (measured in hours and not weeks).

Bottom line: the exact cause of programmer inefficiency really depends on the programmer and the project. You'll have to take time to figure out what is going on, but how you measure efficiency will affect the choices you make to improve it.

share

Busy working environment. That's going to be my biggest problem with efficiency. I get distracted easily. One of the reasons why I love to work from home, although there is plenty of distraction as well.

I tend to put on some music I like on the headphones. For me personally that helps me concentrating, as my brains wonder off less when I do that. Next to that, I force myself to do some walking when I notice I'm staring too long at the screen without really thinking about the code I write.

This goes together with "difficulties getting started". There's always something to do, read, check, or talk about before you get to the coding. So I have the morning planned, allow myself 20 minutes of reading mails and the newspaper, and then I go get a tea. This marks the beginning of coding session for me.

Sounds stupid, but works.

share
    
Busy, noisy office is my #1 issue. Its distracting and I can't focus with people constantly walking past my desk. –  rmx Feb 4 '11 at 12:44
    
+1 As it is the main factor causing inefficiency in my experience. Though I like it that way, distractions are good, involve you more with the business as a whole and build better relationships with colleagues. I do hate the "isolated/insular programmer" stereotype. –  Orbling Feb 4 '11 at 12:53

Choosing the wrong tool for the job. Yes, you can use assembly language to make websites. However, you could also use Python and get it done in a fraction of the time. It would probably be more secure and maintainable, too.

A large part of this is inertia: "This is the tool I know how to use, so I will apply it to every problem I come across."

share

Distraction is a common one for me, and the main cause of delays that I feel are my own fault. In my case it's also largely related to motivation. I try to handle it by developing quality time opportunities, where I'll trade a distraction now for focus later, then resist distraction during what's supposed to be quality time for a given piece of work. An element in this is not expecting a quality time period to be very long, maybe a couple of hours at best.

Looking around, I'd guess distraction/motivation, over-engineering (both in writing code and in the processes that manage it), lack of planning awareness, and simple density or poor taste, are all pretty common.

share

Distractions - the programming profession almost idolizes the state of flow, and I don't object - it feels great and gets stuff done.

  • External: noisy work environment, phone calls, etc. They usually can be helped.
  • Self-Made: Nowadays, mainly the internet - at least the problematic one, because shutting it down is a two-sided coin. There's a huge pool of instant answers right out there, but there's also The Onion, youtube, and other people's questions.

Working disconnected from the crowd requires a different style, which needs to be trained. One technique is to plan "runs" where for e.g. at least 30 minutes you limit yourself to the necessary tools. Kill the network connection if you like. Postpone problems you can't solve immediately, instead of searchig for a tool or asking at stackoverflow. You won't get a solution immediately anyway, and there's a godo chance the problem doesn't need a solution, or turns out larger than you thought.

Planning - plowing ahead is great, if it's the right direction. Having cranked out 1000 lines of amazing code is pointless when the problem sovled is not the problem to be solved. Before you set out to code, have a clear understanding of what and why: you understand the problem, the road to the solution, and know how to test it.

Observation - Observe yourself, evaluate the results of the last coding run.

  • How long did you go without distractions?
  • Did at some point the desire to check facebook or email stop?
  • Does the code written stand up to a rigorous review? Did you have to fix a lot of bugs?
  • What mistakes did you make? Invalid assumptions, typo's, incorrect control flow, forgetting error conditions, ...
  • Do you make certain mistakes more often? Studies show that trivial errors are indeed terribly common, but everyone has his personal stats.

Example: I virtually never have a problem with = vs ==, but yoda style hampers my reading of code. OTOH, I ran into frequent problems with mixing up nested one-letter loop indices i,j,k. So I write if (a.foo == 17), but use lengthy, distinct names for nested loop indices.

share
    
Distraction is the big one for me. British comedian Dave Gorman talked about working with the internet available: "I don't know about you, but all the information in the world ever? For me that's a little bit distracting." –  glenatron Feb 4 '11 at 13:07

I have met and worked with some programmers who manage time and projects poorly. In addition to this, some of them are difficult to talk to, are not very receptive to constructive criticism and seem to consider their chaotic approach towards writing "normal". Why is this? Some code that a programmer uses frequently can be written and saved in files to enter later. Writing and testing small segments of code might seem tedious but, once it is verified as functional it can be saved and stored on a notepad for later use. The grammar of computer language is built on symbolic logic. Just like people who read books, computers will not read one that is poorly written. Why even attempt to compile a string of code with an untested line? That is all it takes to ruin context. Then the problem becomes exponential.

When I was in college, in project management, the professor and the text said that it takes a team of programmers thirty days to write one hundred lines of code. Wow! I do not mind saying that I believe that thinking can be defined in a scientific way. Writing code requires an understanding of how symbolic logic works. It is why programmers in SQL and Oracle make outrageous salaries. A computer can compile large quantities of information when the strings are properly connected. Is the environment noisy? They sell headphones in the sports department for those who go to the firing range. Are there too many meetings? That is usually because the ambiguous quality of information requires frequent reviews.

I hope I am not offending the reader, this is not my intention. If you look in the mirror and there are diodes growing in your scalp and your eyes glow like the light of an inserted flash drive, it is likely you are not spending enough time away from the computer. This is only possible when the team is on the same page.

Steve

share

Not the answer you're looking for? Browse other questions tagged or ask your own question.