List of contributors:
-- KrisJohnson
-- ChristopheThibaut
-- KatieLucas
-- PeterAxelsson
-- EricHodges
-- VhIndukumar
plus some anonymous
Practice
- Write lots of programs, especially big programs. A lot of good practices become obvious once you've made the typical mistakes.
- Writing small programs lets you write more programs in the same amount of time; this will improve some of your programming skills much more rapidly, but others not at all.
- Modify existing programs written by other people. Reading code without having previous knowledge of it is a valuable skill - you can't debug without it --- and you don't get much practice with it when you're writing programs from scratch by yourself. If you reflect on what you've found hard to understand, it can also help you learn how to write maintainable code. Also, this lets you work on many more big programs than you would have time to write yourself from scratch, which helps a lot with those skills that only apply to large programs.
- But... CodeLessTestMore.
Refactor
Design
CodeReview
- Find some good mentors and let them review your code, and try to do some PairProgramming with them.
- Find some peers with whom you can review your code. People of similar skill levels can teach each other a lot. And this gets around problems with sharing your "bad code" with a senior person who might give you a harsher critique than you want (not to mention a bad performance review).
Learn from good programmers
- ReadGreatPrograms.
- Adapt some good code (I learned a lot about C idioms while adapting a Btree Index library in order to add compound key index feature).
- Team with good programmers. Sit at their knees and learn. Emulate their habits. Do not insist they adopt your practices/tools/habits because you think you know a better/faster/cheaper way.
Broaden your horizon
- Learn multiple programming languages. Each language you learn will give you ideas about how to do things better in other languages. (The worst programmers I know are the ones who think that language X is the only one they need to know.) See LearningProgrammingLanguages for related tips.
- Learn different kinds of programming languages: procedural, functional, ObjectOriented, etc. See GroundBreakingLanguages.
- Learn multiple operating systems. Learn to write portable code.
Read
- Read books about code quality, like CodeComplete. It can save you a lot of time.
- Buy the book ThePragmaticProgrammer and read it, learn it, live it.
- Generally, read GreatSoftwareBooks
- Read books about other subjects. Philosophy, history, art... anything. Become a broader person. It doesn't directly affect your programming as such, but it widens the mind, which has to be a good thing.
Learn the ProblemDomain
- Get into the habit of understanding the problem domain. Try to create a MindMap for the problem. Spend good amount of time learning about it. A good knowledge of the problem domain goes a long way in creating good code.
- Work closely with end users. Get their honest opinions about the software you make. It doesn't matter how many algorithms or data structures you know if you aren't making someone's life better.
- And on a similar note: learn from your users. Try to understand where they're coming from. If you learn the problem domain, their requirements make more sense and you get closer to being able to give them results that will do what they wanted, not what they asked for.
Reflect
- If somebody complains that they don't understand your code, find out what it is they don't understand. ("That guy is an idiot" is generally not the reason.)
- Every time you fix a bug, think about how you could have avoided the error in the first place, and what could help you avoiding it next time. Some of the answers lie in GoodCode quality principles, and others in good programming practices.
- By the way, just stop thinking that bugs come to life just from disruption or fatigue. Bugs proliferate in poorly written code. (But do remember that rest and concentration are requirements for doing good work)
- Learn to quit habits and to adopt new habits.
- Take a break. It's hard to do any of these things when you're already coding all week, as fast as you can.
Keep a Journal
See IsAnythingBetterThanPaper CollectingSeashells
These are all good points, really, but I fear most of the programmers out there are supposed to get things done under deadline, aren't they? -- LarsReineke
"Can we do it wrong if we get it done really fast?" (DilBert) -- JamieFristrom
"If a program doesn't actually have to work, it can meet any other criteria." -- GeraldWeinberg
See SharpenTheSaw
"Sorry, boss, I couldn't finish my code on duty, cause I wanted to improve the already running stuff and rewrite it in RubyLanguage, to see if I can improve my skills." (Don't take it too serious, please.)
You can't get better without doing some additional work. That's just how things are. If the boss doesn't provide time on the job for learning, and if you are not willing to devote your personal time to it, then your skills are not going to improve. (I know this may seem to be pointing out the obvious, but too many people are unwilling to accept it.)
Who said that you should improve programming skills only at the workplace? Is the workplace even suitable for cultural improvement of any kind? Of course doing a lot of reading seems to be frightening. Do less of something else (except programming). As to productivity at the job: since you're getting better at it you should not stay too long in situations of pure emergency. Sometimes there are orders of magnitude between the time it took you to do one thing, and the time it takes you after having learned and practiced a programming topic. Example: RegularExpression. -- ChristopheThibaut
Improving skills usually enhances productivity. If your organization doesn't provide for skill improvement, you should ChangeYourOrganization.
Learn the technologies used in or related to your current projects, and learn them much more broadly and deeply than strictly necessary for the job. This way, you can immediately put your newly gained knowledge to work, which helps your motivation, and helps you to understand and remember what you learn. Personally, I'm willing to spend extra time on the job to make up for the time "lost" learning. But if afterwards the learning effort should turn out to have immediate, concrete benefits to the project, I put the time on the company's/customer's bill with a good conscience. -- FalkBruegmann
The previous night of playing SidMeyersAlphaCentauri with the SignificantOther into the early morning hours reminds me how important it is to SleepToWork.
CategoryEmployment
How To Improve Programming Skills