A while back I stood in front of the whiteboard in my home office and tried to map every language, stack, and framework I had worked with across three decades. The list grew quickly: Lotus Macro Language, dBase, Clipper, FoxPro, Visual Basic, Classic ASP, .NET, C#, Web Forms, WinForms, WPF, HTML, XML, XSLT, JavaScript, TypeScript. Beside them I wrote the paradigms and practices I had picked up along the way: procedural, object-oriented, functional, CRUD, CQRS, task-based UI, event sourcing, BDD, TDD, DDD. The left side was a resume. The right side was where I had actually been beaten up.
Looking at that map, I took most of my bruises from changing how I thought about problems. A new keyword or a different way to declare a variable only takes a short.
I started in procedural code. You wrote lines from top to bottom, and when things got too long you learned to group them into procedures. A thousand lines became a procedure with a parameter, then another procedure with another parameter. It was tidy enough until the data and the behavior kept drifting apart. When object-oriented programming arrived in my world, I saw a class as a bucket for related procedures. I missed abstraction, encapsulation, inheritance, and polymorphism. I saw a folder. That misunderstanding cost me years. Later, I could have been writing C# that looked like procedural Clipper with curly braces, but I learned better, fortunately.
The next jolt was passing behavior around like data. In C# 1.0, delegates meant a object-oriented pointers to a function (at least that’s how I thought of them). The idea that you could hand a block of code to another block of code felt strange.
Then LINQ arrived, and I thought “It looks like SQL.”
Until I tried to learn a little more about lambda expressions, and suddenly I was supposed to compose queries out of functions. I had spent years thinking in terms of getCustomerById. Then I looked at customers.Where(c => c.City == "New York") and saw the code describing the shape of the question instead of spelling out the lookup. That small arrow changed how I structured solutions.
The progression is clearer to me now than it was then:
// procedural: ask for a value
SomeProcedure("value");
// object-oriented: ask an object to act on another object
someObject.SomeMethod(anotherObject);
// functional: pass the behavior itself
someObject.SomeMethod((something) => { /* decide here */ });
Each step adds a layer of indirection, and the real shift is in who owns the decision. First the function owns it. Then the object owns it. Then the caller can pass it in. The shift changes how responsibility is modeled.
Testing was another paradigm shift dressed up as a tool. At first I ran the program, clicked through screens, and fixed what broke. Then I wrote tests after the code. Then someone suggested writing the test first. The first time I heard that, it sounded backwards. How do I test something that does not exist? After more than twenty years of doing it, the question sounds as odd as the first time I used a delegate. The test becomes the question you are trying to answer, and the code becomes the answer. That changes the design entirely.
Some shifts took longer than others. I have coached .NET developers who learned the language in year one and then wrote year-one code for the next twenty. They had missed object-oriented design, functional patterns, and SOLID. They could read and write C# without thinking in it. They were fluent in syntax and foreign to the grammar. The real risk of tool marriage is that you stop learning how to think with it long before the tool disappears.
Every one of these shifts was uncomfortable. There was a period where the new idea felt wrong, where my existing mental models fought back, and where I wanted to call the new thing stupid and go back to what I knew. The discomfort comes with learning. Once I accepted that, the shifts became easier to spot. I started asking “what does this language let me express?” more than “what does it do?” Procedural code lays out a sequence. Object-oriented code assigns responsibility. Functional code transforms data. Test-first states the intent before the implementation.
The shifts that hurt the most have also been the most useful. TDD, BDD, domain-driven design, functional composition, and event sourcing were all harder than learning a new syntax. They required me to think in English before I thought in code, to name the problem before I named the variable, and to admit there were other ways to build. Moving from one stack to another without losing the thread is easier when the thread is the thinking; the language changes with each stack.
This is the inner work. The architecture companion to this post is the outer shift: moving from database tables to the tasks people are trying to complete. It follows the same rule:
- First you learn to think differently inside the code,
- then you learn to structure the system around human intent.
Syntax is easy once you can read it. The shifts that change how I structure solutions are the ones I still practice.
Further reading
- Thinking in Multiple Languages
- From Conversation to Code
- Testing Behavior Not Implementation
- The Bottleneck Is not Code It is Translation
Leave a Reply