Interview with: Nuno Marques

Introduction

I’ve recently had the pleasure of catching up with the highly experienced and very well-rounded engineer, architect and leader, Nuno Marques. Ex Equal Experts and more recently of Berlin based start-up Xeotek, Nuno brings a wealth of experience and wisdom in very humble fashion.

Our conversations often digress, as we find ourselves talking travels, kids, the education system, and everything in between (a learning experience for me more often than not), but for the sake of this content series I wanted to offer a window into Nuno’s professional life, and gratefully he has given us just that.

Sure, I’m Nuno Marques, Software Architect. I learned how to code in the mid-90s, took a software engineering degree and started my career as an Engineer in 2003. Initially working in Java, although by now I’ve coded in exactly 20 different languages as part of my job!

I've been around many different industries including finance, payments, accounting, e-commerce, insurance, gaming, government, health, public services, etc... I also started out and run a couple of consultancy offices in Europe (with EE) for 6 years. But yes, I'm primarily an Engineer who likes to solve problems.

What I love the most about coding is twofold. First, it’s the problem solving. In engineering there are lots of constraints that need to be taken into consideration before making a decision, and that's a big part of finding solutions to problems.

Second is the rewarding nature. Whilst a Software Engineer's job is never finished as it can be improved infinitely, you can take small steps and verify completeness as you break down the problems in smaller parts, solving them one at a time. This allows me to experience progress and a sense of completeness, which is very rewarding.

Well, when I started my career, I was between C# and Java. I took the Java route for two reasons; firstly, Microsoft had a terrible reputation back then and I always liked the open-source model which Java had mostly on its ecosystem, with the language also becoming open-source later on (with exceptions). The second reason was the lack of choice in terms of tooling, but also the quality of the tooling that did exist at that point made me steer towards Java. Visual Studio was good, but very expensive.

Right now, I see languages as tools. I don’t have a single preferred language. Some are better than others for specific things, and we should use the one that is ‘best for the job’, to a reasonable degree.

I do have a preference for strongly and statically typed languages, because they allow us to write fewer tests and offer faster feedback from the compiler, which is also better for designing away bad states than tests that can lack coverage.

Kotlin allows me to use better libraries for functional programming, but so does Typescript or Rust. Java’s addition of green threads can help in specific scenarios to get the most out of an application, without having to rewrite it. They did a good job at making it very non-intrusive, therefore better for productivity. But no, I couldn’t give you a favourite. Things always change as languages evolve and add more features.

Yes. I think the moment that was the most impactful to my career was the decision to emigrate from Lisbon to London in the mid naughts. In Lisbon, I would have never been able to use the Agile methods that I learned in university, and that were now becoming popular elsewhere, because there was just no culture for it, and I was just a junior. Now things are different there, but it only really started changing 10 years after I left.

Also, by making that move I was able to personally meet some influential people that I wouldn't otherwise, like Ward Cunningham, or Martin Fowler.

This is hard. I compare it to defining functional programming. No one I know embodies all the traits, and not every trait is necessary, but having a trait is also not sufficient. Without any order I would say: humility, persistence, be industrious, pragmatic, and a leader.

Humility, because it's necessary for learning new things, and to work properly with others.

Persistence, because computers require precision of instructions and sometimes, it's hard to find a good way (or any way!) to express the solution in terms that a computer can execute. Computers will do what we tell them to do, regardless of what we want them to do.

Be industrious, because we need mental energy to keep our productivity high, but it's also necessary to be proactive, anticipate issues and clarify forks on the road by talking to stakeholders.

Pragmatic, because it's engineering. We must be as scientific as possible, leave preferences and emotions mostly out (there are exceptions), focus on the problem and the best solution that can be achieved in an acceptable timeframe.

Leader, because software engineering is mostly a team sport or the military at war, depending on what point of view we look at. It requires a lot of coordination and for teams to be adaptable and agile. We also learn on the job and a leader is not necessarily the ‘team lead’ but is someone that will push the team in the right direction and help maximise the team's performance.

I never anticipate anything. In fact, I try very hard to not get invested in any possible future directions.

The way for me is to be able to be nimble and be able to adapt to the changing environment. Probably why I’ve coded professionally with 20 different languages!

For example, I took a hard look at blockchain and decided that it was not the solution to the banking issues we had in 2007. My opinion is that it was a tech solution to a social problem so it would never work, but the concept of digital money is necessary - it's just not via blockchains.

Now AI is very trendy and there are a lot more applications to the new AI models that have been created. AI has been a thing for many many years, but its application has been more laser focused on specific problems and now we've taken big steps towards general AI, which may never be possible, we just don't know yet.

One thing I've realised is that if I was not horrified to look at the code that I'd written one year prior then I wasn't progressing, and I wasn’t becoming better, same with some managerial decisions.

Maybe my advice would be, make sure you do your best. Everybody does some things wrong, take responsibility and change processes to help you avoid making the same mistake again. If you're not making mistakes, you're not trying hard enough to be better, but don't be too aggressive as too many mistakes will make learning harder still. Do your best.