It's been 10 years since I started my first job in the software industry. Here are 20 principles that I have learned and try to follow in my day-to-day life.
- Be humble - No engineer in the world knows everything, the same applies to you.
- Make it work, make it right (and sometimes make it fast).
- Optimize for change - Prefer duplication over the wrong abstraction.
- Always write tests - If you're not writing tests, you're testing manually.
- Solve 80% of use cases - You never gonna solve everyone’s problem.
- Prefer functional programming - It's easier to understand. If your code requires a Ph.D. to understand, you’re most likely doing it wrong.
- Delete as much code as you can
- Good Enough is Better than Perfect - Don't discard meaningful improvement just because it's not perfect.
- Criticize in private, praise in public
- Make notes - If you think you will remember it, you're lying to yourself.
- Talk to your users - The best software is built by engineers who have empathy for their users.
- Learn with intention - Practice with a clear and specific goal in mind - what you want to improve and exactly how (deliberate practice).
- Do not generalize early - Wait until you have at least 3 duplicates of code before you make an abstraction (aka. Rule Of Three).
- Fix broken windows - One hack in code leads to another hack. Soon your code will become unmanageable.
- Fix the problem - doesn't matter whose fault it is, it is your problem.
- Do what works, not what's fashionable - Try it first with a small team. If it works, expand. If not, abort.
- The best work requires a good rest - Regular time off is essential for top performance. You also don’t expect professional sprinters to sprint all the time.
- Take small steps - Big rewrites don't work. You will lose motivation and focus along the way. Aim to release daily. It gives you the freedom to change focus when necessary.
- Praise for good work - Something we've observed in animals, but works for people too. You will get better results when you praise people for good work rather than punishing them for a bad one.
- Perfect code doesn't exist - It's better to accept this as a fact rather than wasting time and chasing the impossible.
Oldest comments (36)
That's a great list of great advice. Nicely written :)
Now, i probably need to go back and force myself to catch up on half of those, haha.
Good job. (l'm applying point n°19😀)
"6. Prefer functional programming"
It has to be clear here : do you mean functional vs OOP ? If so, then this is debatable. How can this apply using Java or C# ?
If you mean such things like Design Patterns proposed by GoF, then it maybe right, although some people may disagree.
I think he means procedural.
Functional is a terrible name for the alternative
Looking at the features added to the newest versions of Java, I'd say functional programming is totally possible. Functional and OOP are not mutually exclusive.
Lambda expression ? Yes, it is a good addition to the language. C# has it too.
If I would have written the list and was asked this, I probably would have changed it to "Prefer function programming techniques" or "Prefer techniques that feel natural when using a functional programming language". Things like:
Also perceiving typical OOP techniques like classes to a functional lens can help, for example: Realizing classes are a group of partially applied functions. This can help identify functions that should not be grouped together.
my favorite in this read is "write Notes "
Something that I am creating a habit for and understanding that I am human , I cannot always remember everything .
Good Job @ondrejsevcik on this beautiful piece
I really agree with this list. Especially number 7 (Delete code).
Great and insightful post, something else that could be on the list is : If you’re stuck ask questions don’t wait to be asked.
Thanks for these valuable principles
Thank you @ondrejsevcik, number 10 is really important to note and that's a practice I've learnt to enforce. If I see any code maybe on twitter that I need to take note of, I get my twitter note and put it on it.
Great Summary 👍 Can't agree more, especially on point 4 -- always write test.
Very good advice. Thanks for sharing
Some comments may only be visible to logged-in visitors. Sign in to view all comments.