I'm an independent freelancer, providing software engineering services, crafting code with love and thought.

Please explore this website to find:
Oct 2021+
Nov 2017 - Sep 2021
Feb 2014 - Oct 2017
TestFlight and 8 more
2001 - 2014
In chronological order:

I also deeply agree with Alex Sadler, who said: "what matters is peer review, experience and understanding your objective".

These principles are very generic, hence timeless. Three first principles in the list above are ordered by priority. E.g. if making it DRY breaks the KISS severely, then ditch the DRY.

Once I found a code which was begging to make it DRY. I tried, added a dozen of parameters to make it happen. Found it became so complex, that I'd better revert it. Another senior engineer found I'm OK to keep it not DRY (a really unusual situation) and said like nah, I'll make it happen, I'm sure. After some time he reverted it too.

The main idea I've got from the Code Complete by Steve McConnell was: fight the complexity.

It's simple to create a complex code. It's complex to create a simple code.

But the value for the user actually beats even KISS: what's the profit from KISS, if the change doesn't bring a value to the user at all?

Improving the codebase should get the features to the user faster and with less bugs, as in replacing boilerplate Python code with Hasura.

We should build, measure (saying no to vanity metrics), and learn from this feedback data - to find what to build next and what to throw away. One great book I recommend is The Lean Startup by Eric Ries, valuable both for intrapreneurs and entrepreneurs.

Contacts and links: