Software engineering services with love and thought:
  • Solving complex challenges
  • Addressing feedback and goals
  • Proposing ideas and technologies
  • Documenting to reduce iterations
  • Implementing and reviewing the code
  • Reliability and performance tuning
  • Investigating the most tricky cases
  • Answering questions and learning
Skills: Please explore this website to find more.
Jan 2023 - now
Oct 2021 - Dec 2022
Nov 2017 - Sep 2021
Feb 2014 - Oct 2017
TestFlight and 8 more
2001-2014
In chronological order:
Open source:
19 python packages, one is critical
Principles:

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. The same goes for UX.

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 or switching to TypeGraphQL Prisma.

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.

Offer:
Contacts and links: