How to be an effective developer

Arpit Mohan - Nov 22 '19 - - Dev Community

Learnings from three articles I read today

11 rules of effective programming

  • Leave your code better than you found it.
  • Think about the total cost of ownership: cutting corners, skipping tests for later or creating temporary fixes have costly long term repercussions.
  • Look for repeatable patterns from references or projects around you or online that have implemented a feature with similar requirements.
  • Micro-optimization can easily make your code a mess and does not bring much value to users.
  • The cost of fixing bugs grows exponentially over time. Discovering problems early makes them easier to solve too.
  • Avoid multitasking. Studies show that it has a negative impact on performance and productivity.

Full post here, 8 mins read


Slow down to go faster

  • Take time to write automated tests instead of focusing on developing features alone. It will save you manual testing time later and avoid regressions as the code grows.
  • Take time when naming variables, classes, etc, so they are meaningful and self-explanatory. This will ensure other developers can easily grasp the contexts easily from the names.
  • Document your code as you write it. Structure it to start with a brief summary of multi-line functions, inline warnings, and explanations of tricky bits. Record intent rather than implementation.
  • Invest time to think about what you want to achieve while things are still simple. This way, you will not be thrown off track by complexity later.

Full post here, 4 mins read


Your system is not a sports team

  • If you are aligned to a mission, rather than being aligned to a specific system, you will work better for the success of the company.
  • Don’t be obsessed with a system that you have built or worked on for many months/years.
  • Don’t focus only on improving the system you are working on. Look at the larger goal your company is working towards and find the best utilization of your time.
  • Get your team aligned on the problem at hand and not around the tools & technologies to use to solve the problems.
  • Empower all engineers to focus on the impact of their decisions on the overall company by avoiding silos.

Full post here, 4 mins read


Get these TL;DR style notes directly to your inbox every weekday by signing up for my newsletter, in.snippets(), here.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Terabox Video Player