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?
There is a pretty cool wiki about different programming methods here, stuff like Extreme Programming, pattern matching etc..:
http://c2.com/cgi-bin/wiki?ExtremeProgrammingRoadmap
It's pretty entertaining
The more time I spend on this site, the more I am tempted to say: by reading other's posts on stackoverflow.com.
I suggest you check out some topics here about good design pattern books.
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.
Visit www.accu.org 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.
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. (http://www.hanselman.com/blog/CategoryView.aspx?category=Source+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.
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.
I suggest you to read code of other people (not just your co-workers). Go to http://sourceforge.net/index.php'>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.
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.
Look at the list of skills and competencies in the Programmer Competency Matrix, and work to learn the ones you don't know.
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.
Simple: never stop learning - and understand what you learn !
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.
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.
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.
In addition to reading SO as Victor Hugo suggested, I read a lot of "best practices" or "style" books, such as:
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.
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!)
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.
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. :)
A few ideas:
Surround
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.
Immerse
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.
Contribute
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
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!
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.
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:
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.
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:
Enjoy writing code. See it for the creative pursuit that it really is. Live long and prosper.
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 vb.net, actually in don't develop only support my vb.net, 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.
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!
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.
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.
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):
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.........
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.
But most important, write lots of code for as many real life scenarios as you can.
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.
Practice practice practice
Interacting with other programmers and learning from existing code
Learning other languages (broadens the mind)
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.
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
I think writing proper Code and writing Proper logic are 2 different steps in learning proper Coding.