I enjoyed reading Amy Jollamore’s “7 Ways to Be a Better Programmer in 2014.” I agree with all of it.
Yet the advice seems too idealistic at times: “Professionals do not tolerate big bug lists. A huge bug list is sloppy” — sure, but try living up to that when you have three QA departments, spanning several continents, sending hundreds of bugs, 24 hours a day in your direction. Point 6 tells us about the benefits of the Zulu philosophy of Ubuntu — but try explaining to the irate customer, on the other end of the phone line, the finer points of Zulu philosophy when all they want to know is when the new features they need are going to turn up.
So while I’m going to try and follow Amy’s 7 points in 2014, here are five suggestions of my own, that I hope you’ll find practical and immediately applicable in your day to day work.
1. Spend 10 Minutes a Day Reading the Standards Documentation of Your Programming Language
Sure, reading standards docs would be a crappy way of learning, or even becoming proficient at a language. But it’s hard to imagine truly mastering the language without having done so. I discovered so many new, and immediately useful, facets of C++ when first reading through the ISO documentation. It really sharpened up my in-depth knowledge of the language.
So try this: every day, at lunchtime or at home, spend 10 minutes, no more or less, reading through another part of the standard documentation or main reference manual of your language.
2. Spend 10 Minutes a Day Exploring your Version Control System
If you’re reading this, you probably write code for a living. Chances are you use a VCS like Git or Perforce every single day.
But for such an integral part of your programming life, how well do you feel you really understand your VCS? Modern source control code software is extremely powerful, and can really leverage your productivity, but many programmers only scratch the surface, limiting themselves to the basic operations, like committing and updating.
There are lots of ways to further your VCS understanding. If you’re using Perforce or AccuRev then you probably mostly use the UI —- try using the command line interface instead (often more options are exposed through there). Are you using Git or Mercurial? If so read up on the several great reference guides, to explore all of the tools for managing flow of code.
3. Spend 10 Minutes a Day Reading How to Win Friends And Influence People
Hang on… wasn’t this post meant to be about practical, immediately applicable resolutions? Has a book about winning friends and influencing people anything to do with day-to-day programming?
It has everything to do with becoming a better programmer. I have known many helpful and impressive people who have been average programmers; but I haver never known a genuine programming rock-star (in the most positive sense) who wasn’t also friendly, approachable and likeable.
How to Make Friends And Influence People will help you become a better person, and that person will become a better programmer who is more highly regarded, works better with others, and gets their point across. It will help you to become better at bringing others over to your side when it comes to matters of solid programming practice, not the least:
4. Spend 10 Minutes a Day Fighting Test-Driven Development’s Corner
Hopefully you’re already on the bandwagon of continuous refactoring, based on thorough unit test coverage of your code base (if not read this and this and get started now!).
In my experience, unit testing and test-driven development are without questions the most useful improvement you can make to your development workflow: they make code more robust, more measurable, easier to refactor, faster to develop, easier to document and understand.
So spend 10 minutes each day fighting the cause of the TDD: for anyone who’s not using TDD ask them why: if the cause is that it’s too difficult to add new tests, work on improving your testing framework. If they’re holding back because they don’t agree with the idea, then understand why, and try to find ways for them to integrate testing into their workflow in a way that’s agreeable to them, no matter how small (you could even offer to write some tests for them!).
delivering to the customer the product they want, on time and within budget, by iterating frequently, minimizing distance between coder and user, and responding rapidly to change
The customer can be almost anyone: the artist using your toolchain, or the designer you’re working with on a website. Spend a bit of time each day involving them either by getting them a more up-to-date prototype to feed back on; by canvassing their opinion; or simply by listening to their frustrations. Maybe there’s something you can do about those frustrations even if they’re tangential to the task you’re working on, and you’ll have made a happier customer.