Lessons From a Veteran: Peter Morlion on Legacy Code & Bird’s Eye Views

Today, we’re starting a series interviewing veteran developers, asking them questions about their journey to tech mastery and sharing the advice they have for those getting started.

Peter MorlionOur first interview is with Peter Morlion. Peter is a passionate programmer that helps people and companies improve the quality of their code, especially in legacy codebases. He firmly believes that industry best practices are invaluable when working towards this goal, and his specialties include TDD, DI, and SOLID principles.

Let’s hear what he has to share!

Let’s start with some basic logistics. Which stack do you work in? How long have you been doing it?

I started out my career in 2007 as a .NET developer. I preferred Java as a student, but hey, I wasn’t going to be picky for my first job as a software developer. After several years, I found opportunities to work in other stacks. I’ve worked with technologies like Node.js, Python, TypeScript, and AWS Lambda. Since I moved from general software development to helping out with technical debt, the specific stack is less important now. Although I suspect the .NET space is still a big market in Belgium (where I live).

What made you want to go into programming?

Ever since my parents bought a PC when I was about 10 years old, I loved playing and working with computers. As I got older, I started to tinker more and more. I studied political science, but after graduation I decided I wanted to “do something with computers.”

My father-in-law had become a network and systems admin by following night school, so I went the same route. But there I loved the programming courses more than the sysadmin subjects. There’s something very satisfying about seeing the results of your work drawn on the screen. So I switched directions and went for software developer.

What were you most worried about when you made the decision to pursue a programming career?

Because the world of programming evolves so fast, I always worried about staying behind. I know fear isn’t a good driving force, but I’ve seen too many examples of people who I don’t want to be like: It’s the kind of developer that has lost the passion and is no longer interested in learning new things. I’m not judging them. People should do what makes them happy. But I didn’t want to become such a programmer.

I have calmed down in that regard though. I know it’s OK not to know everything. For example, I no longer follow UI technologies from up close. And I’m no expert in databases. But if you need someone to fix your legacy codebase, I’ll do it with a smile!

If it’s not my core expertise, I still try to follow technological evolution with a bird’s eye view, just so I know what is possible and where our world is heading.

What surprised you most at your first programming job?

How unpopular test-driven development was (and sometimes still is). I had learned it in my programming courses and really saw the benefit. I was surprised I had to convince senior developers to write unit tests.

What advice would you offer to people considering a career change to programming?

You are about to start the most amazing journey in your life—also the most demanding.

Don’t be afraid about the enormous amount of topics and knowledge that people are talking and writing about. You’re not expected to know every detail about every aspect of programming. In fact, it’s impossible and that’s OK. You can pick one or a handful of subjects to be an expert in. In fact, I’d say it’s better. Play your cards right, and it will make you more valuable in the market.

But one thing you shouldn’t ignore are the soft skills. Learning to work and communicate with colleagues, customers, stakeholders, and managers is just as important as the technical skills. Unfortunately, they don’t teach that at schools. Developing these skills will allow you to more easily extract what users need from an application (in contrast to what they say they need).

Oh, and if you meet people who don’t appreciate your work or put too much stress on you, leave that group. If it’s the company you work at, realize there is a large demand for programmers and there are companies out there where you will be appreciated and coached well. If it’s a certain community, know that there are thousands of inclusive and respectful communities out there.

Did you ever think that you’d made a huge mistake getting into this field?

Nope. Although there are other career choices that I would have probably loved to do. Helicopter pilot would be awesome. If I had to make a career switch now, I think I would choose to become a fireman. It’s cool, it’s noble, and you stay in shape.

But I’m still passionate about software development and technology, so I don’t really have a reason to switch. And I still have too many long-term goals that I want to achieve.

Who has influenced you the most so far in your programming journey?

I should name several people, although most of them will be unknown to most readers.

One of my programming teachers, Danny Vandriessche, taught me the principles and advantages of test-driven development.

I think a very important foundation was laid by Pascal Mestdach and Marjolein Hubrecht, my first two scrummasters. They taught me the basics of agile. Even though I wouldn’t call myself an expert there, I know enough to apply basic principles and identify areas where an organization can improve.

My friend and ex-colleague Stefaan Bastin convinced me to go independent, one of the best decisions in my career. I always said I would stay an employee for the secure feeling it gave me. But he convinced me of the benefits. There’s the financial benefits but also the freedom to choose how to spend your company money and which clients to work for.

Finally, Erik Dietrich, Jonathan Stark, and Rochelle Moulton continue to influence me in my attempt to improve and specialize my business. I’m evolving from a general developer to specializing in tackling legacy code. Erik inspired me to go that route. And the daily emails and regular podcasts by Jonathan Stark and Rochelle Moulton make me look at running my business differently.

Perhaps with the exception of the last three, most names I mentioned won’t ring a bell for the readers. It goes to show that anyone can be your biggest influencers, not just famous writers or programmers. Which also means that you could be a great influence to someone else.

What programming reference materials can you not live without?

Google to help me find the right Stack Overflow answer 🙂

I’m a slow reader and have always learned better by doing than by reading. That’s why I haven’t actually read a ton of programming books. I have been an avid reader of blogs, though.

So, when I want to learn something, actual programming works best for me. That means I’ll make mistakes and have issues I can’t fix. The internet is a treasure trove of knowledge, and in most cases there will be someone else who has written about my problem. And if not, I’ll ask on Stack Overflow. I usually get a good answer quite fast.

I also read specific articles on Martin Fowler’s website often. There are hundreds of software development subjects that he explains in a concise and understandable way.

What’s something that no training/bootcamp/degree could have prepared you for?

That saying no is acceptable. When a manager asks things you would rather not, it’s OK to explain why you won’t do it. You do have to explain, though. You can’t just say no and leave it at that.

Another developer once asked me to stop writing unit tests. I refused and explained that I actually work faster when I write tests. It gives me feedback faster and it works better with my thought process.

But you can’t win all battles. At another client, the managers asked the team to perform some mindless monkey work to meet a deadline. This was on a project that was drowning in technical debt. It was the classic “we’ll fix it after we make this deadline” argument. I told them that wouldn’t be the case. They would just have another deadline after that. But I also understood that missing the deadline meant real loss in revenue. So we braced ourselves and performed the work.