Image for post
Image for post
Photo by Philipp Berndt on Unsplash

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


Image for post
Image for post
Photo by Kyle Glenn on Unsplash

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

Image for post
Image for post
Photo by Eric Muhr on Unsplash

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


Image for post
Image for post

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


Image for post
Image for post
Photo by Robert Baker on Unsplash

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


Image for post
Image for post
Photo by Markus Spiske on Unsplash

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


Image for post
Image for post
Photo by Khai Sze Ong on Unsplash

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

Liu Tao

Microservices developer in payment industry, https://www.linkedin.com/in/tao-liu-241b559/

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store