views:

192

answers:

7

I have been doing code for a few years and still feeling that my knowledge still not broad enough to become a professional. I have studied some books related to Design Pattern but I know there are many others.

So could anyone list the one which you think it is good to learn to become a better programmer and more professional?

Programming Languages I work on : C# , Ruby, Javascript

+1  A: 

I think the best way is to learn plenty of language. LISP, Scheme, Python, Smalltalk, Erlang, Prolog, Eiffel and many others

And build stuff with them.

mathk
+7  A: 

Encyclopedic knowledge of design patterns will get you nowhere. Plenty of experience applying them will. This will teach you when to use them and when not to.

That said, the original Design Patterns book is still one of my favorites. Pick up other patterns as you go along.

Mark Seemann
*and when not to* - definitely the most important thing to remember. A lot of people seems to go patterns crazy at first and tries to make everything into patterns, sometimes making very easy code much more complex for no gain what so ever.
ho1
@ho1 +1, To true! "To a hammer, everything looks like a nail".
Adrian K
+3  A: 
Mr Roys
Thanks Mr Roys, any suggestion books for what you list?
pang
I find the Pragmatic Bookshelf series very useful - http://pragprog.com/titles. As most in the series are quite short, they make good introductory texts too :) I believe there are quite a few posts on good books in SO, I'll try to find them and then edit the answer.
Mr Roys
A: 

Martin Fowler's Patterns of Enterprise Application Architecture to build up a shared vocabulary with other developers (e.g. Repository, Active Record, Domain Model, Unit of Work).

Douglas Crockford's Javascript: The Good Parts to actually understand how Javascript works.

And I'd really recommend getting into TDD (Test Driven Development). There are a bunch of good TDD books but if you are doing brownfield development (which most of us are) then I'd really recommend Michael Feather's Working Effectively with Legacy Code.

And finally the book that shows you just how refactored and clean code can be: Uncle Bob's Clean Code.

Daniel Lee
A: 

In addition to writing code you should also try reading code. For example, download code from open source projects, try to tinker with it and understand what it's doing and why. Or try reviewing your own code from a previous project. What would you do differently now? Can you still understand why you built it the way you did?

You may also want to look into some of the practices that have come out of the agile community. Especially Test Driven Development comes to mind as a great way to improve the quality of your code.

Marnix van Valen
+3  A: 

The principles is where I'd start, with the patterns being a close second.

Principles: There's a whole raft, but these are the ones I get practical mileage from:

A lot of these (when grouped together) are known as SOLID (object-oriented design).

Patterns:

  • My biggets favourite by a mile is the Dependency Inversion Principle (DIP), also commonly known as (or at least very similar to) Inversion of control (IoC). It's really good for abstracting out data access implementations behind interfaces. Martin Fowler calls it a different name (sorry don't have my copy of 'Patterns of Enterprise Application Architecture' in front of me).
  • Lazy Load is also useful.
  • Factory pattern is a very well known one - for good reason.
  • Facade pattern has also helped me keep out of trouble.

Wikipedia has a pretty good list of Software design patterns, assuming you haven't seen it yet.

A final thing to keep in mind is that there are three basic types of patterns (plus a fourth category for multi-threaded / concurrency); it can help just to know about these categories and to bear them in mind when you're doing something, they are:

  • Creational
  • Structural
  • Behavioral
Adrian K
I think Martin Fowler calls DIP as Dependency Injection (DI). http://en.wikipedia.org/wiki/Dependency_injection
Mr Roys
+2  A: 

Mastering tools (e.g. programming paradigms, patterns, source control, unit tests...) is essential, but it's not enough to call yourself a "professional": IMHO, the mark of a truly professional programmer is the ability to understand what her client needs. Unfortunately, this kind of knowledge is very hard to learn from a book.

nikie