Do you continuously rate/judge yourself while coding?

Question

This is my first subjective question and I hope it won't be closed.

In short, my question is: Do you continuously judge yourself while coding?

By continuous, I would also include "during" the coding at time 't' about time 't-1'. If yes, how do you judge yourself? Do you kick yourself, when you are not able to churn out a code, the algorithm of which you know and just taking the few minutes more, because of whatever reason- may be your language of implementation is not something you have been coding recently, or just learning it or anything else.

For example, I am currently for a week or so, writing pure C code after a long time and it involves a lot of Data structures and algorithms. I am a bit rusty as of now in both and I am taking time longer than usual and I can't help kicking myself during coding. Is this harming my productivity? However, I am picking up well.

Answer 1

I like to look at it this way:

Am I happy enough with this code to show it in public?

Gives me a good gauge.

Answer 2

I'd think that anybody that cares about the job they're doing would be constantly evaluating themselves. I'm not sure how you could do a good job without it.

There's certainly a line that can be crossed and if you spend too much time beating yourself up you can obviously harm your productivity but I'm not sure Stack Overflow can tell you if it's hurting your productivity, specifically.

Answer 3

No. I find this kind of self-monitoring useless and waste of time.

Answer 4

I always judge code I have just written, and see ways to do it better. But I find that balance between productivity, learning and clean code. Sometimes I will go back and clean up if theres time, and other times I will say "good enough, I know better for next time".

As for productivity, a good boss knows that productivity is not just measured in lines of code and functioning programs, but also in the knowledge and experience gained by the developers doing these tasks.

In my opinion, learning and getting better is also productivity.

Answer 5

No, I let ReSharper do that for me...

See here

Answer 6

Thinking critically of your own code means evolving. And no, evolving doesn't hurt, I view it as something positive.

Might be a problem in a corporate environment though, because any personal development not backed by certificates and diplomas is often not appreciated there.

Answer 7

Usually I'm so focused on the code that I don't have time to worry about my overall performance. I already know what weaknesses I have and I'm hacking at my code to correct them. I find programming to be cathartic in that way.

But, from time to time it is good to do a self review. Write out your strengths and weaknesses. Get those things you need to work on in view.

Then have the audacity to force yourself to persist against those imperfections.

Answer 8

Yes, it can happen. It could be used as an indication that you should stop coding, step back and ask whether the design has been thought out properly or not. If the design is sound as far as you know and the implementation is clear in your mind, it should give you the confidence to code without such worries. But some second guessing is probably natural.

Answer 9

Evaluating your skills and processes is a good thing, but beating yourself up is counter productive and will prevent you from ever slipping into a flow state.

If you work at your highest skill level, there's no reason to beat yourself up ever. You can hold your head up high, even if others disagree. Also, if your old code looks like it should have been done better ... it means you've learned something and your future code will be more awesome ... good work, give yourself a pat on the back!

Answer 10

Yes and honestly I am the worst programmer I know

Answer 11

Some people tend to judge themselves during and after. It is common for beginners (or just-intermediate-level programmers) that looking at their older code (from the very beginning days) is not so pleasant. This is natural and makes people more aware of the code they write in the present. So it may be a good idea to look up 1-2-3-4 years old code (not for veterans though :) )

Answer 12

To me it is not so much rating myself, but rather rating my code and trying to improve. Although, I do kick myself when I make stupid mistakes.

At my work we have adopted a policy that another developer must review your changes before you commit or merge to the trunk. This typically ends up being a not very in-depth review, but I found it to be surprisingly useful. First, it forces you to review your changes yourself and to make your code presentable (formatting, comments, etc.), and to avoid being embarrassed and wasting somebody else's time on pointing out things that you yourself know you have to fix. Also, during this self-pre-review you often find some bugs. Then, during the actual review by somebody else, you are forced to explain what you actually did, and then you often see the bugs you have missed when reviewing the code yourself.

I guess my main point is that code must be looked at regularly, otherwise it will rot.

Answer 13

I usually love the code I write... when I am writing it. Right after checking-in, I get highly critical of it, always finding so many possible improvements.

I guess this is what allows me to finish the job, but keep on trying to improve over and over and over.

A good programmer:

• Is a frustrated professional trying to achieve the impossible perfection.
• Is proud of the imperfect code he wrote as it was one necessary step towards the better code he'll write.
• Has absolutely no problem in throwing his own code out the window when it makes economical sense to do so.

Answer 14

You have to let go of that inner perfectionist (at least a little) while working or you will never get your work finished. It is good to be able to spot problem areas or some piece that isn't going to be easy for someone else to read. Just try your best to avoid getting stuck in a write -> re-write -> repeat circle for too long. You should also try to remember...

Anyone can program, it is your job to write code anyone can read

If what you wrote works, your co-workers can understand it and there are no critical code smells; you should be done. If you still don't feel happy about it after all that, then ask a friend or co-worker to come over and do a quick XP session.

Best of luck!

Answer 15

Sometimes yes and sometimes no. If I'm working off a spike and seem to be in the middle of a stream of work, I'll wait till I get to a reasonable stopping point before evaluating what I've done. If I'm working on a card, then the key is to get to a stopping point.

By spike, I mean that tangent work that comes from trying to complete a story and spending many hours off on something else that may or may not be a solution as to how to do the story.

By stream I mean that work of creating classes, tests, and other stuff for some basic functionality so that there is at least a prototype to change, refactor, adjust to make better.

A stopping point can be the end of day, just before a commit, or some other point where things could be handed over and the developer doesn't need to do a lot of head scratching to see where I left it.

There is also an aspect to doing some things in a pair programming situation where each of us can make suggestions as to how to make the code better or possibly divide up what has to be done so we are more productive on grunt work that doesn't really need a pair to crank out the code.

Answer 16

Yes, but usually I constantly judging why I am pulling in other's dependencies. In this way, the code I write has a natural bias towards avoiding implementing something in a way I know I don't like. I keep notes on various libraries, what they seek to accomplish, and how they fall short of specific use cases. Then if I ever wind up in a situation where the library is missing that use case, I know whether I have to roll my own or not. I then know, as I am coding, what decisions to make.