We Live in an Era of an "Industrial Revolution" in Programming

Sun, 12 Apr 2026 08:10:14 +0300

While thinking about what is happening in IT right now, one analogy suddenly came to mind. We are living through a kind of industrial revolution in programming.

Until recently, we programmers wrote a lot of code by hand. We spent most of our working time typing code and assembling the final system out of many small parts ourselves. Now that coding agents have appeared, writing code has become very fast and cheap. More and more work is done not through manually typing lines, but through expressing intent: what exactly you want to get in the end, how it should work, and which constraints matter. The agent then tries to turn that into an implementation.

Something very similar happened during the Industrial Revolution. Before factories, there was a lot of manual labor and craft-based production: things were made slowly, expensively, and depended heavily on the skill of a specific person. Then factories, mechanization, standardization, and mass production arrived. A huge layer of manual labor was automated. Craft did not disappear completely, but it became more of a niche form of work. It seems to me that the same thing is now happening to code. AI agents are automating code writing, while writing code by hand is gradually turning into a kind of craft labor.

But that does not mean a programmer’s work has lost its value. Its form is changing, and so are the tools. Other engineering practices have not gone anywhere. On the contrary, their value has increased dramatically. If coding used to take up 70-80% of the time in product development, now for many people it shrinks to 10%, and everything else becomes more important: product thinking, client communication, requirements analysis, architecture design, UX, communication inside the team, acceptance of the final result, QA, and product support through metrics and observing what is actually happening in the business.

About ten years ago I started out as a full-stack developer. At that time the split between backend and frontend was only beginning to take shape. Why did it appear at all? Because complexity was growing. Each side developed its own difficult specifics, and keeping all of that in one person’s head became harder and harder. Over time I specialized more in backend, in the server side. Then, as products grew, I became more involved in architecture, thinking through how everything should be organized, doing team lead work, and actively participating in processes inside the team and in collaboration between teams.

Since January of this year I have been diving much deeper into agent-based programming. And now I once again feel like a full-stack developer. My technical capabilities have grown dramatically. I am no longer afraid of building UI products in React. Before that, I was simply too lazy to dive deeply into it: my serious immersion in frontend had ended back in the jQuery era. I understand the general principles, but I did not want to spend time learning the modern tools. Now, to a large extent, that is no longer necessary. What matters most is being able to formulate tasks clearly for the agent, understand what result you want, and see potential bottlenecks and problems in advance. That is why a broad technology horizon has become much more important now.

The whole point can be summed up in a very simple phrase: we live in an amazing time. Our profession is changing, and we are changing with it.

Reducing nil pointer panic risk with the Null Type pattern

Sat, 05 Apr 2025 00:00:00 +0000

In the previous article (Russian) I looked at the risks of nullable types. In Go such data is usually modeled with pointer fields, but there are other approaches. This post covers the Null Type pattern, which reduces the chance of nil pointer panics.

Problem context

Suppose we handle an HTTP request whose contract allows nullable types. The payload has two fields: name (null means “no name”) and count (null means “no count”). A JSON schema for this contract might look like this:

type: object
properties:
  name:
    type: [string, null]
  count:
    type: [object, null]
    properties:
      value:
        type: integer
      unit:
        type: string

We can model that in Go as follows.

type Request struct {
    Name  *string `json:"name"`
    Count *Count  `json:"count"`
}

type Count struct {
    Value int    `json:"value"`
    Unit  string `json:"unit"`
}

Pointer fields demand care: you must always check for nil.

var r Request

// ...

if r.Name != nil {
    *r.Name = strings.TrimSpace(*r.Name)
}

if r.Name == nil {
    fmt.Println("no name")
} else {
    fmt.Println("name: ", *r.Name)
}

if r.Count == nil {
    fmt.Println("no count")
} else {
    fmt.Println("count: ", r.Count.Value, " ", r.Count.Unit)
}

Comparing these fields is also non-trivial.

func main() {
    var r1, r2 Request
    if EqualCount(r1.Count, r2.Count) {
        fmt.Println("equal count")
    }
}

func EqualCount(c1, c2 *Count) bool {
    if c1 == nil && c2 == nil {
        return true
    }
    if c1 == nil || c2 == nil {
        return false
    }
    
    return *c1 == *c2
}

Null Type pattern

To lower nil pointer risk, you can use the Null Type pattern. Examples appear in the standard library (sql.NullString , sql.NullInt64 ) and in popular packages (e.g. google/uuid ). The usual recipe is a dedicated type with methods for encoding and decoding:

Scan(), Value() — database encoding/decoding;
MarshalJSON(), UnmarshalJSON() — JSON;
MarshalText(), UnmarshalText() — text;
MarshalBinary(), UnmarshalBinary() — binary formats.

Below is an implementation for our contract, assuming the types are used with JSON and a database.

var jsonNull = []byte("null")

type NullString struct {
    String string
    Valid  bool
}

func (s *NullString) Scan(value any) error {
    var ns sql.NullString
    if err := ns.Scan(value); err != nil {
        return err
    }

    s.Valid = ns.Valid
    s.String = ns.String

    return nil
}

func (s NullString) Value() (driver.Value, error) {
    if !s.Valid {
        return nil, nil
    }

    return s.String, nil
}

func (s NullString) MarshalJSON() ([]byte, error) {
    if !s.Valid {
        return jsonNull, nil
    }

    return json.Marshal(s.String)
}

func (s *NullString) UnmarshalJSON(b []byte) error {
    if bytes.Equal(b, jsonNull) {
        s.String, s.Valid = "", false

        return nil
    }

    if err := json.Unmarshal(b, &s.String); err != nil {
        return err
    }

    s.Valid = true

    return nil
}

Because Count is composite and might map to two DB columns, we skip Scan() and Value() here and only add MarshalJSON() and UnmarshalJSON().

type NullCount struct {
    Count Count
    Valid bool
}

func (c NullCount) MarshalJSON() ([]byte, error) {
    if !c.Valid {
        return jsonNull, nil
    }

    return json.Marshal(c.Count)
}

func (c *NullCount) UnmarshalJSON(b []byte) error {
    if bytes.Equal(b, jsonNull) {
        c.Count, c.Valid = Count{}, false

        return nil
    }

    if err := json.Unmarshal(b, &c.Count); err != nil {
        return err
    }

    c.Valid = true

    return nil
}

Usage example

Rewriting the earlier snippet with the Null Type pattern:

var r Request

r.Name.String = strings.TrimSpace(r.Name.String)

if !r.Name.Valid {
    fmt.Println("no name")
} else {
    fmt.Println("name: ", r.Name.String)
}

if !r.Count.Valid {
    fmt.Println("no count")
} else {
    fmt.Println("count: ", r.Count.Count.Value, " ", r.Count.Count.Unit)
}

var r1, r2 Request
if r1.Count == r2.Count {
    fmt.Println("equal count")
}

What changed?

Some redundant Valid checks can go away (they used to be mandatory).
Core business logic still checks Valid where it matters.
Comparison becomes trivial: r1.Count == r2.Count (only if every field of the struct is comparable).
Field paths get longer: r.Count.Count.Value.

Initialization is a bit more verbose.

var r Request

r.Name = NullString{Valid: true, String: "name"}
r.Count = NullCount{Valid: true, Count: Count{Value: 1, Unit: "kg"}}

Constructors fix that.

func NewNullString(s string) NullString {
    return NullString{Valid: true, String: s}
}

func NewNullCount(value int, unit string) NullCount {
    return NullCount{Valid: true, Count: Count{Value: value, Unit: unit}}
}

Then:

var r Request

r.Name = NewNullString("name")
r.Count = NewNullCount(1, "kg")

You can also add helpers or proxy methods.

func (c NullCount) String() string {
    if c.Valid {
        return c.Count.String()
    }

    return ""
}

func (c NullCount) Add(next NullCount) (NullCount, error) {
    if c.Valid && next.Valid {
        sum, err := c.Count.Add(next.Count)
        if err != nil {
            return NullCount{}, err
        }

        return NullCount{Valid: true, Count: sum}, err
    }
    if c.Valid {
        return NullCount{Valid: true, Count: c.Count}, nil
    }
    if next.Valid {
        return NullCount{Valid: true, Count: next.Count}, nil
    }

    return NullCount{}, nil
}

Alternative

The Null Type pattern is not the only option. With many fields it can hurt readability. If a pointer is acceptable for the whole struct, nil checks inside methods may be simpler—but you must:

use pointer receivers on all methods;
guard the receiver against nil in every method.

Example for Count:

func (c *Count) String() string {
    if c == nil {
        return ""
    }

    return fmt.Sprintf("%d %s", c.Value, c.Unit)
}

func (c *Count) Add(next *Count) (*Count, error) {
    if c != nil && next != nil {
        if c.Unit != next.Unit {
            return nil, fmt.Errorf("unit mismatch")
        }

        return &Count{Value: c.Value + next.Value, Unit: c.Unit}, nil
    }
    if c != nil {
        return c, nil
    }
    if next != nil {
        return next, nil
    }

    return nil, nil
}

Conclusion

The code becomes safer and often clearer. Benefits of the Null Type pattern:

No nil pointer panics from these fields.
Easier comparison of comparable structs (no custom Equal with nil branches).

Applying it everywhere can overcomplicate the codebase. It fits primitives and small structs best; for large structs, prefer other safe-design techniques.