10 ways to improve your programming skills

One of the best ways to learn how to become a better programmer is to do the one thing that everyone says they don't have time to do, namely, DOCUMENT THE CODE!

Let me elaborate.  When you think you have a good solution and spend all night writing your code, you will still make mistakes.  Absolutely no one is perfect.  Why sit down and document the code?  Well, first, it gives you time to remember what you think you did when you wrote the code.  Next, as you are trying to describe the code, you will begin to see where you made some of your mistakes, error catch option 1.

When you get done with the first draft of your documentation, you review the documentation and the code.  At this point, you will find some additional errors, error catch option 2.

Next, you have someone else read the code and the documentation.  This process is usually called a code review.  The person reviewing the code and documentation will find additional errors or suggest coding improvements that will make the code more robust and faster, error catch option 3.

Just by documenting your code after you write it produces three opportunities to find and fix errors at the most cost effective point in the coding life cycle.  Did it slow you down?  Yes, a little, but it results in code that is three times better and completely documented.  This approach saved you three very long debug sessions and a massive task of documenting the code many months after you wrote it.

Trust me, documenting your code as you go is the best thing you will ever do in your programming career.  You will develop working code faster than your peers, with fewer bugs, and it will already be documented, so you will not have to go back to it later.

You my friend have just earned yourself a bonus and most probably a raise!  At the very least, the next time they need a "good" programmer, your name will be at the top of the list.  If you want job security, you want to be on the top of that list, always.

I stayed at the top of the list for 30 years by following this approach.  I was never laid off, and often had managers fighting over who would get me for their next project.

So if you want to improve your programming skills, learn to document your code as soon as you design it.  You will soon become the best known programmer in the office.

Your choice.

DAB

@DAB

Documenting code indeed is a good way to start with.

It seems you are a proffesional, so I wonder, how do you write your document? For example, do you use modelling tools or just text? e.g. for a newcomer, what are the basic steps how you would suggest to start with the document.

@DAB

Documenting code indeed is a good way to start with.

It seems you are a proffesional, so I wonder, how do you write your document? For example, do you use modelling tools or just text? e.g. for a newcomer, what are the basic steps how you would suggest to start with the document.

You could start with adequate remarks in your code. I too have realized, that i forget even the simplest logic that i may have used while coding,if i go back to the code 2-3 months later. You could scribble crucial points of your code on a text file.

Hi Willem,

At the very least, you should start a log book for each project and write down everything you can think of and every decision you make on requirements or design choices.

Yes there are a lot of tools, but learning a methodology for analyzing and designing software is the most important step.  I learned to use structured analysis and design defined by Yourdan back in the seventies.  I have found this method works very well for microcontrollers because it lets you capture both the hardware and software interfaces and trace the processing threads from input to output.  It also lets you capture the control flows and state changes.

Most universities teach UML today, which is fine.  The key is to learn a method very well and use it all the time. 

Unless you plan to do commercial products or work as a programmer, you probably do not need the fancy tools that implement the methods.  Most companies will have their own tools and methods.  They will also have standard documentation formats for you to follow both for defining the requirements and for capturing your code and test cases.

Even if you are just coding for yourself, look into the software documentation standards.  They will look intimidating, but they remind you of all of the things surrounding your software that you should at least conciously decide if they apply or not.

If you are looking from programming work, knowledge of these standards can give you a leg up on your peers.

As you start out, keep it simple.  When you are done, look back at your notes and ask yourself what is missing that you would like to know if you came back to the project a year later.  Then add that material.  If possible, have someone else look at it and give you feedback if they could build or modify your code using the documentation.

Don't get discouraged.  It takes a lot of time to get proficient, but if you do it all of the time, it becomes second nature and you will find yourself writing better software that works much faster than you did before.

DAB