I think this is a very positive sign of your skills. It is far more common for people who have difficulty coming up with the ‘better’ design in a team to be completely incapable of recognizing why another design is better.

You have two really great (and surprisingly uncommon) strengths going for you:

• You are capable of assessing your designs against others objectively
• You have the desire and put forth effort to make your designs optimal

You’re only a couple years in and have a long way to go, but with this attitude you will definitely get there, just don’t give up; we all deal with mental set backs like this. As often as I get a chance I like to plug Design Principles (NOT the same as design patterns) and I think this is a perfect example of where they come in handy. Study them and practice applying them in your designs, you will before you know it have taken another step forward in this regard.

At the end of the day remember, designing is hard. We’re dealing with complex high level abstractions every day, to create these from thin air, have them work well, and easy to use by colleagues is an extremely difficult task. It takes practice, for years.

So chin up and just remember: there’s a bunch of folks out there who can’t assess two designs and actually recognize one as preferable over another, how well do you think they’re getting along in creating good designs?

Edit:
‘nother tip, after getting your head around principles and practicing their application a bit, I think there is another gem from another question here speaking to the value of studying a variety of languages which have different purposes and rules:

Ideally, every programmer should know a language from each class. What could you learn:

1. A static typed OOP mainstream language: Java, C# (mostly used in enterprise software) and C++ (system programming and complex desktop applications)
2. A prototype-based OOP language: Javascript (client side web programming)
3. A procedural language: C (embedded software and system programming)
4. A functional language: Haskell, ML or Lisp (functional languages are good for highly parallelized software).

A logic programming language (Prolog) probably is not that useful in industry, being used mostly in research in AI.

This will help to broaden the variety of ideas that come to mind when trying to design a solution.

1. This is absolutely normal for multiple people to come up with designs of different quality. I have been invited in the past to judge competitions in software design, so I witnessed this firsthand: even the simplest designs resulted in solutions of drastically different quality, all coming from smart and experienced people.
2. Reading source code is too low-level to help you improve your design skills: code addresses complexity at the lower level than the overall design.

The best way to improve at designing software is to design software^*. One way to do it is by looking at design competitions: TopCoder has an archive of 100+ component designs, complete with UML design documentation and implementations in Java and/or C#. Pick up a finished component that you like, read the requirements specification, and try to come up with an original design to fulfill the requirements. Spend an hour or two thinking about the problem and sketching a class diagram, then open the winning design, and read what the author did. Compare his design to yours, spot the differences, and see if your design is better. Check the competition scorecard to see how judges rated the design. This will give you the feedback that you need to decide how to improve your design skills.

^* This applies to things other than designing software: do something many times with a qualified feedback, pay attention to what they say, – and you will get better at whatever you are doing.

Well don’t quit your job. It is better to be working with someone who has better skills than you do, so that you can learn from him or her.

Look at the better design and determine why it is better. LEarn from the accepted design and think about ways where you could apply a simliar design in other situations. Once you know why it is better than your design, then you know what mistatke not to make the next time you do a design. Talk to the other developer and ask how he came up with the design.

To improve design skills, the best thing to do is to create designs, then be brutal with yourself in evaluating them and determining how they can be improved. Ask yourself questions like: Will it work and does it meet the requirement in all aspects, is it maintainable, how will I be able to test this, will it cause performance issues, how likely is the requirement to change and how well will the design be able to handle change. Read about design patterns and then try to apply them to your designs. Refactor mercilessly after coming up with an intial design. If you are designing a database along with the application, read extensively about normalization and performance tuning the db, you will learn much about database design if you learn how to make a database work most effectively and efficiently. For applications think about DRY and SOLID principles in doing your design. Read about antipatterns to knwo what things to avoid doing.

Recognizing a better design is an important ability. You should foster this as you follow some of the earlier suggestions regarding looking at designs.

On what criteria did you judge the other design better? Was it simpler and easier to understand? Did it provide a performance advantage? Was it more extensible? There are many design principles such as decomposition, abstraction, information hiding, and component modularity which you can use to judge designs and which you might already recognize.

• Try to name your criteria, understand them, expand them and reuse them as you look at other designs. When you design things yourself, make it part of your process to use those criteria and consciously measure your designs against them. Then, be prepared to completely modify or throw out your design if it doesn’t meet your criteria.

You will get ideas on different principles for designs from some of the following sources:
http://www.cs.wustl.edu/~schmidt/PDF/design-principles4.pdf
Software Design on wikipedia
Google “Software design principles”

• Understand different models for software design, such as Object Oriented Design or Functional Design or Structured Analysis Design. These can be entirely different mindsets from which to approach a design task and they each have areas where they excel. Learn these as tools for your toolbox. http://userpages.umbc.edu/~khoo/survey2.html

• Make sure you are separating design from implementation, try to diagram things you see as good designs, to separate the language and implementation specifics from the higher-level design principles. And to develop your “design eye” and communication abilities.

• Last, but perhaps most importantly, reading widely is a very good tool – there are many interesting things from Fractals to Bayesian analysis to Fuzzy Logic to Natural Language Processing, which can provide fodder for ideas which will emerge later and unexpectedly. With the web you can peruse topics far and wide, just for your amusement and edification and it will benefit. You don’t need to become expert, just familiar with terms and ideas.

Have some fun – don’t do it if you don’t enjoy it at least a little!

Well, you’ve already taken the first step. You admit that you have something to learn, that your colleague’s work is better than yours, and you want to learn and improve.

The second step is to analyze. Look at his work and don’t just say that it’s better; figure out why it’s better. Look for specific details and points that he did better.

Once you understand that, extract the principles behind it. Ask questions like these:

• What about this design is better than my design?
• Is this point something specific to this design, or is it a general principle that could be applied to other designs in the future?
• If it’s a general principle, what are its limits? When is it a good idea not to do things this way? (This one is very important. It keeps you from treating some useful idea as a golden hammer, even in inappropriate cases.)

Try to figure things out on your own, because you’ll internalize the ideas better if you came up with the chain of reasoning that led you to the conclusion yourself, but also talk with your co-worker to make sure you’re getting things right. (You don’t want to go making mistakes in your reasoning and internalizing a bad principle, afterall.) And feel free to ask your coworker for help if you can’t figure things out. Programming is a discipline where humility tends to be respected, and a lot of coders will jump at the chance to teach someone something new, which is probably a big part of why StackOverflow got so big so fast.

I’d also like to add (in addition to the great answers) that there is more to it than “He can create a better design than me”. The other answers focus on how you can get better at Design, which is all and good… but…

I bet money that YOU can do something better than your co-worker. Not to create a pissing match or anything (You can do Y better? Screw you, I can do X better!), but to point out the truth that everyone has strengths and weaknesses.

At my job there are 4 developers. There are times where the two main “programmers” can create stuff that just leaves me in the dust. Makes my head spin trying to wrap my head around their creations.

But I’m much better at SQL and command-line scripting than they are, and can automate stuff that leaves THEM in the dust.

Are they better than me? In some area’s definitely. Hell, in a lot of area’s they are – I am the junior developer at my shop by far and individually they have years of experience on me. Despite those years of experience, I am better in some area’s than even they are.

Stop focusing on the fact that someone is better at X than you are. That person, without trying or even thinking about it, might be able to out-design you even after you practice at it for the next 10 years. Not that you shouldn’t work on fixing your weaknesses at all, but remember than for every strength there is a weakness.

Focus on both – Strengths and weaknesses – of you and your co-workers.

In every aspect of life you will find people who is not as good as you, as well as people who is better than you, especially after just “a couple of years” of experience.

You have to learn from everyone.

Don’t feel bad. Maybe you colleague is a natural. You should congratulate him sincerely and learn as much as you can from him.

Don’t let professional jealously get between you and an oportunity to learn.

1. A couple of years is really not that much. And than there are people with better or worst high level design views. For example I’ve known people capable of writing complex algorithm for low level programs in a blink of an eye but incapable of understanding higher level design and concepts like cohesion and dependencies. However this is not a de-facto state. Both you can get better at higher level design (read a few books, try a few tricks at home, etc) and also you may discover that at other areas of programming your fellow programmer is less good.
   Also, if you think you are about the same level both in experience and techincal knowledge, this may have had bean a random situation. Next time maybe you have better design ideas. Also, instead of quiting your job, take this opportunity and learn from your colleague. Next time, do a design together, try to catch his secrets, his thoughts. Programming is like a craft, it’s learned by doing and watching others do it.

2. Design skills mostly come with experience and after you read a few important books. I would recommend you the followings:

   • Robert C. Marting – Agile Principles, Patterns and Practices (there are 2 versions, one in Java and one in C#. It doesn’t matter which one you pick, the ideas and principles can be applied to any object oriented – and not only – source code)
   • Than, Robert C. Marting has 2 other interesting books: Clean Code and The Clean Coder
   • Even if Martin covers all the modern design patterns in his first book, you want to look up the original design patterns book by the Gang of Four.
   • Finally, there are other books that are highly prised today: Growing Object Oriented Software Guided by Tests, or Refactoring by M. Feathers (I think), or Writing Effective Use Cases by A. Cockburn and few more you will discover on the way.

None of these books is a magic bullet, but reading the first 2 recommendations will probably change your view and perception about programming forever.

Don’t let it get to you. If you have years of experience fixing bugs and making small programs, that’s what you’ll excel at. Your co-worker probably has years of experience designing larger projects.

Being familiar with the underlying bits is incredibly handy, but if you want to get better at design, you’ll have to design a few projects. Repeat until the skill sinks in.

In short, “years of experience” is not always equivalent. Go make your years worth something.

“Getting better” often implies measuring your designs or code against something/someone better, carefully comparing what’s different, learning from those differences, and continually trying to improve your future designs based on that. Feeling too badly about finding out that you need to learn more will slow down this beneficial process. If you move to someplace where there aren’t people (or other resources) who can sometimes or always provide you with a better comparison, you may lose this opportunity to learn and slow down your process of betting better.