I'm searching for articles, blogs, books etc. for a while now but all I can find are some articles about "girl code". I read the book Code Craft, Beautiful Code and I also want to order Code Complete. I read a lot about design patterns as well and of course I'm programming a lot in my job as a programmer as well as in my spare time (and during my studies in business informatics).

Can you recommend a few links, books or do you have any other tips how I can improve my programming skills?

+2  A: 

There is a pretty cool wiki about different programming methods here, stuff like Extreme Programming, pattern matching etc..:

It's pretty entertaining

"a pretty cool wiki"? That's Ward Cunningham's wiki. He invented wikis.
Kristopher Johnson
+2  A: 

The more time I spend on this site, the more I am tempted to say: by reading other's posts on

I suggest you check out some topics here about good design pattern books.

petr k.
+11  A: 

Read The Pragmatic Programmer by Andy Hunt and Dave Thomas.

Well worth it!

Watch Dave's talk over at InfoQ and take heed of what he says about keeping your skill set up to date.

Rob Wells
Agreed! One of the best books I have read about general programming
+2  A: 

Visit and join!

Their journals (C Vu and Overload) cover loads of topics of relevance. Their book reviews are unbiased and well informed. Their mailing lists are full of interesting items. Oh, and they also run "mentored developer" programmes for members.

Seb Rose

You can read the answers from this question from a while ago.

+1  A: 

Beyond trial and error, you can try checking out examples from other programmers (open source is a biggie here).

Scott Hanselman has a blog where he regularly deconstructs interesting code. (

Another suggestion would be to find an experienced mentor, or even do some mentoring of your own. It is amazing how much you can learn when you are teaching somebody else.

Rob Hunter

One way you could do it is to study an opinionated framework like Ruby on Rails. This could be like a case study. You have programmers who have made decisions based on solid design principles. I would suggest taking single decisions on Rails design and then asking "Why?". For example, why follow the MVC pattern? What are it's advantages, what are the disadvantages? What type of software projects does it work best for? etc.

Dan Harper - Leopard CRM

I suggest you to read code of other people (not just your co-workers). Go to'>source forge, pick some random (small) project and try to read/understand it. When you see some crapy code that you need hours to understand, then you know what not to do.
See your own old code also.


Read The Pragmatic Programmer. An eye-opening book.

A general tip: practice. I know it sounds boring and trivial, but it's the best way. You will encounter real problems you will have motivation to solve, and will test your own solutions in real life. You will probably have to maintain your code, which will give you very needed range of skills. You may even start an open-source project and learn how to collaborate in this environment. Witch a bit of luck it can be very rewarding. Good luck.


In addition to the 'Code Complete' I would recommend another book by the same author - 'Rapid Development'. To able to understand the principles of development better will really help to become a better programmer.

Ilya Kochetov
+1  A: 

Find an Open Source project that you use/are interested in and search for one of their open bugs. Fix it and repeat. The exposure to multiple programming languages, multiple coding styles, multiple mistakes, etc. is much more enlightening than reading a dry text ... not that you should avoid the texts, but this type of immersive experience is a good way to see the reasons behind the lessons of a text and to actually understand their import. And if you contribute your solution back to the community, then you have helped an Open Source project advance as well.


The pragmatic programmer was an excellent book, and I highly recommend it. I also agree with practicing. Jump into something new that you've never tried before, watch the training videos that are out there for it, read through samples, come up with a simple program and try it out. I'm currently learning Silverlight now and although it gets frustrating at times, it is very cool to jumping into a new language without much background on it.

So yeah... practice, practice, practice.

+3  A: 

Look at the list of skills and competencies in the Programmer Competency Matrix, and work to learn the ones you don't know.

Gregg Lind

Seek out projects that are very different than ones you work on, and learn how to solve them. If you know procedural programming, play with a functional language. If you do text processing, try writing a simple socket server. Look for projects that will stretch you.

Gregg Lind

Simple: never stop learning - and understand what you learn !

Iulian Şerbănoiu

I have to recommend the book I'm currently reading: Refactoring: Improving the Design of Existing Code by Martin Fowler.

A great free magazine is RedmondDeveloperNews.


I'd recommend that you sign up to the Freshmeat daily newsletter. That has indeed increased my productivity. You'll discover other peoples libs and probably try some of them in your own projects, or perhaps by contributing to them with your own bugfixes or changes.

Jonas Gulle
+19  A: 

Write more code

I think that answer that consist only of link should be a comment, not a real answer.
Kirill V. Lyadvinsky
But if it's a comment, then it's not an answer. Just because the answer is only a link (with an admittedly very short description of the article), does not mean that it is not an answer.
+5  A: 

I find reading stackoverflow questions that I don't have idea how to solve -or about things I've wondered before but was afraid to ask- a very healthy exercise.

victor hugo
+11  A: 

While I am in no way senior, my routine includes using Google Reader loaded with some of the most prominent blogs for my current primary technology, reading Hacker News, solving problems on Project Euler, and taking problems that I encounter in the wild and try to solve them with some new or different technology. I also try to program in many different paradigms to get a wider basis for problem solving. Smalltalk style OOP and functional programming have probably been the most interesting for how they influence how I use other languages.

Also, work life balance is important. Being an entity of pure code is a poor idea and is only harmful to the quality of output.

Ben Hughes
"Also, work life balance is important. Being an entity of pure code is a poor idea and is only harmful to the quality of output." Could you elaborate? Do you mean being coding all the time even at home? I must admit, I am guilty of that. I code at work and then write the code I want to at home ... yeah the wife gets a little mad at me at times, but I really enjoy the freedom/creativity I find in coding.
"Project Euler" Thx for that! I registered, looks like fun!
It's common, especially for good programmers, for coding to be both a job and a hobby. This is good and necessary to an extent, but it is very easy to be overwhelmed by it. This can lead to burnout, unhappiness, and diminished problem solving ability. You should program for fun, but just balance it with nontechnical pursuits.
Ben Hughes
I second Project Euler, it is a great way to learn a new language.
Wow! Project Euler, I think I'll spend less free time in SO
victor hugo
+8  A: 

In addition to reading SO as Victor Hugo suggested, I read a lot of "best practices" or "style" books, such as:

  • Code Complete
  • The Pragmatic Programmer
  • The Practice of Programming
  • About Face
  • Design Patterns: Elements of Reuseable Object-Oriented Software (a.k.a. Gang of Four book)
  • Head First Design Patterns (Probably should read this first and then read the Gang of Four book for the nitty-gritty)

And even language-specific ones can be helpful, even the ones I disagree with their practices because it gives me deeper insight into the language and how others use it.

  • Effective C++/More Effective C++ (great books)
  • CLR via C# (not so much a style book, but gives great insight into how the CLR was designed)
  • Effective C#/More Effective C# (only agree with some of it)
Great references!! I actually have two of the ones you mentioned: Code complete and design patterns (a.k.a. the gang of four) I will look into the other ones you mentioned. Thx!
Actually, if you like the Gang of Four book, I'd strongly recommend "Head First Design Patterns" as a more understandable and accessible take on the subject. Edited to add it.
Very good references. I think he is refering to resources for a diary or periodical reading though
victor hugo
+1  A: 

code, code, code, read as much opensource code as possible, github is your friend here. Participate in irc channels and when it's all become overwhelming, go to the beach, crack open a brew, and soak in as much bikini clad women as possible ( and if your a gal, feast on those men with the beautiful abs!)

Unfortunately, I have yet to learn how to "let go of work" sometimes I'll be out and about with my family doing something fun and then the problem I am working on creeps back in... ack!
yes I know, but sometimes that when a solution finally materializes!
+2  A: 

Don't limit yourself in what you learn.

Keep going deeper and wider - learning more about things you know, as well as learning about new things.

There are lots of different programming tools - languages, concepts, software, etc.

Learn as many tools as you can. Work out when each tool is for, and most importantly when a problem requires a different tool.

For learning, try different techniques to determine what works best for you - some people like books, others prefer blogs, some like listening to podcasts, others prefer conferences - figure out which ones you prefer, and dive right in. But don't forget to experiment and use what you find. :)

Oh, and don't blindly believe anything a programmer tells you ('senior' or otherwise), without trying it out for yourself, and deciding if you agree.

Peter Boughton
+2  A: 

I like that analogy. What I find helpful is to spend some time solving already solved problems (yep... Project Euler is a great place to start.) Inventing your own way of doing things and then seeing (usually) why it's wrong/inefficient is how you get better as opposed to just reading about the right approach in a book.

Coding, like martial arts, is not rigid. Like Bruce Lee said, you want to flow like water. You want your approaches to adjust to the problem at hand. You don't want to just have a grab bag of rigidly defined ways of solving specific problems.

And of course, programming isn't just about solving problems. One skill that isn't talked about much is designing models. Being able to figure out how you can map your tool-set of data structures to a real life problem is invaluable. The only way to get better at that is to broaden the fields you write applications for. Write a numerical integrator this week. Next week, make a simple database engine.


Change projects as often as possible, and don't feel bad about it. You always learn something new with every new project. Unfortunately it might take you few projects to start making something useful, and not waste your employers money. :)

+6  A: 

A few ideas:

  • Surround. Take on tasks where you are surrounded by people from whom you can learn.
  • Immerse. Challenge yourself with extracurricular activities (dancing, board games, musical instrument).
  • Contribute. Get involved with open source projects.
  • Study. No artist stands alone.
  • Read Websites. Technical websites are a great way to see how people are solving problems.
  • Read Books. Many great books have been listed in this thread. Read them.


By far the easiest way to hone your skills is to put yourself in an environment where other people around you raise the bar of expectations. Not only will you get challenged throughout the day, but you will also be exposed to different ways of approaching problems -- both specific and general.

As well, you will be introduced to technologies that you might not have investigated on your own.


Adopt hobbies that challenge your imagination. The brain's right side sees the "big picture", so exercise the right side of your brain to enhance lateral thinking.


It is not always possible to find a job where you are surrounded by gurus. However, there are many open source projects that have genius++ software developers working on them. A great quality of the people who work on open source projects is that they are not afraid of telling you when an idea is bunk. Plus, they are often eager to illuminate alternatives that you might not have thought of yourself. (This is from my own experience, YMMV.)


Study the techniques of great programmers. See how they approach problems and what tools they used to solve them. Using the most appropriate tool for the task can mean the difference between a project being completed, or a project dying due to insurmountable technical hurdles.

Read Websites

A number of technical websites abound. In no particular order:

If you enjoy any others, do post them!

Dave Jarvis
+1  A: 

Regularly read other people's source code to become a better developer. Scott Hanselman writing regular posts on this subject that points developers to good source code.

I just checked out the site! Awesome thx! This kind of reminds me of chess where I would review alot of played games to see how they did and the strategies that were used behind each move.
+5  A: 

Learn weird languages. Many less popular but actively developed languages center around concepts that seem strange to programmers with a more mainstream background. Some things that come to mind are:

  • pervasive immutability (Haskell, Clojure, Erlang)
  • code as data (anything in the Lisp family)
  • monads (Haskell)
  • prototypes (Self, Javascript)
  • message-passing/actor model (Erlang and maybe Smalltalk)
  • multimethods (Common Lisp, Dylan, Clojure)

Many programmers find that a deep understanding of concepts like these helps them design programs no matter what languages they're using. Of course, it sometimes comes with the downside of causing frustration with whatever mainstream language external requirements are forcing you to use.

I never thought about what you are suggesting. Great idea!
Continuations as in scheme and coroutines as in lua
Tadeusz A. Kadłubowski
+2  A: 

Practice abstraction in all its forms and ignore all the buzzwords and latest fads. Programming at its core is the process of creating useful abstractions. Most programmers think it's twiddling bits.

+1  A: 

All of the answers posted so far share the same theme, and it is the underlying principle for becoming a great programmer: an unquenchable thirst for knowledge. So my answer to your question is, never stop learning.

Our profession is ever-changing. For the vast majority of people, that single fact is terrifying. Constantly having to learn a new technology or technique leaves most mere mortals quaking. For those of us who sincerely love being a software developer, it's exactly this constant, pervasive metamorphosis that interests us.

Aside from being persistently autodidactic, I suggest the following:

  1. Code - a lot;
  2. Read code from acknowledged experts (see Jon Skeet) ;-)
  3. Read some of the aforementioned books. I could suggest some but you really need to find those that suit you. There are plenty of lists ripe for Googling;
  4. Goto 1 (this use of Goto authorized by Dijkstra (look him up))

Enjoy writing code. See it for the creative pursuit that it really is. Live long and prosper.

Bob Mc

Scott gu says ... For learn develop in c#, try a new language feature every day.

I develop my personal framework based on framework 2.0 and c# with this i learned c# at beginning i don't know c# only, actually in don't develop only support my, stepping to c#. Implement your own classes and you learn a lot. With me resulted.


Learn to always ask yourself, "How could things be better?"

When you make mistakes, don't ignore them. Think about what you could have done differently to avoid the problem. This ranges from little mistakes to big ones. When you find a bug in your code, think about how you could avoid that type of bug in the future. I don't mean in the simple sense of telling yourself to "watch out for fence-post errors." Rather, are there coding practices or testing practice you could adopt that would automatically avoid those errors, or bring them to light quickly. The book "Writing Solid Code" has lots of examples of this type of thinking.

But this applies beyond programming. Senior engineer usually need to do more than just write code. They have to be able to mentor and make decisions and recommendations in the context of the companies larger business needs, and so forth. So think about these "big picture" issues too. If you feel like your company makes it hard for junior programmers to figure out how to do something, then ask yourself how to fix that. If you interview somebody and like them, and they turn out to be a bozo, ask yourself what you should have done differently in the interview.

And do likewise with what everyone else is doing around you. If the build process is too slow, don't just grumble about it, figure out how to make it better, even if it's not your job---this could range from actually doing it to learning more about it so you can make useful suggestions to the people who own it. If you don't like or don't understand what your managers or executives are doing, ask yourself what you'd do differently.

Don't be afraid to ask your peers these questions. I find these types of questions great fodder for lunchtime conversations and it's a great way to learn from other people's experience.

Keith Smith

Privately tell your manager you wish to improve your skills and can you please be assigned to projects with the top developers in your group.

Purchase and read and highlight your own books. Keep them on your desk and refer to them.

Start proper code reviews in your team. Proper code reviews are not 'showing your code to the whole team' but rather, having one other coder examine your code and vice versa on a regular basis. 'Sifting trough' combinations of coders examining their code brings a lot of new perspective to your team and to yourself.

Seek out resources that discuss better coding practices and standards. Code Complete by Steve McConnell, and Clean Code by Robert C. Martin are excellent resources.

Beware that business value should always trump design elegance in coding and architecture, anything else is a form of suboptimization.

Finally, if you really want to become more valuable to your company ask you manager how they get bonused and make that your goal. You will get your managers attention if you do that!

+1  A: 

learn ,unlearn and relearn

Now what is that supposed to mean?
its just not a catch it , u can know what does it mean.

Don't take the easy way out.

When you find yourself thinking, "I should really rewrite this to handle other cases than just this one" or "I should really implement error logging" - do it. Don't say, "I'll do that for version 1.1."

You'll learn valuable lessons by forcing yourself to do things correctly.

In the same vein, when you finish with a function, look it over closely and see if it can be re-factored. Does it do just one thing? Does it do it well? Until you get experience, 90% of the time, the answer to both will be "no." Don't give into the temptation to go onto the "DrawFlashyStuff()" routine because it sounds more fun to write. Take the time to refactor this one.

Wade Williams

Josh has linked to a piece by Jeff Atwood called Quantity Always Trumps Quality, which extols the benefits of learning through just doing it.

Jeff wrote another great article (in fact he has written many) entitled How To Become a Better Programmer by Not Programming. Money quote:

You won't-- you cannot-- become a better programmer through sheer force of programming alone. You can only complement and enhance your existing programming skills by branching out. Learn about your users. Learn about the industry. Learn about your business.

In short, writing more code is necessary but not sufficient.

+1  A: 

There is no one thing that can make you a better programmer, it comes from experience. There are books and articles which can point you in the right direction, but it always comes back to experience.

The best way to get experience is to (in no particular order):

  • get a programming job
  • read books and do the tasks they advise you to do
  • write random personal projects
  • go to university

And the best part: rinse and repeat :)

Some SO Questions about programming books ...


The key is maintaining your interest. You're super keen right now, which is great, but will you still be interested in 4 years? 10 years? 15?

Everyone goes through periods of drought, but if you maintain interest, that's the most important thing. Keep learning and learning.


A good coding is RELATIVE. Depends on requirements.

Avoide HardCoding is a good practice. But in some cases HardCoding becomes helpful.

Normalization is mandatory. But Some times it may not me practical.

We will become better programmer day by day through 1,Experiences 2,Books 3,This sort of Communities...

Happy Coding.........

+3  A: 

Get a Job! (of course programming related)

There is no better way to learn the languages and all that code writing philosophy then to work with a real projects. Many companies are hiring for a junior developer jobs. If you will work in a team, then you will also get many help and experience from it's members.

No way... In a job you are working in a team, using team patterns, team standards... Thats a real lesson!
sorry, accidentally I deleted my comment. yes, you are right. I agree...
Ł is right. In a real jab you will be restricted to learning what the team(leader) tells you. And in today's day an age this is strongly influenced by the bean counters. Like: we use Java because Java programmers are easiest to hire.
And the down vote is for?
I didn't down vote:
@x86shadow, nice proof you've got there.
I'm not asking you... I'm asking person who down voted :D
:D no problem. anyway, you gave a good answer
Haha.. I wish you good luck in your way of a professional developer ;)
  • Read books
  • Read code
  • Get your code reviewed

But most important, write lots of code for as many real life scenarios as you can.

+5  A: 

IMHO, the first thing to understand is that we're all different. So there is no "best way" for all of us, just an individual best way. This means: You must examine how you learn things and then apply that pattern.

Personally, I apply three patterns. First, I have a broad range of interests which allows me to look for similar problems and their solutions and apply them.

Then I like to look through existing code and improve that. Software development is one of the rare engineering arts where we don't study great works of the past which is a shame. There is so much to learn from the mistakes and successes of others.

Lastly, I'm not afraid to make mistakes. The day when a production system fails because of something you did and you can face this, you can be proud. After fixing the issue, of course.

Aaron Digulla
+1 for `I'm not afraid to make mistakes.`
this. __curious_geek
+1  A: 
  1. Practice practice practice

  2. Interacting with other programmers and learning from existing code

  3. Learning other languages (broadens the mind)

Anders K.
+1  A: 

The most important thing is the sentiment.

It determines the learning skills.

In my opinion that is starting a great project with the ambition that it does something important (you choose what features) using the language you have chosen and you will learn your programming language properly.

+1  A: 

For book I recommend reading book from the pragmatic programming series rather than teach yourself programming book.

For best practices, read book on design patterns and if you are C# programmer you can start reading series of books/articles published by the Micrsoft Pattern and Practice group

Other than that, I will just advice practicing, find project that interest you in codeplex and download some of them and use it to learn about how others approach the design and code

Fadrian Sudaman

I think writing proper Code and writing Proper logic are 2 different steps in learning proper Coding.

  1. Trying for learning Logic.
  2. Read some good Book.
  3. Practice a lot.
  4. Practice a lot.