He/Him; Senior Software Developer, IT Swiss-army-knife.
Lots of coding, some hardware, some devops & sysops, some micro-controller electronics.
I used Arch BTW :)
"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...
30+ years of tech, retired from an identity intelligence company, now part-time with an insurance broker.
Dev community mod - mostly light gardening & weeding out spam :)
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..)
"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.
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.
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.
30+ years of tech, retired from an identity intelligence company, now part-time with an insurance broker.
Dev community mod - mostly light gardening & weeding out spam :)
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
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.
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!
French software engineer with 15 year experience on 3D data visualisation and processing. Lots of C++, and switch to Unity recently.
I like when it run fast 😉
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.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
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.
"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...
for me:
"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.
I find myself coming back to this one
In computer programming and software engineering, the ninety-ninety rule is a humorous aphorism that states:
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.
"Use the duck Luke" 😁
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.
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."
Great!
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!
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.
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.
Top 10 Coding Principles Every Developer Must Know
Mr. Unity Buddy ・ Jul 12 '21 ・ 7 min read
use small dedicated solutions over all included frameworks
TDD
DDD
SOLID
KISS
DRY
Clean Code
Use design patterns if it's possible. Refactor if not.
Keep is simple...