5 years have passed since I had started working as a professional software developer. Although the programming was my hobby since the early years, my skill started to grow when I had taken a real job.

I was surprised when I had recalled my very beginning because I noticed how much I had changed and how big progress I had taken. So, I decided to write it down.

In this article, I’ll take you on a short journey where I’ll tell you about my development process. You’ll find out what I’ve been thinking about, what I’ve been working on and ultimately what changed from my perspective. Ready?

Junior developer writes working code

Everybody, who started programming knows, that the first of most enjoyable moments is when a program starts to work. It doesn’t matter it writes a static text on the screen, shows a message after button pressing or does a less ambitious job. It works.

At this stage, nobody thinks about architecture. At least I didn’t think. I was fascinated by what I can program yet. Bots to various games, simple website or even more advanced CMS systems. The more experimental projects, the better.

Over time, more advanced projects appear, and with them the first major problems. Problems with the code structure, duplication, readability, and other mess, that lead to increasing frustration. It takes a lot of time to introduce changes and the outcome is rarely satisfactory.

The lack of knowledge about basic patterns can stop even the most ambitious project. The code becomes unmanageable. In the outcome, it’s easier to discard everything and start writing from scratch. Unfortunately, with the same effect.

Some smart people and interesting books have suggested what can I do with it. Making use of rules such as SOLID, DRY, and KISS was the first suggestion I read – I don’t even know where. It sounds great in theory. However, these rules are problematic even for more advanced programmers, let alone beginners.

The solution seems to be the use of design patterns. They will be my basic tool at work soon.

The use of design patterns

During discovering the programming world, I figured out, that most of the problems I had struggled with had been already solved. Some of them were generalized enough to fit into known design patterns, e.g. those proposed in the book of a gang of four.

The whole idea behind design patterns was encouraging. They provide battle-tested solutions for specific problems. For me, as a beginner programmer, it was a way to put a piece of code in a good place in a good way.

Overuse of design patterns

Design patterns were such a great tool, that it seemed almost a mistake to write the code without using them. In the outcome, after some time I saw the possibility of using a design pattern everywhere. Even where it was not needed.

At first, having a generalized solution to every problem seemed like a good idea. Most often, however, the problem became a cluster of abstractions. What he did was deeply hidden in the code.

Now I know that the design pattern is some kind of framework to solve the problem, but it is not a ready solution in itself.

In this time, I’ve been writing most of the solutions by myself. I didn’t want to use ready-made solutions such as frameworks or libraries. On the one hand, it was good because I learned and understood a lot of things when I had to implement them. On the other hand, it required much more time, but the results were rarely satisfactory.

The design pattern is a generalization of the solution, rather than the solution itself. It provides some kind of framework to solve a specific problem.

When I got bored with writing the same things over and over again, my attention switched towards ready-made solutions.

If there is a problem, there is also a library that solves it

I joined in the framework-world quickly. They have added extra restrictions, especially when it comes to the code writing. In the result, they made the work more structured. Frameworks also have had a lot of components that increase the speed of development.

If there is a problem, it’s very likely that there is also a library that solves it. I got used to this approach very fast.

Focus on ready-made libraries instead of solutions

The confidence that there is a library for every problem got me into troubles. Instead of focusing on solving problems, I spent a lot of time looking for a library which would solve it for me. I usually found what I had been looking for and finally, I solved the problem. It doesn’t mean that everything was seamless. Most of the time, third-party code put extra restrictions, which turned into other problems, especially in some more specific business cases.

After some time I started looking very carefully to each library I would incorporate into my project. If I need to spend extra time to adjust functionality to requirements, maybe it’s worth to write it from scratch? In time, more question emerged, e.g. if I use another library, will I have fewer or more problems? Does it solve my problem?

Problem solving

At some point in my career, I understood, that solving problems is not about writing software at all costs. Some classes of problems could be solved by existing software. The key is to know what could be used.

Listening to the client’s needs

I’ll give you an example. Let’s assume that you receive a request about making an application to generate summaries and reports from the company. The client, however, has a very limited budget. You’re not so interested in this cooperation but for some reason, the client reached you or your company.

This should lead you to a few questions, that you should answer.

• Why did the client get to me? Do I aim right customer group?
• Since this client has already asked me, how can I help him?
  • Does the client need a dedicated software?
  • If he doesn’t need dedicated software, is any other tool that I could offer him instead? E.g. Microsoft Excel, Calc from Libre Office or any other spreadsheet?
  • Could I recommend the client to another company specialized in problems that the client needs to resolve?
  • Could I do anything for the client in his budget?

As you can see, not everything has to come down to writing code. If it does, it should take care of solving an actual client’s problem to meet his needs.

Architecture, paradigm, language, framework are only tools, which have the one important task. They are to help in solving a domain problem.

You’ve noticed, that I write lots about problems. I don’t mean the challenges we set for ourselves as programmers by choosing architecture, paradigm or framework. They are our tools, that are designed to help solve the higher level problem, usually a business problem or more generally – a domain problem.

Solving domain problems

Domain problems are the most interesting because they need more than programming knowledge. You need also a specialized domain knowledge. They’re real challenges, that require from the programmer constant improvement and willingness to learn new things, which are not necessarily related to the IT world.

There is where the famous DDD acronym – Domain-Driven Design – appears. It is a holy Graal to every programmer aspiring to be an architect or a domain designer. It’s a place, where developers know what the business expects and, at the same time, the business feels that developers understand its needs.

To make it possible, you should discard all things that introduce unnecessary noise. You may use them only where it’s necessary to solve the problem. You should simplify complicated things, and you should make simple things even simpler.

The favoring of simplicity drives to the situation, where a developer starts to write a code that just works. And it’s simple.

Senior developer writes working code

I’m not looking for projects which I could do in my favorite framework or with the usage of currently top-fashioned architecture. I don’t try to replace each loop by an iterator and I don’t try to complicate things that can be simple.

I don’t reinvent the wheel and I use tools which are designed to solve specific problems. Each written line of code is something that needs maintaining in the future.

Instead, I help others in solving their problems. I try to understand what they need and I suggest the best solution to a specific problem and situation.

Moreover, I also take advantage of the generosity of other programmers who share their knowledge and work. I try to do the same by showing how to write good code and by sharing my knowledge and experience as well.

When I write code, I know, that I’m not the only one who will be reading it. Many eyes will be reading and trying to understand how given functionality was implemented and what it does. My job is to help others understand this.

All these things combined with my experience are my workshop. Thanks to which I can effectively solve further problems, constantly improving myself. Every day I get to know new things and I decide, which of them I can include in my workshop.

Summary

I share my thoughts because I want to show you how at different stages of my life and career I have changed my perspective and my way of thinking.

Once I tried to write as much as I could by myself. Another time I was looking for ready-made solutions. Then I tried hard to use what I had learned. It took me years to learn how to do it well.

As you can see, a lot of things changed – in my opinion for the better. Changes are visible consequences and proof of making progress. However, they are not the result only of the passing time.

Changing a job, other people, maintaining healthy relationships, environment, study, and books. They are some of the most important elements that have influenced my way of thinking. That’s why is so important to open yourself to new experiences and confront your thoughts with new ideas.

What I have described here is my journey, which doesn’t necessarily coincide with yours and probably will not. However, if you somehow identify with what I have presented, please tell me about it by leaving a comment or by e-mail.

This isn’t the end of the journey.

Before we say goodbye, I would like to leave you with one thought – What is the most important change you see in yourself, in comparison to yourself from a year ago?

Featured photo by Émile Perron on Unsplash.