We are proud to announce the start of our Circuits of Life editorial series. Speaking to testers, engineers, architects, QA Analyst and developers from different walks of software life to capture their stories, career highs and lows, their trials and successes, their current company and their role, most recent projects, advice to others and the individuals who they most look up to in the industry.

The first in the series is Arnon Shimoni, a Product Manager at SQream in charge of cloud strategy and user training, as well as leading SaaS products, analytics features, educational and documentation content, and customer research. His experience in development and marketing helps him analyse the technical requirements, understand business requirements, and design value-added solutions for customers.

So, we sat down with Arnon to find out more about why he joined the software industry, what his role as Product Manager entails and his advice to people seeking careers in software. 

Where were you born?

I was born in Ramat Gan, Israel, in the mid-80s.

Where do you live now?

I live in Denmark. I moved here about 3 years ago for personal reasons.

What inspired you to get involved in software engineering?

I have always been interested in how things work. The first time I stood up, as a baby, was to inspect my dad’s Pioneer receiver. I promptly caused some of its lights to stop working – which my dad does not forget to this day. Wanting to know how things worked led me to software development. First by taking a look at how it was built, and then modifying it to my needs. At university, I was interested in how different devices communicate, so I majored in Communications Systems Engineering.

How did you learn to define your software engineering skills?

Just like before, I tend to inspect how things are built first. I look through the state of the art, open-source libraries, and other products. Once I figure out how they work, I can work out what they do well and what they struggle with. It helps me avoid some of the pitfalls.

Did you study software development and if so, what was that experience like?

I studied Communications Systems Engineering. It’s a weird hybrid of electronics engineering and software engineering. The emphasis is on communication protocols, state machines, stochastic processes, graph theory and other horrific sounding topics. The university degree provided the basis for everything else, but it’s not how I learned software development.

Real-world development is not a university project. You have to work through hundreds and sometimes thousands of constraints. You have deadlines, customer demands, and limitations on the deployment. That’s even before we talk about working in a big team. So, really, a university degree will only set you up with the basis. The rest, you’ll have to pick up on the job.

How did you get your first software testing job? Your Job role at SQream is Product Manager, what was your first role there?

I never did software testing formally. I joined SQream as a student Haskell developer in the compiler team. That team writes code in a functional programming language called Haskell. While I had some similar experience with Erlang (used extensively in communication systems, e.g. Ericsson’s phone switches, Whatsapp and Facebook Messenger’s servers, etc), I never used Haskell before. Within my first week, I had my code in production – so I really hit the ground running.

After a few months, I took on a project lead by our architect, to build an extensive test generation framework. This framework could build very complex test flows, designed to test most functionality of our SQL DBMS. It tested configuration, loading, query and statement flows, deletions, clean-ups, memory and CPU/GPU usage, etc. I dubbed the project “Toaster”.

The great thing about Toaster is that it generates very explicit code. This code is super easy to debug and reproduce. It is also repeatable and reliable. We can see exactly what runs when and where. No hidden modules or complex subroutines that perform a million tasks. Even though it was built almost 6 years ago, it’s still in use today because it is so versatile.

What’s your day to day role like now?

Today, I’m a product manager, one of three in the company. Each of us has components of the product that we look after. I usually start the day by reading the latest news. I subscribe to lots of DBMS and “Big data” publications, as well as forums and subreddits. Then, I run through our customers’ feature and change requests, to see if we can push them forward.

Throughout the day, I meet a ton of people. Internally, I speak to dozens of developers, marketing, sales, customer support, and customer success teams. Externally, I’ll speak to at least a couple of our customers a week. Before COVID-19, I’d meet them in person, and attend a couple of tradeshows every quarter. Now, it’s mostly video chats. Because I work Fridays and most of my colleagues don’t, I spend that day writing requirements and user stories. Overall, I’d say 90% of my time as a product manager is spent on stakeholder management.

What’s it like working in a team and do you have any advice on how to manage others?

For a product manager, giving teams autonomy is key. Every person needs their playing field. No one likes being micromanaged. When a person or a team knows that they have an area in which they are responsible, an area that they’re trusted with – they always deliver the best results. This naturally entails building trust. Autonomy and trust go hand-in-hand. A product manager needs to build trust, provide as much context for tasks, and then let the teams work.

Do you have any advice for budding software engineers who are new to the industry?

Be passionate about customers! It doesn’t matter if you’re developing for someone in IT, another developer, or a mobile app user who has never used a computer before in their life. Know your customers, know what drives them, know what they like (and what they don’t like). It’ll help you build something that they want and love. Forget the constant chatter about what the hottest new framework is. These change every 2 years. If you focus on delivering real value to customers, they don’t care which version of Javascript you used.

What’s your ideal software testing project?

As I described above, in my first role. Software is only as good as the tests that verify its correctness. Most customers won’t accept even a tiny probability of wrong results, and they shouldn’t. With modern data-driven companies, the data processing platform has to return correct results, 100% of the time.

You have to anticipate things that the customer doesn’t even know about and will likely never do intentionally. That can only be achieved by extensive, repeated, and automated testing on millions of test cases in hundreds of thousands of different flows.

Do you have a memorable story or an anecdote from your experience you’d like to tell?

We designed it to handle the biggest problems – running analytics on trillions of rows and returning results within a reasonable timeframe. However, the first time I saw our software in use by real people, I was a bit shocked. This was a company out in the far east, and they were testing it like a calculator.

Some of these didn’t work, at the time. The reason was – we never anticipated anyone would run these naïve examples. However, this was part of their testing – and we failed it. They figured that if we can’t run these simple examples, we can’t run them on real data either. I went back home, and we built lots more tests to catch these naïve examples. Based on the test results, we promptly resolved all of these issues. Two weeks later, the customer was happy to see everything worked, and the project continued.

Do you have any advice for budding testers?

I rarely see someone who’s just a tester. At SQream, part of delivering features also includes writing tests. Our coders write tests too. So, probably the same advice for the software engineers. If you care about your users, it’ll show in your work.

What is the most significant project that you’ve worked on to date? What current projects are you working on?

Working on a DBMS is endless. It is without a doubt the biggest project I’ve worked on and the most rewarding one. We are constantly building new functionality, improving performance, and expanding analytics support. However, our latest project involves transforming it into a cloud-native product, which is a whole new world for us. It’s kind of weird but very exciting to get to redesign the product and put different kinds of customers first. As a cloud product, we are building it for more ad-hoc style users, even more than we did for our on-prem.

What is your favourite type of testing and why?

My favourite is also the most difficult one to do correctly: Integration testing.

It’s really easy to write and run a unit test, or a regression. Testing a feature in a variety of situations is a lot more challenging. I find that this is where the most interesting problems are found! It’s challenging to anticipate the complex scenarios that customers run into, especially with DBMSs. The software ends up running on exotic hardware, in a hardened operating system, inside Kubernetes pods, with virtualised GPUs, and data being fed from high-performance network storage which you’ve never heard of before.

Then, an end-user uses a fancy BI visualizer written three decades ago (but modernised), which generates weird non-standard SQL syntax over a protocol also designed in the 1980s, and then wants to display the results in a report, that is the base for a huge amount of business decisions. To complicate matters, the source data set is in the hundreds of terabytes scale.

That scenario is very common in our world. There are so many edge cases that you can’t reproduce with a unit test. There are scenarios that you can’t reproduce at all because you don’t have the customers’ source data.

Do you have any last words for the software engineers and testers out there working on their most recent projects?

You have to be proactive, and build introspection tools into your software. This is easier said than done, but you need to invest a lot of effort into this. It’ll save you later on. The more complex the system is, the more important it is. More often than not, you can’t attach a debugger to a process running at your customer’s site or on their cloud.