You know the feeling when you get a profound experience on what your profession is all about - the feeling when you connect to the history and lineage of generations of engineers who have been solving problems with computations and tried to make the world a better place. Instead of fuzzing over the javascript framework du jour you get to use some math - and compute.

To be honest much of my work career has been solving computationally simple problems in enterprise settings. Moving and transforming data through the enterprise processes has been bread and butter for me for years - with a limited amount of opportunities to grow engineering chesthair and feel extreme proudness over the artifact you worked on. Now do not get me wrong, I have loved every moment of it and challenges we have solved - but there are times when I have thought that just solving these mundane problems, instead of harder problems, makes me a faker.

Some time ago I got a great reminder on how there can be some sudden opportunities to do real computer science and math even in simple problem domains. We were solving an interesting business problem that started vaguely to sound a bit like an optimization problem. As I started to think through the business rules regarding the problem I tried to think how can I turn this problem into a computationally solvable problem - and what would the solution look like. I had to brush up my skills and thinking in mathematics - and do a quick research on what this problem could be about.

Through my digital library, I browsed through “The 5th edition of Model Building in Mathematical Programming” and found my way to “Handbook of Constraint Programming” and “Constraint Processing” books which opened my eyes to a larger field of study that had for decades worked on the problems I was looking at. From those books, I got the vocabulary and thinking to start to formulate the problem in a way that I could solve with linear programming or other tools of the trade. And with that idea, I could start to search for components that could do the heavy lifting for me.

With a few searches, I found out about Google Operations Research or-tools package which was just what I needed to build my first proof of concepts. Initial experience with the or-tools package was a bit cumbersome, as the APIs are hard to navigate – but luckily examples described and covered all the pieces needed in my solution and also provided an excellent introduction to different types of problems that can be solved with the package.

I chose the python wrapper to the or-tools to be my weapon - and started to craft the initial version of the code, learning to model the problem in right way and adding constraints to represent each individual business rule in the domain. Two steps forward, one step back - but eventually getting to a point, where I could say that it works and I can see the elegance in the solution. And as the foundation was set in solid mathematics I was also able to trust the results.

I was happy. And I was satisfied.

Instead of going head-on against the problem in a brute force way I took the time to understand what the problem was about and turned it into something I could solve more easily with just a hint of math. All it required was being prepared to identify a problem space to be one, which is exactly like or similar enough like some area of mathematical applications that I could use those axioms for my benefit.

And that is the gist of my post. Be aware - and math is your most powerful tool.

5⁄5 - would do it again.