The truth is that probably in 2 years when you will see your current code you will agree that it was a mess. Learning programming is a never ending process and there will always be someone who is better at it than you.

So if person who said that your code is a mess is not just mean and it is not another case of “I would do it better” disease common among programmers you should ask him/her what exactly is wrong with your code and how can you improve it.

Don’t take pride in how well you code. Take pride in how well you learn. Then learning that your code needs improvement provides you with an opportunity to demonstrate how good you are at learning, instead of coming across as criticism of how bad a programmer you are.

Read http://www.perlmonks.org/?node_id=270083 if you have no idea what I’m talking about.

After 20+ years I know that some of my own code is still a mess. What it comes down to is making a decision between writing the best possible code versus writing what’s required to get the job done. Getting the job done within an agreed timeframe trumps the never-ending quest for technical perfection any day.

The trick is to learn to accept it. Learn to accept that you could do better. Learn to live with the flaws. Learn to accept that you’re not going to get it perfect this time, and probably the next time too, and that it’s a deliberate choice because the alternative is not delivering. And that’s worse.

Disclaimer: none of this should be read as “bad code is OK”.

Everybody’s code is a mess and there are no good programmers.

There are:

• programmers that ship fast,
• programmers that always ship semantically correct code,
• programmers that always come up with the optimal solution, and the fastest algorithm,
• programmers whose code is easy on the eye.

They hardly, if ever, end up being the same person.

And there are butthurt programmers that need to grow up and:

• ask what’s wrong,
• take no comment personally, as a measure of their worth as a human being;
• realize there are syntax guidelines in teams, and they gotta be followed, and they are arbitrary, so they’re not meant to be discussed ad nauseam, as there is no optimal solution, nor final word;
• get better at commenting their code;
• get better at commenting their code; (sic)
• find easier to debug, less clever, solutions to simple, mundane, tasks;
• take a class in SQL
  (I’d send half of this world’s population to take a class in SQL, just to be on the safe side)

It’s not art, it’s a craft.
We give for granted you’re clever: you’re programming computers, goddamit.
Still AMD64 and x86 are not compelled by the power of your prose. Keep things simple.

Well, a person saying your code is a mess is not constructive, even if they’re right. Did they give you reasons why it’s a mess? Like, methods are too long, responsibilities mixed together, too much branching, etc. Honestly, any code I wrote a year ago I would say is complete crap because I’ve learned a ton since then. So don’t feel bad about it. I would be more worried if you still liked reading the code you wrote that long ago.

The cleaner your code-base is, the less time you spend on fighting the code-base to solve a given problem. A year is a great point to be at because you can feel the pains of any design decisions you made earlier in the project.

On my current project, we’ve refactored several times as we got more comfortable with our technology stack. This should be encouraged and you should make note of tasks that take longer than they should because of present code-base.

Have you gone over some of the older parts of the code you wrote? You can probably see things you’d want to do differently now or refactor.

Also when you mention a lack of testing, this is always something to look at. On our project we had no automated testing and as a result a lot of highly coupled code. Even if you don’t write unit/integration/whatever tests regularly, doing it for a little while will get you in the habit of making your code more modular (and consequently, less of a mess).

I feel so sad and hurt. I really love programming and making them say
something like that really hurts me. I really want to improve myself.

That is good. That is a lot better than having a reaction like “my reviewer has no idea what he is talking about”, “my reviewer is too picky” or just “my reviewer doesn’t like me” and ignoring them. This attitude is a good thing.

But it seems like I’m not a genius programmer like in the movies.

Not sure what kind of movies you watch, but 90% of the programmers in the movies are so fake I have tears by the end of the sequence.

Can you give me advise on how to be better?

Read and practise. Check out books like Code Complete or The Pragmatic Programmer. Look on Amazon for similar books.

Have you ever experience something criticizing your code and you feel
really hurt? What do you do on those events..

Why do you feel hurt? I feel disappointed in myself for being such a moron in the first place. I use that motivation to clean up my code and make sure I don’t make the same mistake again. The last thing I want to do it not learn from it. You have been put down once, don’t let it happen again for the same reason.

No programmer is born perfect, or even close. The more code your write, the more reviews you get and reviews you provide, will make you an all-round better programmer.

One of the best things to me about being a developer is that every day is a learning process. There will always be someone out there who doesn’t know something which you do, and there will always be someone who knows something which you don’t. I certainly wouldn’t consider myself to be anywhere but at an entry/junior level, but I appreciate any criticism I can get as long as it is both justified and given with respect.

An analogy that might be fitting relates to a time period in which I was a writing tutor at a university, as well as when I took part in creative writing courses. Writing code, for all intents and purposes, is much like writing a poem, essay, short story, or novel. Each individual has their own way of going about doing it, but at the same time, even the best writers (or, in this case, developers) make mistakes or let things slip through the cracks. We can often fail to notice these things because we become so used to our own voice (or again, in this case, style of code).

Much like in any field, there are those who are considered to be experts. If those people didn’t exist, we wouldn’t have anyone to learn from. Assuming this individual in question is truly an expert, I would listen to what he says and ask what he would suggest you do to improve upon your code. Never forget, though, that he is not the only one who can give his assistance; we have the good fortune that a plethora of resources such as SE/SO exist.

Mess is rather subjective. The best thing you can do is to actually ask that person (or the review report): why is it messy? (from their point of view, that is)

They’re bound to answer you and you’ll be able to either:

• Argument against it (if you have a good reason to do so, of course)
• Feel very happy, because you just learned something new and your future code is bound to be more awesome since you now know how to make it less messy thanks to their advice.

The fact that you’re concerned is a good sign. Let’s start with that. You mention you love to program, but do you love being a professional programmer? There’s a big difference between an enthusiast and a professional. As a professional you will be under constant scrutiny for your work product.

Our team is composed of 5 programmers, and 4 of us are new

The fact that you’ve worked two years without any confrontation tells me that you’re working in a very laid-back job which, is not so good if you’re actually wanting to move forward as a professional. Mind you, some of the best programmers in the world work for the Linux foundation and be rest assured they do not get treated kindly when they make marginal mistakes … much less ‘messy code’.

For a quick review of some fairly standard coding guidelines, the Linux Community Contributors Standards should give you an idea of the level of responsibility to aspire towards for your product. Refer to GETTING THE CODE RIGHT.

To further that assertion you should learn to embrace review as most good software is thoroughly reviewed. This supports Linus’ Law stating …

“If there are enough reviewers, all problems are easy to solve.”

Personally, I’ve seen highly skilled, responsible and dependable developers get the axe for something as simple as forgetting to leave comments … so if someone tells you your codes a
mess then it probably is … Get over it … Refactoring. It’s part of the gig.

I feel so sad and hurt. 

Go make a sadness application to gauge how upset you get when you don’t apply yourself.

You answered your problem … You Don’t Test!

After seeing a comment you made stating that your a java developer, I almost got upset. So if I understand you correctly your saying that you and your development team are working in a java shop and don’t have a test framework for your applications …

Therein Lies The Rub

“We deployed our program to the program without thorough testing.”

Cribbing UML Creator Grady Booch …

The amateur software engineer is always in search of magic,
some sensational method or tool whose application promises to
render software development trivial. It is the mark of the
professional software engineer to know that no such panacea
exists.

Alistair Cockburn provides a wealth of information on his site on using agile methodologies to increase performance and quality for you and your team.

One of the most important aspects of programming {and life} is knowing your strengths and weaknesses. If you don’t work on your weaknesses you will not have a well-rounded skill-set.

Outro … Your doing fine – Just don’t whine. Move forward in developing your craft and let your passion for programming keep you going. Good Luck 🙂

Don’t let your emotions get in the way of improving your code. The goal of a code review is to find problems, so you shouldn’t be too surprised if there are some. That said, they aren’t supposed to be a coder-bashing session either.

They also shouldn’t be just saying ‘Ewwww’ and leaving it at that. There is always a reason why something is wrong in programming. For instance, it’s wrong to leave lots of commented-out code all over the place, but it’s wrong because it clutters up the code and makes it harder to read, not because somebody said so in a book.

Your code is not you. Remember that.

I’m going to be the dick here and advise on the basis of.. well, the obvious. Obviously, your code IS a mess or the question you’d be asking is “WHY is somebody saying my code is a mess?” But you’re not challenging the supposition. You’re just acting hurt and quite frankly there might be crying but there’s no feeling when it comes down to justifying programming.

But really, why are you asking? You know your code sucks or you’d be asking a different question. If somebody told me my back-end web code stank, I’d laugh and say “okay what’s wrong with it?” If they told me my JavaScript stank, I’d give them the social programmer equivalent of a fat lip and I’d never ask for advice on how to react because the little bitches are clearly !@#$ing wrong.

Own what you’re good at. And I really mean take responsibility for it. because it only takes one goof for some twit to second-guess you. Don’t ask permission to be good. Just know your stuff. The end.

Remember this: The worst code you will ever see is your own!

Jeff Atwood of codinghorror.com wrote alot about the topic, you might want to start here: http://www.codinghorror.com/blog/2009/07/nobody-hates-software-more-than-software-developers.html

If you want to improve, start to read stuff about coding style, patterns, workflows, basically everything you can get your fingers on. Also learn more programming languages, see how they do stuff. If you are doing OOP, read this: http://en.wikipedia.org/wiki/Design_Patterns

Also talk to other programmers and do pair programming or watch others code.

Making mistakes is unavoidable, repeating them is.

Most of the time you should say “Thank You” to the person that told you this.

Chances are that they care about their profession, they care about their work, they care about their team and they care about you.

It can be hard to take criticism. Don’t get mad about it. Think about what they are trying to tell you and don’t let your emotions get the better of you.

I’ve been programming for a long time (30 years) and my style and code is improving all the time (I hope). The only way that I know its improving is when other people tell me or if I go back and review my code.

Try looking at code you wrote at the start of your career. What does it look like to you now? Does it look as good as you thought it did when you wrote it 😉

First off someone saying your code is a mess is very vague and subjective. It can mean different things to different people. Here’s why; there are two different things that have to be considered.

Structure

The structure of your code is governed by the language, industry standards, and company standards to name a few. Obviously there are other factors as well.

These are the types of mistakes that lint, test tools, and similar products are designed to identify. They are well defined and you or your tools can make objective decisions as to their validity/correctness.

Style

Despite standardized structure/rules for code, every developer has a certain style in the way they write and approach a problem or task. Do code maintenance in any team environment and over time you’ll be able to take an educated guess as to who wrote the code based on the style. You’ll also develop your own style and it will change as you gain experience and learn your craft.

So any time that someone says your code is a mess you need to understand if they are talking about the structure or the style. They are two very different things; structure is objective while style is absolutely subjective.

That being said, any constructive feedback from other programmers can be very valuable to you. It’s all up to you and how you take the criticism. Over time you’ll learn who’s opinion to take to heart versus who’s to take with a grain of salt.

As you progress in your career you’ll look back at your own code and see things that you could do differently, better, cleaner, and faster. It’s all part of the learning process and seeing your own past mistakes is a true indication that you are honing and improving your craft.

Don’t let a bit of criticism dampen your spirits. Take what you can from it and if it’s meaningful and valuable add it to your store of knowledge.

First of all, you must understand that programming is an iterative process, much like writing an article or a book. First you write a “rough draft” of your program, just to get it to work. At this stage, your code will be a mess. So you refactor to make the code clean. Then you profile and see what you need to optimize to make it fast. The trick is to refactor continuously, otherwise the mess will grow. You have to clean your code regularly, just like you have to clean your house.

Code reviews are absolutely essential. You must have your code looked at by at least one other pair of eyes. When you spend countless hours looking at your code, you get used to it, and you can easily miss a bug or a code smell that your coworker might notice instantly.

Also, the act of explaining your code to someone else is a great way to see if you have missed anything. This is like reading a paper you are writing out loud. Your brain processes audio and visual information in different ways, and you can find flaws in your reasoning by switching modality. Also, if you explain your code to a coworker, and something does not make sense to her, that is a good indication that you should refactor your code.

When doing a code review it is very important for both the author and the reviewer to check their egos at the door. The goal is to make the code better. So the reviewer must be respectful, and the author must keep an open mind. Remember, your co-workers are the ones who will have to maintain your code, so it must be clear to them. If the reviewer does not understand what a variable does, rename it. If the reviewer can’t understand what a block of code does, refactor it into a function with a descriptive name. Irrespective of what you may think, if your co-workers cannot understand your code, it is not good.

Speaking of refactoring, you absolutely must have a unit test framework, because without it, you cannot refactor.

Finally, I highly recommend reading “Clean Code” by Robert C. Martin. It will tell you why your code is a mess, and what you can do to clean it up.

Can you give me advise on how to be better?

Jay’s answer which recommends books is a good one, however it sounds like you’re at a turning point at work already.

Past:

Our team is composed of 5 programmers, and 4 of us are new, 1 has more
than 3 year experience. We’ve been working for a program for almost a
year now and nobody ever review my code and I was given a page to work
with.

Present:

Now it is tight and we need an approval and code review first before we make changes with the code.

It sounds like your company/team/department is learning as whole, in terms of project and team management as well as programming. Starting to review code is an excellent opportunity to improve in pretty much all areas if it’s given proper attention.

Use this as an opportunity; assuming you’re doing peer reviews (with the other developers on your team) suggest to them that this process is important and that everyone can learn from it.

At the base line it will be a quick review with the outcome being “yeah looks ok”. With a little more focused effort you can bounce ideas off of each other, “yeah that works, but you could have approached it in this way, which would have made your goal clearer…”. Take notes for future even if the code is deemed ok to deploy.

If this is going to be successful, you need to get your team and manager on side, which often means explaining the benefits to them. To the other developers this is an opportunity to learn. To your manager this is the opportunity to up-skill the team at little cost, therefore creating outputs a) with more value or b) faster c) with less maintenance cost (usually a big issue!).

This is a culture change, which you can’t force through by yourself, but you can help to nudge things in the right direction!

Don’t forget, this is kind of culture change can be hugely beneficial to organisations; good managers will recognise that you’re working to make the whole team better, something worth rewarding.

Can you give me advise on how to be better? Have you ever experience something criticizing your code and you feel really hurt? What do you do on those events.

The answer to this can be found in the new generation companies. I have been to companies like Google and FaceBook and I see that if you follow Agile/Scrum process religiously, then you can write better code and improve it every sprint.

How to be better? 

The answer is continuous refactoring. The modern development tools like visual studio has lot of tools that helps you in this process. If you follow Scrum software development process, then say for ex, you wrote bad code in sprint cycle 1 and someone pointed out during review it’s bad, then in sprint 2, you have the opportunity to refactor the code.

These issues are occurring in the first place because of lack of good process. So the solution is to come up with a good software development process for your team and practice continuous refactoring.

I would thank them for the feedback, and then ask them to explain what makes it bad and how it should be improved.

If you agree the person giving the feedback is making sense, consider making changes in the future. But remember, just because someone says it doesn’t mean it is true.

Can you give specific examples of what has been called “a mess” ?

While it is important to recognize when your own code is a mess (very typical feeling among programmers, especially as they become more experienced and their earlier code ages) it is even more important to listen when other people tell you so.

There are only so many issues you can recognize in your own code, since it was produced in constraints of your current programming knowledge.

Code review is essential learning opportunity because it likely exposes you to new knowledge that you didn’t have while working on the code (otherwise you would use it and there would be no mess).

I think there are two parts to processing negative feedback.

1. Determine nature of raised issue(s) and what you should learn from it

When I review or have my code reviewed I sort information about code issues in roughly such buckets:

• violates hard technological requirements
  • plain wrong (does not function or perform to requirements)
  • will fail in other circumstances (environment/configuration change)
  • uses deprecated functionality and will break in foreseeable future
• violates industry best practice, lacking in things such as
  • using proven approach to specific problem
  • performance
  • backwards compatibility
  • ease of maintenance
  • coding style
  • documentation
• violates workplace best practice
  • same as industry, but more specific to company/colleagues and can differ from industry in details
• not in line with personal expertise
  • can be improved in some way, in opinion of person reviewing

Note that this ranges from very objective things (“this will break when deployed to our production server”) to very subjective things (“I don’t like how you named variables”).

2. Determine which (if any) changes to the code will be made as outcome of review

After information is processed there comes decision if it is actionable and if code should be changed. This is not necessarily your decision, your opinion might or might not matter depending on parties involved and specifics of your situation (seniority, etc). But possible outcomes roughly are:

• address issue in full
  • fix broken
  • format to required coding style
  • and so on
• come to compromise if issue should be addressed at all or partially, since there might be
  • no resources (such as time or budget)
  • no need (will only achieve insignificant improvement, compromise stability, etc)
• come to understanding that raised issue is invalid
  • feedback (especially from subjective opinion category) can very well be outright harmful and should not be acted on blindly

You’ve learned that it feels painful to get negative feedback and it very well might be painful every time in the future. However you have left learn how it is important learning opportunity and how the process helps you to improve professionally and your workplace to achieve better code base.

Well don’t feel broken. Eventually you will learn from the mistakes. Once you are done with the issue you can talk to guy so it makes him feel that you want to improve. Try to listen more and argue less.

I have been through this situation and I can understand.

TL;DR

How would you react if someone told you your code is a mess?

My straightforward, “too long didn’t read (all the answers – apologies, I will hopefully find time to later and edit/amend this if necessary)” answer/tip:

• Good old Peer Review. Ask different crews with different collective mentalities, expertise levels and/or levels of aggressiveness to review your code.
• Just to elaborate a bit on what I mean by “different” peer groups: the StackExchange diaspora is probably the most clued up, professional and esteemed group because of the relative difficulty in becoming part of it compared to, say, Reddit. Reddit tends to be very aggressive in the more popular sub-reddits – but strangely enough the programming subreddits are quite friendly (from what I have experienced).

A good, perhaps the best, example of the aggressive, gangsta type of clique mentality are the XDK Forums crowd, and the worst of the worst trophy I hand to the CyanogenMod for Android forums/IRC channel populace.

That was a bit longer than I intended; my point was supposed to be – get varied reviews, but focus on getting honest critique from the people that know their trade, and know what constructive criticism is.
Oh, and be able to take any form of criticism without letting it get you down. Rule of thumb: if you start to hear similar commentary pertaining to a thing that can be mutual to the comments, then do some more thorough introspection.