DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’» is a community of 966,155 amazing developers

We're a place where coders share, stay up-to-date and grow their careers.

Create account Log in
Cover image for 20 principles I learned from 10 years of developing software
Ondrej Sevcik
Ondrej Sevcik

Posted on • Originally published at ondrejsevcik.com

20 principles I learned from 10 years of developing software

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.

  1. Be humble - No engineer in the world knows everything, the same applies to you.
  2. Make it work, make it right (and sometimes make it fast).
  3. Optimize for change - Prefer duplication over the wrong abstraction.
  4. Always write tests - If you're not writing tests, you're testing manually.
  5. Solve 80% of use cases - You never gonna solve everyone’s problem.
  6. Prefer functional programming - It's easier to understand. If your code requires a Ph.D. to understand, you’re most likely doing it wrong.
  7. Delete as much code as you can
  8. Good Enough is Better than Perfect - Don't discard meaningful improvement just because it's not perfect.
  9. Criticize in private, praise in public
  10. Make notes - If you think you will remember it, you're lying to yourself.
  11. Talk to your users - The best software is built by engineers who have empathy for their users.
  12. Learn with intention - Practice with a clear and specific goal in mind - what you want to improve and exactly how (deliberate practice).
  13. Do not generalize early - Wait until you have at least 3 duplicates of code before you make an abstraction (aka. Rule Of Three).
  14. Fix broken windows - One hack in code leads to another hack. Soon your code will become unmanageable.
  15. Fix the problem - doesn't matter whose fault it is, it is your problem.
  16. Do what works, not what's fashionable - Try it first with a small team. If it works, expand. If not, abort.
  17. 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.
  18. 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.
  19. 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.
  20. Perfect code doesn't exist - It's better to accept this as a fact rather than wasting time and chasing the impossible.

Top comments (37)

Collapse
 
ravavyr profile image
Ravavyr

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.

Collapse
 
mwarren2 profile image
mwarren2

Perfect list, but the tops would be:

  1. Make notes

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

Collapse
 
othimar profile image
PΓ©lΓ© Oussoumanou

Good job. (l'm applying point nΒ°19πŸ˜€)

Collapse
 
chemwenochelsea profile image
Chelsea Chemweno

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

Collapse
 
lexiebkm profile image
Alexander B.K.

"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.

Collapse
 
lorenzotenti profile image
Lorenzo Tenti

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.

Collapse
 
lexiebkm profile image
Alexander B.K.

Lambda expression ? Yes, it is a good addition to the language. C# has it too.

Collapse
 
eecolor profile image
EECOLOR

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:

  • Immutability
  • Composition
  • Single responsibility

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.

Collapse
 
andrewharpin profile image
Andrew Harpin

I think he means procedural.

Functional is a terrible name for the alternative

Collapse
 
allobrox profile image
Tamas Rigoczki

Thanks Ondrej, these are very valuable.

Collapse
 
rooneyhoi profile image
Dax Truong

Couldn't agree more. Thanks for the great list

Collapse
 
biffbaff64 profile image
Richard Ikin

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.

Collapse
 
arielbk profile image
arielbk

Criticize in private, praise in public

Praise for good work

I especially like these ones!

It reminds me of the Charlie Munger quote,

Praise by name, criticize by category

which was reinterpreted by Naval Ravikant as,

Praise specifically, criticize generally

Collapse
 
stevepenner profile image
Steve P.

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.

Collapse
 
samuel_kelv profile image
Samuel Kelv

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.

Collapse
 
hamzaelkotp profile image
Hamza Elkotb

helpful article i like this list of advice,
but what do you mean with point number 4?

Collapse
 
ondrejsevcik profile image
Ondrej Sevcik Author

If you don't have automated test for the software, you have to test it manually - like really running the software and checking if it does what it's supposed to do.

Collapse
 
hamzaelkotp profile image
Hamza Elkotb

Thank you so much

Collapse
 
kissu profile image
Konstantin BIFERT

Love the Criticize in private, praise in public. Is it specific to you or more towards the others?

Collapse
 
elabftw profile image
eLabFTW

I really agree with this list. Especially number 7 (Delete code).

Collapse
 
somtookaforr profile image
Somtochukwu Okafor

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.

Some comments may only be visible to logged-in visitors. Sign in to view all comments.

Take a look at this:

Settings

Go to your customization settings to nudge your home feed to show content more relevant to your developer experience level. πŸ›