Ten pieces of advice to coding
My highly opinionated, biased advice to anyone interested in coding
Here are my six random, incoherent, and sometimes contradictory pieces of advice to programmers and aspiring programmers:
1. No code is the best code
Each line of code has a cost to maintain, test, and run. Jeff Atwood (creator of StackOverflow) said this more than ten years ago. More often or not, programmers tend to think everything can be solved by more code, but if you take into account the hidden costs to each line of code, say bug count, extensibility, testing effort, deployment effort, the moment you type in a line of code, you already accrued some technical debt (no matter how small) that has to be repaid in the future.
This guy had achieved nirvana.
No code is the best way to write secure and reliable applications. Write nothing; deploy nowhere.
2. More code is better
If coding cannot be avoided, use more code to achieve readability and ease of understanding, whether it is to your future self 6 months later, or to your colleagues, who will thank you for at least making your shitty code approachable.
3. Use bigger fonts
I use Input 14 pt. when coding in C♯; I use Fira Code 16 pt. when coding in F♯/Haskell.
Some laugh at me for having gigantic fonts on my screen, but I know who would be laughing after ten years.
Some say large fonts make them scroll horizontally too often. That’s a code design problem, not a font problem.
4. Learn to recognise patterns
No. This is not (only) about design patterns. It’s about recognising how others write code, how they write code a certain way, whether it is that weird spacing line/break habits, or that uncommon acronym they like to use.
They might be good, they might be bad, it does not matter.
I can recognise the author of a piece of code without even searching through the source control history. Recognising how others write code helps you develop awareness and forces you to form critical opinions. It also forms a guideline as to how you should reflect on your own code. ‘If I were the author of this method, is there a way I could have written this method better?’, ‘This guy used an interesting pattern here. Is he using it correctly?’ are questions that you should be asking yourself constantly when looking at others’ code.
5. Learn what proper dependency inversion is
First and foremost:
- Using a DI container is not dependency inversion
- Using interfaces everywhere is not dependency inversion
A quick acid test, consider a typical three-tier (UI, business logic, data access) application written in a compiled language. Does your business logic layer compile when you remove the data access layer (in a typical .NET project setup, try deleting the whole DAL project)? It should at least compile, and having all its unit tests passed because that is the point of dependency inversion. Your UI layer should fail to compile because that’s the entry point of the whole solution, where everything is integrated, but your business logic layer should certainly be independent of the UI and data access layer.
This should be independent of the programming paradigm you use. You should be able to achieve dependency inversion on OOP/FP.
6. 80 characters per line
Yes. You read that right. 80. Eight-zero.
People might challenge you as being impractical, and quoting 80 characters per line is a historical artefact.
People might say it is impossible to write lines with less than 80 characters per line when you have lines like foo.Bar.Baz.Qux.Method<FooBar>(quz) = quz.Bar.Baz;.
80 characters per line is a rule of thumb to any existing printed publications. Reading a book? Try counting the number of characters per line. Reading this article on a desktop browser (the story is a bit different for mobile browsers)? Try counting the number of characters per line. Chances are they are most likely having 80 characters per line.
You might ask, what’s the point of this when you have 24, 27 inches-wide 16:9 HD monitors on your desk? All the spaces seem to wasted on the sides!
This is not about aesthetics. This is about ergonomics of the human eye: The human eye is simply not good at reading lines that are too long (or too short). Long lines make you easily lose track of where you are laterally; lines that are too short, on the other hand, forces your eye to keep track of where you are vertically.
One of my favourite site about typography (the study of typefaces/fonts) backs this up by suggesting a line length of 45–90 characters, 80-character-per-line falls perfectly inside this range. Coincidence? I don’t think so.
If you have lines that look like foo.Bar.Baz.Qux.Method<FooBar>(quz) = quz.Bar.Baz; that does not fit 80 characters per line, you have a code design problem, consider looking up the Law of Demeter and remove nested dereferencing.
7. No man is an island
Programmers do not work on their own. They need to work with other programmers, business stakeholders, project managers to understand and analyse technical requirements. Coding actually only takes a small portion of your time. If you refuse to work with others, not only does this increase the risk of you building the wrong thing, it also takes away your opportunity to understand the business better and come up with a more appropriate technical solution.
8. Do not let others disturb you while you code
Having proper concentration while coding is paramount. Programmers like to talk about being in the zone where time seems to travel so fast that we lost track of it.
This is the period where creativity is at its peak and any slight disturbance will disrupt its flow and you would have to try again to get back into the zone again.
However, with modern day open office environments, people screaming around you, project managers chasing you for updates and meetings, it is almost impossible to be completely in the zone for the whole eight hours in your 9–6 day job.
Consider yourself lucky if you have one-third of your time in the zone on any given day.
9. Use the best tools for your craft
Software or hardware, please get yourself the best tools available for your job if you are serious in the craft. The best tools should excel in either one of the qualities:
- Comfort/ergonomics
Get a good keyboard and mouse. Your hands will thank you.
Get a comfortable and ergonomic chair too.
- Developer productivity
Get the best IDE, the best static code analysis tool (if your language supports it) and learn from the tools. They also help immensely when you are just starting out to learn a new language.
Learn useful shortcut keys so that it becomes muscle memory. You will need it if you are compiling/refactoring/running your code more than 50 times a day.
10. Do not try to power through a problem when you are hopelessly stuck
If there is only one thing I would say to be the most important, this is the one.
If you are stuck, take a break. I do not care what is your definition of a break, a walk to the toilet, leaving early for the day, just take the focus off of the problem at hand for a moment.
I lost count how many times I came up with a much better solution after that break when before the break I thought there would be none. Programmers are but humans, our brains need breaks as well. By taking breaks, we gain new perspectives on the problem when we catch on with our lives and do things completely unrelated to coding. We come back to the problem with a fresh perspective and usually, that is the time the solution suddenly pops up.
I hope you like my ten pieces of advice to coding. Thanks for reading!
