5 most valuable things I learned in my 10+ year career

Back in late 2008, I started to work as a Junior Java Developer at a middle-sized company in the finance sector. Today I work at ePages, but overall I’ve been working as a developer (mostly with JVM-based languages) for almost 13 years. Along the journey, I came across many different types of people, organizations, cultures, and obviously software. With this post, I want to present the 5 (for me) most valuable things I learned in my 10+ year career. Let’s break it down.

1. Emotional intelligence

Many young developers want to become better at coding. But looking back, coding was the simpler task compared to dealing with conflicts, people, or problems you need to solve. At this point, emotional intelligence is very useful. You have probably heard this term before. But what does it mean, you may ask?

Basically, it consists of 4 parts:

1. Perceiving emotions: The ability to realize the emotions of people. This includes facial expressions, gestures, posture, and voice.
2. Using emotions: The ability or knowledge to use your own and other people’s emotions to ease cognitive activities, e.g. problem or conflict solving.
3. Understanding: The ability to analyze emotions and how these can change over time.
4. Managing: The ability to influence your own emotions or those of other people.

2. Think about ‘The Big Picture’

The big picture can have a lot of meanings, depending on the person you ask. While working on projects or products, usually you become the expert of your team’s domain. Many developers tend to overestimate the importance of their own domain in the system.

Let’s assume there are 3 views on that:

• Business: How to be more successful as a company, and how can this be achieved?
• User: How can you provide value to the end-user or customer with the code you write?
• Technology: How to build software that is robust and lasts long (clean and homogeneous architecture, efficient, low memory usage etc.)?

When you start working on new tasks, it is always helpful to know the answers to the what-why-how questions. Usually, these questions always helped me to get a grasp at the big picture:

• have the end in mind (what?)
• understand and challenge the requirements (why?)
• connect the dots (how?)

3. Become a T-Shaped person

Many people argue if you should become a specialist or generalist in your industry. For me, the answer is a simple yes and no. But first, we need to understand what being a T-shaped person means:

I always had the ambition to have a broad knowledge. I wanted to know more than just the programming language and the framework I used to write my code. Additionally, I learned and tried to use new languages, concepts, new (web) technologies in simple pet projects. The opposite of a T-Shaped person is an I-shaped person who only has deep knowledge in one field and no general knowledge. There is also the dash-shaped person who only has general knowledge and no deep knowledge of a topic.

But why should you aim for that goal?

• Collaboration with other people is easier because you have at least some basic knowledge about other topics.
• You stay interested in learning new things.
• You can break the ice with new colleagues more easily.
• As you become more and more familiar with concepts outside of your knowledge, you become slowly immune against the Paradox of Expertise.
• You will get tasks with more responsibility from your employer.

4. Learn about software architecture (how to integrate external systems: file transfer, remote procedure, messaging)

A lot of developers love to code. Design patterns will pop up along the developer journey for sure. Patterns like MVC, Strategy, Bridge, Adapter, Singleton are almost common knowledge for a developer. But there is a lot more to software architecture than this. For example, in modern software architecture, you have to integrate a lot of external services instead of implementing them by yourself. There are lots of ways to do this (e.g. Webservice based solutions, file-based integrations, and more can be found, for example, in this book). Choosing the right (also technical) solution or pattern can base on many factors. One of the biggest influences you have on your decision is based on the purpose and size of the software. There are huge differences between B2B, B2C, B2G or C2C applications. Each will bring its own rules and pitfalls. This could be:

• traffic load (B2C)
• high complexity (B2B)
• obligation of special laws (B2G)
• transaction/distribution strategy (C2C)

Documentation of decisions becomes very important and is one pillar of an effective and robust architecture for the distant future. If you document your decisions (including arguments for/against other options as well as assumptions), they will make future decisions and your system more robust.

5. Be open-minded

While working for several companies over all those years, there is one thing you will always stumble upon - discussions and disagreements. Every developer has a lot of knowledge and thinks their decision or opinion is the right one. And the developer tries not to give in as pride is standing in their way.

I would be lying if I said this never happened to me. At some point, I read an article that was not just about being open-minded, but rather how to be. If I need to break it down into short and concise bullet points, I would describe it as:

• Always approach disagreements with curiosity.
• Always fear that you may be wrong, no matter how confident you are that you are right.
• Try to fully understand (not just hear) other peoples arguments first, and then reject or accept those arguments. Furthermore, try to understand what people are saying, and their reasoning behind it.
• Look for the best answer, not the best answer you can come up with by yourself, but as a team.

Outlook

Obviously, there are a lot of other topics, which are no less important in the daily work of a developer. Clean code, lots of hard skills, know how to use Git, Test Driven Development, Refactoring… the list is very long. I tried to pick the things I found very valuable for myself.

I am curious about what I will learn in the next 10 years. Being a developer in a fast-changing world also means lifelong learning.

About the author

Waldemar Schneider is an experienced Java Developer. He loves working with Java and tries to be a photographer in his private life.