Rules of Thumb for Becoming a Better Developer
Lessons learned the hard way from a full time Android developer.
Understanding code is much harder than writing it
When you first start coding or developing professionally, you think solving issues and creating solutions will be your most difficult task. It’s not. Working out what the newbie’s code next to you is doing is far higher up the ladder of difficulty. Understanding other developers’ code quickly and efficiently is a skill that may take your entire career to master, but it is a skill that will make you invaluable. If you don’t need three months to get up to speed at a new job or on a new project, your value goes through the roof. Spend time figuring out other people’s code and developing this skill.
You’re the one to blame for that “unfixable” issue
It’s not the platform that’s wrong.
It’s not the perfectly documented API that’s wrong.
It’s you.
If you’re inexperienced and have ever come to the conclusion that someone else is to blame for a bug or issue without putting real effort into understanding why, don’t go complaining to a more experienced dev or your mentor saying it’s “unfixable”. Shut up and go through everything three times — and I mean everything. The quantity of embarrassingly stupid errors that you, yourself, create are directly proportional to how sure you are that you’re haven’t made any. A wise dev knows how stupid he can be on a bad day.
Be consistent
If you have 10 classes that do exactly the same task with minor variations, spend time creating a format and style that makes sense then stick to it. Better yet, stick to it for the entire project. Follow a convention. Any dev can easily tell which code is mine, because it’s all laid out the same. Interfaces are always declared first, then public fields, private fields, constructors, public methods, private methods, helper methods, then inner classes last. This means anytime I need to go back to a project I haven’t touched in 2 years to update a specific piece of code I know exactly where to look. I don’t need to hunt for that one damn field in the middle of all the class methods. The same rule applies to naming conventions, file structures, whatever. You’ll often be changing context on a project; From Slack to emails, to coding, to something else… Strip away as much cognitive effort as you can, and you’ll be faster and more productive.
Code as if the next developer on the project is a psychopath that knows your home address
You might think you’re awesome for creating an insanely complex bespoke solution with a builder pattern and 15 different constructors for any scenario, totalling 300 lines in one file instead of a dozen 100 line classes. You’re not. You’re actually a complete douchebag if you make something like that without putting a single comment in it. No one thinks like you do and no one knows what you were thinking when you wrote that piece of code. Always think of the developer that comes after you, and do everything you can to make their life easier, because most of the time, that developer is going to be you six months later.
Avoid shared state at all costs
If there’s anything I’ve learned in the 4 years I’ve been developing Android apps, it’s that global state is the bane of a complex system’s existence. Any time you can push state to the edge of your system, or better yet, get rid of it entirely, do it. It doesn’t matter if you have to pass around 15 variables through an app flow, do not build a singleton to hold that state. I’ve been there and spent a month fixing the issues of 6 classes modifying a giant bucket of state that wasn’t cleared properly somewhere along the way. As a rule, if your solution needs a isSet() or clearState() method that another class calls, start over. Keep state where it belongs, internal to the class that uses it.
Embrace the separation of concerns
Another key lesson I’ve learned over the years is to split up code. As an example, the first Android apps I worked on had one giant module, containing everything from UI elements to network requests. They were in their own packages, but still one huge chunk. Now every project I start has a minimum of 3 modules; one for UI, another for business logic, and one entity/shared module for the classes that are referenced throughout the app. Not only do you gain the benefits in compilation speed, but it also forces you to think about a hierarchy of concerns in your architecture, which in turn leads to a cleaner architecture as a whole.
Build up a bag of tricks
Anytime you solve a particularly annoying problem, keep track of the code. Post a Gist, create a library, or just keep the code around once you’re finished with it. I can’t keep track of the times I’ve dived into a previous project to retrieve a class or file that I can reuse. Don’t re-invent the wheel if you’ve already made it, re-use that shit and spend the time more productively elsewhere. The more of the boring code you have in your head or in another project, the more you can enjoy the new problems that need to be solved for the first time.
Have someone else test your code
I don’t know what it is or how it happens, but you will never find all the bugs in your own software, you may not even find most of them. When testing code, for instance, a particular flow in an app, the very fact that you made it will cause you to subconsciously avoid the parts that might cause bugs or crashes. Try as you might, you won’t find half the bugs someone else will find within minutes of picking up your code. I’ve proudly sent countless builds down to QA , after spending hours testing it myself, only for them to have it crashing in seconds. Get someone else to test your code. Plead with them, pay them, whatever it takes. The best solution I’ve found is to offer to test another developer’s code while you test theirs. Two birds with one stone anyone?…
Shit happens
On the flip side of the coin; accept that bugs will end up in production. Bugs are caused by creating something new, and if we aren’t creating new things then what on earth are we doing? You will never be able to account for all bugs before a release, and crashes are inevitable sooner or later. Why do you think beta testing and staged rollouts were invented? Don’t get caught up in how a bug got loose, and instead focus on iterative cycles, regular releases, and fixing the issues as they arrive.
I hope that this article has been thought provoking if nothing else, and that it might prove useful for any devs out there looking for tips to improve their skills.
Feel free to recommend or share it, and be sure to leave a comment with your thoughts. Until next time, happy coding!
Hacker Noon is how hackers start their afternoons. We’re a part of the @AMI family. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.
If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!
