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

Instatechcoach is a livestream I'm doing on Instagram where I offer short, free career coaching for software professionals every Saturday at 1PM Central Standard Time. 

You'll hear me discussing the career challenges of other developers, and answering questions about my own career, as well as The Healthy Software Developer show. 

Follow me on instagram as jayme.c.edwards

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