How to become a better programmer.

April 5, 2016 by Christoff Truter

In this post I am going to discuss four posts I recently read on the subject at hand, please note that I paraphrased their key points, while adding my own input, be sure to read the original posts as well.

Feel free to add additional links on the subject in the comment section, I am always looking for ways to improve my craft.

The first list we're going to look at was written by Adam Turner.

10 golden rules of programming - a living discipline

1. Don't re-invent the wheel.
   
   The author advises against unnecessarily improving / changing production code, as it might escalate into a full blown project, resulting in wasted company time.
   
   I believe context is important here, in an academic / research context re-inventing the wheel is an important part of the learning process, most of what I've learned over the years spawned from this.
   
   Re-inventing the wheel is also important in the context of the wheels of progress, finding new/better ways to solve problems.
   
   
   
   But that said, look at your actual work environment, you might have different constraints, you might be confronted with deadlines and budgets. Ask yourself, is this the right time and place, the right context to reinvent?
   
   There is also the matter of using third party code, e.g. do you really need to waste time and write our own charting library for example? Rather keep your team busy with actual project requirements.
   
   
2. Keep things as simple as possible.
   
   This is basically just a warning against over-engineering.
   
   Basically the KISS and YAGNI principles, I wholeheartedly agree with this.
   
   I've worked on systems that aim to be future proof and overly dynamic, most of the time that future never came, you might end up spending more time on software architecture than on actual client requirements.
   
   
3. Learn from others mistakes, not your own.
   
   
   
   Study the habits of other developers and learn from their mistakes e.g. via forums etc.
   
   I can see wisdom in this, however I found that hitting your own head is a better teacher, e.g. after hitting your head a thousand times, you will have a deeper understanding about what not to do.
   
   
4. Performance has no competition.
   
   Don't just throw hardware at software problems.
   
   I don't completely agree with this point, sometimes we need to sacrifice performance in the name of writing maintainable code, e.g. I am sure writing all our software in assembler will be a lot more performant than using C#, but do we have the time to do this?
   
   I believe there needs to be a balance, obviously performance is first price, but looking at the overall context of Adam's post, time and easily maintainable source code to save that time will often times be more important.
   
   End of the day we need to deliver source code in a timely manner, we've got bills to pay, if optimization hinders that we've got a problem.
   
   
5. Bug free code is more important than clean code.
   
   First focus on quality of code, neat code is secondary.
   
   I get the impression that Adam spent time with developers that spent more time on architecture than quality code (as seen in point 2) ?
   
   For me personally clean code translates to more manageable code, which leads to bug free code (not sure bug free code even exists).
   
   
6. Begin with an end in mind
   
   Before writing code, get management or the customer to sign-off on a finite design.
   
   In an ideal world yes, I found it rather surprising in the comments of Adam's post people commenting that this is a given?
   
   In my 15 odd year professional career however, I more often than not found it very difficult to get a customer to commit themselves to a spec (perhaps I am very unlucky?). Yes we all hate scope creeping, but getting a customer to understand this?
   
   
   
   In one of the companies I worked for we had to fire a customer due to their unwillingness to pay for a design he signed off for, the project dragged on for months, resulting in wasted time / money.
   
   I think the biggest problem here is that often people don't really know what they want / need and unfortunately what they want / need becomes clearer when they physically have something in front of them.
   
   Producing clear prototypes might be the answer?
   
   
7. If it's not broken, don't fix it.
   
   I can't really see the difference between this and point 1? The author advises against unnecessarily improving code. 
   
   
8. First seek to understand, then to be understood.
   
   Listen, comprehend and understand, before giving your input.
   
   We have one mouth, two eyes and two ears for a reason ;)
   
   
9. There's a place for everything and everything in its place.
   
   Use the right tool for the right job.
   
   
10. Scalability is next to godliness.
    
    Get in the habit to build code libraries that you can later reuse as a foundation to easily and effortlessly develop scalable applications.

The next 10 "rules" I found at www.codeshare.co.uk, written by Paul Seal, a .NET Web Developer from Derby in the UK.

10 golden rules for becoming a better programmer.

1. Don't repeat yourself.
   
   The DRY principle, related to the DIE (Duplication is Evil) principle.
   
   

   Of all the principles of programming, Don't Repeat Yourself (DRY) is perhaps one of the most fundamental. The principle was formulated by Andy Hunt and Dave Thomas in The Pragmatic Programmer, and underlies many other well-known software development best practices and design patterns. The developer who learns to recognize duplication, and understands how to eliminate it through appropriate practice and proper abstraction, can produce much cleaner code than one who continuously infects the application with unnecessary repetition.

   from O'Reilly Commons.
   

2. Name your variables to say what they are for, not what data type they are.
   
   The author referrers to an identifier naming convention called Hungarian Notation, which is a very old fashioned way of naming your variables that we used to adhere to back in the day. In a language like C# for example, it is kinda pointless to use this convention.
   
   But that said, generally when working with older legacy code, just let it be ;)
   
   
3. Give your methods a clear name for what they are going to do.
   
   Obviously always keep your company's naming conventions in mind when taking advice like this, but yes, I always do this.
   
   
4. Don't use magic numbers or string literals.
   
   Make use of constants, enums etc.
   
   
5. Write your methods so they can be tested without having any dependencies on other parts of the application, where possible.
   
   
6. Don't be afraid to ask for help.
   
   I firmly believe that discovering things by yourself is more valuable than mere knowledge being handed to you, but again, context is important.
   
   In a work environment, spending two weeks to solve a problem that should take two seconds is a waste of time and money, ASK.
   
   
7. Follow the boy scout rule.
   
   Leave code better than you found it.
   
   If you see something is broken, fix it, don't just leave it for someone else.
   
   
8. Share knowledge with others.
   
   This goes hand in hand with a post I wrote at the end of 2010, which is a big part of why I have this website in the first place.
   
   
9. Don't interrupt your colleagues whilst they are in the flow.
   
   Uhm yes, I can relate, but that said, when working in a team this can't be avoided and often times the flow might be heading in the wrong direction, so uhm.. context?
   
   
10. Use criticism as a positive instead of a negative.
    
    
    
    Constructive criticism is very important, it helps us to improve our skills, so have an open-minded approach towards it, you don't want to be in a position where everybody is too scared to help you.
    
    Regardless of what your mother told you, you're definitely not perfect.
    
    And when dishing out criticism, don't be a douchebag about it.

The next quick list was written By Tobias Gunther, the CEO of fournova.

Become a Better Programmer: 5 Essential Methods at a Glance

1. Unit Testing
   
   Very important, this will help you to catch bugs early on in your development life cycle.
   
   
2. Code Review
   
   You might have overlooked something, a second eye is always a good thing, which leads to better quality control and collective ownership of source code.
   
   
3. Pair Programming
   
   This is basically mentorship.
   
   
4. Keep it Simple
   
   Back to the KISS principle previously mentioned.
   
   
5. Design Patterns
   
   This is also related to the re-inventing the wheel point in the first list mentioned in this post, if a problem was already solved a million times before, why re-invent?
   
   Design patterns are very important to the vocabulary of a developer, e.g instead of explaining the proxy pattern every time, its implementation / definition should be obvious to anyone.
   
   

The last list we're going to look at comes from a transcript of a video interview with Pete Goodliffe.

Going Beyond Code to Become a Better Programmer

1. A Great Developer's Attitude
   
   Humble, state of constant learning, absorbing new knowledge, wanting to learn off others.
   
   The invert of this is known as "the overconfidence effect".
   
   
   
   Have you ever worked with a super hero programmer? You just can't tell them anything, but meantime back at the ranch...
   
   Not only is this an annoying quality to have, it is also detrimental to the learning process.
   
   If we get to the point where we think we know everything, that is the point where learning stops and we turn into dinosaurs.
   
   
2. Write Less Code
   
   Work smarter, not harder, avoid pointless comments, avoid writing verbose code, don't unnecessarily abstract code, simple clear to the point.
   
   
3. Communicating Effectively
   
   Effectively communicating with others is a vital skill (not necessarily verbally, but via the code we write as well).
   
   
4. Handling Complexity
   
   Necessary complexity and unnecessary complexity, well crafted software has none of the unnecessary complexity.
   
   
5. Keeping Your Skills Up to Date
   
   Pete named a few things in his video, which mainly boils down to challenging yourself, in his context he is focussing a bit more on high level tactical thinking when it comes to projects, rather than only focussing on the technical aspects.
   
   
6. Recommended Resources
   
   Sitting at the feet of great programmers, joining local user groups.
   
   

   I have learned the most in my career when I have been around excellent people

Final Thoughts

You might find some of the points in these lists contradictory.

But contradiction is perfectly normal in our line of work, we do after all have different ways we think about things, who is right? Who is wrong? Who knows? You can show a piece of code to two different programmers and receive vastly different opinions (hates and loves).

There are more than one way to skin a cat...



The important thing is to find a balance that works for you.

Now I don't presume to be a good programmer myself, but here is some additional thoughts I would like to add to the subject.

1. Pet projects
   
   Throughout my career I've worked with thousands of people, jumped from company to company whenever I smelled the stench of stagnation on my backside.
   
   Even though this gave me a wide range of experience, I feel my general reason for leaving was wrong, but it taught me one thing.
   
   Your day to day programming tasks are just not enough and you cannot blame the company you work for, they're there to pay your salary, the rest is up to you.
   
   E.g I worked for a company that still used COBOL, arguably we may call them dinosaurs, but its not their responsibility to keep my skills current, its my responsibility.
   
   For that reason I would advise anyone to keep pet projects.
   
   
2. Authority Bias
   
   I recently discovered that I was a victim of authority bias, I blindly accepted something Anders Hejlsberg said on a subject and missed out on some awesome technology.
   
   The thing we need to understand is, there are no prophets in programming, people are fallible, opinionated, we all have our biases.
   
   Make up your own opinion and join the mediocrity ;)
   
   
3. Polyglotism
   
   I find it rather strange how many programmers I found over the years only dabbling in one programming language.
   
   In fact, even the first post I quoted by Adam Turner I found a bit weird when he said "don't bother learning something you'll never use".
   
   Over the years I've programmed in so many programming languages at this point I lost count, we can argue choose a language and go with it.
   
   But is this wise? I've met a lot of programmers over the years that followed this don't bother to learn something paradigm and most of them are busy re-skilling themselves.
   
   What seems useless now, is not an indicator of its value in the future.
   
   
   
   
   
4. EU/US Passport
   
   Apparently the key to being a good programmer is having an EU / US passport?
   
   Nah, I am joking, I am just a bit frustrated with my on going struggle to escape the inevitable collapse of South Africa.