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.

What are the techniques that you use just about everyday, but are still awful at? Are you bad at it because of the difficulty of the task, laziness to learn better, or some other reason?

share|improve this question

closed as not constructive by Jonas, Mark Trapp, bigown Oct 14 '10 at 15:03

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

19 Answers 19

up vote 4 down vote accepted


Comments should really explain why I've done something - however, I usually completely forget to comment on why I've changed something (if I was fixing a bug, for instance) or put a comment which doesn't help in the slightest.

And then I get annoyed when I see bad comments in code :(

share|improve this answer
Why you have changed something should be left to your commit message, nobody wants to read that in code. –  Johnsyweb Oct 14 '10 at 12:09

Regular expressions.

Really need to make an effort of learning those, once and for all.

share|improve this answer
Had this aswer in mind before opening the topic. Thank god for regexbuddy –  Thomas Stock Oct 13 '10 at 9:43
I don't have a problem with the concept of regexes, but the specific syntaxes (different depending on whether you're coding them in perl / python / bash etc) means I have to look something up every single time. –  Vicky Oct 14 '10 at 10:19

Time estimates are always a challenge.

It doesn't help that we have pressure from both within and without to give unrealistically short estimates:

  • Most of us overestimate how much we can get done in a given amount of time.
  • The customer (understandably) wants things done yesterday.
  • The customer is of the opinion that our estimates are unrealistically long because they can use Excel (or whatever) to solve parts of the problem so quickly. They don't realise that the bits Excel can't do are hard (user interfaces, edge cases, transactions, multi-user, etc - as well as getting to know the problem domain). Moreover, they don't understand that the parts the problem that Excel can solve are also hard. Microsoft has invested thousands of hours in making them look easy - and we have to reproduce these bits, too.

The solutions to these challenges are:

  1. To give realistic estimates based on experience and rules of thumb
  2. Refuse to change estimates based on pressure from managers or customers
  3. Try to ensure that people understand that an estimate is an estimate, not a promise
  4. Prioritise features based on customer needs.
  5. Deliver functionality early and often.
share|improve this answer
...also to decompose the anticipated tasks to the smallest units possible. That way likelihood of overall error in estimates is reduced... some go over and some go under thereby smoothing the result. –  spender Oct 13 '10 at 11:50
other way to look at it is the estimate was spot on, just had the wrong person(s) doing the work. –  Ken Henderson Oct 14 '10 at 2:28
Also look at previous projects that had similar requirements or tasks. Extrapolate from the actual time spent, rather than the estimates. If you present your estimates with a break-down of the tasks involved and include best-case, worst-case and most-likely-case estimates, the customer and project manager will have all the info they need. It would be hard for them to beat you up if they have all the details of exactly how hard it is, so they can make decisions based around cutting features or reducing scope. –  JBRWilkinson Oct 14 '10 at 8:55

Debugging other people's hacky code.

And yes, given that this is what 90% of the work is about in my current gig (and in most programming jobs), it's a huge problem.

And the reason I'm bad at it is because I have a bad internal response to the task. Subconsciously, I think the thought process goes something like this:

  1. This stuff shouldn't be so bad/overengineered/complex/undocumented.
  2. It shouldn't be my job to deal with this stuff.
  3. I wish I was doing something else.
  4. Ok, better just suck it up, concentrate, and deal with it.
  5. GOTO 1.

....and often step 4 gets missed and I end up in a frustration loop where I hate my job.

share|improve this answer
+1 for frustration loop. –  Chris Oct 13 '10 at 14:38
In that case, perhaps you could lead by example by writing great code that needs little maintenance and is easy to extend (clear, self-documenting, etc). Eventually, your efforts will stand apart from the other 'cowboys' and people will pick up on your good practices. –  JBRWilkinson Oct 15 '10 at 21:52

Typing. My typing is really bad (speed is OK but accuracy is poor) and I've never found the time or motivation to unlearn all my bad habits and learn to type "properly".

share|improve this answer
I find this happens to me during the transition from home to work and back again. Having a different keyboard makes sometimes really just gets in the way. Toss in a netbook and somedays I feel like I have the accuracy of a 3 year old. –  Chris Oct 13 '10 at 14:39
The only class I've ever failed outright. Three times. I'm almost, after 20-some years programming, to three-finger no-look typing. –  DaveE Oct 13 '10 at 17:15

Multi-threading. I quite often have to write stuff that runs asynchronously and it's as though my brain can retain the concepts but I totally forget what libraries/classes/methods I used last time and have to go back over my old code or go out in search of tutorials before I can get it again.

Then debugging multi-threaded code... shudder

share|improve this answer
I suspect that not many people can, with confidence, claim they're good at debugging multithreaded code! –  Frank Shearar Oct 13 '10 at 9:07

I'm not as good at math as I should be. Compared to the general population I'm fairly competent, but for someone with a degree in computer science, I feel like I should be a lot better at it.

share|improve this answer

Behavior-Driven and Test-Driven Development... (or pretty much any other *-Driven Development.)

All of my peers rave about it and talk about how it not only improves the quality of code but it also helps to organize your thoughts when it comes to development. Honestly, I've tried it before, but it's hard for me to justify writing tests for something that I haven't written yet. I don't know... I'm sure that if I got it I'd be standing right along my peers singing it's praises, but, honestly, I don't think my brain is wired that way.

share|improve this answer

Interfacing with Customers

Not a technical skill, but a skill we should possess regardless. I'm not a people person in this regard. Just feed me the specs and I'm happy.

share|improve this answer


I do 95% of my programming work in C# or C++ equivalents, and I can do DDL to create the appropriate tables just fine. However, when the time comes to populate a table with some sample data for debugging purposes, I have to look up INSERT INTO every time!

share|improve this answer

Syntax is my Nemesis.

I can solve the problem conceptually easily enough, but having learned a squillion different languages and tools and frameworks or whatever, I think I can be forgiven for having to Google the right syntax now and then.

<Rant> Don't you just hate paper programming excercises in interviews? All about syntax, nothing to do with my ability to solve real problems. Grr. </Rant>

Anyway, the answer is easy. The IDE is usually quite helpful with syntax, and Google is my friend.

share|improve this answer
+1. I hate how companies assess you through paper programming instead of just writing pseudo-code. –  Terence Ponce Oct 13 '10 at 14:00
Gotta disagree here. If you can't write actual code for the interviewer, that tells them something: that even when you can think of a solution to a problem that you think should work, you're going to have a lot of trouble turning it into the actual code that they're hiring you to create. –  Mason Wheeler Oct 13 '10 at 21:32

Microsoft Word formatting codes.

Like it or not, writing documentation, specs, test plans, etc. is a part of programming. In my office, MS Word is the default tool. Nothing frustrates me more than trying to figure out how to keep large documents formatted correctly and consistently. I am always wrestling with autonumbering, tables, indenting, page breaks, and all the other ways Word "helps" by inserting hidden metainfo.

share|improve this answer
Why wouldn't you just use HTML? It's a standard, there are tons of editors and viewers and has a clear focus on semantics. –  back2dos Oct 13 '10 at 14:49
Why not? Years of inertia at this large coproration I guess. –  AShelly Oct 13 '10 at 15:20

Not sure if this counts, but autotools are my nemesis. This means autoconf, automake, autotest and libtool. A lot of projects that I manage were inherited with those tools in use for build configuration, and every time I need to change something about them .. my brain starts throbbing.

Classic example, right now, today I'm working on breaking some code that is shared by 10 things out into a few shared libraries. I've maintained library code managed by autotools, but I'm drawing a complete blank on how to start a whole new project using them. I should know how to do this, but I keep digging through existing code to get 'help'.

CMake, here I come.

share|improve this answer

LINQ and Lambda Expressions

Well the LINQ part only really applies to .NET but I always end up asking on SO rather than learning it for myself.

share|improve this answer

Actually, C++. I use C# whenever I can but I do a lot of Windows Installer work and M$ in its infinite wisdom doesn't support custom actions written in .NET so occasionally I have to get the stone tablets out and crank out some of that horrible C++ mess. It's not just the language, it's the archaic nature of the tools and the APIs you have to work with.

I should really spend some time getting better at it but as soon as I stop I'll just forget it all again - it's like my brain actively purges the evil from its neurons to be replaced with something more healthy. Like beer.

share|improve this answer

debugging. going in the code and try to figure out what he hell is happening and wher, trying to figure out what went wrong and where, putting logging into my code what watch the console

share|improve this answer
I personally love debugging code. Something about it presents an interesting challenge whereas starting with a fresh document just seems so easy since you get to create all the bugs yourself. –  Chris Oct 13 '10 at 14:40

OOP. Some concepts are making sense lately but still a lot to go. Hmm.. I like functional btw.

share|improve this answer
read the SOLID principles and get the book Head First Design Patterns. it shows you the design rules you need for your refactorings. some pointers: try to hide information from other classes, be concise in inside a class (stick to things that are related) and communicate to other classes as having a contract (little as possible, clear) –  Belun Oct 14 '10 at 9:33


I would write an explanation why, but ... ugh, brain hurts.

(Then again, they say that in the simple solutions lies the genius :-))

share|improve this answer

Converting between binary, hex and decimal. I always have to pull out a calculator (or ask my colleague, who can do the conversions in his head quicker and more accurately than I can do them with the calculator).

share|improve this answer

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