Soft(er) skills that make you a better programmer
Aman Gautam Feb 8
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!
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
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
It has been about 5 months now. Since I started making the change to pursue graphics programming. I have done a ton of work in that time. Between school and learning a new language and studying a whole lot of math. And in this time, I have decided why not start documenting my process.