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.
Top 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.
Perfect list, but the tops would be:
I started doing this far too late in my career - now I save so much time.
Software installation - think you will remember how you installed all those tools you need in order to work? Ha! You won't. And that software will often get trashed in ways you hadn't foreseen.
Sql - keep notes of all the sql queries you do for your colleagues/clients that aren't saved in code somewhere
Solutions to obscure error messages that had you searching the net for days before solving the problem, because one of them will come back again soon - like the killer in the horror movie you thought you'd taken out who suddenly reappears at the end BLAM! just as you were relaxing.
Any many, many more reasons - I must have a thousand or more of useful notes
Good job. (l'm applying point n°19😀)
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
"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.
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.
I think he means procedural.
Functional is a terrible name for the alternative
Couldn't agree more. Thanks for the great list
Nice list, but I completely disagree with #6. I would never prefer functional programming over OOP if the language I'm working with supports OOP. I don't find any difficulty in reading, or following, OOP code and I love working on OOP projects.
I especially like these ones!
It reminds me of the Charlie Munger quote,
which was reinterpreted by Naval Ravikant as,
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.
Agree about the note-taking: in any meeting with those who supervise, I am jotting down (key)words almost like a stenographer where the thoughts/words coming out are not making sense to listeners but will end up being useful at some point, either as part of a to-do or reminder, or a question in follow-up, but definitely a task. Of course most notes in a session will make sense beyond mere jotting down whatever is uttered.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.