How to overcome the "Everyone else's code sucks" attitude?

Question

I'm the only programmer at work. A result of downsizing, I have to work on programs that have been created/maintained by many different past programmers. When I look at the code in some of them, I shudder to think that I worked with these people and they produced code like that. Now if I sound big headed and demeaning, well, I'm trying not to, but one would think that a programmer claiming 20 years of experience would write half-way decent code. Code that meets a minimum of standards.

What bothers me, is that I think other people's code really sucks. Am I a good judge of other people's code? I suppose I have been in the trenches long enough to judge.

The funny part is, I am almost always able to modify their code to do what I need, albeit, if the code were structured more correctly, it would be easier and less time consuming, but the fact is that I can modify the ugly, nasty, good for nothing code to do what I want.

Perhaps that says something about my ability as coder, or perhaps it says something about code in general.

At any rate, I still have that little voice within me saying, "if only they would have done it this way or structured it that way, I wouldn't be spending all of this time figuring this stuff out."

Is that attitude/thinking wrong? How do you rid yourself of that way of thinking?

Answer 1

A good way to rid yourself of that thought is to realize that the other person probably would think the same way about your code, if they were in your shoes.

Everyone can make better sense of the code they've written themselves, than code that was written by someone else.

Pride yourself on the fact that you can puzzle out someone else's code.

Answer 2

By educating others and introducing them to better * ways of tackling problems.

*better dressed up as alternate

Answer 3

It's not a problem as long as you also understand that your code sucks.

Yes it does.

Answer 4

I would say it is a matter of maturity and job satisfaction. Like you yourself, previous programmers were learning as they go, under deadlines, or maybe just lazy on a sunny July afternoon. It happens. You can whine and frown and hate it, or you can accept it and start enjoying your job just a little bit more. And maybe work to institute standards that would make it easier for future programmers on the project to write better code.

Answer 5

Look at some of your code circa two years ago.

Answer 6

Most of the time, you just bridle at the code being different to how you would have done it. It's rare that it's anyway near as bad as you think it is.

Answer 7

Yes you may find other people's code sucks, and yes you might be right, from your reasoned approach I think you propbably are. So embrace that, there's nothing wrong with finding problems and fixing them, I'd suggest moving forward with a couple of positive thoughts.

1) Just because their code was rubbish, does not make them rubbish people.

2) It was your good fortune to be the eagle surrounded by chickens, you're the one left when all others have been re-trenched - that's a pretty good place to be, or would you rather be looking for work?

3) Your final point "...I wouldn't be spending all of this time figuring this stuff out..." - that's your job, if it was easy someone costing half the money would be doing it. When IT gets hard, remember that's why we're well paid.

Answer 8

Take a look at this article by Joel

Also, as an exercise, force yourself to list (mentally, or on paper) why you believe the code "sucks".

• Does it use different coding conventions?
• Does it have a lot of "whiskers"?
• Is there significant duplication?

Sometimes it’s the code that sucks, but sometimes the problem domain "sucks" - it’s really complicated and inconsistent.

Answer 9

Humility: "It's what you learn after you know it all that counts."

Attributed to Harry S. Truman

Answer 10

Yes, yours, and mine, code sucks a little to other developers.

As a programmer, one always starts with good intentions of clean simple code, but eventually one becomes slightly constrained in the internal coherency of their personal logic...

Answer 11

It's within yourself to adjust your attitude - just make a decision to accept the way things are and simply get on with the job. And I mean really acccept it, not just tolerate it.

You seem to be blaming the other developers for writing poor code... dude, you worked with them - why did you not know what sort of code they were writing??

The real problem happened long ago. Where was your coding standard? Where was your code reviews? Where was the quality control?

It's not the code that sucks, it's your software development practices.

You were part of this failure. Rather than point the finger at people who no longer work with you, realise that you were indeed part of the problem, so you can be part of the solution. Make your attitude positive - strive to improve the code base and don't dwell on how it got into that state in the first place as you can't change that. Stop playing the victim and start being a good software engineer.

I'm sure you could find a consultant who could come in once a month and do code reviews with you, or mentor you in the ways of good software development. If you need it, tell your boss and make it happen.

Answer 12

Stay on a project long enough to you reach the point where you say "What idiot wrote this code?!" and then you look back through the source history to find it was you.

Answer 13

Assume that, somehow, your own code still sucks and you still can learn from others. This is not to say that some other peoples code doesn't suck, but I can assure you

1. You're not perfect
2. There are people better than you

I'd even tell that to Jon Skeet (from inside a very large glass house though)

Answer 14

You need to go back to the basics. Back to 1970 to be exact.

There is a chapter in "The Psychology of Programming" which talked about the history of a piece of code.

Yes some code is hard to work with, yes it is sometimes because of the skill of the original programmer, and sometimes because of programming process.

Sometimes, though it is because of the history of the program.

Some original constraint forced the program to take an unusual turn, and subsequent modifications didn't make it better, but only made it worse.

Answer 15

Remember that in our field we are all continually learning/improving. That said I don't think you can say that about all other people's code.

If you have looked/worked with lots of other people's code, there is the rare code base that you look and feel really well about it. Most likely it can be improved, but you can tell its well crafted software.

I am sure that even with your own code, you will have projects that you feel good about and ones that you don't. The type of experiences each person brings is an important factor, but also mistakes can come into play.

Keep learning and understanding how you can get better code and how you can explain that to others. Keep working with other code bases, if you think all the code you have access to is like that, look at open source projects. You will surely gain some skills/understanding that will make you look back and remember that you were also (and still are) on the path of learning.

That said, there are lots of really ugly code out there. Always improve the code you are working with at least a bit (just a little), since that continually improves the situation. You will notice this will challenge your skills for some scenarios.

Answer 16

Just find another coder to show you how badly your code sucks. In other words: Code Review.

Answer 17

just remember you were once like that when you first started coding.

the real difference between you and your nasty coders is that you're learning and looking for ways to improve your coding skills. while they just don't bother too much.

Answer 18

I think there is an "absolute" law that explains your (and our) problem: Code is more difficult to read than to write.

So, it's hard for you to work on old code written by someone else? Me too! Us too! Try now to slowly refactor that code your working on: It's a good way to appropriate ourselves an "ugly" code.

Answer 19

I honestly think my problem when I see crap code is, why did they want to make it a pain for everyone else including themselves? Then I get to thinking that either a) They didn't care to write it any better or b) they have no idea how to code. With b) I'm usually left with: who the heck hired this person, and then how can I teach them without looking like I'm teaching them. Hey, I know my code sucks, as I can tell about every 6 months when I go back to what I wrote before. My issue is, I then clean it up to be better, and they don't. This continues it seems for YEARS and we're left with a steaming pile of crap when I get hired on.

When I do encounter crap code I just start with my refactoring hat on and just go to town. I really try to clean up everything I can before I check it in. Most often, I have the extra hour or 2 it takes to get this done so I use it. If I don't have the time, I just shrug it off and try my best to not care. It's the caring about it that always gets me.

The best thing about your situation is you don't have to explain to anyone why you changed something. Sure, I'm all for teaching others, but a lot of times when you're on a group of 6 other people it's pretty daunting when they are all doing it.

I guess that last thing I'd say to you (and keep reminding myself) is that at least you care enough to strive to be better, and typically when you are "better" you are rewarded more than others. Focus more on the caring about improving your skills and use the opportunity of crap code to learn how to break dependencies, write great tests, and refactor like super-man.

Answer 20

On another note, you could think of it this way:

At a prior job, I did so well that the program had very few bugs (we'd find 1 every few months) and the code was pretty clean. 96% test coverage, and hadn't had a bug in 5 months.

Since it worked so well and didn't need someone maintaining it, I was laid off!

In other words, that crappy code you're mad at is keeping you a job. Oh the irony :P

Answer 21

Two things are there.

Craps are always craps. Throw it away. You may have better solution for the problem you're dealing with. The solution should be judged based on various parameters like performance, reliability, readability, ease for further enhancements, budget and time available etc...(which all matters)

If you feel each and every peice of code is not good, that's again problem with the attitude, I believe

There are few facts that

1. The whole lifecycle of a project is not one man show. There are many other stake holders and programmers who should contribute to develop complete softwares. So none of these components are avoidable.

2. All contributions should well taken and corrected by management over time.

3. Respect other's knowledge and experience. If you've a better solution, suggest it while respecting your coworker.

4. Realize that, no one is really smart programming computers.

5. After reading 'Themese in Software Craftsmanship' and 'Personal Character' from Code Complete (2nd edition), lot of my perspective got changed. I'd suggest you to read taht.

6. Jeff Atwood made a great post on - Nobody Cares What Your Code Looks Like

So as I said before, categorize a code as 'crap' only by proper judgement.

Answer 22

I got cured of this fairly quickly when I got told that my code sucked in a code review. :-)

Answer 23

the simplest answer is be open minded and work to help others to come to a common style somethings that may really help are

Doing Code reviews, if other people are going to see your code, you will code better and by review code and making the author explain why they did something the way it was done may give you better appreciation for what they are doing

pair programing (your basically doing on the fly code review)

Answer 24

Remind yourself that the existing code is often a result of evolution. That means different developers came and went, requirements were changed, enhancements added, bugs fixed, rushed schedules, hacks around the original architecture, code ported from a different app. It may have actually been well written code at one point, but simply degraded over time, the software equivalent of bit rot. The architecture, which might have been well articulated initially, might have gotten jumbled through all of this. It may not be the fault of any one developer. Code ripens itself up for some refactoring every once in awhile. That being said though, there are plenty of poor programmers too, so what you see might be some combination thereof.

Answer 25

Experience doesn't mean much. It's a fallacy to think that having lots of experience makes someone good at anything. Lots of people slide by on personality or are only good at very specific parts of their job, and they suck at the rest. A lot of everyone else's code does suck.

The only way I could think to get over this attitude would be to take some sort of mind altering drugs on a regular basis, and then you would be as stupid as the people who's code you are reading that sucks and so you would no longer notice it sucked, but I don't recommend that.

Answer 26

The best programmer I've ever known knew that his code sucks.

He was always mourning about how badly he had written something.

Maybe that's why he's so good.

Answer 27

Often, I look at a piece of code, and ask "what idiot wrote this?" More than once, I've looked up the file history, and the answer has been "me". Remembering things like that helps keep you humble.

Answer 28

Another thing to think about is that sometimes code was orginally written under constraints that no longer apply. What looks bad now might have been the only way at the time to get the thing to work. But you have better hardware now or a newer framework with cool new features or a database that supports some better ways for handling oh say recursion that weren't available in 1997 when the orginal code was written. Sometimes the constraints aren't even things you can know about at a later time like the time someone had to put this together on Friday afternoon to meet a deadline when they didn't give him the requirements until two hours before the deadline but wouldn't move the deadline. Or maybe he had a requirement that was ridiculous but for political reasons (i.e., it came from the CEO's girlfriend to pick a not so random example) was stuck with that made the system cludgier than it needed to be. You are likely judging without knowing all the pertinent facts.