StealthyCoder

The first improvement we will make is to move away from int to string to int conversion in the previous code and implement integer only operations. We can do this by using the modulo and floor integer division.

A small mini optimization is to move the call to len out as the length of the number does not change.

The next thing we can optimize is the fact that the result of the powers calculation does not change during the same length of the numbers. In order words, 3 ** 3 does not change for the numbers 123, 345, 543 and any other number containing a 3 in the range of 100 – 999.

The next mini optimization we can do is to bail out earlier because when summing the number and we overshoot the original then we can stop immediately. For example 9 ** 6 is a big number and so with bigger numbers it makes sense to bail out earlier.

So for the smart people out there they might have already figured out that the result for 153 is the same as for 135,315,351,513 and 531. This means that we can calculate the result for all of those once and just check if the result of that calculation is in that list. Which is the case for the number 153.

I recently had a small discussion on why it is a bad thing when we can not automate, or script, something. The only argument this person had was if we spend two weeks on automating something that takes 5 minutes that is a bad thing. There are several reasons to automate procedures and saving time is not the main thing.

This is a short post about a phenomenon I have seen already in the past years. Every time we build a project the developer makes everything work locally in whatever way is known to him. So either using a service or own docker images or installing the actual software on the host system.

I recently read an article about Sacrificial Architecture and it got me thinking on software design and longevity. In the article it actually alludes to something I thought of when thinking of what Sacrificial Architecture would mean.

Today I found myself in a discussion about why the state of the project was in the state it was. The voices of concern were that we were just working blindly without there being a refined user story and ticket to keep track of. No usage of Pythonic standards were followed. No linting, no tests and no clear structure in the code. In short all the things we as developers have said time and again we should not accept in a project yet we did it again anyway.

So I read this article which is a response to this article recently. The reaction article is what triggered me to write this post.