-
Rule of least surprise
Rule of Least Surprise says: anything ( some it system in our case) should behave in the way that causes the least surprise to people, users, us. We all love suprises we feel good about… not the biggest fans abotu those bad or negative experiences. Surprise creates confusion, bugs, and lost trust. Prefer predictability over cleverness. Think about it… when you call a function, you expect it to do what it says, not sneak in extra behavior. Silent mutations are a classic trap. Side effects are unknown to the user. Trust me, the user will NOT FIGURE IT OUT. Passing an object and having it changed behind your back. Magic…
-
Another clean code bullet points to remember
Some thoughts after reading a lot of stuff lately and working on totally diferent things. It is just another clean code bullet points compilation to remember or recall every know and then. I know that nobody is capable to remember about all of it all the time. God knows it cannot implemented anyways. I love how people dance cause inventing 3 layers of abstraction to avoid simplicity 🙂 Let us remember the most noble truth of them all… Common sense… Like a brain, remember to use it.
-
Why bother with Vue composables – 6 reasons to do
Why bother with Vue composables ? So it will make our lifes easier, more straightforward coding and simplified testing to say the least. Composables in Vue.js are functions that encapsulate business logic and allow it to be reused across different components. Your regular dependency inversion, composition or what ever You want to call it. Designed to make it all simple and pleasurable. Why Use Composables? Reusability Composables encapsulate logic that can be reused in multiple components. One ring to rule them all. One place to change them and in a component bind them. Something like pinia store. For example, if geospatial filtering logic is needed in more than one place,…
-
Typescript perfect sync – 3 tricks to keep it tight
Typescript perfect sync can be kept using couple of strategies. Most of us start with simple union types, like this: const ScenarioStatus = 'success' | 'fail' | 'error' | 'other'; So far so good. That works great… until you need to iterate over those values for rendering, validation, or other logic. And now You are stuck with two separate definitions: one array for logic, and one string union for the type. Sooner or later, they’ll fall out of sync and provide headaches to people. You could go for en enum…. Below behold the three TypeScript tricks to make your code tight, hard to break, cleaner, safer, DRYer and resistant to…
-
Estimations in sprints are ludicrous ?
Estimations in sprints are ludicrous ? We switched from fibonacci complexity to just plain man day. Estimating work in sprints has become a cornerstone of Agile | Scrum methodologies More and more evidence suggests it often creates more problems than it solves. On the other hand it is a nice “form” You can wrap Your work into. It is a nice template. Teams routinely face mismatches between predicted complexity and actual time investment. Exacerbated by meetings that should be an email, administrative overhead and tasks like code reviews. The Fallacy of Sprint Estimation is why complexity metrics miss but do we have anything better ? The complexity is time disconnected…
-
Lauers Law – why less code is better
Lauers Law – why less code is better as a very solid idea. Just remind Yourself about all those DTOs that could be a simpler one with a mapper or a dedicated if-else-tree somewhere around data transformation. It challenges developers to prioritize efficiency and elegance in their coding practices, ultimately leading to cleaner, easier to understand and more maintainable systems. The Essence of Lauer’s Law At its core, Lauer’s Law emphasizes that reducing the amount of code can lead to better outcomes. The principle suggests that if developers had twice as much time, they could create a system with half the code while maintaining or improving its quality. The idea…
-
The philosophy of unix – 9 commandments
The philosophy of unix is a guideline of standards and software design & philosophy approaches : Elaboration : The philosophy of unix is a universal approach to any development, not only software 😉
-
Chestertone`s Fence in coding and not only
The Chestertone`s Fence in coding is the principle named after the writer G.K. Chesterton. Serves as a critical reminder in programming and software development: before removing or altering existing code, one must understand why it was implemented in the first place. This principle is universal for life. Emphasizes the importance of historical context and the potential consequences of change, especially a quick and fast one. Urging developers to approach modifications with caution and respect for prior decisions. Even if they are unknown or seem meaningless. Understanding the Chesterton`s Fence Chesterton`s Fence principle, at its core, suggests that every piece of code, no matter how outdated or unnecessary it may seem,…
-
A Philosophy of Software Design by John Ousterhout – review
A Philosophy of Software Design by John Ousterhout is a great book. Period. I would say that it is a great additional to reading Clean Code. Clean code in my opinion is dry and very… strict ? Not much room to fiddle around with rules set by Uncle Bob the Guardian of the Clean Code. John Ousterhout provides us with a more kind and flexible approach without strict, dry rules to follow. Since the book was wrote by a professor at Stanford that had classes it might get a bit technical when John goes through the different code sets but it does print a better picture of the whole problem.…
-
How to write code – part 1
How to write code ? Writing Code for Future Comprehension. How to write code In the “fast-paced” world of software development is a very tricky question… The ability to “write code so in one year you or anyone else will be able to easily understand what it is about” can be a crucial skill. This practice not only enhances the longevity of your projects but also significantly improves team collaboration and code maintenance. Gives a lot less headaches also. Let’s explore why this approach is essential and how you can implement it in your coding practices. As always.. take a grain of salt with a dose of common sense… The…
