Being a Better Programmer
Roger Ngo
on Sun Dec 27 2020

Here are some ways I try to become a good programmer. It is a never-ending and amazing journey, as there are always things to try to improve upon. But this list has the things I truly believe in and try to practice in my day-to-day to be a good programmer.

This list will grow and become more refined through time… Feel free to check back for more interesting things in the future.

Writing Code

  • Be motivated when writing code. If I don’t care about the code you write, the sloppiness will show.
  • Code should solve a problem, and shouldn’t just “sort of work”. It either works, or it doesn’t. How we define what works is up to the team.
  • Don’t write confusing code, or code that is confusing because it is clever. Other software developers will be reading your code, and maintaining it in the future. Leave no mysteries.
  • If I am going to write comments, make them easy to maintain, and keep them up to date.
  • If I can’t name a variable clearly, then you don’t know what it will be used for. Shame on me!
  • Variable names don’t need to be terse to be good. Variable names need to be clear in what they are. So, if it has to be a long variable name, make it longer. Auto-complete is our friend.
  • Keep things simple (KISS), don’t repeat yourself (DRY), and question if you’re really going to need a specific feature (YAGNI).

Reviewing Code

  • Code layout should be the least of your concern as a reviewer. Just have an agreement on a specific style within your team, and stick with it.
  • If I have a million nit-picks about basic code layout and structure, I will take it personally to the developer. There is no need to point out the obvious in a code review. It really doesn't do good to the morale of the team. Treat a code review as if it was your code. 

Experience

  • Refactor when I can. Go back regularly to see if I can write code I’ve written in the past, better.
  • Careful about what refactor really means. I need to remember that a refactor means to change the structure of existing code, and not change the behavior.
  • Write lots of tests to ensure stability after refactoring sessions.
  • Remove dead code when I find it.
  • Don’t invent new requirements out of nowhere just because I think, or feel it is a good idea. Does it solve a problem, and bring value?

Onboarding to a Codebase

  • Make simple goals:
    • Clone the codebase, set up the development environment.
    • Build the system and see if I can run a local copy.
    • Make a simple UI change.
    • Look for a basic function and trace the execution path.
    • Fix a bug.
  • Ask questions.
  • Look at the tests.
  • Run the tests!

Responsibility

  • Don’t be lazy and ignore errors. Always check for errors and see if they can be handled gracefully.
  • Avoid silent failures. If there is a silent failure, make sure that behavior is documented well. However, usually, silent failures will almost always lead to painful debugging sessions once something goes wrong. Why? Because by the time you have to debug, I would’ve forgotten the reason, or existence of why that silent failure exists in the first place. True story. Happened to me and scarred me for life.

Bugs

  • Stated before, and will state it again… Don’t write clever code. Keep code as simple as possible. Simple code is easy to debug.
  • If a bug is very hard to reproduce, then I have to be as sharp as possible to solve the bug. What is an approach?
    • Reduce the steps to reproduce the bug to a minimal set of steps.
    • Stay focused on the problem. It is likely that I will encounter other bugs in the process – what will happen is that I will be tempted to conflate bugs, or confuse them for each other.
    • Try to make the bug very reproducible
    • Then use binary chop strategy to zero-in on the bug. Use assertions and logging in various places. Partition the problem space into two and work out to a middle point.
  • Look through previous commits to see if the bug was somehow introduced recently.
  • Take regular breaks. Debugging can be draining on the mind.

Tests

  • Arrange, act, and assert.
  • Always try to write code in a way to make it “testable”. Turns out, having this mindset will lead to better code design.

Version Control

  • I should be familiar with the version control my team uses. Makes it easier to switch between branches, merge commits, and revert things.
  • Make small commits. It will help reduce the chances of a conflict.

Investigating

  • Take lots of notes, and the tone of the notes should be as if I am teaching, or talking to myself.
  • Create simple examples to try and understand harder things.

Communication

  • Be nice. Always be willing to help and explain things. After all, I was clueless about something else at one point.
  • Keep virtual tone very happy. It is hard to convey tone virtually in chat messages. I have to overdo this to ensure I stay approachable.
  • When saying hello to others to ask a question for the very first time, type your question and provide as much context in the very first message.

References

  • Becoming a Better Programmer - Pete Goodliffe - https://www.goodreads.com/en/book/show/22512921-becoming-a-better-programmer