My TL;DR style notes from articles I read today.

Effectively Naming Software Thingies

“Programs are meant to be read by humans and only incidentally for computers to execute”
— Donald Knuth

• Write intent revealing names. If the variable stores the last updated record, name it ‘lastUpdatedRecord’, not just ‘record’, or even ‘lastRecord’
• Make clear distinctions. What kind of info will ‘ProductInfo’ has that the ‘ProductData’ won’t?
• Add context to names. Put variable state in well-named classes.
• Don’t abbreviate. Say ‘getWindow’ not ‘getWin’
• Pick one word per abstract concept & stick with it. Using both fetch and retrieve will cause confusion. Pick and use only one.
• Don’t pun, don’t make your readers mentally map names to something else.
• Use conventions for common operations.
• Avoid similar sounding & easily misspelled names.
• Favor readability over brevity.

Full post here, 7 mins read

What Makes a Good Programmer?

• Problem decomposition

  “…there are very few inherently hard programs. If you are looking at a piece of code and it looks very hard – if you can’t understand what this thing is supposed to be doing – that’s almost always an indication that it was poorly thought through. At that point you don’t roll up your sleeves and try to fix the code; you take a step back and think it through again. When you’ve thought it through enough, you’ll find out that it’s easy“.
  - Bernie Cosell

• Scenario analysis: Good programmers always ask themselves - how can this break?

• Naming things well

  “There are only two hard things in Computer Science: cache invalidation and naming things.”
  - Phil Karlton

• Consistency: Consistency across your programming practices allows you to concentrate on essential complexity & and not accidental complexity.

• Continuous learning about the developments in software engineering

Full post here, 5 mins read

Good Engineering Practices while Working Solo

When you are working solo, you are filling multiple roles on a project. Following these practices help with a good outcome:

• Stick to a workflow
• Organize & share components
• Write documentation
• Monitor
• Observe & iterate
• Communicate regularly with the rest of the team/client

Full post here, 11 mins read

I share these TL;DR versions of articles on software engineering that I read every weekday through my newsletter - in.snippets(). Sign up here if you liked what you just read.