I'm a novice programmer and often when I'm working on my own projects, I always get the feeling that the design of my code is not the best it could be, and I hate this feeling. I end up spending time looking things up, but then I become overwhelmed easily with many details, such as design patterns to choose from and when to use an abstract class or an interface. Am I supposed to try and learn a little bit of everything at once?

  • 15
    use deodorant ;)
    – Pemdas
    Commented Jan 26, 2011 at 3:17
  • 6
    And maybe a disinfectant / insecticide to get rid of the bugs :-)
    – Stephen C
    Commented Jan 26, 2011 at 3:24
  • 3
    Eat some garlic. People will probably notice your bad breath more. Commented Jan 26, 2011 at 3:28
  • 4
    and now you have: codereview.stackexchange.com where you can get help with specific examples of your code.
    – LRE
    Commented Jan 26, 2011 at 4:44
  • 1
    Open windows... oh wait...
    – Mchl
    Commented Jan 26, 2011 at 12:32

11 Answers 11


A few suggestions:

  1. Use encapsulation to manage complexity by separating functionality into distinct building blocks. Prove each block works (via unit tests), and you can use it without being concerned about its inner details.

  2. Learn and study software patterns. Software patterns are tried and proven methods for performing certain common, well-known tasks.

  3. Study and understand data structures. Learn the appropriate uses and performance characteristics for each type of data structure.

  4. Know your programming language well, its strengths and weaknesses, and how to best use its features.

You don't have to know all of this at once, but you should study all of it over time.


My advice is: stop worrying.

Experience is the best teacher, and you don't get experience if you don't write code. Also, badly designed code that is written is better than great design that is not.

So, write more code. Finish your projects. That feeling that the code is not ideal is probably right. And you'll probably have problems with this code. And when you have these problems, then you'd learn why exactly it was bad. You'd learn way more from firsthand experience than from "looking things up".

Also, don't hope that this feeling of "code smell" will ever go away. As you are getting better, you'll fix some problems, but start noticing new, more obscure/advanced ones.

  • +1 for badly designed written code is better than unwritten great code! Commented Jan 26, 2011 at 7:11
  • It sounds like a truism, but it's not. Badly designed code that does what it's meant to is better than well designed unwritten code. However, if the code is badly designed, how likely is it that it will do what it is meant to do?
    – Matt Ellen
    Commented Jan 26, 2011 at 8:43
  • We're talking about personal projects here. Of course, if we consider nuclear-missile-controlling software, no code IS better than bad code.
    – Nevermind
    Commented Jan 26, 2011 at 9:18
  • @Matt - depends on how badly written it really is. IMO almost all real-world code smells to a degree, and ivory towers don't react well to change (one of the problems with too much data hiding and too many layers of abstraction). Experience really is the only solution, though there's a good reason why the standard rules are taught of course. The main experience thing is less knowing the rules, and more knowing when and how to break them. As for learning the rules - I've been a programmer for nearly 30 years now, including child hobby stuff, and I still learn new stuff all the time.
    – user8709
    Commented Jan 26, 2011 at 9:27
  • @Steve314: Yes, I agree, hence my caveat about doing what it should do. You can't learn to code without out coding, as you've pointed out, and when working on personal projects to gain an understanding of basics, or more advanced topics, I think it is important to think about what you are trying to achieve, rather than rush in and start coding. A little bit of design can go a long way, because, as I'm sure you know, programming isn't just about coding.
    – Matt Ellen
    Commented Jan 26, 2011 at 9:42

This is a common problem with beginning programmers. Dont paralyze yourself by thinking everything has to be perfect. Thats the surest way to never finish a project. One of the most important skills to learn as a developer is the difference between perfect and good enough. Accept that every system you create can be improved upon. Focus on finishing your projects. After you finish, you can go back and improve on them. Thats why we have version 2.0's, after all.

  • Good call! Knowing that something could have been better is a good start.
    – ozz
    Commented Jan 26, 2011 at 9:18

Am I supposed to try and learn a little bit of everything at once?

I hope not. On the other hand, you should be learning and improving the whole time.

Read books, take courses, get qualified, work at it, and you should improve.


My best advice is to focus on the fundamentals such as the list Robert Harvey suggested. Software development is a complex monster that takes years to even get remotely good at, especially in the topic of good interface design. It is really hard to appreciate many aspect of software development without first experiencing them. Even something as basic as commenting code can be under appreciated. From day one, you are taught to write well documented code. I'll admit that it wasn't until I was really bit in a$$ attempting understand code that I wrote months ago before I truly appreciated the value of good comments. The same can be said for many programing concepts. For example, data encapsulation, low coupled modules and crisp clean interfaces.

The most valuable resource that I have encounter is my co-workers. You are going to bad write code. Just accept that. It is what you do to make sure that you write better code over time that defines you as a programmer. For example, when I first started working, my company didn't have any sort of formal code or design review procedures. I took it upon myself to subject my work to the criticism of my more senior co-workers and to be honest, I felt like an idiot for better part of my first year working.

Software development is an on going learning experience. Ask tons of questions, have your code reviewed, understand the why's of the suggestions more senior people give, don't be afraid to questions the validity of the suggestions more senior developers give and most of all don't be afraid to be wrong. Eventually the intimation factor or sense of being overwhelmed fads. For the record...learning curves suck.

  • First: Refactoring (it will still smell but will be a little more organized)
  • Second: See if you can use some Design Patter to make the refactored pieces match your logic.
  • Third: when things start looking better, remember the time you spent doing the first and second step. This way when you write some new feature, you'll think about then while your doing it and not as another process.

Take a look at the book Refactoring: Improving The Design Of Existing Code, by Martin Fowler. The first thing you should do is refactor your code, in order to improve code readability and reduce complexity to improve the maintability of it.

When you refactor your code, you're already using Design Patterns, Encapsulating code, etc.

This is one of the best books I've ever read about this topic. It provides lots of useful recipes.


A good resource is The Pragmatic Programmer. The chapter on "Broken Windows" describes where you see yourself. The short and pithy response is to fix the problems.

When you start fixing your design, it helps to understand what you don't like about it. It's easy to come up with the vague answers like "it just goes all over the place" or "why did I do that there?". But take the time to see if there are any common patterns that you used.

  • Good design will reuse a small number of concepts throughout the codebase (the ideal is one concept, but in practice you may need a couple more)
  • A good design will make it easy to figure out where to fix problems (DRY principle, SRP principle)
  • A good design will have good error reporting (related to the point above, but called out as a separate item because it is an often overlooked aspect)

Once you figure out where you want to go, take small, easily reversable steps to get there (i.e. this is what Refactoring is about). Every time you improve your code, consider the impact on the rest of the code. Did you make things better or worse? This at least is my approach to bringing order to chaos.


If you already have some experience in programming, why don't you study some open source projects that have clean code? You could look into THIS question from SO which has some relevant links.

Also, design patterns is a must know -- think about it, the whole idea of having patterns is to solve known problems without re-inventing the wheel or writing buggy code.

Finally, looks like you need some dose of functional programming to clear your head. Look into Haskell or Ocaml for a start.


If you're not a dangerous monster, you should find a so-called friend, who can review your code, and vice versa. Also, if you making things, which will be revisited, or just overseen by others, it's a good pression to do it better way.

And don't forget, programming begins before coding, always revisit your ideas, plans. If your plan is bad, it's a joyful act to throw it out: you have just saved the frustration of throwing out a bunch of code (and the time of its creation) based on a bad plan.


My advice is take each of the smells seriously and try to fix it. There are many good books on the topic (Clean code and GOOS are the best IMHO). But more than books go to conferences to hear and discuss with other people and on online comunities (mailing list, groups). Still better try to join your local xxug (dotnetug, jug, xpug, etc.) or found one.

Discuss with other programmers is the only way I know to really improve (unless you're luckily enough to work together with other dedicated programmers).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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