When you're working with teams, it's important to write approachable, readable, breathable code. Here are 4 quick and easy tips to make sure your code is always breathable and maintainable.

Increments is a show about coming up for air once a while and evaluating where we are in our tech careers, and being intentional with our professional aspirations. I've never started or run a podcast before. I've toyed around with the idea - so we'll see how this goes!

 Just a quick word on Defensive Coding: You can write very secure code that isn't defensive. #DefensiveCoding isn't just about secure code. It's about making your code more maintainable, easier to read, understand, and user-friendly ("user" being other developers interacting with your code.) 1) Follow SOLID principles 2) Reduce code smells 3) Design your code the way you would your UI/UX. Make it simple, straightforward, intentional, and handle user error where possible. This will help you reduce the risk of new bugs and save you tons of time when you have to revisit your code base.

Regardless of industry, regardless of role - we all face problems. They may be technical related, code related, or people related - they lead to bugs, degraded performance, outages, security breaches, lost revenue. Problem solving is a critical part of any technologists life - and yet, training on effective problem solving techniques is rare. Wouldn't it be great if we had a formalized set of tools that we could immediately use when faced with a problem? Whether you suffer from analysis paralysis, or rely a lot on intuition, instinct or experience - this talk aims to show that problems are just solutions in disguise. Recorded live, virtual TechCoach session with the Greater Nashville Technology Council, on August 6th, 2021 Sources and Good Reads Thinking in Systems by Donella H. Meadows Cracked it! by Bernard Garrette What's Your Problem? by Thomas Wedell-Wedellsborg How Would You Move Mount Fuji? by William Poundstone The Success Equation by Michael Mauboussin Stan Browne,

We need to change how we interview in Tech. The demand for tech workers is skyrocketing, and interviewing cycles are still taking too long. I think this is simply due people not knowing how to easily assess someone's technical skill - and from there, you get the dreaded take-home Technical Assessment. Here's the thing: You wouldn't ask a candidate to fix a bug in your product's code base, would you? You also wouldn't ask them to build some internal productivity tooling, or you an app that you can sell, right? Seems wrong, doesn't it? You're benefiting from free work. That's exactly what you're doing when you give them a take-home technical assessment. Sure - you may not be looking to productize their submission, but you are still asking them to produce something that materially benefits the company. It is free work you are capitalizing on, that addresses a problem you couldn't resolve with the resources you have. In this case, they've solved