What are your software development principles?

Anything you live by?

Comments

[Ryan Brown]

"Always check your assumptions"
This comes into play best when debugging. Assuming an input has a specific value (or even a value at all), assuming a method is being called, assuming a library works as you think it does, assuming that your deployed code and configuration is as you expected it to be, assuming debug and release will behave the same in all circumstances...

[Phil Ashby]

for me:

• Use a Decision Log (probably a pool of ADRs in version control + associated tests - you've got tests right?)
• Keep It Simple Stupid ('cause simple code is maintainable code eg: interfaces only where implementations will change, consider monolith before microservices, etc.)
• You Ain't Gonna Need It (just enough code to pass the tests.. you've got tests right?)
• Refactoring Is Always Valuable (tidy code is simple code, simple code is maintainable..)
• Feedback is King (as change is inevitable!)

[CitronBrick]

1. Follow code conventions: Indentation, Case
2. Name variables/functions/classes appropriately.
3. Use small private helper functions.
4. Don't let error cases/ exceptions slide off quietly. Just log them.

[Anurag Vohra]

"If I had eight hours to chop down a tree, I'd spend six sharpening my axe".

Always write agorithm before, you start coding. When you write, many problems becomes evident, which you can remove right there. Once it become satisfactory, it become too easy to code.

[Ben Halpern]

I find myself coming back to this one

Ninety–ninety rule

In computer programming and software engineering, the ninety-ninety rule is a humorous aphorism that states:

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

View on Wikipedia

[lando calrissian]

The Debugging Paradox: The harder you push to find a bug, the more elusive it becomes. The moment you step away from the keyboard, the solution suddenly becomes clear.

[Phil Ashby]

"Use the duck Luke" 😁

[Jean-Michel 🕵🏻‍♂️ Fayard]

It's not really a paradox than a developer can think more clearly when she is relaxed under the shower than when she is stressed and glued behind a computer screen.

[Nicholas Hutchind]

It's very small and simple, but:

"Continuous Improvement: Feeling dissatisfied with your past code is natural and appropriate. It shows an understanding of your evolving skills."

[Jannis]

Great!

[Oscar]

Keep it simple, but also follow basic workflows. I have a whole list of them, like what to do for incorrect function returns.

It's not rigid at all, but I often find myself doing the completely wrong thing, so basic workflows (or problem flows, if you will) tend to be helpful!

[Thibaut Andrieu]

KISS - YAGNI

I cannot count the number of time I've heard "This interface will be useful next quarter when we will address this requirement".
Finally, priorities change, and your beautiful useless abstraction just become yet another over-designed layer developers have to deal with every day of their life...

If your abstraction have a single implementation, you didn't built and abstraction. You just built a pass-through layer over your specific case.

[Jean-Michel 🕵🏻‍♂️ Fayard]

Programming is very simple: you learn all the best practices, and then you forget about them and focus on what your colleagues and your customers need.