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.

Sucking Less Every Year -Jeff Atwood

I had come across this insightful article.Quoting directly from the post

I've often thought that sucking less every year is how humble programmers improve. You should be unhappy with code you wrote a year ago. If you aren't, that means either A) you haven't learned anything in a year, B) your code can't be improved, or C) you never revisit old code. All of these are the kiss of death for software developers.

  1. How often does this happen or not happen to you?
  2. How long before you see an actual improvement in your coding ? month, year?
  3. Do you ever revisit Your old code?
  4. How often does your old code plague you? or how often do you have to deal with your technical debt.

It is definitely very painful to fix old bugs n dirty code that we may have done to quickly meet a deadline and those quick fixes ,some cases we may have to rewrite most of the application/code. No arguments about that.

Some of the developers i had come across argued that they were already at the evolved stage where their coding doesn't need improvement or cant get improved anymore.

  • Does this happen?
  • If so how many years into coding on a particular language does one expect this to happen?

Related:

Ever look back at some of your old code and grimace in pain?

Star Wars Moment in Code "Luke! I am your code!" "No! Impossible! It can't be!"

share|improve this question
3  
IMHO people who think they are perfect and think they don't need to improve are right. They can't improve. Any sensible person knows they can never be perfect, there is always room for improvement/learning new stuff. I would be horrified if I found out that I can't improve myself - I don't want to think I have a ceiling. –  MAK Mar 18 '11 at 9:24
    
I love going back to projects I made when I was very new, and looking at code that was so difficult for me to write. Many times the code is sooo simple. It makes me chuckle. –  The Muffin Man Apr 5 '11 at 20:35

10 Answers 10

up vote 6 down vote accepted
  > Sucking Less Every Year ?

No but Sucking different Every Year :-)

After my first reviews many years ago i suffered about missing naming-conventions.

Then i suffered that my coded was (unnecessary) implemented to be as generic as possible but that made the code difficuilt to understand and maintain.

Then i leared testdriven development, InversionOfControl, what dot net generics where and many more.

conclusion

suffering of old bad habbits decreaset but was over compensated by new sufferings i got because i learned more.

share|improve this answer
    
+1 for "different" –  Aditya P Mar 18 '11 at 9:44

1.How often does this happen or not happen to you?

How often am I unhappy with my old code? Almost always. There's rare exceptions where I have code that I'm really proud of... but again, they're rare. I've been told that code I wrote a couple of years ago was good... I cringed and thought "you poor poor person for having seen worse than the garbage that I wrote."

2.How long before you see an actual improvement in your coding ? month, year?

It is usually in stages... I get really into a style or methodology (take fluent interfaces for instance... as that was the last style that I had a huge wet one for) and butcher everything I write for a month or four. Then it starts looking better.

3.Do you ever revisit Your old code?

Not as often as I'd like. Most of my old code, is owned by previous employers. Personal code gets white-washed far too often.

4.How often does your old code plague you? or how often do you have to deal with your technical debt.

Being that previous employers have most of my old code, and I white wash most of my personal code... not very often at all.

share|improve this answer
    
white wash=re-factor? are you referring to a project code or your personal code base. –  Aditya P Apr 6 '11 at 4:46
1  
@AdityaGameProgrammer: White wash = toss it all out and re-write it from the beginning. I'm talking about my personal code. –  Steve Evers Apr 6 '11 at 12:38

I actually have both sides of the coin for this.

On the one hand, you look at old code and you see it's full of bugs and complicated ways of doing things that are simply accomplished by taking advantage of techniques and language features you didn't know about back then.

On the other hand, you spot a particularly elegant solution to a problem and you can't help releasing a smug grin at how clever you were back then.

And then you scroll down a couple of lines and grimace in horror at the fact you used GOTO in C.

share|improve this answer

It happens quite regularly when I'm looking at code and wondering, "What was I thinking when I wrote this?"

There are usually improvements all the time as sometimes a new idea for organizing the code, styling the code or something else will come to me and while it may not be a great improvement, every little thing may help that is worth doing.

Depending on the work environment, I may be seeing code from a few years ago as I continue to work in the same code base and be quite familiar with what is in there and is something to manage.

Old code is almost always plaguing me as usually I'm either changing an existing system or replacing the system. In either case, I have to know the existing system's quirks to ensure they are there in the new one.

While I'm sure there are those like Jon Skeet that can just think out perfect code, most other people saying that their code can't be improved are saying that from an ego point that could well be unattractive. At the same time, in terms of finding a big improvement every time that isn't always going to be the case.

share|improve this answer

In another question, the subject was about the ways to evaluate the quality of your own code. One of my suggestions was to review it in few years, when your experience is much higher than it was when the code was written. One quote of my answer to this another question is directly related to your question:

"in my case, the lifespan is one year: it means that I may modify the code which I wrote six months ago, but if the code was written two years ago, it has a strong chance of being thrown, then rewritten completely, since it just sucks too much."

So yes, in practice, every piece of code I've written becomes unbearable from my point of view in a year. And I'm not talking about throw-away code, but also about the code I've written with quality, maintainability and readability in mind. For the moment, there were no exceptions.

To answer your second question about the lifespan, it varies a lot. A throw-away piece of code has a lifespan of zero seconds: it sucks just after you've written it, but it doesn't matter. Some pieces of code I've written were bearable after two years, but needed some cosmetic changes: a bit of refactoring, enforcing of StyleCop rules, etc. In average, in my precise case, the lifespan varies between eight months and one year for C#, and between two six months for PHP.

Do I revisit my old code? Yes, of course, as every developer, unless you don't care about DRY and reinvent your own wheel again and again. There are also chances to review and improve code very frequently if you have a common codebase which you use in many projects. Another point is that if you work on huge projects, some may take you years, so you will have to revisit the old code.

Some of the developers i had come across argued that they were already at the evolved stage where their coding doesn't need improvement or cant get improved anymore.

When a person says that she's so perfect that she doesn't need to learn anything, it means that she's not even capable to understand how totally dumb she is.

Even if you have twenty years experience in computers/programming, things change too fast, so there are always new things to learn and new techniques to improve code. For example, a C# code written when there was no .NET Framework 3.0 can very probably be made more readable and better with the new things we have today (including Linq, Code contracts, etc.), and this, even if the old code was written by the smartest developer.

share|improve this answer
    
Its more like if you ask this you are at a risk of appearing to be like someone who does not know how to write good code. –  Aditya P Apr 6 '11 at 4:48
    
@AdityaGameProgrammer: There is a difference to make between buggy, ugly code, and good code which, after a year or less, may be written in a more elegant way. (1.) Nobody can write perfect code which will stay perfect forever, so we must admit that our code can be improved over time. (2.) We gain experience and knowledge over time, which is also source for improvement of the old code. –  MainMa Apr 7 '11 at 10:33
  1. How often does this happen or not happen to you?

  2. How long before you see an actual improvement in your coding ? month, year?

  3. Do you ever revisit Your old code?

  4. How often does your old code plague you? or how often do you have to deal with your technical debt.

  1. Every time I learn something new, hopefully that's everyday.

  2. If I get to implement what I've learned, then its immediate from when I implement it.

  3. Yes, only for (1) New features, (2) Bug fixes, (3) Nostalgia, (4) See how I solved something, can be useful.

  4. Related to 1. , when I learn how to do something better, I'm aware that some older projects "could" have been done better. I leave them be. Just make sure the next project is done the better way. I don't worry unless its an actual bug.

share|improve this answer
    
+1 for answering the direct questions –  Aditya P Mar 18 '11 at 9:54

Often people thinks that good code just suddenly happens but for most of us mere mortals good code grows in our codebase. I mean, it's very difficult to write the perfect piece of software from the beginning since requirements are constantly changing and we are not perfect programmers neither so stupid decisions are made constantly from managers and programmers. Then I see each requirement change a good opportunity to refactor some of the old code into better code (and be paid for it!) and repay a bit of technical debt. As they say: "leave the code repository a bit better each time you commit code". Then your system will evolve into a closer-to-ideal system.

I know absolutely no programmer that is proud of his piece of software but that is good. Than means that the programmer has learnt in the process.

Also if you read the book "Clean Code" then you'll increase your own code "suck factor" several times. :D

share|improve this answer
1  
I disagree with you on one point, I believe some code you can be proud of. The ironic thing is you can have one project go extremely well, and be proud of it, with maybe some little annoyances. Then the next project, your WTFs per hour are high... for your own code! :D –  jamiebarrow Mar 18 '11 at 7:44
1  
Maybe depends on the step you are now. Now I find code I wrote one year ago and even I find difficult to understand some names or the purpose of some methods. Also I find code uncovered by tests and things like that. As I keep on improving, things like that tend to be exceptions rather than norm and I start getting embarrased at problems that before seemed to be unimportant... –  Rafa de Castro Mar 18 '11 at 8:02
    
+1 for Clean code though its the comparison is always with your self. –  Aditya P Mar 18 '11 at 9:00

Hmm...I'm frequently fairly pleasantly surprised by how good a lot of my older code is.

If I were doing it today, I'd often write it differently, but if I had to live with the limitations of the time, I'm not sure I would. When you can count on a typical machine having at least a couple gigs of RAM, you can (and often should) write your code a bit differently than when a large hard drive was 100 megabytes.

share|improve this answer

Interestingly, all the "rockstar" programmers I ever worked with were extremely humble, keen to learn, and ready to admit that they don't know everything. Heck, many were actually outright self-deprecating, at least in light-hearted moments.

I don't think I've ever met a developer who thinks their coding "can't be improved", but something tells me these guys would be about as far from rockstar as you can get - to put it mildly.

share|improve this answer
2  
I agree 100%. They're silent assassins! Oh and awesome username, xkcd? :) –  jamiebarrow Mar 18 '11 at 7:41
    
@jamiebarrow: Of course. :) –  Bobby Tables Mar 18 '11 at 9:36
    
another failure case is the person who says "all software is bad, its all hacks, your ideas for improvements don't matter". Kind of depressing to work with those types. –  Doug T. Apr 5 '11 at 19:21

The following points are not advices but a personal log:

  • using fewer global variables
  • don't use abbreviation for variables or function names
  • write [some] testing codes
  • don't judge code as slow (or fast) without benchmarking
  • learn how to load test an app
  • don't fix it, if it ain't broke
  • use a source code management tool (git/hg)
  • refactoring is cool, don't under-estimate the cost of testing it brings
  • security is hard, so beware of this as early as possible
  • patch some open source project bugs
  • blog something new
  • usability may not be a feature request but it's important

I didn't learn all within a year, everything takes time ...

share|improve this answer
    
I like how you mention "write [some] testing codes". I believe nobody ever reaches perfection where they will never make a mistake as a programmer - we're all human, and we make mistakes from time to time. Unit tests and integration tests can reduce our mistakes. And I notice you say 'some' tests, which is important, because sometimes I've gotten carried away writing tests that weren't really useful. –  jamiebarrow Mar 18 '11 at 6:56
    
In fact, I think underneath "don't fix it, if it ain't broke" I would add "If it's broke, and it's complicated, reproduce and fix the bug with test code" –  jamiebarrow Mar 18 '11 at 6:57
2  
Can I add a few? If it's an API, don't expose more internal details than you have to, if you hide it you can change it later. Always use constants in place of magic numbers because they're easier to document and change. Immutability is extremely useful, especially where concurrency is involved. Work on someone elses' codebase, it's an infinitely valuable process to judge your own coding style when you have to justify it to someone else. Get the spec frozen (if possible) because it's harder to hit a moving target. –  Evan Plaice Mar 18 '11 at 8:47
    
If working on-site or around clients pack your no-authority and higher-power cards. If they ask you to change something outside of the spec, pull the (I have) no-authority card followed by the (referral to) a higher-power card (preferably a PM offsite who can take on the requests). Best case, it will free you up to focus on development; worst case, it'll cut down on the number of drive-by feature requests. (controversial) Return early and return often, if return was meant to happen at the end of a code block there wouldn't be a keyword for it. Hopefully, I'm continuing to suck less every year. –  Evan Plaice Mar 18 '11 at 9:05

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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