I’ve been writing code for almost 11 years now. One thing I am completely sure of is that for being a really good programmer, you have to do a lot more than write code. Being great is simple (not easy!).
Here are some important practices that can make anyone a better programmer.
Write it for other humans
Write code for a junior developer who will come to fix issues in your code 2 years from now. This means:
- Choose better variable and function names
- Explain why(not what) the code does what it does using inline comments
- Write better commit messages
- Have a README with installation guidelines and coding guidelines
- Treat documentation as an integral part of code base that needs constant review and refactoring
Write your codebase as it will be managed by an idiot in future, because eventually, it may be.
PS: Optimising code for machines is important too, but try to abstract that from fellow homo-sapiens.
Write test cases
The best products I’ve worked with have had test coverages between 85–95%. It clearly looks like a big commitment, specially when you’re an indie developer.
It’s not possible to test everything, but at least write test cases for the parts that are likely to fail or change over time.
Writing unit or integration test sometime seems like an expensive affair, but at the end of the day they are always cheaper than fixing issues making it to production.
Stick with your tools
It takes considerable work before you get comfortable with your tools (ex IDE). It takes even more work to make a tool part of your subconscious.
Surprisingly large number of developers change their tools, languages, frameworks on a very frequent basis. I am not against getting the experience of working with all these tools, but I am surely against switching these on a very regular basis.
It’s doesn’t have to be a marriage between you and your tools, but you shouldn’t be having too many one night stands as well. Settle down for some time, kid!
Deploy it!
I’ve lost count of projects that never saw daylight. Most developers have two amazing personality traits:
- Perfectionist: The part that doesn’t let you launch anything short of perfect
- Procrastinator: That doesn’t let you make anything perfect Don’t let these traits take over and stop you from launching even if you don’t have a good product. Don’t let your dream app die in a private git repo!
Defend your best practices
If the doctor washes his hands before doing your examination, that is considered normal (in fact, a good practice).
But if a developer wants to write test cases before writing actual code, many employers/clients find it weird.
Each trade have some good practices that should be followed religiously. Sometimes being a great salesman is the pathway for being a great programmer. Sell your best practices!
Your client/employer may not know about the best practices in tech. It’s YOUR responsibility to educate them and, if required, even tell them what may happen if you don’t follow the best practices. (It’s ok to scare them with an historical example or two).
Learn a new programming language
Learn a new language every year. If you can use it for work, Awesome! If not, that’s ok. A new language won’t just give you an additional skill, it will also give you new ways to think.
For example, coming from Java and C++ background, it took me some time to digest the fact that we can run a program in PHP without a main function.
After working on PHP-Apache based urls (e.g. home.php), Python’s way of implementing routes and URIs was almost a shock for me.
Learning a new language will help you question the standards in your current language.
Call to action
If you could change one thing about your programming practices, what will it be? Change that. NOW.
PS: The article was originally published here
Top comments (10)
Excellent summary! I make many of the same points in my other articles, but I love how you boiled it all down.
I would say, however, that "best practice" does not exist. Good practice is important, but there are three important things about it:
Know it and follow it strictly until you have a good reason to depart.
Don't let it become dogma. Adjust it as you learn more. Practices, standards, and methodologies exist for people, not the other way around.
Good Practice for one project may be Bad Practice for another project, sometimes even in the same language or stack! Be ready to defend your practice in the scope of your own project, but don't assume it's the Answer To Everyone's Problems.
As I've said before, Best Practice cannot exist, because if it did, it would mean that there was One Great Solution To Every Problem Ever™, and the entire history of computer programming proves that premise ridiculous.
Solid tips, Aman.
Based on the title I was expecting you to take things in another direction: project management, leadership, human communication, marketing, domain knowledge, estimating, time management, teamwork, etc.
Despite my surprise, I like your tips very much.
Nice summary. The first part about human communication is essential.
Curiosity is a good point but not only with new programming language, sometimes another domain (architecture, design ...) could be very usefull to lean new practices and process. I'ld like to write something about that one day.
Moreover when you create a software go to see how user use it (UX design) it's very very instructive.
Disagree with learning a new language everyear. I’ve found it’s far more marketable in a profession where new technologies arise and die rapidly to learn and build deep proficiency in a fewer languages that meet the demands of the market. Plus, languages share traits with one another—making it likely that if you know one language deeply, you’ll be able to work in another without much difficulty—Ruby vs Python for instance. By mastering the language you work in, you’re learning to use other similar languages as well. There’s also a bunch of trendy crap in the tech world that is a waste of time to learn. In the end, we’re all in this field for the money—that’s what careers are all about. Use your time wisely and maximize your value.
Some are, others aren't, human motives are not this simple.
Awesome post. I follow most of what is mentioned in "Write for other people", except the 2nd point about comments. I just realized that I've done exactly what you said in my comments - I've explained the 'what?' but not the 'why?'. Thank you.
I have drummed into every one that has worked with me a few key concpets around code:
I could do better at writing better commit messages!
I think I am past learning new languages at this stage of my career, but perhaps not, always fancied having another go at Ruby as the first time I looked at it the documentation was in Japanese!
I used to use UltraEdit, but moved across to PHPStorm a couple of years ago, for most of the web scripting I do. Worst decision made, using netbeans ...
Someone (I think on this site) once said we should call these professional skills. I agree with them, b/c I think it's useful to be able to use "hard" and "soft" skills to mean "skill based tasks" and "intuition based tasks". Eg the sequence of keys you press to rename a variable a hard skill, choosing the right variable name is a soft skill, caring about variable names (readability) is a professional skill.
Anyway, other than that nitpick, I agree.
Oh, maybe worth saying that I agree within the common context that we typically write code in. In general, they can change as goals and constraints change. Eg I enjoy tweeting programs (example), and to meet the constraint of tweetable, descriptive variable names and proper indentation are counterproductive. Thus, the most important professional skill is to know the goal.
The fact that you need to write comments is an indication that your code itself is not clear enough.
Remember that comments need to be maintained and refactored with the code. An out of date comment is worse than no comment at all.
I prefer restructuring/renaming code until it is clear what it does instead of commenting difficult parts.
Great post, I like to add one more skill (not too soft then other).
Try tô teach the juniors of the team is a great skill, you develop the teach skills (obvious) and social skills