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

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? 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 (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 Visit me at thrivingtechnologist.com

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

It’s common in many companies for there to be animosity between programmers and managers – but it’s smarter to consider healing that rift. Earlier in my career I met many other software developers who loved to complain about management. And I’ve been just as frustrated, especially when it seems like management doesn’t know what they’re doing. But eventually after having several experiences talking to other programmers I respected, my perspective changed. In this episode, I share some stories about software projects I have been on where I was challenged to be enlightened to continue. I hope these stories help you think about what you can do to take the power of your career back into your own hands. 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 the daily scrum meeting is really just a status meeting in disguise? The daily scrum or “stand-up” meeting was created as part of the scrum methodology for agile development to reduce time wasted in meetings. But some companies use it to gather status. In our modern software development market, there are many tools that can provide managers with real-time access to status, so this is unnecessary. In this episode, I share several tips for getting your daily stand-up meetings under control so you can run a daily scrum that actually benefits developers. Though it’s tempting for management at software companies to use the daily scrum meeting to gather status, they actually make the job of software developers harder by doing this – and put their software projects at risk! 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 can be confusing when most companies don’t make it clear how software developers can get promoted for more senior roles. If you’re a junior developer and trying to figure out, what exactly do I need to do? – it may not be cut and dry. Rather in this episode, I share some soft skills I’ve found in working with over 30 software development teams that I see those who get promoted exhibit. If you want to be considered for a senior software engineer role, or perhaps a higher level role such as a team lead, development manager, director, or even CTO – these skills are incredibly valuable. They will make you stand out from other candidates and naturally be seen as a more mature option for a technical leader. 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

Software developers are often frustrated when a product manager changes the design at the last minute. But product managers are a programmer’s best friend! In this episode, I share how your colleagues in product management are actually your biggest ally. Whether you’re in Operations, UX,Ssupport, or any other aspect of developing software – a good relationship with the manager of your product is indispensable. As the “CEO of their product”, these individuals have access to resources and the ability to influence the company in ways you may not have thought of. 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 tempting to jump into refactoring code that’s hard for you to understand – but make sure you’re doing it for the right reasons! But before you take that leap, you should probably consider that there can be some dangers. Whether you’re coding in Java, Javascript, C#, Python, or any other language – there are non-technical implications of code refactoring that you should be aware of. In this episode, I share 6 considerations to take into account that will help you avoid getting into a stressful situation when you choose to refactor code. 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 been confronted with accepting circumstances you couldn’t change on your software project that were really difficult? Maybe you don’t agree with a decision, or you’ve been forced to work in a way that you’re not happy with? Though most of us like to think we’re able to control our career, there are times we inevitably have to learn to let go, and accept difficult circumstances. In this episode, I share a set of steps I go through to help me on software projects when I struggle with this. If you can accept difficult circumstances easier, you can get back to enjoying your 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

In working with over 30 companies, I’ve seen 7 common big FAILS in agile software development processes! These are so common, but so easily avoided, and they have little to do with whether you’re doing kanban or scrum. In my experience, agile issues are rarely because of a single step in the software development process, but rather because of not considering the implications on the 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