You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Obsidian/00.04 IT/My guiding principles after...

76 lines
8.3 KiB

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

---
dg-publish: true
Alias: [""]
Tag: ["", ""]
Date: 2022-03-22
DocType: "WebClipping"
Hierarchy:
TimeStamp: 2022-03-22
Link: https://alexewerlof.medium.com/my-guiding-principles-after-20-years-of-programming-a087dc55596c
location:
CollapseMetaTable: true
---
Parent:: [[@News|News]]
Read:: No
---
 
```button
name Save
type command
action Save current file
id Save
```
^button-Myguidingprinciplesafter20yearsofprogrammingNSave
 
# My guiding principles after 20 years of programming
*🇨🇳* [*FLMN*](https://twitter.com/flmn) *kindly translated this to Chinese* [*here*](https://www.jitao.tech/blog/2020/03/my-guiding-principles-after-20-years-of-programming/)*.*
Ive been programming since 1999 and this year Ive officially coded for 20+ years. I started with Basic but soon jumped into Pascal and C and then learned object oriented programming (OOP) with Delphi and C++. In 2006 I started with Java and in 2011 I started with JavaScript. Ive worked with a wide range of businesses from robotics, fin tech, med tech to media and telecom. Sometimes I had a different hat as a researcher, CTO, TPM (technical product manager), teacher, system architect or TL (technical leader) but Ive always been coding. Ive worked on some products that served millions of people, and some that failed before being released. I worked as a consultant and I even had my own startup. I have spent lots of time on open source projects, closed source projects and internally open source projects (proprietary code that is developed by a community inside the company). Ive worked with tiny microcontrollers all the way to mobile and desktop apps to cloud servers and lately serverless.
For my 20 years programming anniversary, I tried to list the top principles that have been accumulated over the years as my guiding principles through my career:
1. Dont fight the tools: libraries, language, platform, etc. Use as much native constructs as possible. Dont [bend](https://medium.com/free-code-camp) the technology, but dont bend the problem either. Pick the **right tool** for the job or youll have to find the right job for the tool you got.
2. You dont write the code for the machines, you write it for your colleagues and your **future self** (unless its a throw away project or youre writing assembly). Write it for the junior ones as a reference.
3. Any significant and rewarding piece of software is the result of collaboration. Communicate effectively and collaborate openly. Trust others and earn their trust. Respect people more than code. Lead by example. Convert your followers to leaders.
4. Divide and conquer. Write isolated modules with separate concerns which are loosely coupled. Test each part separately and together. Keep the tests close to reality but test the edge cases too.
5. Deprecate yourself. Dont be the go-to person for the code. Optimize it for people to find their way fixing bugs and adding features to the code. Free yourself to move on to the next project/company. Dont own the code or youll never grow beyond that.
6. Security comes in layers: each layer needs to be assessed individually but also in relation to the whole. Risk is a business decision and has direct relation to vulnerability and probability. Each product/organization has a different risk appetite (the risk they are willing to take for a bigger win). Often these 3 concerns fight with each other: UX, Security, Performance.
7. Realize that every code has a life cycle and will die. Sometimes it dies in its infancy before seeing the light of production. Be OK with letting go. Know the difference between 4 categories of features and where to put your time and energy:
**Core:** like an engine in a car. The product is meaningless without it.
**Necessary:** like a cars spare wheel. Its rarely used but when needed, its function decides the success of the system.
**Added value:** like a cars cup-holder. Its nice to have but the product is perfectly usable without it.
**Unique Selling Point:** the main reason people should buy your product instead of your rivals. For example, your car is the best off-road vehicle.
8. Dont attach your identity to your code. Dont attach anyones identity to their code. Realize that people are separate from the artifacts they produce. Dont take code criticism personally but be very careful when criticizing others code.
9. Tech debt is like fast food. Occasionally its acceptable but if you get used to it, itll kill the product faster than you think (and in a painful way).
10. When making decisions about the solution all things equal, go for this priority:
**Security** > **Reliability** > **Usability (Accessibility & UX)** > **Maintainability** > **Simplicity (Developer experience/DX)** \> **Brevity (code length)** \> **Finance** > **Performance
**But dont follow that blindly because it is dependent on the nature of the product. Like any career, the more experience you earn, the more you can find the right balance for each given situation. For example, when designing a game engine, performance has the highest priority, but when creating a banking app, security is the most important factor.
11. Bugs genitals are called **copy & paste**. Thats how they reproduce. Always read what you copy, always audit what you import. Bugs take shelter in **complexity**. “Magic” is fine in my dependency but not in my code.
12. Dont only write code for the happy scenario. Write [good errors](https://medium.com/hackernoon/what-makes-a-good-error-710d02682a68) that answer why it happened, how it was detected and what can be done to resolve it. Validate all system input (including user input): fail early but recover from errors whenever possible. Assume the user hold a gun: put enough effort into your errors to **convince** them to shoot something other than your head!
13. Dont use **dependencies** unless the cost of importing, maintaining, dealing with their edge cases/bugs and refactoring when they dont satisfy the needs is significantly less than the code that you own.
14. Stay clear from [**hype-driven development**](https://blog.daftcode.pl/hype-driven-development-3469fc2e9b22). But learn all you can. Always have **pet projects**.
15. Get out of your comfort zone. Learn every day. **Teach** what you learn. If youre the master, youre not learning. Expose yourself to other languages, technologies, culture and stay curious.
16. Good code doesnt need documentation, great code is **well documented** so that anyone who hasnt been part of the evolution, trial & error process and requirements that led to the current status can be productive with it. An undocumented feature is a non-existing feature. A non-existing feature shouldnt have code.
17. Avoid overriding, inheritance and implicit smartness as much as possible. Write pure functions. They are easier to test and reason about. Any function thats not pure should be a class. Any code construct that has a different function, should have a different name.
18. Never start coding (making a solution) unless you fully understand the **problem**. Its very normal to spend more time listening and reading than typing code. Understand the domain before starting to code. A problem is like a maze. You need to progressively go through the code-test-improve cycle and explore the problem space till you reach the end.
19. Dont solve a problem that doesnt exist. Dont do **speculative programming**. Only make the code extensible if it is a validated assumption that itll be extended. Chances are by the time it gets extended, the problem definition looks different from when you wrote the code. Dont **overengineer**: focus on solving the problem at hand and an effective solution implemented in an efficient manner.
20. Software is more fun when its made together. Build a sustainable **community**. Listen. Inspire. Learn. Share.
I dont claim to be an authority in software development. These are just the wisdom I earned along the way. Im sure this list will be more mature after another 20 years.
If you liked what you read, follow me here or on [LinkedIn](https://www.linkedin.com/in/alexewerlof/).
 
 
---
`$= dv.el('center', 'Source: ' + dv.current().Link + ', ' + dv.current().Date.toLocaleString("fr-FR"))`