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
Top comments (3)
I really enjoy this article. I wish that the full post articles were also brought into dev.to as well. There is an rss link tool for porting stories here. I personally feel that it allows for more uniform engagement of this community, and not having different user accounts to engage the same conversation.
Rules to live as a developer! Great read agree with all.
My favorite b/c so often forgotten or easy to not do and not think about “ Take time when naming variables”. Everyone appreciates you more when you do this.
Concise. Thank you.