Healthy Developer

If you've been programming for a while and it doesn't seem as fun as it used to be, maybe it's time to take a step back and look at why. In this episode I'd like to help you figure out what the the root cause of your frustration with coding might be. It's only natural that if you started off writing code and eventually got good at it, you'd come to the conclusion that programming is the best tech job for you. But there could be a better fit, or you may need to double down on persuasion and some other skills than just writing code. When you're on too complicated of a tech stack, you haven't learned important soft skills like persuasion, and you make work your life - it's pretty likely that coding is going to start to suck. The good news is, you don't have to stay that way! By identifying which of these reasons for why you're not having as much fun programming apply to you, it's possible to start taking action today to get your tech career back on track. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Chapter markers / timelinks: (0:00) Introduction (0:40) Why Isn't Programming Fun Anymore? (0:56) 1. You're Not Challenged (2:16) 2. Programming Not Biggest Talent (4:23) 3. Your Industry Is Boring (5:26) 4. Tech Stack Too Complicated (6:28) 5. You're Not Learning To Influence (8:09) 6. Your Job Is Toxic (9:30) 7. Work Is Your Life (11:18) Episode Groove Visit me at thrivingtechnologist.com

How does being a software architect differ from a typical programmer? In this episode, I share the 10 aspects I've approached software architecture from that I learned over 20 years of doing it. I was promoted to be a software architect at just 20 years old, and while I was qualified with some aspects of software engineering - I didn't really know what I was getting myself into. Being a great software architect takes a variety of skills that a typical software developer will also benefit from, but are actually essential to software architecture. Yes, using coding patterns, knowing how to interview as a software architect, and making technology selections are required. But there are also other things that if you don't focus on, can hamper your ability to pursue a software architect role either at your current job, or the next one. I hope this episode helps you understand that while there is some overlap between a software architect and a programmer, the less "fun" aspects of the job are actually essential to being a really great one. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Chapter markers / timelinks: (0:00) Introduction (0:51) 10 Aspects of Being a Software Architect (1:03) 1. Zoom In / Zoom Out (2:17) 2. Domain Sensitive (3:07) 3. Understand Tradeoffs (4:02) 4. Selfless Decision Maker (5:02) 5. Embrace Change (5:44) 6. Communicative Mastery (6:26) 7. Infrastructure Aware (7:40) 8. Strategic Coder (8:50) 9. Consider Scale (10:28) 10. Cost Sensitive (11:49) Episode Groove Visit me at thrivingtechnologist.com

One of the biggest challenges for all software developers in 2023 (and leading into 2024) - is simplifying their tech stack so work can get done. The continued explosion of boutique frameworks and libraries is making it harder than ever to manage complexity as the stack of tools and technologies we use on our projects grows. Whether you're a software architect, senior engineer or developer, or any other role that encounters tools and technologies on a software project - the decisions we make about what frameworks, APIs, libraries, and other pieces of technology to use on a software project impact us all. In this episode, I'd like to help you simplify your tech stack by sharing some of the things I've learned as a software architect about making informed and reasoned decisions about tech stack choices. I hope it helps you avoid some of the typical pitfalls we programmers can fall into when we select tools and technologies as soon as we find them - instead of stepping back and finding out if they're really high value enough to the team to adopt using them. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Chapter markers / timelinks: (0:00) Introduction (1:07) 1 THE DANGERS OF TECH STACK COMPLEXITY (1:12) 1.1 Tool Overload (1:40) 1.2 Decision Fatigue (2:03) 1.3 Integration Challenges (2:34) 1.4 Cost Implications (3:26) 1.5 Diluted Focus (3:44) 2 SIMPLIFYING YOUR TECH STACK (3:52) 2.1 Prioritize Value (6:35) 2.2 Embrace Versatile Tools (7:39) 2.3 Standardize and Document (8:50) 2.4 Seek Community Input (10:01) 2.5 Regular Review and Upgrading (11:33) Episode Groove Visit me at thrivingtechnologist.com

Burnout is one of the most common dangers to programmers over their career, and I was no exception. Software development and programming can make it difficult to find a healthy balance between work and life. My burnout was a combination of self-inflicted bad decisions, things done to me, and circumstances in my personal life. In this episode, I share the story of my own burnout and how I lost nearly everything. Through it all, I found what really matters in life - and work became a smaller part of it. I hope this episode encourages you to share your own struggles to get help. Maybe some of the things I learned after going through burnout can also encourage you to keep going. My wife Angie's podcast, "A past, repainted" is here: https://apastrepainted.com/content/podcast/ Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Chapter markers / timelinks: (0:00) Introduction (0:59) 1 SELF-INFLICTED BURNOUT CAUSES (1:05) 1.1 People Pleasing (1:41) 1.2 Overextending at Work (2:03) 1.3 Side Gigs (2:15) 1.4 High Expenses (2:51) 1.5 Drug Addiction (3:18) 1.6 Guilt and Shame (3:59) 2 OTHER-INFLICTED BURNOUT CAUSES (4:16) 2.1 Political Lies and Manipulation at Work (5:31) 2.2 Recurring Project Firefighting (6:42) 2.3 Betrayed by a Coworker (8:04) 3 CIRCUMSTANTIAL BURNOUT CAUSES (8:34) 3.1 My Child Struggled With Dangerous Addiction (10:07) 3.2 My Father Died At a Young Age (10:45) 3.3 9/11 Work Culture Changes (12:04) 3.4 My Wife's Abuse (13:36) 4 BURNOUT TRIGGERS (13:42) 4.1 Startup Partner Exited (14:27) 4.2 Marriage Became Distant (15:13) 4.3 Recurring Relapse of My Child (15:54) 4.4 Company Bought Out (17:04) 5 MY BURNOUT SYMPTOMS (17:12) 5.1 Chronic Insomnia (19:03) 5.2 Uncontrollable Anger (19:47) 5.3 Forced to Resign (20:25) 5.4 Spent Emergency Savings (21:29) 5.5 Spent Remaining Cash (21:49) 5.6 Sold All My Stocks (22:09) 5.7 Fell Behind on Mortgage (22:54) 6 STRUGGLING THROUGH RECOVERY (23:05) 6.1 Tried Quitting Development (23:33) 6.2 My Wife and I Found God (26:11) 6.3 My Addicted Child Moved Out (27:03) 6.4 I Started on YouTube (28:32) 6.5 I Started Career Coaching (30:43) 6.6 My Sleep Improved (32:01) 7 HOW BURNOUT CHANGED ME (32:11) 7.1 Recovery is Daily (32:31) 7.2 Confronted My Addiction (33:09) 7.3 Became Aware of My Limits (34:01) 7.4 Embraced My Suffering (34:24) 7.5 Motivated By Change (36:50) 7.6 I Began Tithing (39:03) 7.7 Learning To Live Sober (40:13) 7.7 Focus on The Positive (41:09) 7.8 Reject Being Defined By Work (43:56) Episode Groove Visit me at thrivingtechnologist.com

Trusting people is getting tougher than ever these days, and nobody seems to have a harder time than programmers and managers. In this episode, I'll teach you how to get some hard evidence to determine whether your manager is trustworthy or not. The goal is for you to find out YES and just have a healthy relationship with your manager. But if there are trust issues, you'll have some tough decisions to make about your software development career. This episode can help anyone who has a boss on a software project (programmer, QA, DevOps, etc.), but since there are some unique ways programmers can have their trust broken by managers - I'll focus on that. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Chapter markers / timelinks: (0:00) Introduction (2:36) 1 WHY DON'T PROGRAMMERS TRUST MANAGERS? (2:48) 1.1 Manager Can't Do What Programmers Can (4:17) 1.2 Limited Visibility in Command and Control (6:35) 1.3 Hearsay (8:05) 1.4 Power Dynamics of Reporting to Someone (9:43) 2 WHY DON'T MANAGERS TRUST PROGRAMMERS? (9:55) 2.1 Can't Comprehend All of Their Work (11:01) 2.2 Past Bad Experiences (12:26) 2.3 Remote Visibility Problems (13:36) 2.4 Assumptions of Immaturity (15:30) 2.5 Anxiety Due to High Cost (17:26) 3 HOW TO LEARN IF YOUR MANAGER IS TRUSTWORTHY (17:41) 3.1 Micro-Commitments (19:49) 3.2 Corroborate With Coworkers (22:14) 3.3 Corroborate With "Skip Level" Boss (24:55) 3.4 Set and Track Measurable Objectives (27:48) Episode Groove Visit me at thrivingtechnologist.com

Just the name Tech Lead has this kind of prestigious ring to it, and if you're like most programmers you might think it's the job to shoot for. But 20 years of my career have been spent leading software teams, and you might be surprised to know that tech lead is actually the worst job for most programmers! Some of the information in this episode applies to IT professionals in any technical leadership role: whether that be leading programmers, UX, DevOps, QA - or any other discipline related to software development. But several of the points are more specific to programming leadership. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Chapter markers / timelinks: (0:00) Introduction (1:20) 1 TECH LEAD MYTHS (1:29) 1.1 Smartest Team Member (2:11) 1.2 Writes The Best Code (2:59) 1.3 Chooses Key Technologies (3:45) 1.4 Most Highly Compensated (4:12) 1.5 Motivates Through High Standards (5:19) 2 WHAT SHOULD A TECH LEAD DO? (5:22) 2.1 Improve Team Effectiveness (6:35) 2.2 Defend Team Members (7:52) 2.3 Congratulate Team Publicly (9:00) 2.4 Getting Team Consensus (10:19) 2.5 Help When Things Get Hard (12:57) 3 HOW BAD TECH LEADS GET PROMOTED (13:28) 3.1 Strong Individual Contributor (14:13) 3.2 Company Promotes Out Of Fear (15:01) 3.3 Management Misunderstands Role (15:25) 3.4 No Desire To Lead (16:15) 4 BECOMING A TECH LEAD (16:34) 4.1 Practice Defending Your Team (18:19) 4.2 Practice Congratulating Team (19:30) 4.3 Read Books on Leadership (20:46) 4.4 Work Closely With Others (21:52) 4.5 Learn More About the Business (23:28) Episode Groove Visit me at thrivingtechnologist.com

As programmers, we often follow practices because of hidden desires - and "self-documenting code" is chief among them. In this episode I'd like to share some of the tradeoffs and implications of choosing to add comments to your code or not, to help you make the best decision for your software development career. When I first started developing software 25 years ago, the company I worked at mostly used C++ with a little Visual Basic and Java. At that time, all the other software engineers I worked with added comments to their code. And at the next two software product companies I worked for, programmers also chose to add source code comments as a regular practice. But once I moved to Austin, Texas 15 years ago and got my first job as an IT consultant I noticed something interesting. None of the other programmers on my team added ANY comments to their code! When I asked them about this, they would often say "the client is paying for features, not comments". I didn't find this a very acceptable reason for not adding comments to code, but I did my best to play along. Around this time the popular programming practice of "self-documenting code" first showed up on my radar. The idea being if we write our code with a clear enough intent, but using business terms and clean designs for the software we write, comments are unnecessary. But upon closer inspection I found this to be (in my opinion) wishful thinking rooted in laziness, upon a host of other factors. I hope this episode helps you make an informed decision about whether the benefits of code comments are worth writing them, or whether you should continue to practice self-documenting code as a principle. I believe we can have the best of both worlds: well-written code that reflects the business domain and is simpler to read, but with accompanying comments to reduce the time it takes for our software development team to use the APIs, helper classes, and other functionality our code and libraries provide. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Chapter markers / timelinks: (00:00) Introduction (02:50) 1. Why Practice "Self-Documenting" Code?(02:56) 1.1 Laziness(04:43) 1.2 Reduce Visual Clutter(05:43) 1.3 Refactoring Burden(06:39) 1.4 Overconfidence in Simplicity(07:56) 2. 6 Benefits to Commenting(08:03) 2.1 Reduce Comprehension Effort(08:50) 2.2 Accelerate Business Understanding(09:50) 2.3 Use Comment Features in Editor(11:03) 2.4 Surface Code Behavior(12:07) 2.5 Additional Documentation Opportunities(12:48) 2.6 Treat Code Like a Product(13:51) Episode Groove Visit me at thrivingtechnologist.com

Ever wanted to do something new, or make a change on your software project - but other people on your team won't support you? Maybe you want to move from scrum to kanban, use a newer JavaScript framework like remix, or if you're a UX designer introduce something like customer journey maps. It would be nice to always have support from other people, but if you've never had pushback for one of your ideas, it's a matter of WHEN - not IF. So at some point, unless you want to quit your job every time you need a change to keep delivering great software, you'll need to persuade other people on your software team, or in management - to support you. In this episode I'd like to share with you what I learned over 15 years of software development consulting about persuading IT management and other technologists on your software team. Persuasion is a soft skill that is more valuable than many people realize! Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Chapter markers / timelinks: (00:00) Introduction(01:13) 10 Steps to Persuade Others(01:21) 1. Be Honest About Your Skills(01:57) 2. Have an Authentic Relationship(03:40) 3. Know How To Measure Success(04:43) 4. Identify Benefits To Others(05:44) 5. Incremental Persuasion(07:00) 6. Create Visual Aids and Assets(08:38) 7. Future-Pace The Benefits(09:53) 8. Know How They're Measured(11:08) 9. Timebox The Response for Support(12:29) 10. Practice Persuasion(13:39) Episode Groove Visit me at thrivingtechnologist.com

Many software development teams use an agile backlog but have NO business agility - and are actually using scrum with a waterfall mindset! When the product backlog is used on a scrum project and the business doesn't really understand agile, it wastes money and makes most programmers feel miserable! In this episode, I share what I've learned about using agile methods with software teams that actually produces business agility. Business agility is the ability for a company building a software product to adapt to feedback and data gathered about how customers are using it. Since software development is such an unpredictable engineering activity, a business can choose to put their hopes in estimates, or deliver releases more often and let data be their guide. I hope this episode helps you understand how programmers, product owners, scrum masters, and everyone else who works together to build and release software can do it in a healthy way - where less stress is placed on everyone trying to predict the future through estimates. Instead, we can use the insights gathered through feedback and recording data in production about how customers are using the software to product the RIGHT features - and at a sustainable pace! Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Chapter markers / timelinks: (00:00) Introduction(00:57) 1. The Purpose of a Backlog(01:19) 2. 7 Waterfall Backlog Signs(01:28) 2.1 No Feature Usage Metrics(02:09) 2.2 No Release After Sprint(02:55) 2.3 Backlog Never Reordered(03:37) 2.4 Features Never Removed(04:19) 2.5 No New Features(04:54) 2.6 Estimates For All Stories(05:35) 2.7 Measuring Output Not Outcomes(06:32) 3. 7 Ways To Get Backlog Agility(06:53) 3.1 Measure Feature Impact(07:51) 3.2 Release Every Sprint(08:51) 3.3 Don't Build Onto Features(10:08) 3.4 Use Data To Reprioritize(10:42) 3.5 Remove Bad Features(11:28) 3.6 Commit To Outcomes(12:40) 3.7 Use Cross-Functional Teams(15:25) Episode Groove Visit me at thrivingtechnologist.com

When programmers are forced to estimate code on software projects and they turn out wrong, who's to blame? Are there other reasons why estimating software development projects are so hard, that are outside the control of each programmer? In this episode, I share some of the unique properties of estimating code, and why programming estimates are different than many other types of work. Most of it boils down to treating software development like manufacturing, which is a repeatable process that doesn't involve as much teamwork. Programming on the other hand, is usually done on a team. And to meet the commitment forecasted by our estimate, we need help from other developers. There are also complexities to our work that make estimating increased the chance that things go bad that are a symptom of misunderstanding the nature of programming by project managers, product managers, and scrum masters at some companies. They need help from software developers to understand why the number of variables increases the chance that estimates turn out bad, and that the degree of things being wrong can have disastrous consequences for business commitments that relied on estimates. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Chapter markers / timelinks: (00:00) Introduction(01:19) 1. Why Programming Is Unreliable(01:26) 1.1 Not Repeatable(02:06) 1.2 Too Many Variables(02:50) 1.3 Surface Understanding(04:06) 1.4 Unique Integration(04:59) 1.5 Low Diagnostic Output(06:08) 1.6 Knowledge Work Mismatch(07:19) 1.7 Undervalued Teamwork(08:20) 2. Reduce Impact of Bad Estimates(08:42) 2.1 Reduce Estimated Work(10:06) 2.2 Keep Estimates With Estimators(11:26) 2.3 Estimate In Components(12:50) 2.4 Choose Familiar Technologies(13:56) 2.5 Find Native Integrations(15:04) 2.6 Stop Using Estimates(16:10) Episode Groove Visit me at thrivingtechnologist.com

Every programmer seems to want to vomit the second they hear the word scrum. What is it about scrum that's made programmers hate coding so much, and how can you prevent this on your software development team In this episode, I share 7 reasons why programmers hate scrum, and how it makes our jobs nearly impossible on software projects where the scrum master, product owner (or product manager), and the rest of the software company use it to abuse programmers. These mostly get down to not understanding the scrum guide, and human nature! In this first section of the video, I explain how management on scrum projects usually focus on speed and visible features to the point that it puts the quality of the product at risk. They treat story points like time. They resist investment in things like improved architecture, testing, deployment, and the other things needed to keep developers from quitting unless kept in check. And they fail to accept reality when bad user stories, missing acceptance criteria, and abuse of the burn down chart (and velocity metrics) turns scrum into a numbers game instead of about delivering a quality software product. In the second section of the video, I share 7 practical tips for changes you can make on your software team to start loving scrum again! If programmers on your team hate scrum, drawing clear lines between what software developers and project managers, product managers, product owners, or scrum masters can and can't make decisions about is essential. But as programmers, we also need to be more diligent with how we follow scrum processes. We need to closely inspect the work and only move forward with 100% acceptance criteria. We can't make commitments to vague user stories. And we have to stop estimating just for programming and include time for all the things we know we need - QA, automated testing, automated deployment, infrastructure as code, software architecture - basically all the goodies that keep a project on track as it grows in complexity. This is how modern teams do continuous delivery and devops. I hope this episode gives you some good things to think about. Scrum is a complicated topic, but following everything exactly by the scrum guide is a slippery slope. To love scrum again, programmers need to work with management and the rest of the company to adapt processes to meet the way everyone needs to work together to deliver software. And that's different for every team! Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this video on YouTube. Chapter markers / timelinks (00:00) Introduction(00:36) 1. 7 Reasons Why Programmers Hate Scrum(00:58) 1.1 PO in Daily Stand-Up(01:36) 1.2 Overstepping Scrum Master(02:15) 1.3 Obsession With Features(03:38) 1.4 Story Points Treated As Time(04:42) 1.5 Refusal To Cancel Sprint(05:48) 1.6 No Acceptance Criteria(07:19) 1.7 Burn-Down Chart Used To Blame(07:54) 2. 7 Ways To Love Scrum Again(08:16) 2.1 Remove PO From Daily Stand-Up(09:00) 2.2 Put Scrum Master In Their Place(09:49) 2.3 Buffer Estimates For Code Quality(11:03) 2.4 Don't Commit To Multiple Sprints(12:04) 2.5 Keep The Burn-Down Chart With Developers(13:00) 2.6 100% Acceptance Criteria(13:52) 2.7 Deliver Features That Delight(15:16) Episode Groove Visit me at thrivingtechnologist.com

Professional habits are what makes the difference between someone who actually writes code like a senior programmer - and wishful thinking. The syntax and patterns you use on software projects don't matter nearly as much as the standards you hold yourself to for professionalism. In this episode, I share the essential habits I've developed while working on nearly software projects over my career. If you want to write code like senior programmers do, I hope these practices help you stand out from the pack. 6 HABITS FOR WRITING CODE LIKE A SENIOR PROGRAMMER The first habit is to finish the code you start! There's immense pressure on some scrum or kanban projects to show progress, but if you aren't done - don't lie about it! This only leads to more personal technical debt that you will be under more stress to finish later. If you don't want to let the code grow out of control - this is completely up to you. The second habit is to enforce coding standards. If other programmers on your team have different preferences for how they like to format curly braces, spacing, or any other aspect of your code - this makes it frustrating to share code across the project. We've got the tools to do this automatically now - use them! The third habit is to be disciplined about documenting the patterns the team has agreed to use. You absolutely must have a wiki topic or markdown file in your project that has links to how to apply every major pattern on your project. If you do this, it reduces wasted time in code reviews, and prevents people from introducing new patterns without a justifiable reason for having a discussion before it permeates throughout the codebase. The fourth habit is to review new coding patterns with your team as soon as you introduce them. Rather than replace an existing pattern all over the code base (ask for forgiveness rather than permission), do your teammates a solid and be inclusive as soon as you have something to show. They'll probably have good advice for how to improve on your use of it, and you can get their buy-in and enlist them to help you with the full refactoring effort. The fifth habit is to NEVER expose refactoring as tasks, user stories, or tickets in jira, github issues, trello, asana, visual studio online - or whatever tool your team may be using for work tracking. Whenever an essential engineering practice is called out as a separate item - it only tempts management to pull it out. And the sixth and final habit is to always assume there will be unexpected change in the project for every task you need to estimate. Whether it's unplanned software design meetings, troubleshooting, or documentation - to write code like senior programmers actually do, you can't be pressured to cut corners. While we can't predict every possible uncertainty on a software project, if you estimate like nothing will go wrong - it's your own fault. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this video on the YouTube channel. Chapter markers / timelinks (00:00) Introduction(00:25) Why senior code matters(00:30) 1. Team comprehension(00:57) 2. Reduce interruptions(01:28) 3. Extend longevity of code(02:10) 6 habits of senior programmers(02:18) 1. Prevent unfinished work(03:46) 2. Enforce coding standards(05:11) 3. Document chosen patterns(08:11) 4. Review new patterns early(09:28) 5. Never expose refactoring(11:16) 6. Assume unexpected change(12:40) Episode groove Visit me at thrivingtechnologist.com

I thought I knew what developers needed, but then I met over 200 people online to learn what unlocks their career. The results were surprising in some ways, and not in others. The first thing I learned was that having a plan for your career in software development is something programmers aren't getting enough help with. When I would need a new job, I often took the first reasonable offer instead of having more purpose. It seems other developers are treating their career the same way. The second thing I learned was that developers need more help getting a new job. They treat LinkedIn like an online resume when it's not. LinkedIn is a social profile for your career in software! Software engineers, programmers, data scientists, and other types of developers often have too many languages and technologies on their resume over time - and this bleeds into LinkedIn. I like to help them redo their profile to be more focused on their human side - and learn better techniques for networking to find the best job. The third thing I learned was that developers are suffering from burnout in their career in droves. I've actually had a company pay me to help their lead developer recover from burnout! Recovering from burnout is more than a better diet, exercise, or having a therapist - though people who come to me for help with burnout often already have one. You need help with setting healthy boundaries with your employer so you can be a healthy software developer! The fourth thing I learned unlocks the career of IT professionals in software development and engineering jobs is earning respect and getting recognition from their colleagues. Sometimes there's a difficult person they're dealing with who's a narcissist or just has unrealistic expectations. I use some of the techniques I've learned in IT consulting to help them appeal to the desires of the person they're frustrated with. Once they start earning trust and resetting expectations - rewards and promotions should follow! The fifth thing I learned developers really need to unlock their career is becoming more common. Most of the over 200 I met online were at least considering going into freelancing or IT consulting as a way to work for themselves. Showing developers that the paperwork and administrative tasks needed aren't as bad as they think is something I love to do. I would never go back to being an employee unless I had to at this point. I love being able to pick my own IT consulting clients. The sixth and final thing I learned developers really need in their career is to start using a new tech stack, cloud or data science platform, devops technologies, or maybe switching from a business analyst or product management gig into being a scrum master. Don't hit the books, and waste time on algorithm crunching sites like Hackerrank and Leetcode. Build confidence through having a better relationship with people who might interview you, and have great examples of work. Are there things you're struggling with in your software development career that don't fit into these 6? Leave me a comment! My career purpose is to help more people be healthy software developers. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Episode timelinks: (0:00) Introduction (0:37) Have a Career Plan (2:09) Get a Better Job (5:31) Stop Burning Out (5:55) Earn Respect and Recognition (8:45) Work for Myself (11:17) Use New Skills or Technology Visit me at thrivingtechnologist.com

It's tempting to compare yourself to other developers or take skill assessments to see how you measure up, but honestly it's impossible to truly know if you're a good programmer! In this video I share what I've learned over my 25 year career as a programmer, software architect, and consultant that I hope reduces any anxiety you may have around your self worth. To start this off: why do we even care if we're good programmer? Well first of all, the people who depend on us to do a good job as a developer need to know we're competent and can get the job done. Basically our coworkers have expectations, and we want to meet them. The second main reason I see people caring how good they are, and is the bigger focus of this episode, is comparing themselves to others! With social media (especially LinkedIn) and other influential people showing off their accomplishments, we often wonder how we measure up. But that's a dangerous game. How do we try to assess how good of programmers we are? The first way is skill assessments like tests, bootcamp outcomes, certifications etc. And while these can help, I don't put much stock in them. They usually have a very focused and narrow view. The second way is looking at what we've accomplished in our career as programmers. Have we produced good output for the company? Have we been able to get features out in a reasonable time? The third way is getting feedback! While performance reviews can help, asking another developer, manager, or another trusted professional for explicit feedback is a great way to find out. There are two reasons why I don't believe we can really know how good we are. The first is that we don't have a standard definition of what makes a good programmer. There are so many skills we need! Coding, testing, DevOps, wiki topics, scrum, kanban, data science - it's crazy. And that's only the technical and process stuff. There are also all of our personality traits like openness, coachability, motivation and such. The second reason why we can't really know how good we are is based on the Dunning-Kruger effect. I left a link below where you can read more about it. But it explains what I experienced in my career. That I went through a progression of growing confidence until I realized my own incompetence, then had to build it all over again. We go through these cycles of high and low confidence uniquely for every skill we use as a programmer! So be kind to yourself. It's practically impossible to know how good you are, because we're all different, and we're all growing different skills at different times! Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Episode timelinks: (0:00) Introduction (0:35) Why Care If We're Good? (0:39) Reason #1: Confidence (0:50) Reason #2: We're Comparing Ourselves (1:17) How Do We Evaluate Skill? (1:23) Eval Approach #1: Assessments (2:15) Eval Approach #2: Accomplishments (2:48) Eval Approach #3: Feedback (3:39) Why Can't I Know??? (3:58) Reason #1: No Standard (6:10) Reason #2: Warped Self-Image (8:00) The Dunning-Kruger Effect (10:15) Having Realistic Expectations (11:20) Every Skill Grows at a Different Pace (12:52) Next Time (13:33) Episode Groove Visit me at thrivingtechnologist.com

The first software project of my career was a masterclass in surviving corporate politics that I'll never forget. Programming was the least of my problems! The perfect storm of addiction, deceit, and surviving a death in the family sent me into a downward spiral on this true story of a software project. In this story, I share the personal details of how my struggles with marijuana addiction and the lies of IT leadership collided. Looking back at this software project in the context of my career, I can see how it shaped me. No programming degree or bootcamp could have prepared me for working in software development would really be like when powerful people were involved. As a result of this experience, I went through a period of not trusting anyone, and learning to be vulnerable again took decades. But it also taught me some important lessons about loyalty, perseverance, and putting work/life balance in perspective. I hope by sharing this story, I can encourage you to take some responsibility for your own actions while coding. While at the same time being alert to the evil tactics people can threaten you with when ego, power, and money are on the line. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Episode timelinks: (0:00) Introduction (1:10) The Calm Before The Storm (2:07) A Fragmented User Experience (3:00) Boredom Births and Idea (3:50) An Unexpected Demo (5:45) Mutiny In The Ranks (6:19) The Replatform Distraction (6:55) The Mutiny Exposed (7:50) The Confusions of Addiction (8:55) Impending Family Tragedy (9:41) The Burden of Responsibility (10:31) Putting Life Before Work (11:50) Comparmentalizing Grief (13:02) Accusations of Incompetence (13:50) Investigating the Truth (14:34) Relieved - But Not Really... (15:12) Act II: The Downward Spiral (15:47) A Foreshadowing Warning (16:53) A Seemingly Standard Practice... (17:41) Signs of Sabotage (18:34) The Deception Sinks In (19:44) A Coup D`Etat (20:57) A Harsh Lesson in Project Politics (21:17) New Leadership Arrives (21:38) Unrealistic Expectations (22:33) Mission Impossible (23:45) A Last Ditch C@ckblock (24:27) An Unjust Casualty (25:16) Conclusions (27:41) Next Time (28:17) Episode Groove Visit me at thrivingtechnologist.com

There are tons of people online telling you how to get a better career in software development. Unfortunately, they usually tell you a fluffy story that glosses over the truth. In this episode, I share the 4 career desires of every software developer. This is a concept I discovered through career coaching other people in tech positions (developers, product managers, DevOps, data science, etc.) over the past 3 years. An important thing to know about these desires is that they change over our lives. What I wanted from my career in my 20s, was very different in my early 30s, and then in my 40s. This isn't specific to your age per se - it's more about being aware of your changing life situation. I got myself into a lot of trouble in my software development career when I was pursuing the wrong career desires. The first desire is impact. This is the feeling that the work you do makes a difference! Not feeling like you're making an impact can be either because you aren't able to use the skills you want, or the mission of the company doesn't inspire you. The second desire is growth. This is acquiring new skills to increase your value in the marketplace and get to do more different things on the job. These don't just need to be technical skills like programming however. There are also the skills of persuasion, communication, leadership, negotiation - or anything else that makes us more effective in our software development career. The third desire is work/life balance. This is the whole reason I made the healthy software developer YouTube channel in the first place! If you're having trouble sleeping, no energy to exercise, no time for your spouse, kids, or friends, and you spend almost no time pursuing your dreams - you're burned out! I suffered from serious career burnout as I've discussed in many other videos. Don't let this happen to you! The fourth and final desire, is rewards (or benefits). While the things we do on software projects can be fun, to have a career we need to be compensated well for our efforts. However rewards like getting to work with someone you look up to, flexible hours, stock options, key opportunities that lead to others in the future area also benefits. The perfect job would be one where you're making a big impact, acquiring lots of new skills, have a healthy work/life balance, and incredible rewards. I tell people this software development job doesn't exist! These 4 career desires oppose each other. To get more work/life balance, you may need to sacrifice pay, or impact at times. To get an opportunity to have a bigger impact on a software project, you may need to grow less and use the skills you're already really great at. The important point is to not expect the same level of growth in all 4 of these career desires. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. CHAPTER MARKERS (00:00) Introduction (00:55) The 4 Developer Career Desires (01:28) The Desires Change Over Time (03:03) Desire 1: Impact (05:22) Desire 2: Growth (07:11) Desire 3: Work/Life Balance (08:56) Desire 4: Rewards (10:41) The Perfect Job That Doesn't Exist (11:22) The 4 Desires Oppose Each Other (12:18) Pursuing A Desire Is A Tradeoff (12:55) A Call To Action! (13:31) Next Time... (13:44) Episode Groove Visit me at thrivingtechnologist.com

Get your tech career unstuck here: https://healthydeveloper.com/coaching Are you looking around on your software project and just waiting to see someone fail? Are you quick to condemn a manager or developer and cast them useless after a single mistake? Today we're going to talk about how canceling developers and other IT professionals for mistakes can hold you back from the career you want in software. When I first began developing software, I wasn't particularly ambitious. I needed to make a living to support my wife and son, but I came from a background of partying and playing in a band. But after a few short years I had several promotions and raises, and it started to go to my head. With each new success, my pride got bigger. Once software projects started getting complicated, I started looking for people to blame. The scrum master didn't understand agile enough. The operations team wasn't making it easy enough to release changes into production. The other developers weren't following my coding patterns. Yeah, I became an elitist jerk. But as I've told you many times on this channel, I fell hard eventually. A victim of career-long burnout, I lost my job, a lot of money, and sunk into depression. But when I came out of it, I made this channel and started giving software developers and engineers career advice. It also led me to learn how to work better myself - and help you be a healthy software developer. A moment though of reflection for yourself: are you on the way there? Starting to get rewards and recognition for developing software? Is it getting easier to see flaws in developers and other people on your software project, making you quick to judge? Are you canceling the people who can help you for simple mistakes? If we're humble and honest, we've all made mistakes. And I'm sure I'm going to make many more, whether on a software project, coaching you on your career, or on this channel. I'm pretty sure if you're willing to take an honest look at yourself, you know you're going to too. But you've made mistakes in the past and been forgiven. So should you be more forgiving too? Can we really be fair canceling anyone? What would it be like if all our teams were more like this? What if we worked together assuming we'll make mistakes, and not being surprised? What if we spent more time forgiving, learning, and teaching - and less blaming? Imagine the courage we could have to try and do risky things that might be breakthroughs with our products, technologies, and careers? Episode timelinks: (0:00) Introduction (2:35) The Dangers of Leading (4:35) Falling Hard (6:14) Is Success Putting You in Danger? (8:15) Motivation for True Forgiveness (9:20) Leading Means Helping! (11:00) For Future Leaders... (12:52) What Could Teamwork Be Like? (13:48) Why Should You Care? (14:30) A Call To Action!!! (17:40) Next Time... (19:25) Episode Groove

Can you believe it's been 3 years since I made an episode? Yeah you can - you've been asking me to come back. Sorry! I just wasn't ready yet. I got clean from marijuana addiction in 2019 but it's taken me a lot longer than I'd hoped to get better. At least better enough to come back on YouTube. In the meantime, I've met with about 200 people all over the world to learn better how to help you with software development career issues. There were a lot of things I thought I understood. And some of them I did. But it was humbling to realize many problems you're having with your career are forcing me to step up and learn again. You may notice this video looks different! I've collected some gear over Craigslist and whatnot to try and create a more interesting look for our time together. I hope you like it. I'll be tweaking it over time as I make more videos about Healthy Software Development. I should mention, thank you for blowing up my channel over a year ago! The video "Why do so many programmers lose hope?" got recommended by a well known programming channel and within a short period, the channel grew 10x! I'm not someone who believes the number of subscribers determines the value of content, but it sure helps me to know you care. In the next episode, I'll be talking about learning from people who've made mistakes. Chief among them - me! I see a real problem in our culture right now with developers and other people in IT only looking to people with a fake persona of having all the answers or being flawless. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. CHAPTER MARKERS (0:00) Introduction (01:33) Where I've been (02:44) I'm still having health challenges (03:55) The channel purpose hasn't changed (04:48) I'm career coaching now (07:30) I'll focus on career outcomes that work (09:45) Channel production changes (09:51) The channel blew up 10x! (11:40) Thank you for your support (13:13) The next video is about... Visit me at thrivingtechnologist.com

I've been working through anger issues after reflecting on the content I've put out there for people in the software industry. I mostly avoided social media for the past 5-8 years and when I started putting my ideas out there, I bought into the "outrage culture". I also have been on many failed projects. And I've had personal problems with my family and identity. I made this video to apologize for my anger and how I've come across as "knowing everything" sometimes. I don't think it helps anyone to be another voice in this, and so I'm committing from here on out to be more discerning with how I share my opinions and advice. When I was 14, I stopped going to church because I wanted to party with my friends. 5 years later I got my girlfriend pregnant and had a really hard time with being a father. I felt too young in public, frustrated with myself and my bad decisions, and so I began to smoke marijuana pretty regularly after work. After my Dad died from cancer, I didn't understand how to cope with the grief and so I used video games (MMOs at the time), music, and pot to escape from what my life had become. Though from the perspective of people I worked with I was successful, my home life was a mess. Software developers make a lot of money and even though I had most of my financial and material needs met, I was really empty inside. After suffering from a bout of chronic insomnia two years ago, I began going back to church. It was really strange and I felt completely out of place. But after I started going to a men's group offered by the church on Fridays, I met several other men who were open about their failures and willing to counsel me where I'd went wrong. I began praying that God would help me with a lot of things, but 3 in particular kept coming up. First, that I would have the courage to do what's right even when people don't like me. Second, that I would heal from bitterness in my life, and that my heart would soften to let go of anger. And third, that I would have more discernment to make decisions that would be better for my life. My life has been going much better in all areas other than my career. I've decided to go into management after reflecting on where my passions are with helping companies and people be more healthy about how they develop software. What this means for the channel is that I'll continue to make content, but I need to do it in a more sustainable way. I need to focus more on my personal responsibilities, and healing from burnout on projects. I've started writing songs again to try and provide myself with a better creative outlet. It can be really frustrating to work at companies when they put you in a box and don't allow really good work to be done. I was looking for the opportunity for creativity in the wrong place in my life. Thank you for being so supportive over the past 2 years of me doing this. I just wanted to help people avoid the mistakes I've made, and I never thought there were so many other people out there who needed help too! Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Related resources: Colin Zera - Sister (Home Acoustic Video) Visit me at thrivingtechnologist.com

Scott Nimrod is an experienced Software Consultant based out of Miami who specializes in Test Automation, WPF, Functional Programming, and a variety of other technologies. In this interview, Scott and I discuss the balance between strengthening your reputation through your personal brand as a developer, and the teamwork necessary to be successful in your career. We also touch on concepts in the interview with Woody Zuill about mob programming and the "noestimates" movement. Scott also runs a YouTube channel with great interviews and live programming exercises. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

Working on a software development team where everyone does their work separately – and thinking of trying something new? Today I have a special guest, Woody Zuill, who is the leading voice in our industry around the concept of Mob Programming. If this is the first time you've heard of it, Mob Programming is essentially an entire team working together with only one person's hands on the keyboard. There are some surprising advantages to this approach that you may not have encountered before. I hope this interview with Woody gives you some insight into how this practice may help you. I learned some really interesting things about the origin of this practice and how Woody found himself in the position of being its primary spokesperson. The interview is also filled with valuable advice about influencing change and earning credibility to help software development teams be more agile – whatever that means to you :). You can follow Woody on twitter here: https://twitter.com/woodyzuill or visit his website here: http://woodyzuill.com/ Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

Does it ever feel like you'd get so much more done if it weren't for how much work people have you do to make commitments? Today I'd like to help you understand whether the development team you're on is using commitments in a way that makes sense, or will stress people out and put the software project at risk! Since most teams I have worked with aren't really agile, I'm concentrating on helping you understand the risks with commitments between the wrong people which often happens in "traditional" software development companies. Whether your a programmer, in UX, or maybe operations - commitments that are too strict, or too unrealistic, put your job and the success of the project in danger. First I will teach you some insights I've learned about how commitments can cause agile teams to grow toxic. Afterwards, I'll give you some actionable tips on what you can do to cope with traditional (non-agile) teams that require unrealistic commitments. I hope this information helps you select the best project for your career, or if you're on an unhealthy team - protect yourself so you have the best chance of being successful! Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

Over the weekend I posted a video clip from episode 3 of my series on this channel "How Agile Teams Grow Toxic!" to reddit. The full video is about how teams can become unhealthy due to how % complete forecasting is done on most projects. In the clip I posted, I spoke specifically about the unpredictability of our work as software developers. There were over 100 comments on reddit alone with some other great ones here on the channel. In this video, I respond to several of these comments to provide further clarification on the concepts of healthy software development. I'm going to do a future video called "My Software Development Philosophy" in which I'll go into many of the things I touch on in the response in more detail. But for now, I hope you enjoy the responses. If you don't agree, let me know why! If you do agree, how can we get this information out to more people? Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

With all the challenges in the software industry with languages, frameworks, and processes... It's easy to forget we're human. I've been making some really serious level 301 agile nerdgasm content lately, so I made this episode to just have some fun. Here are three stories of times I was embarrassed in my software development career. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

Deadlines! "Drop dead" dates! Changing the schedule to meet "new requirements"! Do you ever think there's gotta be a better way to do this? Well there is, and today I want to share with you some information about a topic that often bores software developers... But in my experience of working with many teams and companies, when developers are frustrated on their project - it is this topic that's often the culprit. In this video I discuss how people who pay for software development projects forecast. Before you bail, if you hang with me on this video you'll know more than many agile coaches and product managers about why investing in software projects is unique! I'll share the dangers of traditional forecasting on software projects - and an alternative way to give investors confidence. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Related resources: Eric Ries: The Lean Startup | Talks At Google Visit me at thrivingtechnologist.com

To keep an agile team from becoming toxic, you should know how the background of the founders of the company impacts hiring. In this episode I'll help you understand how this impacts how fulfilled you'll be on your project. When you interview at a company, you need to be wary of stated company values and instead use your experience with actual people as your guide. Hiring today is impacted by a concept called "mirroring" from the psychology field where people tend to accept others who are most like them. So founders and hiring managers will tend to hire people who have shared experiences, even though what the company may most need are fresh ideas. When you go in for an interview, you need to determine whether the company hiring you is filling a short term skill need – or they truly want to invest in you as a person. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

One of the most frustrating things over my career has been working at companies where the workplace culture has become toxic. Though many companies hire agile coaches to try and improve the way they deliver, in my experience the leaders are the ones who most need "agile transformation". This video kicks off a series called "How Agile Teams Grow Toxic". I'll share the dark side of human behavior on projects, and why the situation can seem almost impossible to improve. In this episode, I discuss how the core value, or motivation for starting the software company that the founders have impacts this greatly. Most software companies or projects are started for one of the following 3 reasons: Money Fame Impact It's preferable if you can find a company with founders (or leadership if the founder left) that are motivated by impact. But this won't guarantee that the project will be successful! You should also look at where the founders skills originated. Did they come from a business, or engineering background? This will give you some ideas as well about the founder values. Ultimately, you want to find a software company or product where the leadership are looking to YOU for innovation and help. Not treating you like a pawn who can only crank out code and shouldn't think about the business or its products. I discuss a simple way to research founders and other members of the management team at a company to get an idea of whether the culture there is healthy. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

Have you ever had to quit a good software project...because you figured out you weren't going to be successful in your role? I had the opportunity to help two consulting companies try and rescue a troubled software project for a client. Though I was originally brought in to help figure out how much work was left to do, I found myself in the position of being "the expert" once again. Because of politics, deadlines, and challenges with the maturity of the companies understanding agile - I found myself overwhelmed. Though I continually tried to reset expectations and get help, I decided eventually that it was better to move on. Have you ever been on a good project, with good people, only to find when you really think about it you're not effective in your current role? Did you have a hard time getting support from management to make the changes necessary? Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Related resources: The ModernAgile YouTube channel Visit me at thrivingtechnologist.com

Over my career I've seen many software projects fail spectacularly due to political infighting between team members. Blame-shifting and improper application of scrum got people fired on this one! I prefer a simple definition of politics: when people tell each other what they want to hear instead of the truth. I'd like to share the story of a software project I worked on, where the client was a non-profit company with a big budget. They wanted to redesign a major application used to help struggling educational institutions. But the staff were inexperienced with agile. And multiple contractors on the project were fighting. In this episode, I share how inexperience with software development processes can actually get people fired. Especially when there's politics. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Related resources: Are User Stories Making Your Project Late? Visit me at thrivingtechnologist.com

It's bad enough when you're working on a software project and you run into a problem. But it's even worse when you know that problem might block other people from getting work done! It's always blown my mind how some managers try to keep everyone working as if nothing's wrong when this happens. Software projects are getting more complicated every day and so it's easy to get to a point where you're blocked. And I've been in the situation many times where I've had to explain a problem I'm having to my boss or managers. But when the problem blocks other people, I've had bosses at times pretend there is no problem! Especially if there's pressure, blocking multiple people to fix a problem can feel horrible for management – if they're focused on how much people are getting done. I talked with you in another episode about how focusing on how much work a team gets done actually hurts how much money a product makes for your company. So in this episode I want to help you get your manager or boss to support you when you need to make a change that will disrupt other people. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

One of the most frustrating software projects I've been on involved webcam spying and finding the people who hired us rewrote our code! A large company that bought out two young entrepreneurs hired me and other consultants to help them. But the entrepreneurs didn't really want help. Soon it was apparent that they had no desire to listen to our advice, or treat our opinions as worth anything whatsoever! In this story, I share how software developers can act irrationally when they are under fear of being shown something "they don't know". Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

Over the years I've had to lead many software developers, and it's become much easier since letting go of being seen as "the expert". Even if I'm only leading a few people there's always too much work and I have to choose really carefully what I do. If you've watched any of my other videos you know I'm a big fan of teams where there's less management. But whether someone is officially recognized as a "lead developer" or not, most teams usually have people on them who are more experienced. And people naturally seem to take ownership for areas of the product they're most interested in and can start being seen as a leader around that idea. Maybe that's you, or maybe you're considering stepping into a role where you'll be leading developers to do something with the software. In my career I've found it's really easy to get overwhelmed when I'm leading other developers. Meeting with the business, supporting developers, and still trying to get work done on the product myself can feel impossible. You've probably heard the saying "give someone a fish, feed them for a day. Teach someone to fish feed them for a lifetime". But even though I know this, it can be hard to let other developers do more to help you if it's going to take longer than just doing it yourself. In this video, I share how I've had more time to support my team when I let other developers have more responsibility, and you can too. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

Sometimes I get an opportunity to show a team how to use a technology that not only solves a business problem, but I really like! In this case it was continuous delivery to deploy business intelligence dashboards to production. When a client of mine was burned by a prior vendor that couldn't deliver their software project, they needed to see progress made quickly. The software product was supposed to be a set of complicated visual dashboards that pulled in data from a bunch of different healthcare systems. At the time deploying these types of software systems was a manual, error prone process. So I had built a framework to automate releases. This would help us follow continuous delivery. But the lead on the project was resistant at first, and the client wasn't sure they were ready. In this episode, I share how the continuous delivery framework I used earned trust at first...but was eventually abandoned. I still had many things to learn about how to support my own software frameworks! Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

As you grow, it can be tempting to start comparing your career to other developers. It's only natural that as you notice other people getting promotions, recognition, and opportunities to lead exciting efforts – you consider: "Would I like that too?" But it's a slippery slope from discovering some new worthy goals to chasing someone else's! In this episode I share some ways I've come to cope with many projects where I ask myself: "How do I feel when someone else gets recognized?" Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

John Cutler is an experienced Product Manager, writer, and consultant. You can read his many popular articles on Medium where he discusses a variety of topics related to software development in the hacker noon publication: https://hackernoon.com/@johnpcutler In this video, John and I trade some thoughts around the perceived decline of agile in some areas of the industry. We also discuss the challenges surrounding balancing making changes with accepting things as they are. You can also find John on twitter here: https://twitter.com/johncutlefish Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

Over my career I've seen more projects fail due to misuse of user stories than any other practice commonly used on agile teams. You probably already know that user stories are just a simple format for writing requirements on scrum or kanban agile teams. Today I want to help you avoid some bad advice I see out there about what user stories are and how they can help (or hurt) you. Why User Stories Were Created Before agile methods for development, teams wrote big documents describing the design of a software product before building it. Since the project was designed up front, it was also funded up front. The more detailed the documents, the better the estimate of costs. But companies were finding that by the time software was done, customers wanted something different. Early leaders in the agile community came up with a great idea to only build and release a little bit of a software product at a time. This would let the team change their mind about what to build once the project started. Since it takes a long time to document something you might not build, the industry began using user stories to describe requirements. The thought was to describe just enough about what value a feature offered to the customer that it could be prioritized. The Pressure For Traditional Budgeting But some leaders and business owners still wanted to know exactly what they were getting before approving budget. They forced people to estimate and scope every idea anyway because they were too scared to fund a team without knowing exactly what they were getting. Many agile coaches tell teams that a user story is just a placeholder for a conversation. Once the team starts working on it, they'll talk with the customer or Product Manager and get the full details. The problem is, once this conversation was held, many additional details emerged. And this caused the estimate to go way up. With Non-Agile Leaders, You Need More Than User Stories If your stakeholders (product managers, customers etc.) are focused on cost, you are much better off creating detailed acceptance criteria that describes a user story in detail before you give out any estimates. Acceptance criteria reads like a test script and describes exactly how someone can use the software, or write an automated test, to verify it's done and works right. If you don't have acceptance criteria, the rough estimate you give out for a user story will change. And every time it does, you'll lose trust with your stakeholders because you'll look like you estimated wrong. So match the level of detail in your design and requirements on your project with your stakeholder's tolerance for uncertainty. If they are focused on costs, certainty, and predictable deadlines - writing only user stories and committing to estimates without acceptance criteria is foolish. It's like committing to a waterfall project with 10% of the documentation necessary to really estimate it!! Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

Ever been on a software development project where one team is putting pressure on another because of a hidden agenda? I was once asked to investigate two teams that worked together to build a software product for doing taxes. The first team contacted us and said they needed help with releasing software better. So I planned to use an interview I'd come up with over the years. It had questions I could ask people about how they work together. Things like how they gather requirements, test the software, and approve releases for example. While interviewing the first team, it became clear that they did't like the second team. The second team wasn't following scrum, while the first team was. The first team was convinced the problem was with the second team. However after interviewing many people on both teams, we realized the second team was following kanban. But they were doing it for a good reason - to respond to unpredictable changes in tax code. So eventually we presented our findings, and though many people were pleased - our client was disappointed that we hadn't only found issues with the second team. In this episode, I share the story of how I had to avoid being used as a pawn in corporate politics at my client. I hope it helps you avoid being put into a situation where you're pressured to side with a group of people to force another to change unwillingly! Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

There's an old saying "you improve what you focus on, and you focus on what you measure". There are just way too many software companies I run across focused on the wrong things – because they're measuring the wrong things. In this episode, I'll show you how you can help your company make more money with the software you build by measuring the right things. When your company makes more money, you'll get the opportunities and rewards you want. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

One of the most frustrating software projects I've been on was when we designed a product that never got built! A couple different things happened on this project that made it difficult... First, the project was being sold to use an agile process, but then was suddenly switched to fixed cost at the last minute. Secondly, there were too many people in management positions. It created confusion where team members were getting conflicting instructions. The client was telling each manager different things! And lastly the client had never designed a software product before. We tried to warn them to design a simpler product than their entire vision, but they wouldn't listen. Because they tried to design the product up front, they designed a product that was too complex for a first release. Though we did what we could to keep the project on track, it ultimately was too expensive for them to build. I hope this episode helps you avoid some of these mistakes on your software projects. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

When talking about the differences between scrum (or kanban) and agile development, the motor and steering wheel of a car can be a useful analogy. When your team is working to write requirements, write code, test, and deploy releases of your software – they probably follow a development process like scrum or kanban to get work done. This work can be thought of as the motor of the car that propels the software product forward, changing or adding new features to it. However software companies sell products in a changing market – competitors can force us to change, customers can force us to change, and our own team members can discover information that forces us to change. This is when the leadership of a software team especially need to trust their other team members to make changes. Each time the team makes one of these changes to respond to unplanned events, they are being agile. Being agile in software development is like using the steering wheel of the car. When things change, the direction of the features needs to be turned so the "power" of the engine is focused on something different. In software development, we steer the car by putting new product backlog items (or kanban tickets) at a high priority to make satisfying our customer paramount. Customers won't buy a software product when we've built everything WE think they want – but only what THEY accept. In this episode, I share some thoughts around this analogy and how you might use it to ask this question next time you're making a software development process decision: "Is this practice going to help, or hurt our team's ability to 'steer' the car that is our software product's queue of work to be done?" Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

Is there a time to just stop learning and write code? Software development draws many of us in with endless opportunities to learn, but is it right for every project? Early in my career I wanted to know everything possible about the software companies I worked for. But a couple of years in software consulting taught me I could actually be a better developer by learning to ignore information sometimes. In this episode, I share a story of a project I was on where the relationship was in trouble between my agency and a client. Fixing the relationship was the most important thing to do - but it could only be done by solving their problems quickly. The relationship was repaired quickly - but only through ignoring learning some things about the software! Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

At some software companies, it can be hard for people to learn from mistakes they make as a developer, product manager, or any other role that works together on a project. Because building software requires so much communication, it's natural for things to get lost in translation and mistakes to occur. But we can treat mistakes as an opportunity to blame someone else, or a chance to encourage them to learn. And this also reflects back on us, showing others we can use encouragement too when we make mistakes. I hope this episode gives you some useful advice to prevent you from having the mindset I did earlier in my career – …that people should be held to the same expectations of reliability as a computer! Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

There's no shame in getting help from a friend on a software project! Let me tell you the story of a project I worked on soon after moving to Austin, Texas. I was new to the consulting side of the software development industry, and didn't know anyone in town. After being put on a project with a more experienced consultant, I ran into a few challenges. But after realizing the other consultant wanted to help, I got myself out of a jam that was starting to make me feel pretty stressed out. I hope this story helps you think about the next time you're struggling to get some work done. There's no shame in asking for help, or even giving your work over to someone else. Businesses pay us to get value delivered to customers - but we don't always have to be the ones to do it! Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

It's always been popular to tell people how they're "doing it wrong" and agile software development is just as easy to call "fake". But in working with many teams who read these same articles, they still get lost in a sea of opinions and need a definitive answer. So I made this short episode to help you spot fake agile teams in under 7 minutes. With this information, you'll know the truth, but may be disappointed with whether your project even benefits from agility. There are really only two questions you need to ask! By the end of this episode, you'll be able to know in an interview whether the team you're joining is agile, call B.S. on an agile coach who misses the point, and help the people on your team work together better. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

Let me tell you a story about one of the weirder software projects I've been on – and how trying to change the culture went wrong. Early in my programming career I had a taste of some successful projects at a Fortune 500, and I focused entirely on technology and basically had *no* soft skills. So coming into a small company that wanted to grow their technology business seemed like it would be "easy". Little did I know how simple decisions about the relationships I made (and didn't make) would lead to disaster. There were also things outside my control, and those always seem present on every project to this day. Whether you want to help a team be "more agile", maybe try and achieve DevOps, or just use the latest Javascript framework – I hope this short story helps you avoid culture problems if you ever want to change your software development team. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

Iain Lowe is an experienced software developer and manager based out of Montreal, Canada. Iain found me on Twitter after viewing a short clip from my interview with Scott Nimrod. In this interview, Iain and I discuss the controversy around the Reddit post about estimating that I created from my interview with Scott Nimrod, organizational culture in the tech industry, the dogma of transformation in agile practices, and considerations for the career of growing developers. Follow Iain on Twitter where he provides a lot of great advice and support for budding software developers: https://twitter.com/realilowe Iain also has a YouTube channel you can check out: https://www.youtube.com/user/iainlowe Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com

I'm still figuring out how to help more software developers understand how important consulting skills are! Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide Visit me at thrivingtechnologist.com

Scott Nimrod is an experienced Software Consultant based out of Miami who specializes in Test Automation, WPF, Functional Programming, and a variety of other technologies. He was an early subscriber to my channel and has given me a lot of great advice and support since I started out on YouTube in 2017! In this interview, Scott and I discuss some serious topics related to software craftsmanship and consulting. Specifically the dynamics between consultants and managers, working with difficult people, career growth, testing – and the direction of the software industry. Scott also runs a YouTube channel with great interviews and live coding exercises: https://www.youtube.com/user/Bizmonger Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. CHAPTER MARKERS (9:55) Rescuing Projects with Quality (13:17) Short-Term Product Decisions (17:40) Continuing Developer Education (20:34) Accepting Unmotivated Employees (26:01) Getting Blamed for Failures (29:11) Staying Positive and Fearless (35:31) Establishing Industry Authority (42:53) Unpredictability and Estimating (48:45) Forcing Process Changes on People (58:40) Focusing Your Passion on People (1:00:27) Coping With Corporate Politics Visit me at thrivingtechnologist.com

It's like I have a filter - I can't even tell you everything I want to! Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide Visit me at thrivingtechnologist.com

Does it sometimes feel like the decisions made by leaders are almost trying to get programmers to hate their software development projects? I would often take for granted the things that I knew as a developer and assume that leadership at my company understood them. Because software development is so expensive, and the business schools many CEOs come from are still steeped in tradition, there can be lost trust and mistreatment. If your CEO, Product Manager, or Project Manager doesn't know these things, disastrous results can occur on your software project that causes people to get angry and eventually leave. In this episode I share 9 truths of software development that if understood by leadership, will help them get along with programmers better at their company. Join my Patreon: https://thrivingtechnologist.com/patreon Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles The Thriving Technologist career guide: https://thrivingtechnologist.com/guide You can also watch this episode on YouTube. Visit me at thrivingtechnologist.com