In traditional programming languages like Java or C++, null is a member of all reference type. It’s used to model that one value is either unknown or non-existent. Tony Hoare invented it in 1965 and now described it as a billing dollars mistake.
This led me to suggest that the null value is a member of every type, and a null check is required on every use of that reference variable, and it may be perhaps a billion dollar mistake.
For example, you defined a Person class and created a group of person objects. All of them have the same attribute and behavior. But secretly, the language injects null into this group. …
And how to use events to build agile and predictive enterprise
It’s all about business
As pointed out in this post From Programmer To Business Enabler:
The software itself is not an industry, but it’s eating the other industry.
IT system now is the nervous system of the whole enterprise. It enables almost every step of the business process, enable the enterprise to respond to the environment in a timely fashion. There are three areas that one better IT system can contribute to improving business performance:
- Timeliness: How quick can enterprise respond to an event
- Agility: How quick can enterprise update its business process to respond to an event
- Awareness: How quick can enterprise put the right information at the right level. …
and how they bring agility to your enterprise
The problem with monolith application
You have been working on a monolith application for a long time. As time goes, a lot of feature request made the initially perfect design not that perfect anymore. No matter how much effort you put to keep the module separated and layered, there will always be more and more coupling, and it will become more and more expensive to envolve. You hope you will get a chance to start over.
The problem with monolith application is not the code quality. It’s the wrong engineering approach. …
And it will save more time in the future
I skim through this topic in this post: separate business logic from error handling. But this topic seems well worth dig much deeper. I have seen in many codebases, error handling is just afterthought of the design phase and most likely are just randomly plugged in. This post will give some thought food about why and how of error handling in our daily practice.
It’s all about signal/noise ratio in your code
As programmers, we use code to solve problems for our business. If we think harder, write less code, our business will bear less maintenance cost in the long run. In most cases, error handling code won’t provide business values. On the other side, the error-handling code is more complicated than happy path code and is difficult to get it right. …
And keep it soft in the long run
Software is Hard
Peoples generally think that software is pretty soft and easy to change. It’s right in some sense, if we don’t need to guarantee the software we changed still work. Any experienced programmer will tell you that software is hard to change, and will only get harder and harder over time.
What soft means
Let’s go to the dictionary and find out what soft means. Below is the first definition from dictionary.com:
yielding readily to touch or pressure; easily penetrated, divided, or changed in shape; not hard or stiff:
So peoples are right. …
And how it can help you advance further in your career.
You love coding, great. After practicing in this industry for many years, sometimes, you may be wondering what’s the next step. To survive as a programmer, we always have to write working code and learn new technologies. But to be a great developer, there is something deeper that we need to grasp. This post gives a list of those crucial aspects that may help you advance further in your career.
Understand the Problem Space
Any software development requires two types of knowledge, technical knowledge and domain knowledge. Many programmers put a lot of effort into the technical side and assume that domain knowledge will slowly build up over time. It would be much better if we intentionally put efforts into learning the domain and try to understand it in a bigger picture. …
And improve your productivity in the long run
Why should we write simple code
As programmers, one of our most important tasks is to manage complexity. Cognitive load in our code is one primary source of it. If our code is only made up of dull statements, no decision points in between, no fancy data structure or algorithm, the cognitive load is much lower.
Of course, there are cases that we need to use advanced algorithms, maybe for performance reason. Then as a last resort, we should encapsulate them with boring interfaces, with a meaningful name and minimum parameter.
First thing first, try your best to avoid code
The simplest code we could ever produce is no code at all. Code is easy to create but hard to remove. Each developer should have a mindset that your code is your debt, not asset. …
About
