My name is Benjamin G. Janusek

Below are some of my core thoughts on creating products. This document will change over time as I encounter new situations and come across new experiences.

"Everything in moderation, including moderation" ~ Oscar Wilde

Most problems that arise within a team or product can be solved through some reasonable middle ground. Some examples:

• Have a particularly nasty bug in your product? A quick bandaid fix to make the customer happy followed by a longer term, more robust fix is probably the best approach.

• Accumulating a lot of tech debt? Start mixing in work to pay down tech debt alongside of new features. Generally I've found you don't need as many new features as you think, and your customers will be just as happy with a stable, simple product than one with too much functionality anyways.

• Need to add a large, new feature? Breaking it down in to separate, smaller features that can be released over time will always be better than spending numerous months without shipping something. Many of the general approaches outlined in Shape Up (specifically around managing "appetite") are useful here.

It's worth noting that this is also true for work/life balance. Sometimes life gets in the way of work and sometimes work gets in the way of life. Occasionally, extra hours are needed to get a large release out the door, but those times should be the exception not the rule.

We're all adults. Both giving and receiving constructive feedback with raw honesty is crucial to having a mutual understanding and working towards working better together. Egos should be left at the door.

I'll almost always opt for tried and tested components of software over something that may be new and flashy. Most problems (scalability related, bugs, etc) that would come up with pieces of software that have been around longer will most likely have already been solved by someone, somewhere with useful information readily available online.

This sort of goes hand in hand with the previous point. Using a new NoSQL technology might sound exciting and fun, but I'd rather use a relational database if that's all that's needed to solve a particular problem.

Simple solutions to problems makes everything easier and less stressful. Onboarding new engineers won't require learning large, overly complex systems. Your product will be more stable. This applies to everything from how an infrastructure is configured to how code is organized.

• 🚲💨 Road Bikes, Follow Me on Strava!
• Zen and the Art of Motorcycle Maintenance
• The Creative Act: A Way of Being