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. …
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:
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. …
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.
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. …
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.
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. …
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.
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. …
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.
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. …