.png)
Ingage Partners kicked off the first C3: Code, Craft, Community meetup of the year on January 21 at our new Blue Ash office, bringing together developers for an evening focused on algorithm design and code optimization.
C3 is our monthly developer meetup where engineers of all experience levels come to write code, explore technical challenges, and sharpen their craft. Each session centers around a hands-on kata designed to push thinking beyond the straightforward solution and into deeper conversations around performance, scalability, and clean design.
This month’s challenge? Numerical palindromes, a deceptively simple problem that quickly turned into a lesson in efficiency, trade-offs, and thoughtful refactoring. The focus of this meeting was on implementing what appears to be a rather simple problem but quickly becomes complicated when the straightforward solution doesn’t scale.
The Kata: Numerical Palindromes
This month’s Kata was finding numerical palindromes which are numbers that are the same forwards as they are reversed (i.e. 1, 11, 22, and even 1905091). Participants saw that the straightforward implementation of looping over all integers and writing a single method IsNumericalPalindrome was an easy problem to understand, develop, and surround with unit tests to guarantee correctness.
Now that the initial problem was solved, they could start concentrating on optimizing the solution. This could be either improving the efficiency of the algorithm or through incrementally tuning the code to remove bottlenecks.
Participants were asked to record the time it took to generate the first 10k palindromes, and then same for the next 10k. This helped them realize the straightforward brute force algorithm wasn’t linear and suggested that a better algorithm was probably the next step.
One better algorithm was realizing that we didn’t need to check each and every number. In fact, if we split any number into a few pieces, we can generate the next palindrome. Those pieces are left side, possible middle, and right side. For example, if we take the number 42816 the next palindrome would be 42824. The algorithm would break 42816 up into 42 (left side), 8 (middle for odd length numbers), and 16 (right side). If we compare the left side with the right side and we notice that 42 > 16. Since palindromes need to be mirror images if we reverse the left side 42 we get 24. We can then rebuild our next palindrome with original left side (42), original middle number (8), and reversed left side (24).
This example only handles a portion of the new algorithm. To complete the algorithm, we would have to implement the following cases among others
- Right Side = Left Side
- Right Side < Left Side
- Handle for numbers that are even length (22, 1000, etc.)
- Numeric Overflow
Once fully implemented we would see the code generate palindromes much more quickly and in much more consistent timeframes for each batch of 10k palindromes. If you would like to see the full implementation, see Pull Request: C# Implementation with Algorithm and Performance Tuning
This all sounds overly complicated, potentially error prone, and I imagine the code would be harder to read as well. While this kata doesn’t have much of a real-work application, it does bring up whether this kind of “improvement” is a good idea. Since we don’t have a real-world constraints, the decision probably centers around how large of numbers do we want to consider for our problem space. If we are talking numbers between 1 and 1 million the brute force approach is probably best, but if we are talking about unsigned long in languages derived from C, which are between 0 and approximately 18 quintillion, then harder to understand and more performant code beats out more straightforward code.
As to whether the new code is error prone, this is where our unit tests and categorization tests come into play. Test driven development pays off here and helps to make the refactoring safer. We had working code and working tests before refactoring the algorithm, so we should be able to quickly validate our new results using the existing tests. Categorization tests might also be useful here. We would use the old algorithm to write out the first 10k palindromes to a file and then do the same with the new algorithm. If the files are the same, we would gain more trust in the new algorithm and code assuming we have exercised all the edge cases.
If we need further performance improvements, we are going to likely need to move towards “incremental” code improvements by finding and subjugating bottlenecks. This could be things like reducing our use of strings where arithmetic might be more performant. Using tools like code profilers might help identify slow code, and creative problem solving and googling, chatting, etc. might help find quicker implementations. Again, these “improvements” might cost code clarity.
Learning in Action
While I haven’t yet found any real-world use for numerical palindromes, I know that writing the solution challenged me in various ways.
- It made me think about the performance of the brute force algorithm
- It reminded me to add timing metrics to measure actual execution time as a baseline, and to constantly compare “improvements” with the baseline
- Not all the improvements I experimented with were more performant
- Efficient code isn’t always elegant
- Making improvements anywhere besides the bottleneck does not help much
- Correctly identifying bottlenecks is key to solving performance problems
- Stepping back from a working solution, observing from a different perspective, and being creative about solutions sometimes has the biggest impacts
If you would like to try it out, the requirements and hints can be found in this GitHub repo.
Why It Matters
This is more than a meetup. It’s a reflection of who we are.
At Ingage, we invest in growth—not just within our company, but in the broader Cincinnati tech community. We know that building better developers builds better teams, and better teams create better outcomes for our clients.
Interested in Coding with us?
If you’re a developer in the Cincinnati area, we’d love to see you at our next C3 meetup. We meet monthly, on the third Wednesday of the month, at the new Ingage Partners office (4445 Lake Forest Drive, Suite 440, Blue Ash, OH 45242), and we welcome developers of all backgrounds, experience levels, and technologies & programming languages. Come to write code, pair up, ask questions, and eat some pizza.
Because when we share knowledge, everyone levels up.
