Looking back at my career and life as a programmer, there were plenty of different ways I improved my programming skills - reading code, writing code, reading books, listening to podcasts, watching screencasts and more.

My question is: What is the most effective thing you have done that improved your programming skills? What would you recommend to others that want to improve?

I do expect varied answers here and no single "one size fits all" answer - I would like to know what worked for different people.

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

18

Practice, practice, practice. And never be satisfied with the first thing that comes to mind.
–
Mark RansomSep 3 '10 at 5:28

2

+1 for Mark Ransom...The difficulty comes when you're still not satisfied with the 100th thing that came to mind!
–
Stimul8dOct 21 '10 at 8:11

The single most effective thing I learned about good programming was to be disciplined about refactoring. I have decent design skills, but good designs can go astray either during initial implementation or ongoing maintenance. This is especially true when new features are added later on as they tend to increase code complexity and brittleness.

Discipline matters precisely when refactoring becomes harder. We should usually be doing the easy, trivial refactoring on an ongoing basis as part of normal coding. It is when refactoring becomes hard that it can be of the greatest value in maintaining code quality and keeping design/implementation flexible and reusable. One has to keep return-on-investment in mind about when and where to do major refactoring, but it is a necessary part of good programming.

Lastly, taking on the harder refactoring scenarios helps to reinforce and ingrain the importance of refactoring as a standard part of one's coding practices in more trivial situations. The earlier and more frequent, the easier it usually is to keep code quality high and extend the usefulness of the existing software designs.

I would say strict adherence to rules (see:Legalism) may lead to burnout very early. I would suggest learning the reasons behind the rules, and what other 'good' programmers think about them.
–
JoePasqJun 4 '10 at 11:06

4

It is a good list to aspire to. I disagree with #4.. comments are just a repetition of what the code is trying to do and should only be used when the code is difficult to understand - which is something I aim to reduce as much as possible!
–
Mongus PongJun 4 '10 at 13:53

10

I totally disagree! The code should be suficient to document the application context. If you have code such as "if string.length > 8 ", and you must put a comment like "check string length long enough to be a bank account number", then it implies the code needs rewriting. Create a constant MIN_BANK_ACCOUNT_NO_LENGTH = 8. and rewrite the code "if string.length > MIN_BANK_ACCOUNT_NO_LENGTH". The comment then becomes redundant as any one can (and should) read the code to understand. Remember in a fast changing world, comments can quickly become out of sync with the code.
–
Mongus PongJun 4 '10 at 14:10

1

Having to amend the comments with the code is an error prone process. Think about it, how often do you find yourself actually reading the comments to work out what is going on? ;-)
–
Mongus PongJun 4 '10 at 14:12

1

I'd like you to expound about '7. Learning functional programming'; not because I don't believe you, just because I'd like some perspective.
–
Jim G.Jun 4 '10 at 19:05

Trying to build a game engine from scratch, just for fun. It touches on so many different aspects of programming that I had to learn all sorts of new things in order to get various parts of it to work.

I didn't specifically do this to improve programming skills. I just realized that it seriously affected them.

Contests made me learn about—and actually implement—a lot of standard algorithms and operations with common data structures. They taught
me to find "corner cases", and to write programs in such a way that these cases do not make my code look like a mess. They taught me to find an effective algorithm for many problems, and, most importantly, not to be afraid of difficulties when I'm to write something non-standard.

By programming contests I mean contests where you're to write small programs that solve simplified problems. A participant (or a team) is given limited amount of time and a small problem set. The goal is to implement the problems in such a way that they pass all the sets prepared by jury. Usually requirements (time and memory limit) force you to implement effective algorithms.

Over the duration of my career I learn one important thing that if its a difficult task programmers tends to do everything together. take small breath ,forget about the deadline ,break it in small bits and don't think about what you have to do after that (the next bit).

I forget to implement it sometimes. but when i do it do wonders for me.

In the last year of my Computer Science undergrad degree, I took a compiler writing course. It was a full year course and in that course we created a pascal compiler from scratch. I wrote everything in C and I did not use lex or yacc.

That project advanced my programming abilities more than anything else that I have ever done.

Beyond that, the most important thing I've found that improved my coding abilities is to improve my analysis and design abilities. If your analysis and design skills are poor, you will be a bad programmer.

1) Writing code. Lots of code. Most of it were only fun little dinky programs to solve a special problem, but since I've been on the workforce, I've written some production code. Every time I've seen something that I have done wrong, so next time I did it in a different way. In one word: experience.

2) Reading code. Before I only wrote code, but recently this is changing. I've been doing some code reviews, reading and evaluating open source stuff, sometimes even modifying some of it. This gave me a lot of tips, know-hows. Also, I can handle open source stuff with bad documentation somewhat better.

3) Show your code to someone. Other points of views can show you stuff you never tought about. A programmer on embedded systems may recognise something that can be done with less resources, a security programmer can point out failures, etc.

4) Tutor someone. Despite what some people say, programmers have to maintain human contact. Also, it gives something back to the community. I've met some of my friends during tutoring sessions. It makes you a better programmer because you'll be able to communicate better (which is realy important if you want to write good documentation).

5) Learn a wide range of languages at least to some degree. The difference between them is not just syntax. ASM needs different thinking than Java. Lisp programmers program different than PHP developers. Knowing a lot of languages at least to some degree gives a perspective.

6) Work on something for a while. If you have a cool idea, work it out. Try getting your peers involved. It's realy fun to work in a small group, solving your own problems. The company I work for started this way. But before you begin your career, it will help you understand teamwork. Also, you'll get to see how an application is designed, implemented and maintained.

Probably digging into GoF design patterns, which certainly opened my mind in terms of source code reusabity and maintainability. Also, Martin Fowler's book and articles on refactoring made me a better programmer.

I have a personality quirk that leads me to re-invent just about everything. I want to know how everything works, and that tends mean writing a huge amount of code. I've become very good at it.

Programming is a lot like playing the piano. The more you ACTUALLY WRITE CODE, the more skilled you will get at that. The more you debug code, the more skilled at debugging you will become.

I had a step-father who was a really amazing pianist. He told me that he estimated you needed to play about 10,000 songs on the piano and then you'd be excellent. He didn't think it mattered much what kind of learning styles you used... you just had to get the practice in. The goal is to retrain pathways in your brain and get yourself all tuned up.

Obviously playing chopsticks 10,000 times isn't going to make you a concert pianist, so don't be stupid. However, anything halfway reasonable should work.

If you think code reuse means spending 8 hours on the internet searching for someone else's solution to a problem and then copy and pasting that in... sorry... you aren't going to improve very much.

I've met a great number of people who want to believe that with the right tools, you don't need to program very much. You must absolutely, totally purge any inkling of this concept from your head and stomp on it until it's about 2 nm thick. It's horribly destructive from a self improvement point of view.

"New software for concert pianists from Rational Software! Convert your Symphony Modeling Language diagrams directly into sheet music! Export to all current platforms using MIDI, perforated scrolls, or music box cylinders! No more hours and hours slaving over the keyboard!"

Learning Haskell gave me a fresh perspective on my programming approach. This has improved the way I approach programming problems considerably. I cannot recommend enough trying out different programming paradigms in order to improve your problem solving skills. It doesn't mean you have to abandon your favorite environment. Just look at how things can be done differently and learn from that.

Subscribing to Coding Horror lol. Actually I found that getting a new job on a project that interested me helped the most. Mind numbing web programming for the great state of NY was kinda depressing and was holding back my coding potential.

For myself, being open to new ideas and trying to see the bigger picture which gets to be a bit of a paradox at a point. Some examples:

Design Patterns - Reading about them, using them in new projects, seeing where they may already be used but I don't know that that is a pattern. These can also be work patterns or patterns in how projects are done though these are usually viewed as practices...

Practices - In my case this is learning refactoring, Agile, Scrum, estimating work using a modified Fibonacci values, TDD, as well as new tools like Resharper, SVN, etc. Also in here can be concepts like technical debt and broken windows that can be really neat ways to convey ideas in some cases.

Architecture - See how some big systems are tied together and how different components come together to build say a CMS or CRM system.

Evolving technology - I can look at how I use VS 2008 and try to remember back to using VS 6.0 many years ago and some parts of how I build web applications has definitely chaned over time which can be beneficial to see new ways to put things together.

The paradox comes from that at some point, I'm looking at things from such a high level that nothing is really in focus and so the challenge them becomes trying to get back down enough to know how to put together the smaller parts while still understanding a big picture for where I'm trying to improve something.

Finding better work environments is another big thing can affect my skills. If I'm working with people that produce code of a high quality, polished code with tests, that can act as a way to influence me to be better about what I add to the codebase. Similarly, if I work with a bunch of cowboy developers, this may make me be more of a cowboy coder myself.

By cowboy I mean that kind of developer that regularly has spaghetti code that as it was all done by 1 or 2 people they know what ideas where behind various parts of it and there can be many times where one has to go, "Crap, now I go fix that," or "Whoa... how did I miss that?" or, "What do you mean someone tried to put in X as a number? That's not cool."

I've not been programming for long - roughly a year, unless you count HTML/CSS work and very basic PHP stuff for querying databases.

I started programming in Pascal at college, and found I had a natural 'knack' for programming. Most of the tasks given to me were easy (it was only an introductory course). Since I started the college course (I'm about to start university in a couple of weeks), the following things have helped me:

Note that these are very much from a student's perspective.

Make programs more complicated than required in the tasks given. I made all my programs go 'the extra mile' - more functionality, a better UI, more suitable for a real-life application. This gave me the opportunity to learn new things that weren't necessarily included in the course.

Do a lot of reading. I read a lot of material, admittedly mostly online, on Pascal and how to do what I wanted. Since then, I have also done a lot of reading about other languages - C, C++, PHP. And also other paradigms, especially OOP. Reading what other people have to say, from a variety of sources, has given me a pretty decent idea of how to program well.

Program, program, program. The more I actually program and put into practice the things I have learned from college or reading, the better understanding I have of what I'm doing and how the theory really works.

Review your code. I find that going back to programs that I have previously written and taking a critical view of them really helps. I can see how to better write the code with the knowledge I've gained since then.

Rewrite your code. After reviewing old code, I find that rewriting it using new methods I've learnt really helps me to appreciate what I've read. If I can successfully rewrite, for example, a holiday quote system that I wrote while at college, I can see the benefits from start to finish of using new methods.

Ask questions. Sometimes tutorials and articles can be a little too technical and a lot seem to assume prior knowledge, even so-called 'beginners' guide to...' articles. Asking someone you know, or using place like SO means you will often receive a much more useful answer in terms you can better understand. Especially if you are a beginner.

Design code first. We only did basic top-down design in my college course and at the start I had a habit of writing the code first and then 'cheating' the design process. Once I got onto larger programs, I really began to appreciate the benefits of designing my programs first - made the actual programming part so much easier and quicker.

Program, program, program. This is definitely the thing that has helped me improve my programming skills the most. It's worth two mentions, I think. Having theoretical knowledge is fine, but if you can't put it into practice, what's the point?

I'd recommend all the above things to people who want to learn how to program, and probably one other thing: Don't be afraid of jumping in with both feet.