Call them changemakers. Call them rule breakers. We call them Redefiners. And in this provocative podcast, we explore how daring leaders from across industries and around the globe are redefining their organizations—and themselves—to create extraordinary impact in today’s rapidly changing world. In each episode, Russell Reynolds Associates Leadership Advisor Hoda Tahoun and former CEO Clarke Murphy host engaging, purposeful conversations with leaders in and out of the business world who shar ...
…
continue reading
Player FM - Internet Radio Done Right
39 subscribers
Checked 14d ago
Added eight years ago
Content provided by Jayme Edwards and Tech Career Strategist. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Jayme Edwards and Tech Career Strategist or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://ppacc.player.fm/legal.
Similar to Healthy Developer
Big tech is transforming every aspect of our world. But how, and at what cost? This season of Land of the Giants – The Disney Dilemma – focuses on Disney’s ability to weather the ups and downs of the business cycle and changing tastes and explores what has kept it successful for over 100 years. The entertainment giant has leveraged nostalgia and its intellectual property to build a beloved brand, but after an acquisition spree that included Marvel, Lucasfilm, and 20th Century Fox, can it sus ...
…
continue reading
Some Goodness is hosted by Richard Ellis, a seasoned sales leader passionate about inviting top business minds to share their wisdom. Each episode is only 15-20 minutes, perfect for your commute or workout.
…
continue reading
T
The Brutal Truth about Sales and Selling - We interview the world's best B2B Enterprise salespeople.
1
The Brutal Truth about Sales and Selling - We interview the world's best B2B Enterprise salespeople.
Brian Burns
11k
279
No BS Allowed - Are you sick of empty suits telling you to work harder? - Learn about The Maverick Selling Method, which models the world's best salespeople and what they do differently. If you are in sales and are passionate about selling, you will like this podcast. The focus is on b2b sales and selling. If you are selling or in sales, this podcast is for you. I cover cold calling, spin selling, challenger sale, solution selling, and advanced selling skills. Strategic selling, LinkedIn, sa ...
…
continue reading
T
The Influence Factor by The Influencer Marketing Factory
1
The Influence Factor by The Influencer Marketing Factory
The Influencer Marketing Factory
37k130
Alessandro Bogliari, CEO and Co-Founder of The Influencer Marketing Factory, a global influencer marketing agency, talks with great guests about influencer marketing, social media, the creator economy, social commerce and much more.
…
continue reading
It didn’t all change in March 2020. Not really. The UK high street has been in the throes of a gradual revolution for decades. From the rise of ecommerce, to the birth of mobile, social commerce, and a growing emphasis on experience, change has been underway for a while. In fact for many, the pandemic has acted as a wake-up call. Digital transformation was no longer a ‘nice to have’ but a matter of survival. Necessity sparked innovation and customers are enjoying more flexibility and conveni ...
…
continue reading
Rachel Cooke is your guide to leadership and communication, helping you craft a workplace environment you can feel good about. She’ll share tips to help you balance your work and personal life, effectively invest your time, and be mindful about where you’re devoting your energy. Let Rachel help you navigate your path to success—however you define it.
…
continue reading
The fun email marketing podcast. Sell more of your online courses, grow your membership and bring in more coaching clients with email marketing that doesn't stink. Sound good? Then join your fellow Email Marketing Heroes for your weekly dose of fun, practical, yet brutally honest email marketing advice. You can listen in to a piping hot, fresh episode every 'Email Marketing Wednesday' or if you prefer learning with your eyes instead of your ears, we turn each episode into a full written blog ...
…
continue reading
Hosted by productivity strategist Mike Vardy, A Productive Conversation offers insightful discussions on how to craft a life that aligns with your intentions. Each episode dives into the art of time devotion, productiveness, and refining your approach to daily living. Mike invites guests who are thinkers, doers, and creators to share their strategies for working smarter and living more intentionally. From practical tips to deep dives on mindset shifts, this podcast will help you reframe your ...
…
continue reading
Career Tools is a weekly podcast focused on specific actions you can take to grow and enhance your career, whether you are a manager or not. Career Tools won the Podcast Awards Best Business podcast in 2010 and was nominated every other year it has been eligible. Whether you are interested in jump-starting a stalled career, or sharpening your edge, Career Tools is the podcast for you. Go to http://www.manager-tools.com/testimonials to read what others are saying about the impact Career Tools ...
…
continue reading
Player FM - Podcast App
Go offline with the Player FM app!
Go offline with the Player FM app!
))
Daily Deals
Podcasts Worth a Listen
SPONSORED
S
Squid Game: The Official Podcast
Squid Game is back—and this time, the knives are out. In the thrilling Season 3 premiere, Player 456 is spiraling and a brutal round of hide-and-seek forces players to kill or be killed. Hosts Phil Yu and Kiera Please break down Gi-hun’s descent into vengeance, Guard 011’s daring betrayal of the Game, and the shocking moment players are forced to choose between murdering their friends… or dying. Then, Carlos Juico and Gavin Ruta from the Jumpers Jump podcast join us to unpack their wild theories for the season. Plus, Phil and Kiera face off in a high-stakes round of “Hot Sweet Potato.” SPOILER ALERT! Make sure you watch Squid Game Season 3 Episode 1 before listening on. Play one last time. IG - @SquidGameNetflix X (f.k.a. Twitter) - @SquidGame Check out more from Phil Yu @angryasianman , Kiera Please @kieraplease and the Jumpers Jump podcast Listen to more from Netflix Podcasts . Squid Game: The Official Podcast is produced by Netflix and The Mash-Up Americans.…
This Is Why Managers Don't Trust Programmers...
Manage episode 415733223 series 1756036
Content provided by Jayme Edwards and Tech Career Strategist. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Jayme Edwards and Tech Career Strategist or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://ppacc.player.fm/legal.
Have you ever seen another programmer who wasn't as skilled as you get promoted? Did you tell yourself management was making a mistake?
Earlier in my career I didn't realize I was doing some things that caused managers to lose confidence in me. I would spend all my time writing code and never think about how I came across to other people.
In this episode, I share some harsh truths I've learned about how being a software engineer can cause us to do things we think the company wants - that actually hurt our reputation in the long run.
Companies are actually paying you for confidence as a programmer. And this episode is full of practical strategies for making sure you don't fall into traps that stop you from getting recognized for the great code you write as a programmer - before your career is really getting started!
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:19) 1. What Companies Really Want From Programmers (2:12) 2. How To Build Employer Confidence as a Programmer (2:22) 2.1 Minimize Communicating Problems and Doubt (5:42) 2.2 Repeat Management's Desires (7:46) 2.3 Anonymize Blame on Dependencies (10:57) 2.4 Reduce Your Throughput (14:52) 2.5 Elevate Your Coworkers (17:05) 2.6 Over-communicate Status (20:11) 2.7 Highlight Discovered Shortcuts (22:20) 2.8 Document Verbal Decisions (26:58) Episode Groove
Visit me at thrivingtechnologist.com
178 episodes
ShareManage episode 415733223 series 1756036
Content provided by Jayme Edwards and Tech Career Strategist. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Jayme Edwards and Tech Career Strategist or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://ppacc.player.fm/legal.
Have you ever seen another programmer who wasn't as skilled as you get promoted? Did you tell yourself management was making a mistake?
Earlier in my career I didn't realize I was doing some things that caused managers to lose confidence in me. I would spend all my time writing code and never think about how I came across to other people.
In this episode, I share some harsh truths I've learned about how being a software engineer can cause us to do things we think the company wants - that actually hurt our reputation in the long run.
Companies are actually paying you for confidence as a programmer. And this episode is full of practical strategies for making sure you don't fall into traps that stop you from getting recognized for the great code you write as a programmer - before your career is really getting started!
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:19) 1. What Companies Really Want From Programmers (2:12) 2. How To Build Employer Confidence as a Programmer (2:22) 2.1 Minimize Communicating Problems and Doubt (5:42) 2.2 Repeat Management's Desires (7:46) 2.3 Anonymize Blame on Dependencies (10:57) 2.4 Reduce Your Throughput (14:52) 2.5 Elevate Your Coworkers (17:05) 2.6 Over-communicate Status (20:11) 2.7 Highlight Discovered Shortcuts (22:20) 2.8 Document Verbal Decisions (26:58) Episode Groove
Visit me at thrivingtechnologist.com
178 episodes
All episodes
×
H
Healthy Developer
1 He Thought Product Management Was The Answer... 48:33
48:33 
Play Later 
Play Later 
Lists 
Like 
Liked48:33
Play Later Play Later Lists Like LikedEver thought about stepping into product management—just to try something totally different from engineering? Want expert guidance to grow? Apply for 1-on-1 tech career coaching with me . That’s exactly where Monte found himself. After years in dev and even engineering leadership, he made a move he thought would lead to more ownership and product vision. But once he was in the role… something felt off. In this coaching session, we unpack what actually happens when you chase product titles inside companies—and why the version you’re offered often isn’t what you imagined. Monte thought he was stepping forward. Instead, he realized he was just managing user stories and process artifacts. If you’ve ever wondered, “Is this really what the role is supposed to be?”—you’re not alone. You can also watch this episode on YouTube . Visit me at healthydeveloper.com…
H
Healthy Developer
You ever notice how sometimes the people around you see what’s really going on before you do? That’s what happened with this channel. I tried to go broad, help everyone in tech, chase what the “experts” and the algorithm said people wanted—but you knew better. You told me what made this channel special wasn’t the hype or some generic success formula. It was the real talk. The raw stories. The focus on staying healthy, sane, and actually living your life while you write code in an industry that rarely cares about either. In this episode, I’m owning up to where I lost the plot—and why I’m bringing it all back to what *actually* matters. We’re going deep on why “Healthy Developer” is the right home for this community (and for me), what’s staying, what’s changing, and what you can expect from here on out. If you’re here to argue or troll, you won’t like this one. But if you’re tired of the tech grind, and you want real strategies for staying grounded and growing as a developer *without* burning out, you’re in the right place. Thanks for holding me to a higher standard—and for helping me find my way back. Let’s build something better, together. You can also watch this episode on YouTube . Visit me at thrivingtechnologist.com…
H
Healthy Developer
In this real coaching session, I talk with John, a developer-turned-manager, who’s navigating the messy middle of leadership. He’s caught between two teams, two continents, and shifting expectations. Sound familiar? We dig into: The difference between managing people and leading culture Why growth-stage teams break without intentional leadership How to lead without authority (especially when others outrank you) The startup → scale-up trap most companies fall into Ways to influence product direction by fixing culture first This is one of the most honest, practical coaching conversations I’ve had on team culture, dev leadership, and transitioning into management. If you're a senior dev or manager trying to scale impact without losing your soul, you’ll get a ton out of this. You can also watch this episode on YouTube . Visit me at thrivingtechnologist.com…
H
Healthy Developer
Ever feel like tech work has turned you into a robot? Just crank out code, stay in your lane, and don’t ask too many questions? Yeah—same. → Find Out If You're Ready To Go Solo in Tech In this real, unfiltered coaching session, I work with Charlie—a creative technologist who’s been wrestling with how to bring *real* artistry back into his work. After running his own 3D animation business and helping other creatives thrive, he’s now stuck between paying the bills with soul-draining contracts... and figuring out how to build a career where he actually gets to make things that matter. We talk about time management, identity, and how hard it is to self-promote when your creativity feels personal. If you’re a developer or designer who’s ever wondered “How do I get back to making stuff I care about?”, this one’s for you. You can also watch this episode on YouTube . Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 Helping a Dev Rediscover His Entrepreneurial Drive 1:06:31
1:06:31 Play Later Play Later Lists Like Liked1:06:31
Play Later Play Later Lists Like LikedToday, I’m sharing a real conversation I had with Matt—an experienced developer who’s been wrestling with where to take his career next. If you’ve ever felt like you’re stuck doing the same thing over and over, or like your potential is being wasted, this episode is for you. → Find Out If You're Ready To Go Solo in Tech Matt’s been on a journey to figure out what he truly wants, beyond just writing code. We dug into some deep topics—like whether he’s truly competitive, how to test his business idea, and finding clarity between stability and ambition. It’s a powerful session where Matt starts to rediscover his entrepreneurial drive and get real about what he wants to build. I think you’ll find a lot of takeaways you can apply to your own journey. You can also watch this episode on YouTube . Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 5 Signs You Shoulda Quit the Tech Grind YEARS Ago 17:44
17:44 Play Later Play Later Lists Like Liked17:44
Play Later Play Later Lists Like LikedGet your tech career unstuck here: https://healthydeveloper.com/coaching Ever feel like you're living in the tech job twilight zone? One minute you’re daydreaming about quitting, selling everything, and disappearing into the mountains. The next? You’re convincing yourself, “Eh… it’s not that bad.” Yeah—I’ve been there. For years. I spent nearly a decade gaslighting myself out of leaving corporate life, ignoring burnout, and pretending I was just “in a rough patch.” But after coaching over 120 devs since going solo, I’ve learned this: most of us know we’re done. We’re just too skilled at lying to ourselves. So in this episode, I’m calling it out: Here are 5 signs you shoulda quit years ago—and 5 actions you can take right now to start your escape plan. No fluff. No "just follow your passion" nonsense. Just hard-earned lessons from someone who's been in your shoes—and walked out the other side. We’ll discuss: Why being too good at your job is actually a trap How apathy about tech might be a deeper signal The sneaky way your side projects are trying to tell you something What your unused vacation days really mean And why your coworkers’ loyalty is starting to feel cult-like Chapter markers / timelinks: (0:00) Introduction (1:41) 1. 5 Signs You Should Have Quit Working in Tech Years Ago (1:53) 1.1 You're Too Good At Your Job (2:49) 1.2 You Stopped Caring About the Tech Stack (3:50) 1.3 Your Side Gigs are Your Real Job (5:01) 1.4 You're Hoarding Vacation Days (6:10) 1.5 You Get Annoyed By Other People's Loyalty (8:00) 2. 5 Immediate Actions to Start Breaking Free (8:25) 2.1 Quit Caring About Your Next Performance Review (9:45) 2.2 Sell Some Old Tech Gear (10:45) 2.3 Reclaim an Hour From Your Job (12:17) 2.4 Pitch a Fake Client Proposal (13:58) 2.5 Burn One Bridge of Responsibility (16:30) Tech Solopreneur Readiness Scorecard…
H
Healthy Developer
1 Helping a Dev Manager Focus on Action—Not Fear 1:15:56
1:15:56 Play Later Play Later Lists Like Liked1:15:56
Play Later Play Later Lists Like LikedEver feel stuck in analysis paralysis, trying to figure out if you should go solo or stick with a stable tech job? In this live coaching session, I help Ben—a seasoned engineering manager and Agile coach—shift his focus away from fear and toward action. → Find Out If You're Ready To Go Solo in Tech We break down: Why even a stable tech job can still feel uncertain How fear of the unknown keeps devs stuck—and how to move past it The real way to test your next move without risking everything How to balance financial security with the drive for independence If you’re a developer, tech lead, or engineering manager who’s thinking about making a big career move but unsure where to start, this conversation is for you. You can also watch this episode on YouTube . Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 Loving Money Makes You a Perfect Programmer Slave 18:32
18:32 Play Later Play Later Lists Like Liked18:32
Play Later Play Later Lists Like LikedMost people get into software development for the money—and hey, I get it. The tech industry can be insanely lucrative. But if your end goal is to break free from the corporate grind and work for yourself, could a high income actually be holding you back? Grow Faster in Your Tech Career: https://thrivingtechnologist.com/coaching Join the Thriving Tech Community: https://thrivingtechnologist.com/community In this episode, I dive into my own career stories—when money was a good motivator, and when it turned me into a "perfect programmer slave." I’ve seen it all—from promotions I didn’t even care about to chasing startup dollars and, finally, finding freedom through coaching and serving others. You can also watch this episode on YouTube . Chapter markers / timelinks: (0:00) Introduction (1:27) 1. How Loving Money Prevents Self-Employment (1:39) 1.1 Story: Early Raises (4:19) 1.2 Story: Starting Up to Cash Out (7:11) 1.3 Story: Starting Up to Serve (10:43) 2. 3 Ways to Find Freedom from High Income Dependence (11:18) 2.1 Reduce Monthly Expenses (13:10) 2.2 Focus Effort on Your Highest Value (14:44) 2.3 Quit Your Corporate Gig (15:10) Take the DevPathfinder Career Assessment (16:54) Join our Discord Community Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 Programmer Employees Don't Have a Career Anymore 11:15
11:15 Play Later Play Later Lists Like Liked11:15
Play Later Play Later Lists Like LikedThe days of stable employment in tech jobs as a career is over. I don't say this to scare you, but so you take some action to be less dependent on companies that couldn't care less about you! Grow Faster in Your Tech Career: https://thrivingtechnologist.com/coaching Join the Thriving Tech Community: https://thrivingtechnologist.com/community In this episode, I share some of the latest developments in my time coaching over 120 software professionals. One of the biggest things I've learned, is that practically everyone is miserable. This year I have some exciting new announcements to make though - I'll be helping you escape the corporate grind! You CAN have a career in tech, but you have to step up, take more responsibility, and give up the delusion that corporate employment is a long-term strategy anymore. Those days sadly, are long behind us. You can also watch this episode on YouTube . Chapter markers / timelinks: (0:00) Introduction (2:14) What I Told My Son about The Tech Industry (3:24) The Low-Value Career Death Trap (4:08) Employment is Now Maximum Risk (5:14) AI Has Made it Easier to Start a Business (6:45) Willful Ignorance Has Consequences (8:15) Temporary Employment is Honorable 9:16 Career Stability Is Possible Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 Stop Solving Problems for Your Development Team! 37:17
37:17 Play Later Play Later Lists Like Liked37:17
Play Later Play Later Lists Like LikedAre you helping or holding your team back? In this episode, I explore why sharing technical answers with your development team might not be the best way to help them grow. Instead, learn how to use resourceful questions to empower your team members to think critically, solve problems independently, and build long-term confidence. This coaching strategy is rooted in co-active coaching principles and can transform how you mentor junior developers or lead your software team. Grow Faster in Your Tech Career: https://thrivingtechnologist.com/coaching Join the Thriving Tech Community: https://thrivingtechnologist.com/community As a tech lead, manager, or mentor, it’s natural to want to provide answers when your team is stuck. But constantly solving problems for them can create dependency and stifle their growth. By shifting from a directive approach to a coaching mindset, you’ll help your team develop essential skills, foster ownership, and reduce your own workload in the long run. In this video, I’ll share practical examples and techniques you can start using today to guide your team effectively without always giving them the solution. If you’ve ever felt the pressure to be the “go-to expert” on your team, this episode will challenge that belief and show you a better way to lead. Coaching your team to solve their own problems not only benefits them but also makes you a stronger leader. Watch now to learn how to implement these strategies and take your leadership to the next level! You can also watch this episode on YouTube . Chapter markers / timelinks: (0:00) Introduction (1:14) 1 Bringing Out The Best in Your Software Team (1:31) 1.1 Solving Problems For People Holds Them Back (2:48) 1.2 Let People Struggle (4:36) 1.3 The Role of Resourceful Questions (11:30) 1.3.1 Examples of Resourceful Questions (11:35) 1.3.1.1 "Have You Broken This Up Into Smaller Pieces?" (12:33) 1.3.1.2 "Have You Really Considered ALL Your Options?" (14:07) 1.3.1.3 "What if I Wasn't Available?" (15:09) 1.4 Shifting From Expert to Coach (22:36) 1.5 The Long-Term Benefits of Coaching (26:16) 2 How To Start Leading Like a Coach (26:48) 2.1 Start Small (28:50) 2.2 You Don't Need Formal Training (29:50) 2.3 Where to Start Coaching (30:02) 2.3.1 Code Reviews (31:08) 2.3.2 Design Reviews (32:46) 2.3.3 Project Planning (33:30) 2.3.4 Debugging Sessions (34:30) Get Help with Leadership Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 Can Employees REALLY Set Boundaries With Managers? 13:47
13:47 Play Later Play Later Lists Like Liked13:47
Play Later Play Later Lists Like LikedEver had a manager who expects you to be Superman? No matter what you do, they keep asking for "more, more, more." Earlier in my tech career, I thought it was my manager's fault. But when I learned the art of setting healthy boundaries at work, I realized that the power to push back was in my hands. Grow Faster in Your Tech Career: https://thrivingtechnologist.com/coaching Join the Thriving Tech Community: https://thrivingtechnologist.com/community In this episode, I’ll share insights gained from working with over 20 software companies as a developer, architect, and management consultant on setting effective boundaries with managers. Getting this right can bring immense peace and prevent burnout. Without clear boundaries, it's easy to feel overwhelmed by unreasonable expectations—and the result is often exhaustion or even job burnout. Managers often respect employees who assert boundaries more than those who don’t. It may seem counterintuitive, but consider it: would you respect someone who allows themselves to be treated like a doormat? You can also watch this episode on YouTube . Chapter markers / timelinks: (0:00) Introduction (1:20) Setting Boundaries with Your Manager (1:40) 1 Agree on Responsibilities for Your Role (3:13) 2 Determine Unacceptable Expectations (4:20) 3 Assign Consequences (6:17) 4 Communicate Your Boundaries (8:55) 5 Have a Backup Plan Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 Does Corporate Culture KILL Creativity in Tech? 17:44
17:44 Play Later Play Later Lists Like Liked17:44
Play Later Play Later Lists Like LikedAre you a tech professional who feels your creativity is being stifled by corporate culture? In this episode, I explore the impact of corporate culture on creativity in the tech industry. I share my personal journey—from leaving behind my passion for music to embracing programming as a new creative outlet, only to find that corporate constraints in tech began to suppress my creative spirit. Grow Faster in Your Tech Career: https://thrivingtechnologist.com/coaching Join the Thriving Tech Community: https://thrivingtechnologist.com/community I'll delve into how creativity in tech is often threatened by corporate environments that favor predictability over innovation. Discover why expressing creativity is vital for personal fulfillment and how the suppression of creativity can drain your energy. We'll discuss strategies to navigate tech workplace culture and reclaim your creative energy for your personal pursuits. Join the conversation about creativity suppression in tech. Have you experienced the stifling effects of corporate culture on your creativity? Share your stories and insights in the comments below. Let's work together to keep the flame of innovation alive in tech companies - and our personal lives! You can also watch this episode on YouTube . Chapter markers / timelinks: (0:00) Introduction (1:11) A Story of Creative Loss and Redemption (3:24) 1 The Unmatched Value of Creativity (3:50) 1.1 Fueling Personal Fulfillment (4:36) 1.2 Enhancing Problem-Solving Skills (5:34) 1.3 Driving Innovation & Growth (6:53) 2 Navigating Corporate Constraints on Creativity (7:21) 2.1 Preference for Predictability (8:31) 2.2 Creatives Seen as Disruptors (9:37) 2.3 Leadership Suppressing Creativity (11:49) 3 Preserving Your Creative Energy (12:14) 3.1 Respect That Creative Energy is Finite (12:38) 3.2 Avoiding Creative Burnout (14:11) 3.3 Allocating Energy to Personal Pursuits Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 If Your Tech Job is Comfortable, You're in Danger 21:21
21:21 Play Later Play Later Lists Like Liked21:21
Play Later Play Later Lists Like LikedIs your tech job feeling a little too comfortable? You might be unknowingly putting your career at risk. In the fast-paced world of technology, complacency can lead to career stagnation, limiting your earning potential and jeopardizing your job security. Grow Faster in Your Tech Career: https://thrivingtechnologist.com/coaching Join the Thriving Tech Community: https://thrivingtechnologist.com/community In this video, we'll uncover The Hidden Dangers of Comfort in Tech Jobs - How staying in your comfort zone can make you obsolete in a rapidly evolving industry. Signs You're Experiencing Career Stagnation - Recognize the red flags that indicate you're not growing professionally. The Importance of Continuous Skill Development - Why updating your skills is crucial for career advancement and remaining competitive. Strategies to Overcome Complacency - Practical steps to reignite your passion and drive in your tech career. Exploring Self-Employment and Tech Consulting - How becoming self-employed or starting a solo venture can enhance your career growth. Don't let the comfort of today become the regret of tomorrow. It's time to take control and ensure you're not left behind in the ever-changing technology industry. You can also watch this episode on YouTube . Chapter markers / timelinks: (0:00) Introduction (1:29) 1 A Story of Me Getting Trapped (2:59) The Illusion of Security (5:00) 2 Signs Your Tech Job is Too Comfortable (5:26) 2.1 Lack of Learning (6:18) 2.2 Routine Work with Repetition (7:05) 2.3 No Networking (8:44) 2.4 Content with The Status Quo (9:25) 3 The Consequences of Complacency (9:45) 3.1 Career Stagnation (11:31) 3.2 Job Insecurity (12:12) 3.3 Reduced Earning Potential (12:30) 3.4 Missed Opportunities (13:19) 4 Solutions for Growth when You've Become Complacent (14:41) 4.1 Continuous Learning (16:50) 4.2 Skills Diversification (18:29) 4.3 Consider Self-Employment Benefits (19:28) Career Compass Tech Career Coaching Package Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 Think Your Corporate Job Is Secure? Think Again 24:40
24:40 Play Later Play Later Lists Like Liked24:40
Play Later Play Later Lists Like LikedWhat if the real risk isn't leaving your corporate job, but staying in it? If you’re comfortable in your tech job today, layoffs aren’t the only risk you face. The myth of job security is a common cause for staying stuck and growing complacent. 7 years ago my life was turned upside down when I realized for the first time - just how trapped I’d become. I developed chronic insomnia and anxiety, and it eventually emptied my bank account. All because I refused to accept that I’d outgrown working for corporations. I wasn't sure if I wanted to be an entrepreneur or just work solo as a consultant - but I knew I was done with having a boss. In this episode, I’d like to help you get a sober view at what staying in corporate jobs can cost you. Unfortunately, job security is a myth. I hope this content about overcoming fear of self-employment helps you find the courage to explore more empowering ways of work - if you’ve outgrown the corporate tech job grind. Whether you want to become an independent software development consultant or start a SaaS (software as a service) business, tech professionals in IT jobs and at software companies don't have to stay chained to their corporate jobs forever. There is no such thing as a "secure job"! But you'll have to step into the unknown waters of being a solopreneur - if you want to experience self-empowerment. 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:41) 1 The Lie of Corporate Stability (1:55) 1.1 Cognitive Biases (4:40) 1.2 Hidden Risks (6:38) 1.3 Opportunity Costs (9:19) 2 How Self-Employment Can Reduce Risk (9:31) 2.1 Diversify Income Streams (11:34) 2.2 Growth & Adaptability Mindset (16:42) 3 Overcoming Fear of Self-Employment (16:44) 3.1 Challenge Fear of The Unknown (19:31) 3.2 Embrace Risk as Opportunity Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 The Secret to Finding Profitable Software Ideas 13:55
13:55 Play Later Play Later Lists Like Liked13:55
Play Later Play Later Lists Like LikedThinking of quitting the tech industry grind to start a profitable software business yourself? Before you take the plunge, don't make the same mistakes I did! The secret to finding a profitable software idea, is that it must come from your customers. Unless you know a real pain that people who would use your software are experiencing, you can easily fool yourself into thinking it's good enough to build a software product business on. In this episode, I share what I've learned about finding real software product ideas. I use a combination of IBISWorld, ChatGPT, and a book by Dane Maxwell to help my software development coaching clients discover software startup ideas. IBISWorld Businesses https://www.ibisworld.com/industry-statistics/number-of-businesses/ Start from Zero by Dane Maxwell https://www.amazon.com/Start-Zero-Business-Experience-Freedom/dp/1950367185 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:42) Finding a Profitable Software Idea (1:54) 1. Select a Customer Market (2:50) 2. Determine How to Contact Customers (4:37) 3. Ask Customers for Their Biggest Problem (6:05) 4. Ask People Who Responded To Meet (7:03) 5. Ask Them 5 Questions (7:15) Make Sure You're On The Same Page (7:29) How Are You Solving It Today? (8:15) What Happens When You Don't Solve This Problem? (8:50) If You Could Wave a Magic Wand, How Would You Solve It? (9:36) Would You Pay for That Solution? How Much? (10:48) Identify Consistent Profitable Problems Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 Real 10x Programmers Are SLOW To Write Code 15:04
15:04 Play Later Play Later Lists Like Liked15:04
Play Later Play Later Lists Like LikedIf you've ever been jealous of programmers who seem to write code faster than you - take heart. The myth of the "10x programmer" is misunderstood in many software teams and tech companies. What's important to companies is NOT that you're actually 10x faster at writing code. It's that you help the company produce features 10 times faster. Wake up call - you're not the only member of the team! Over my career, I've met software developers who come into companies and write code super fast - but end up slowing the project down. They bossed around the other junior developers and thought they were God's gift to programming. It was a real disaster. Instead, use these 6 techniques I learned as a software consultant. They'll speed up the project, make you popular on your team, get results for your company - and actually make your tech job easier! Besides, what's more important: that you can write code fast, or that you can avoid writing more code in the first place? 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:36) 6 Techniques Used By True 10x Programmers (1:50) 1. Technological Empathy (3:29) 2. Negotiate Streamlined Features (5:06) 3. Cross-Technical Insight (7:59) 4. Reject Ambiguity (9:42) 5. Minimize Architectural Complexity (11:53) 6. Document Innovation Visit me at thrivingtechnologist.com…
H
Healthy Developer
If you've ever been on a software project and you can't get your boss to listen, I've been there. Many of us are technical types, so we often think facts are enough to convince management to support us. In this episode, I share 4 strategies I've used to actually get your boss to listen. These take some patience, but if you want to see real results - they do work. No matter what tech job you work on, you'll eventually run into problems that can only be solved if you can win support from management. If you practice these strategies, they can unlock new opportunities in your career that few other professionals in IT ever get to experience. 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:45) 4 Strategies to Influence Management (1:58) 1. Frame Your Feedback in Terms of Impact (7:44) 2. Build Allies and Gain Support (10:51) 3. Choose Your Battles Wisely (12:43) 4. Present Solutions in Steps Visit me at thrivingtechnologist.com…
H
Healthy Developer
Have you ever felt like your software project was doomed from the start, almost as if it were the plot of a bad movie? Well, if so, you're not alone. I've been through my share of nightmarish projects, but one in particular stands out. It involved shady characters, SWAT teams, and a project that was destined for disaster from the beginning. If you've ever felt like your software project was spiraling out of control, this story might make you feel a little better—or at least a little less alone. 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:40) Part 1: Red Flags (10:44) Part 2: Turning a Blind Eye (17:10) Part 3: S$!t Hits The Fan (24:15) Part 4: The Fallout (30:58) Episode Groove Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 Does LinkedIn Brainwash You Into Hating Your Job? 18:46
18:46 Play Later Play Later Lists Like Liked18:46
Play Later Play Later Lists Like LikedLinkedIn is a great resource for connecting with people, but it can also cause serious mental health challenges - and even lead to burnout. If you're looking for a job or just trying to find customers, there are some features of LinkedIn that can ruin your personal peace and drive your anxiety through the roof. In this episode I share some ways I've helped my tech career coaching clients avoid LinkedIn becoming a problem. Most of these center around avoiding comparing yourself to other people. As Gary Vaynerchuk famously recommends, "produce don't consume". If you follow some of the tips in this episode, you'll be able to responsibly use LinkedIn - and not let it use you! 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:16) 5 Ways to Keep Calm on LinkedIn (1:38) 1. Avoid Accomplishment Signals (4:08) 2. Use, Don't Consume (7:45) 3. Don't Engage Rage Bait (11:02) 4. Don't Attend Unjustified Meetings (14:19) 5. Keep Your Network Relevant Visit me at thrivingtechnologist.com…
H
Healthy Developer
Are you a programmer, or in any individual contributor tech role really? Considering switching into management? Be VERY careful. Most companies will not prepare you for what it takes to really be an effective manager. If you've ever been upset with a manager or felt like they weren't equipped to do their job, it's probably because they were promoted due to their success as an individual contributor - but weren't taught effective management techniques and strategies. In this episode, I'd like to help you avoid being looked at as incompetent by other programmers or anyone in any software development role. You already know that programming and other tech jobs require intentional and ongoing study and improvement. Management is no different! 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:56) 5 Skills To Become a Great Manager (2:06) 1. Holding People Accountable (4:24) 2. Taking Responsibility for Others (8:45) 3. Making Yourself More Available (13:17) 4. Studying and Practicing Management (15:56) 5. Being an Incentives Translator Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 Are You Truly Motivated To Change Your Tech Career? 6:30
6:30 Play Later Play Later Lists Like Liked6:30
Play Later Play Later Lists Like LikedIf your tech career isn't what you want it to be, it could be a mild annoyance - or something urgent. Knowing how ready you are to actually make a change is important before you take any action that could change the course of your life and career. When I started career coaching, I noticed sometimes tech professionals would come to me frustrated about their career but not really willing to change. After a while I began using motivational interviewing. This is a technique I use to help me figure out how ready someone is to really make a change in their tech career. If you're thinking of getting a promotion, switching roles from perhaps programming to something like product management, UX, or data science; or looking to just find a better job - you should assess how urgent the change really is. In this episode I offer 5 stages of readiness for change along with symptoms you can experience at each of them. I hope this helps you know if your tech career is actually in a better place than you thought - or if it truly is time to make a change today! 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:06) 5 Stages of Readiness for Tech Career Change (1:16) 1. Contemplation (1:56) 2. Mild Irritation (2:30) 3. Active Exploration (3:41) 4. Serious Consideration (4:37) 5. Urgency and Desperation Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 "Agile Signaling" is Gaslighting The Tech Industry 22:16
22:16 Play Later Play Later Lists Like Liked22:16
Play Later Play Later Lists Like LikedToday most tech companies engage in agile signaling - without even knowing it. They do nothing to make it easy to adapt to change, but put on a show to pretend they're agile. Many software developers and other professionals in the industry, even those with long careers, have never been on project with a truly agile software development process. And so it's not uncommon to hear software engineers and project managers talk about how much they "hate agile" behind closed doors. A select few understand what being agile really means. It means working together in a way where adapting to change is easy. For those unfortunate people, it can feel like gaslighting to work for these companies. Tech workers all over the industry are expressing more disgust with scrum and agile than ever. And when the SAFe, or "Scaled Agile Framework" arrived - it signaled a final nail in the coffin of many companies ever being able to realize the true benefits of being agile. In this episode I'd like to help you understand two things. First, we we need agile development more than ever today. With the arrival of AI, software projects are getting disrupted faster than ever and need to adapt. And who knows what the future could bring! I'll also help you understand 4 key events in the history of the software industry that caused the definition of the word agile to essentially mean "anything BUT change"! 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:31) 1. Do We Even Need Agile Development? (1:37) 1.1 Inability To Respond To Market Change (3:55) 1.2 Over Budget and Late Projects (5:50) 2. 4 Key Events That Co-Opted Agile (6:16) 2.1 Burn-Down Charts and Velocity Tracking (9:21) 2.2 Jeff Sutherland's Book (12:47) 2.3 Agile Certifications (15:51) 2.4 SAFe (Scaled Agile Framework) (21:12) Episode Groove Visit me at thrivingtechnologist.com…
H
Healthy Developer
Does programming ever get tiring? Are you frustrated by being left out of key decisions by the company? You may begin to wonder if you should become a manager. In this episode I'd like to share 5 important considerations before switching from being a programmer to management. It's common advice that "all programmers must become managers eventually", and I don't agree with this. There are many ways to grow in our career, and management is just one path. However, for some people it may be the perfect next step. I hope this episode helps you know what you're walking into before you take the step to become a manager. 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:13) 5 Signs It's Time to Switch to Management (1:32) 1. You're More Concerned with People than Technology (3:42) 2. You Want More Organizational Insight (5:37) 3. You Hate The Technical Interview Process (9:39) 4. You Want To Work Less Overtime (12:39) 5. You're Tired of Learning New Technology Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 Why Do Programmers Accept Being Stuck in Their Career? 27:37
27:37 Play Later Play Later Lists Like Liked27:37
Play Later Play Later Lists Like LikedMany programmers are stuck in their career today, but they place the blame on everyone else. Yes, there are some difficult things going on in the tech industry. But one of the biggest reasons programmers stop growing, is they don't get help. In this episode, I'd like to share the things I've learned after coaching over 100 software professionals that keep us from getting the help we need. 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 (4:56) 6 Reasons Why Tech Workers Stay Stuck (5:06) 1. Skepticism of Marketing and Sales (8:28) 2. False Sense of Uniqueness (12:43) 3. Knowledge-Inflated Pride (14:45) 4. Fear of Relational Intimacy (17:10) 5. Internet Addiction and Distractions (20:57) 6. Opportunity Cost of Inaction Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 10 Steps to Becoming a Solo Technology Consultant 35:15
35:15 Play Later Play Later Lists Like Liked35:15
Play Later Play Later Lists Like LikedWant to quit working for companies as an employee, make more money, and choose the clients you work with? It might be time to go solo - as a technology consultant. To be successful, you need to be smart about how you start. In this episode, I share the exact steps I took to become a solo technology consultant offering software architecture and a variety of other professional services. Whether you're a programmer, in QA, DevOps, do Product Management, Data Science, or any other software development technology role - a technology consultant is not a contractor. You are actually starting a business, and so you need to think like one! I hope this episode helps you avoid some of the pitfalls that software engineers and other tech professionals can fall into when they try to work for themselves. Learn about Solopreneur Jumpstart, a coaching package to bootstrap your solo consulting business https://thrivingtechnologist.com/services/software-development-coaching/solodev-coaching-package/ 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:55) 10 Steps to Become a Solo Technology Consultant (3:00) 1. Design Your Services (6:38) 2. Discover The Client (8:51) 3. Price Your Services (11:16) 4. Build Client Awareness (13:37) 5. Incorporate (16:33) 6. Acquire Clients (19:01) 7. Negotiate Contracts (23:34) 8. Manage the Engagement (26:16) 9. Keep Financial Records (30:27) 10. Finish Strong and Get a Reference (34:15) Episode Groove Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 Can a Programmer's Mind Become Their Prison? 23:52
23:52 Play Later Play Later Lists Like Liked23:52
Play Later Play Later Lists Like LikedProgrammers have to learn an incredible amount of information to even BEGIN to be effective at their job. So it's only natural that we don't like to find out something we learned - is wrong in a different context. With so much invested, being open to the possibility that there's a better way to do things can be hard. In this episode, I share some mindset limitations that we can fall into in tech job roles. We can feel so strongly about experiences we've had, that they blind us from being open to other equally valid perspectives. Every one of these is a mistake I've made more than once in my career. I hope by being aware of these, you don't end up believing lies. Instead, this information can help you make wiser decisions on your software project - so you don't end up looking like a fool. 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:43) 5 Mindset Limitations Programmers Believe (1:53) 1. Binary Thinking (5:16) 2. Anecdotal Overconfidence (12:12) 3. Absolutist Stances (16:05) 4. Recency Bias (19:03) 5. Vanity Metrics Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 Why Tech Consultants Have Management's Ear (And You Don't) 31:36
31:36 Play Later Play Later Lists Like Liked31:36
Play Later Play Later Lists Like LikedEver seen management bring in a technology consultant, and suddenly they're open to ideas you've been telling them all along? When this first happened to me, I figured technology consultants were probably just better at selling snake oil. But halfway into my career I became a software development technology consultant, and I learned they were masters of one thing I sucked at - communication. Here's the good news: you don't have to become a technology consultant to be a master of communication. It's simply a decision you make to focus on it. In this episode, I share 9 ways you can communicate like a consultant, that will get people to stop and listen to what you have to say with more authority and urgency on your software projects. Whether you're a software engineer, in QA or DevOps, or a product or product manager - we all respond to persuasive and informed communication the same way. I hope this helps you get unstuck in your career in technology, and achieve things you never thought were possible on your software development project! 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 (3:10) 9 Ways to Communicate Like a Consultant (3:17) 1. Be Business-Focused (5:11) 2. Presentation Skills (8:20) 3. Adapt To Your Audiences (12:25) 4. Frequent Feedback Loops (15:26) 5. Negotiation Skills (18:02) 6. Healthy Resistance to Rushing (20:34) 7. Project Documentation (23:38) 8. Client Relationship Management (26:34) 9. Continuous Learning (30:20) Episode Groove Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 Why are Programmers Terrified of Self-Employment? 16:08
16:08 Play Later Play Later Lists Like Liked16:08
Play Later Play Later Lists Like LikedMost programmers have considered self-employment at one time or another, but fear grips them when they think about how to even get started. When I began working for myself 7 years ago, I had no idea how to transition to being self-employed, but I knew I couldn't stand working for corporations any longer. In this episode, I'll share the most common fears any programmer faces when they think about what it might be like to work for themselves. And for each of these fears, I'll offer some perspective on how I did it, and you can too. With the uncertainty of the software industry today (and really any tech job), relying on corporations for employment over our entire career may not be wise in the long run. I hope this episode offers some hope that self-employment isn't impossible as a programmer. But there is no escaping that you'll need to face your fears head on - and overcome 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:38) 1. 3 Reasons Programmers Fear Self-Employment (1:44) 1.1 Financial Uncertainty (2:46) 1.2 Lack of Business Skills (3:54) 1.3 Comfort With Current Tech Job (5:46) 2. How To Overcome Self-Employment Fears (5:54) 2.1 Financial Planning and Savings (9:02) 2.2 Gradual Skill Development (11:53) 2.3 Start Small and Build Confidence Visit me at thrivingtechnologist.com…
H
Healthy Developer
It's finally sinking in. Your software project is FAKE agile. Is there anything you can really do about it? The sad reality is that more companies have fake agile software development processes than those that are authentic. You can fight tooth and nail to try and change the system, or you can accept when there's nothing you can do. Being a truly agile software company is not usually something any individual programmer or manager can change. It has to start from the top. If the company doesn't do agile budgeting and have a culture of adapting to feedback, they are a typical feature factory focused on output over outcomes. In this episode, I offer some practical ways to let to of your frustration and do the best job you can given the circumstances. If you're the type of software engineer, manager, or any other tech job role that considers themselves a change agent - you may be challenged by this one. But this episode isn't for everyone. It's for those of us who are experiencing mental health issues, burnout, and anger over our software project being fake agile. I hope it offers some relief. 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 EPISODES Spot a Fake Agile Team in Under 7 Minutes! https://youtu.be/H6GdK-dChtY An Agile Budget Keeps You From Being a Code Monkey https://youtu.be/pG4wNLopMZA Is Your "Agile" Backlog Really a Waterfall Project? https://youtu.be/OosYzkP-pLk Can User Stories Make Software Projects Late? https://youtu.be/NavlPobhj7A Are Programmers Really To Blame For Bad Estimates? https://youtu.be/m5A1Wg8hYGo Chapter markers / timelinks: (0:00) Introduction (1:30) How to Cope With FAKE Agile Development (3:25) 1. Stop Forcing Change (5:10) 2. Exercise (7:25) 3. Become a Requirements Lawyer (10:33) 4. Charge for Changes (13:12) 5. Protect Your Reputation (15:12) 6. Define Your Own Success (21:54) Episode Groove Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 My Vision of Hope For the Tech Industry's Problems 15:05
15:05 Play Later Play Later Lists Like Liked15:05
Play Later Play Later Lists Like LikedIf you're bothered by the problems in the tech industry, I am too. But while every day we seem to hear more and more negative news about it - we're actually paying attention to the wrong problems. There are many things wrong with the software industry, but very few we can control. And one thing we can control, is how much we understand each other. Programmers complain that managers set unrealistic deadlines. Managers complain that programmers are lazy. And these are just two examples of the many different tech job roles where misunderstanding each other causes us to feel frustrated and hopeless. In this episode, I'm sharing my vision for how we can help each other get out of complaining about the tech industry - and DO something about it. While none of us is empowered to fix every problem out there, we can at least fix what's right in front of us. This episode marks a new chapter for the channel. I'm renaming it to Thriving Technologist! Thriving because we don't just need to be healthy in tech - we need to thrive and succeed. Technologist because we need to help not just software developers thrive, but everyone in the tech industry. Only when we have empathy for each other and stop seeing each other as enemies, can we stop the anger and begin building a better tech industry for us all to work in. So this is an official welcome to all the people who are not programmers over the years to join us in the effort to create a healthier, more sustainable workplace in tech for us all. 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…
H
Healthy Developer
1 Learning Addiction Keeps Programmers in Chains 18:14
18:14 Play Later Play Later Lists Like Liked18:14
Play Later Play Later Lists Like LikedLearning new technologies, frameworks, and processes as a programmer gives you a feeling of accomplishment. But unchecked, learning can become a dangerous addiction that damages your software development career. In this episode, I share how software engineers can cap their earning potential if they fall into common traps when learning is the absolute wrong thing to do. If you want to have a long career in software and get the rewards, recognition, and success you deserve - knowing when to (and not to) learn is essential. 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:22) 1. How Learning Addiction Harms Tech Careers (1:28) 1.1 Procrastination (3:03) 1.2 Sunk Costs (3:57) 1.3 Declining Value (5:41) 1.4 Social Avoidance (7:15) 1.5 Work/Life Imbalance (8:48) 2. How To Know When Learning is a Trap (8:54) 2.1 Self-Delusion Your Project Requires It (10:01) 2.2 Self-Delusion You Need It To Get a New Job (11:20) 2.3 Influencer Hype and Vanity Metrics (13:03) 2.4 Tech Industry Pushes Fear of Missing Out (FOMO) (15:10) 2.5 Current Challenge Looks Easier in New Tech Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 This Is Why Managers Don't Trust Programmers... 28:18
28:18 Play Later Play Later Lists Like Liked28:18
Play Later Play Later Lists Like LikedHave you ever seen another programmer who wasn't as skilled as you get promoted? Did you tell yourself management was making a mistake? Earlier in my career I didn't realize I was doing some things that caused managers to lose confidence in me. I would spend all my time writing code and never think about how I came across to other people. In this episode, I share some harsh truths I've learned about how being a software engineer can cause us to do things we think the company wants - that actually hurt our reputation in the long run. Companies are actually paying you for confidence as a programmer. And this episode is full of practical strategies for making sure you don't fall into traps that stop you from getting recognized for the great code you write as a programmer - before your career is really getting started! 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:19) 1. What Companies Really Want From Programmers (2:12) 2. How To Build Employer Confidence as a Programmer (2:22) 2.1 Minimize Communicating Problems and Doubt (5:42) 2.2 Repeat Management's Desires (7:46) 2.3 Anonymize Blame on Dependencies (10:57) 2.4 Reduce Your Throughput (14:52) 2.5 Elevate Your Coworkers (17:05) 2.6 Over-communicate Status (20:11) 2.7 Highlight Discovered Shortcuts (22:20) 2.8 Document Verbal Decisions (26:58) Episode Groove Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 Only Developers Who Know This Should Post on Social 33:52
33:52 Play Later Play Later Lists Like Liked33:52
Play Later Play Later Lists Like LikedMaking videos, podcasts, or blogs could be just what your career as a programmer needs. But it could also be a complete waste of time. Many programmers become influencers, but there are two very different reasons for doing so. In this episode, I share the difference between being a pure influencer, or posting online for content marketing. Content marketing is helping people solve some problem they have with your content to encourage them to consider doing business with you. If you're considering working for yourself by starting a software product company, becoming a consultant or freelancer, or selling courses on software development or engineering - becoming an influencer through content marketing is the key to making sales and actually having a business. 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:27) 1. The 2 Purposes of Online Content (1:31) 1.1 For Social Status and Influence (3:49) 1.2 Demonstrating Competence (6:09) 2. How Content Marketing Helps Your Career (6:14) 2.1 Getting a Better Job (7:38) 2.2 Sell Products and Services (10:03) 3. 5 Myths of Content Marketing (10:12) 3.1 Your Ideas Must Be Original (12:31) 3.2 You Have To Post Everywhere (13:40) 3.3 You Have To Post All The Time (17:04) 3.4 You Should Post a Variety of Topics (20:40) 3.5 You Must Post in All Mediums (23:51) 4. Building a Business Through Content (24:13) 4.1 Give Away Something Valuable (26:37) 4.2 Have a Contact Form (29:40) 4.3 Get Referrals Through Shares (32:53) Episode Groove Visit me at thrivingtechnologist.com…
H
Healthy Developer
Six years ago I was suddenly struck with chronic insomnia where I couldn't sleep more than 3 hours a night. This lasted for nearly 3 years, and I struggled through sleep studies, behavioral changes, and all the typical tips you read online about overcoming insomnia. Working as a programmer in the tech industry can create a lot of anxiety because we work with our mind. And if your mind is stressed out, add on to that the pressure of personal relationships and finances - and you've got a recipe for horrible sleep problems. What ultimately treated my insomnia and helped me heal was a combination of psychological, behavioral, environmental, and physical changes I made. In this episode I share 25 practical steps you can try if you're personally struggling with getting a good night's sleep. I hope if you've lost hope that healing your insomnia is possible, my story and what I did gives you the courage to give it another try. Learn about the CBT-i app: https://www.ptsd.va.gov/appvid/mobile/cbticoach_app_public.asp 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:15) Negative Effects of Insomnia (2:19) Categories of Insomnia Solutions (2:29) 1. Psychological Sleep Solutions for Insomnia (2:35) 1.1 Wrap Up Your Workday (3:57) 1.2 Keep a Notepad By Your Bed (5:03) 1.3 Schedule Worry Time (7:04) 1.4 Do 1 Thing You're Putting Off (8:41) 1.5 Reduce Social Media Use (9:21) 2. Behavior Sleep Solutions for Insomnia (9:27) 2.1 Set a Realistic Sleep and Wake Time (11:54) 2.2 Don't Look at The Clock (12:58) 2.3 Only Use Your Bed for Sleep or Sex (14:10) 2.4 Stay off Devices for an Hour Before Bed (15:19) 2.5 Quit Drinking or Doing Drugs (16:35) 3. Environmental Sleep Solutions for Insomnia (16:40) 3.1 Keep Your Room Dark and Cold (18:28) 3.2 Use a Fan or White Noise Generator (19:37) 3.3 Use Tungsten Light Bulbs (21:32) 3.4 Use a CPAP Machine or Tape (23:05) 3.5 Side Sleeping with a Tall Pillow (24:20) 4. Physical Sleep Solutions for Insomnia (24:24) 4.1 Don't Eat or Drink After Dinner (25:33) 4.2 Cardio Exercise Every Morning (28:45) 4.3 Reduce or Eliminate Caffeine (31:07) 4.4 Drink Water Throughout the Day (32:29) 4.5 Get Enough Magnesium Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 Can a "DIY Mindset" Keep Programmers From Growing? 14:17
14:17 Play Later Play Later Lists Like Liked14:17
Play Later Play Later Lists Like LikedWe programmers love to "do it ourselves", and this can help us stay productive and keep ourselves busy. But the dark side of this tendency, is that it can make it harder to get help - when we actually need it. In this episode, I share some ways I've learned that software engineers are trained by society, the workforce, and the software industry to resist getting help from others. Then I offer some practical questions you can ask yourself to know if you're in a situation where you should really adopt the DIY mindset - or avoid getting trapped into learning something you don't need 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 You can also watch this episode on YouTube . Chapter markers / timelinks: (0:00) Introduction (1:22) 1 3 Reasons Why Programmers Don't Get Help (1:28) 1.1 Individualized Education (2:02) 1.2 Corporate Reinforcement (2:41) 1.3 Gossip over Substance (4:49) 2 5 Reasons DIY Can Be a Bad Idea (4:57) 2.1 Low Repeatability Activity (6:41) 2.2 Outside Your Core Skill Set (7:41) 2.3 You've Failed 3 Times (9:23) 2.4 You Keep Putting It Off (10:41) 2.5 Easy Access to An Expert (12:33) Episode Groove Visit me at thrivingtechnologist.com…
H
Healthy Developer
Ever try to sell someone on why you're the right person for them to hire in tech? Or maybe you have a software product or offer freelance IT consulting services you need to sell? I'll bet you've run into the situation where the other person you're talking to doesn't seem to "get" why you're the best solution to their tech problems. In this episode, I share what I've learned through digital marketing about how to really connect with the person you're convincing in tech, so they can understand the value you offer - and buy your idea. This can help you escape the corporate grind and work for yourself as an entrepreneur, consultant, coach - or sell courses. But it can also help you with the everyday challenge of convincing software architects, managers, and anyone you work with to support any idea you have. 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 (3:02) Episode Outline (4:25) 1 How Aware Is Your Prospect of The Problem? (5:10) 1.1 Problem Unaware (7:27) 1.2 Problem Aware (9:46) 1.3 Solution Aware (10:43) 1.4 Ready to Buy (13:46) 2 How Well Do You Know Your Prospect? (14:44) 2.1 Basic Demographics (16:12) 2.2 Industry-Specific Demographics (18:21) 2.3 Psychographic Profile (21:29) 3 Are You Selling To The Right Prospect? (21:37) 3.1 Who's The Ultimate Buyer? (23:52) 3.2 What's The Prospect's Budget? (25:47) 3.3 How Urgent Is Solving The Problem? Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 Should You Fight Dirty to Climb The Tech Ladder? 21:07
21:07 Play Later Play Later Lists Like Liked21:07
Play Later Play Later Lists Like LikedOn the first software project of my career, I thought doing a good job was all that mattered to move ahead. And while I was successful, I was manipulated by many other programmers through political games. After that experience, I was tempted many times in my career to fight dirty. And sometimes, I made the wrong decision. In this episode, I share the reasons why we're tempted as coders on software projects to throw ethics to the wind when the temptation for money, power, or prestige are strong. And how falling prey to that temptation may get you ahead in the short term, but it hurts you in the end. I hope you find some encouragement to take the high road when faced with political games on software development teams, and refuse to bend to other people's will who are unethical! 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:04) 1. Why Programmers Are Tempted To Fight Dirty (2:09) 1.1 High Stakes Competition (3:00) 1.2 Visibility and Recognition (3:50) 1.3 Fear of Obsolescence (5:32) 1.4 Cultural and Structural Encouragement (8:22) 1.5 Misguided Notions of Success (9:37) 2. Resisting Corruption in Tech (10:31) 2.1 Long Term Results & Reputation (12:39) 2.2 The Power of Networking (14:54) 2.3 Personal Peace and Satisfaction (17:17) 2.4 The Ripple Effect of Positivity (18:42) 2.5 Faith In Doing The Right Thing (20:10) Episode Groove Visit me at thrivingtechnologist.com…
H
Healthy Developer
After my first decade of coding, I learned so much I thought: "I must be at least somewhat intelligent, right?". But there was something more valuable I lacked - wisdom. Without wisdom, you'll make decisions in your career that look right in the short term - but turn out disastrous over time. Wisdom is the ability to make decisions when the rules don't apply. There's no book you can read, no guide to follow, and no clear cut answer. It's derived from experience, sound judgment, a broad perspective, and considering the ethical implications of a decision. And if you learn to cultivate wisdom, you can achieve the things that really matter in your career - and life. In this episode I share why people in tech careers often mistake intelligence for wisdom. Then I'll help you understand why our industry is so prone to making unwise decisions. I'll go on to help you see the dangerous outcomes of short-term thinking. And finally, I'll share some practical things you can do to become a wiser programmer - and technologist in general. Learn about one-on-one career coaching with me: https://healthydeveloper.com/coaching Chapter markers / timelinks: (0:00) Introduction (1:23) Defining Intelligence and Wisdom (2:14) Stories of Intelligence and Wisdom (5:10) 1. How Tech Jobs Confuse Intelligence and Wisdom (5:20) 1.1 Equating Problem Solving with Broad Insight (6:27) 1.2 Prioritizing Speed over Sustainability (7:51) 1.3 Specializing vs Holistic Understanding (9:44) 2. How Ignoring Wisdom Hurts Us in Tech (9:51) 2.1 Ethical Implications (12:42) 2.2 Short-Term Over Long-Term Thinking (13:45) 3. How To Be a Wiser Technologist (13:52) 3.1 Expand Your Breadth of Knowledge (16:35) 3.2 Get a Mentor (18:30) 3.3 Reflect and Be Mindful (22:02) 3.4 Seek the Counsel of Generalists (25:02) 3.5 Engage with Non-Technical Communities…
H
Healthy Developer
If you want a lasting career in software development, you've got to be wiser than your average coder. There's a lot of advice that promotes short-term thinking around programming, and if you aren't careful you can burn your bridges before you reach the finish line. In this episode, I share what I've learned about why most programmers don't last in their career. There are 8 laws to a lasting career as a programmer. If you follow these laws, you'll not only move ahead much faster than most programmers - you'll be able to develop software in a healthy way! 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:33) 8 Laws to a Lasting Programming Career (1:52) 1. Embrace the Imposter (3:08) 2. Make Technology Stupid Simple (4:27) 3. Buffer and Delay Commitments (7:21) 4. Skip the Leveling Grind (9:29) 5. Pick Your Battles (11:18) 6. Always Be Networking (12:40) 7. Know When You're The Code Monkey (14:27) 8. Get Out While You Can (17:50) Episode Groove Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 Is Your Tech Job Really Bad Enough To Quit? 28:08
28:08 Play Later Play Later Lists Like Liked28:08
Play Later Play Later Lists Like LikedThe familiar question "should I stay or should I go?" is common to programmers, or really anyone in a tech job. But it's tempting to just bail the moment you don't like some aspect of the job, hoping for greener pastures. The flipside of this is when you probably should have left a long time ago but you stick around! Hey, I've been there. It's easy to have fear and blind spots make it hard to know what to do. In this episode I share 7 signs it may be time to quit your toxic tech job and move on to something better. If you only see several of these signs, that's actually pretty normal. But if you're stacking up a bunch of these (or a few are particularly bad) you need to take action! 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:57) 7 Signs it's Time to Quit Your Tech Job (2:42) 1. Personal and Professional Stagnation (3:32) 1.1 Self-Serving Pitching of Opportunities (4:42) 1.2 Career Advancement Opportunities (6:15) 2. Misaligned Goals or Ethics (6:22) 2.1 Unethical Asks by Company (7:19) 2.2 No Passion for Company (8:20) 3. Toxic Work Environment (8:30) 3.1 Poor Decisions by Management (9:47) 3.2 Micromanagement (10:56) 3.3 Lack of Support (11:50) 3.4 Overwork Culture (13:15) 3.5 Undervalued Employees (14:25) 3.6 Rife with Politics (15:56) 4. Work/Life Imbalance (16:04) 4.1 Unsustainable Work Hours (16:59) 4.2 No Flexibility (18:28) 5. Compensation Below Industry Standard (19:08) 5.1 Mismatch betweeen Qualifications and Pay (20:27) 5.2 Lack of Benefits (21:31) 6. Diminished Quality of Work (21:42) 6.1 Lack of Motivation (22:28) 6.2 Overlooked Contributions (23:24) 7. Better Opportunities Elsewhere (23:41) 7.1 Talk to People When Employed! (25:14) 7.2 Failure to Follow Industry Changes (26:32) Episode Groove Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 Is Working in Tech Hurting Your Romantic Partner? 26:18
26:18 Play Later Play Later Lists Like Liked26:18
Play Later Play Later Lists Like LikedYou already know working in tech while staying in a romantic relationship is hard if you spend a lot of time on the computer. But there are other even more dangerous aspects of a tech job that can risk losing your romantic partner if you aren't careful. In this episode, I share lessons I've learned while married for 25 years to the same woman - and working in tech at the same time. It wasn't easy and I almost lost her a few times. But eventually I learned how to both be a successful programmer - and stay married. I hope this episode helps you avoid divorce or breakup if you're trying to balance a healthy relationship with a romantic partner with progression in your tech 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 . Chapter markers / timelinks: (0:00) Introduction (2:15) 1. 5 Ways Tech Sabotages Relationships (2:45) 1.1 Long and Unpredictable Work Hours (6:14) 1.2 Communication Breakdown (7:58) 1.3 Financial Stress and Lifestyle Inflation (11:01) 1.4 Lack of Shared Interests & Experiences (14:55) 2. 3 Ways to Keep a Relationship Healthy Working in Tech (14:13) 2.1 Schedule & Prioritize Quality Time (17:56) 2.2 Open Communication of Stress & Expectations (22:35) 2.3 Establish Boundaries With Work and Home Life Visit me at thrivingtechnologist.com…
H
Healthy Developer
If you've never been an addict, you may be surprised to know many programmers (and other people in tech job roles) struggle with drug use. Nobody working in tech is a stranger to stress and pressure! But sometimes the ways we cope are unhealthy. If you're currently using, I've been honest and transparent with you - I've been there. I was a marijuana addict for 25 years, and often used it with the rationale that it helped me manage the stress of my job. However, I learned the hard way that using drugs to cope with work creates more problems than it solves. In this episode, I'd like to help you understand WHY drug use is so prevalent in the tech industry. I'll also share the consequences to your career that arise from ongoing use of drugs. And finally, I'll offer some healthier ways to cope with the inherent problems that programming and tech related jobs introduce - rather than turning to drugs as a coping mechanism. I hope this helps you have some compassion for your coworkers who may be trapped in addiction, do what you can to improve the conditions we all work in, and if you're currently struggling - get help so you can flourish in your 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 . Chapter markers / timelinks: (0:00) Introduction (1:12) Three Stories of Drug Use in Tech (5:32) 1. Why Do Programmers Use Drugs? (5:36) 1.1 Attempt To Inspire Creativity (7:27) 1.2 High Stress and Pressure (11:09) 1.3 Isolation and Lack of Social Support (13:36) 1.4 Normalizing Culture (14:57) 1.5 Burnout and Mental Disorders (17:01) 2. How Drugs Make Work Harder (17:08) 2.1 Impaired Cognitive Function (19:23) 2.2 Damage Mental and Physical Health (21:50) 2.3 Legal and Ethical Consequences (24:21) 3.1 Supportive Community (26:53) 3.2 Adopt Prayer or Mindfulness (30:23) 3.3 Better Nutrition and Exercise (34:11) Episode Groove Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 How Hard Tech Projects Make You a Stronger Person 30:40
30:40 Play Later Play Later Lists Like Liked30:40
Play Later Play Later Lists Like LikedThe popular thing to do when faced with a toxic software project - is to complain until you get out. But a healthier alternative, is to use it as an opportunity to get stronger in your tech career. In this episode I share some things I learned by reflecting back on my career through the lens of the book of Proverbs from the Christian Bible. It showed me that I actually have more opportunities to grow than I thought when I deal with difficult software projects. I hope that even if you don't believe in the Bible, it maybe causes you to step back and look at your suffering through a different lens. And if you do believe, it encourages you to put your faith to action whether you're a programmer, product manager, QA tester, in DevOps - or really any role on a software project! 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) 5 Ways To Grow From a Toxic Project (3:11) 1. Gain Resilience Through Adversity (7:40) 2. Enhance Problem Solving Skills (12:20) 3. Improve Collaboration Skills (18:39) 4. Grow Empathy and Leadership Skills (22:56) 5. Increase Appreciation for Positive Jobs (26:20) A Story of a Toxic Hire (30:00) Episode Groove Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 Why Do Most Programmers Who Start Companies Fail? 28:11
28:11 Play Later Play Later Lists Like Liked28:11
Play Later Play Later Lists Like LikedIf you're a programmer tired of the corporate grind, and thinking about starting a software company - watch out. I tried this twice and failed, but the third time went much better. Here are some practical tips to avoid pitfalls as a software engineer if you want to start a software company - and be 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 . Chapter markers / timelinks: (0:00) Introduction (1:05) 8 Mistakes Programmers Make Starting Companies (1:19) 1. Picking a Product That's Fun To Build (3:54) 2. Choosing a Viral Business Model (6:26) 3. Overengineering (9:00) 4. Having a Fixed Mindset (12:59) 5. Spend Too Much Time Building The Product (15:14) 6. Poor Financial Management (18:27) 7. Failing To Build Networks of Help (21:18) 8. Low Self-Confidence Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 Do Programmers Actually ENJOY Being Miserable? 32:01
32:01 Play Later Play Later Lists Like Liked32:01
Play Later Play Later Lists Like LikedThe software industry may be messed up, but I need to be straight with you. You're resisting help! If you really want your job and life to get better, and to achieve better things in your software career - the complaining needs to stop. You need to stop resisting the things you already know you should do - and DO them. You can't solve all these problems alone! In this episode, I'm going to share some harsh truths with you about your responsibility for why your career may suck. I don't share these to criticize you, but to help you confront the seriousness of your situation - and show you how you are truly more empowered to change it than you may 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: (4:55) 5 Ways We Stay Miserable (6:34) 1 Tribalism (10:22) 2 Avoiding Responsibility (13:17) 3 Giving In To Fear (18:08) 4 Escapism (21:21) 5 Pride Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 Can You See The Red Flags Of A Toxic Tech Company? 29:35
29:35 Play Later Play Later Lists Like Liked29:35
Play Later Play Later Lists Like LikedIf you're about to get a new tech job, sometimes the red flags are obvious. But what happens when you want the gig anyway? The temptation to take a job when the pay is high, there's prestige, or it's a promotion are strong. In this episode I share some things I've learned about spotting these red flags, and resisting the temptations that come with the allure of tech company offers. I hope they help you take a more healthy job, and not get sucked into working for a company that drains your soul. 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: (1:16) A Story of Deceit (6:32) 1. Red Flags of a Toxic Tech Company (6:52) 1.1 Vague Answers About Work/Life Balance (8:18) 1.2 Long Hours Are a Bade of Honor (10:02) 1.3 Suspiciously High Salary of Title (11:34) 2. Why Do We Ignore Red Flags? (11:40) 2.1 Justifying Stress With Money (13:27) 2.2 "It's a Stepping Stone" (15:54) 2.3 Need to "Prove Our Worth" (18:03) 3. How Can You Overcome The Temptation? (18:12) 3.1 Make a Relational Impact List (20:13) 3.2 Ask Brave Questions (22:51) 3.3 Avoid Companies That Resist Transparency (24:22) 3.4 Listen to Your Gut! (26:20) 3.5 Write a Catastrophic Story (28:31) Episode Groove Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 3 Ways Programmers Escape The Corporate Grind 39:59
39:59 Play Later Play Later Lists Like Liked39:59
Play Later Play Later Lists Like LikedIf you're tired to the deadlines, pressure, and unrealistic expectations - it may be time to take programming for money into your own hands. In this episode, I share 3 ways you can escape the corporate grind and make money in tech yourself. Being a solopreneur isn't easy, but it's very rewarding if you're willing to learn things like digital marketing. I weigh 5 aspects of considering being a solo IT consultant, starting a solo software product company, or selling what you know about technology through online courses in this episode. 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:34) 1. 3 Ways To Escape The Corporate Grind (0:48) 1.1 Solo Consulting / Freelancing (3:23) 1.2 Build a Software Product (5:49) 1.3 Sell Education Online (10:01) 2. 5 Aspects of Each Method of Escape (10:12) 2.1 Effort vs. Income (15:20) 2.2 Marketing Effort (21:42) 2.3 Dependence on Others (27:19) 2.4 Transition Cost (34:53) 2.5 Learning Required Visit me at thrivingtechnologist.com…
H
Healthy Developer
Programming starts out like any other career - then one day you wake up addicted. In this episode, I share big problems with programming's impact on your work/life balance, and offer solutions. As a software developer, it's easy to get caught up in the endless cycle of coding and problem-solving, often at the expense of personal time and well-being. I discuss how this imbalance can affect your life and provide insights on how to manage it effectively. I also share some personal experiences and tips on maintaining a healthy balance between your programming career and your personal life. The video is not just about coding; it's about living a fulfilling life while pursuing your passion for programming. Remember, programming is an exciting and rewarding career, but it's important to balance it with other aspects of your life. Don't forget to like, share, and subscribe for more content on navigating the challenges of a software development career. Your support means a lot! 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: (01:45) 1 Signs Programming Is Taking Over Your Life (02:07) 1.1 Only Digital Free Time (03:42) 1.2 Stimulate and Chill Cycle (06:12) 1.3 No Quality Time with Friends or Family (07:58) 1.4 No Non-Technical Hobbies (10:50) 1.5 Living Paycheck to Paycheck (12:52) 2 Life Changes To Get Time Back from Programming (12:59) 2.1 Divorce Yourself from Software Industry Values (15:52) 2.2 Schedule Social Activity After Work (18:43) 2.3 Get Control Over Your Finances (21:56) 2.4 Explore Other Tech Job Roles (24:50) 2.5 Have a Career Exit Plan (29:10) Episode Groove Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 How To Stop Getting Overwhelmed By Your Tech Job 24:58
24:58 Play Later Play Later Lists Like Liked24:58
Play Later Play Later Lists Like LikedFeeling swamped in your tech job? You're not alone! In this episode, I dive into the heart of what makes our programming world so overwhelming and, more importantly, how you can navigate it with ease. In this episode, I'm not just talking at you; I'm talking with you. We'll explore the common pitfalls that lead to feeling overwhelmed in tech jobs and share practical, actionable strategies to help you manage your workload and stress levels. Whether you're a seasoned programmer or just starting out, this video is packed with insights tailored just for you. Programming can be a rollercoaster of challenges and triumphs, and it's totally normal to feel overwhelmed at times. But don't worry, I've got your back! We'll look at how to prioritize tasks, set realistic goals, and create a work environment that supports your well-being and productivity. Remember, being overwhelmed doesn't mean you're failing – it's a sign that you're pushing your boundaries and growing. So, let's turn that overwhelm into empowerment together! 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: (01:41) How To Stop Being Overwhelmed By Your Tech Job (02:31) 1.1 Relentless Pace of Projects (03:17) 1.2 Pressure To Continuously Learn (04:32) 1.3 Glorification of Hustle Culture (05:47) 2 Signs of Being Overwhelmed (06:01) 2.1 Constant Fatigue / Lack of Motivation (08:36) 2.2 Brain Fog (09:41) 2.3 Feeling Inadequate Despite Achievements (10:36) 2.4 Anger at Requests for Help (12:13) 2.5 "Too Busy" for Social Activities (13:08) 3 How To Reduce Overwhelm (13:21) 3.1 Prioritize Your Tasks (15:38) 3.2 Learn To Say No (17:20) 3.3 Practice Mindfulness or Prayer (19:34) 3.4 Exercise and Get More Sleep (21:51) 3.5 Social Media Fast Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 Don't Believe The AI Hype! Do This Instead... 23:52
23:52 Play Later Play Later Lists Like Liked23:52
Play Later Play Later Lists Like LikedLet's get real about AI and how it impacts programming. There's a lot of propaganda and fear being thrown around related to artificial intelligence (especially in software development and engineering) - so let's cut through the noise together. I made this video for all you software developers, engineers, and programmers out there who want to get a real perspective on AI's role in our field. Whether you're deep into your software career or just starting out, I've got some insights that you'll find valuable. 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 (4:01) 1. Who Stands To Gain From AI Hype? (4:10) 1.1 The Media (5:08) 1.2 Employers (6:04) 1.3 Startups (7:27) 1.4 Tech Training Companies (8:24) 2 A Rational AI Approach for Programmers (8:30) 2.1 Become an AI Generalist (10:00) 2.2 Spot The Sensationalism (11:52) 2.3 You Are The Compiler (14:38) 2.4 Use AI To Diversify Your Skills (18:11) 2.5 Build a Non-Technical Industry Product (20:22) 2.6 Teach Non-Technical Companies AI Visit me at thrivingtechnologist.com…
H
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…
H
Healthy Developer
1 What Software Architects Do That Programmers DON'T 12:51
12:51 Play Later Play Later Lists Like Liked12:51
Play Later Play Later Lists Like LikedHow 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…
H
Healthy Developer
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…
H
Healthy Developer
1 Programming Burnout Is Real - But You CAN Heal 44:56
44:56 Play Later Play Later Lists Like Liked44:56
Play Later Play Later Lists Like LikedBurnout 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…
H
Healthy Developer
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…
H
Healthy Developer
1 Is Tech Lead the WORST Job For Most Programmers? 24:29
24:29 Play Later Play Later Lists Like Liked24:29
Play Later Play Later Lists Like LikedJust 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…
H
Healthy Developer
1 If Code is Self-Documenting, Why Do Comments Exist? 14:23
14:23 Play Later Play Later Lists Like Liked14:23
Play Later Play Later Lists Like LikedAs 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…
H
Healthy Developer
1 The Art of Tech Persuasion: A Programmer’s Guide 14:42
14:42 Play Later Play Later Lists Like Liked14:42
Play Later Play Later Lists Like LikedEver 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…
H
Healthy Developer
1 Is Your "Agile" Backlog REALLY a Waterfall Project? 16:33
16:33 Play Later Play Later Lists Like Liked16:33
Play Later Play Later Lists Like LikedMany 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…
H
Healthy Developer
1 Are Programmers Really To Blame For BAD Estimates? 16:51
16:51 Play Later Play Later Lists Like Liked16:51
Play Later Play Later Lists Like LikedWhen 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…
H
Healthy Developer
1 Why Does Scrum Make Programmers HATE Coding? 16:14
16:14 Play Later Play Later Lists Like Liked16:14
Play Later Play Later Lists Like LikedEvery 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…
H
Healthy Developer
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…
H
Healthy Developer
1 200 Software Developers Told Me What They REALLY Want 15:36
15:36 Play Later Play Later Lists Like Liked15:36
Play Later Play Later Lists Like LikedI 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…
H
Healthy Developer
1 Is There Really Such Thing as a GOOD Programmer? 14:29
14:29 Play Later Play Later Lists Like Liked14:29
Play Later Play Later Lists Like LikedIt'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…
H
Healthy Developer
1 My First Software Project Was a Political Firestorm 29:16
29:16 Play Later Play Later Lists Like Liked29:16
Play Later Play Later Lists Like LikedThe 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…
H
Healthy Developer
1 Why Are Programmers Never HAPPY With Their Job? 15:21
15:21 Play Later Play Later Lists Like Liked15:21
Play Later Play Later Lists Like LikedThere 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…
H
Healthy Developer
1 The Hidden Value of Being a Forgiving Developer 20:55
20:55 Play Later Play Later Lists Like Liked20:55
Play Later Play Later Lists Like LikedGet your tech career unstuck here: https://healthydeveloper.com/coaching Are you looking around on your software project and just waiting to see someone fail? Are you quick to condemn a manager or developer and cast them useless after a single mistake? Today we’re going to talk about how canceling developers and other IT professionals for mistakes can hold you back from the career you want in software. When I first began developing software, I wasn't particularly ambitious. I needed to make a living to support my wife and son, but I came from a background of partying and playing in a band. But after a few short years I had several promotions and raises, and it started to go to my head. With each new success, my pride got bigger. Once software projects started getting complicated, I started looking for people to blame. The scrum master didn't understand agile enough. The operations team wasn't making it easy enough to release changes into production. The other developers weren't following my coding patterns. Yeah, I became an elitist jerk. But as I've told you many times on this channel, I fell hard eventually. A victim of career-long burnout, I lost my job, a lot of money, and sunk into depression. But when I came out of it, I made this channel and started giving software developers and engineers career advice. It also led me to learn how to work better myself - and help you be a healthy software developer. A moment though of reflection for yourself: are you on the way there? Starting to get rewards and recognition for developing software? Is it getting easier to see flaws in developers and other people on your software project, making you quick to judge? Are you canceling the people who can help you for simple mistakes? If we're humble and honest, we've all made mistakes. And I'm sure I'm going to make many more, whether on a software project, coaching you on your career, or on this channel. I'm pretty sure if you're willing to take an honest look at yourself, you know you're going to too. But you've made mistakes in the past and been forgiven. So should you be more forgiving too? Can we really be fair canceling anyone? What would it be like if all our teams were more like this? What if we worked together assuming we'll make mistakes, and not being surprised? What if we spent more time forgiving, learning, and teaching - and less blaming? Imagine the courage we could have to try and do risky things that might be breakthroughs with our products, technologies, and careers? Episode timelinks: (0:00) Introduction (2:35) The Dangers of Leading (4:35) Falling Hard (6:14) Is Success Putting You in Danger? (8:15) Motivation for True Forgiveness (9:20) Leading Means Helping! (11:00) For Future Leaders... (12:52) What Could Teamwork Be Like? (13:48) Why Should You Care? (14:30) A Call To Action!!! (17:40) Next Time... (19:25) Episode Groove…
H
Healthy Developer
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…
H
Healthy Developer
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…
H
Healthy Developer
1 Scott Nimrod on Personal Reputation vs Teamwork 1:25:09
1:25:09 Play Later Play Later Lists Like Liked1:25:09
Play Later Play Later Lists Like LikedScott 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…
H
Healthy Developer
1 Woody Zuill on Mob Programming and Influencing Change 1:08:11
1:08:11 Play Later Play Later Lists Like Liked1:08:11
Play Later Play Later Lists Like LikedWorking 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…
H
Healthy Developer
1 How Agile Teams Grow Toxic! Ep. 4 Commitments 25:04
25:04 Play Later Play Later Lists Like Liked25:04
Play Later Play Later Lists Like LikedDoes 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…
H
Healthy Developer
1 Response to Comments on "Sprint Planning is Bullshit!" 12:35
12:35 Play Later Play Later Lists Like Liked12:35
Play Later Play Later Lists Like LikedOver 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…
H
Healthy Developer
1 3 Embarrassing Software Developer Stories From My Career 13:03
13:03 Play Later Play Later Lists Like Liked13:03
Play Later Play Later Lists Like LikedWith 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…
H
Healthy Developer
1 How Agile Teams Grow Toxic! Ep. 3 Forecasting 18:13
18:13 Play Later Play Later Lists Like Liked18:13
Play Later Play Later Lists Like LikedDeadlines! "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…
H
Healthy Developer
1 How Agile Teams Grow Toxic! Ep. 2 Hiring Talent 25:12
25:12 Play Later Play Later Lists Like Liked25:12
Play Later Play Later Lists Like LikedTo 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…
H
Healthy Developer
1 How Agile Teams Grow Toxic! Ep. 1 Founder Values 14:21
14:21 Play Later Play Later Lists Like Liked14:21
Play Later Play Later Lists Like LikedOne 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…
H
Healthy Developer
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…
H
Healthy Developer
1 Scrum Got 3 People Fired From A Software Project! 11:38
11:38 Play Later Play Later Lists Like Liked11:38
Play Later Play Later Lists Like LikedOver 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…
H
Healthy Developer
1 How To Pause A Software Project To Fix A Problem 8:35
8:35 Play Later Play Later Lists Like Liked8:35
Play Later Play Later Lists Like LikedIt’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…
H
Healthy Developer
1 They Watched Us With Webcams And Rewrote Our Code! 13:40
13:40 Play Later Play Later Lists Like Liked13:40
Play Later Play Later Lists Like LikedOne 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…
H
Healthy Developer
1 Lead Software Developers Better By Letting Go! 11:17
11:17 Play Later Play Later Lists Like Liked11:17
Play Later Play Later Lists Like LikedOver 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…
H
Healthy Developer
1 It’s Hard To Keep A New Team Doing Continuous Delivery 7:56
7:56 Play Later Play Later Lists Like Liked7:56
Play Later Play Later Lists Like LikedSometimes 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…
H
Healthy Developer
1 How To Stop Comparing Your Career To Other Developers 10:48
10:48 Play Later Play Later Lists Like Liked10:48
Play Later Play Later Lists Like LikedAs 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…
H
Healthy Developer
1 John Cutler on Agile Skepticism and Developer Impact 45:27
45:27 Play Later Play Later Lists Like Liked45:27
Play Later Play Later Lists Like LikedJohn 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…
H
Healthy Developer
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…
H
Healthy Developer
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…
H
Healthy Developer
1 Should You Really Measure Progress On A Software Project? 7:56
7:56 Play Later Play Later Lists Like Liked7:56
Play Later Play Later Lists Like LikedThere’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…
H
Healthy Developer
1 We Designed A Software Product That Never Got Built 10:17
10:17 Play Later Play Later Lists Like Liked10:17
Play Later Play Later Lists Like LikedOne 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…
H
Healthy Developer
1 Scrum Is The “Motor” Of Your Project, But Who’s Steering? 8:58
8:58 Play Later Play Later Lists Like Liked8:58
Play Later Play Later Lists Like LikedWhen 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…
H
Healthy Developer
1 Know When To STOP Learning And Just Write The Code! 7:07
7:07 Play Later Play Later Lists Like Liked7:07
Play Later Play Later Lists Like LikedIs 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…
H
Healthy Developer
1 Is It Safe To Make Mistakes On Your Software Project? 18:16
18:16 Play Later Play Later Lists Like Liked18:16
Play Later Play Later Lists Like LikedAt 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…
H
Healthy Developer
1 I Got By On A Software Project With Help From My Friend 7:03
7:03 Play Later Play Later Lists Like Liked7:03
Play Later Play Later Lists Like LikedThere'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…
H
Healthy Developer
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…
H
Healthy Developer
1 A Tale Of Software Development Culture Change - Gone Wrong! 15:29
15:29 Play Later Play Later Lists Like Liked15:29
Play Later Play Later Lists Like LikedLet 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…
H
Healthy Developer
1 Iain Lowe on Estimating, Culture, and Agile Dogma 1:10:43
1:10:43 Play Later Play Later Lists Like Liked1:10:43
Play Later Play Later Lists Like LikedIain 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…
H
Healthy Developer
1 Senior Developers Forget They're Really Consultants 11:04
11:04 Play Later Play Later Lists Like Liked11:04
Play Later Play Later Lists Like LikedI'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…
H
Healthy Developer
1 Scott Nimrod on Consulting and Software Craftsmanship 1:09:32
1:09:32 Play Later Play Later Lists Like Liked1:09:32
Play Later Play Later Lists Like LikedScott 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…
H
Healthy Developer
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…
H
Healthy Developer
1 Why Do Leaders Treat Programmers Like Children? 18:52
18:52 Play Later Play Later Lists Like Liked18:52
Play Later Play Later Lists Like LikedDoes 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…
H
Healthy Developer
1 Healing The Rift Between Programmers And Managers 24:20
24:20 Play Later Play Later Lists Like Liked24:20
Play Later Play Later Lists Like LikedIt’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…
H
Healthy Developer
1 Daily Scrum Meeting: A Status Meeting In Disguise? 14:32
14:32 Play Later Play Later Lists Like Liked14:32
Play Later Play Later Lists Like LikedDoes 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…
H
Healthy Developer
1 What REALLY Gets Software Developers Promoted? 12:48
12:48 Play Later Play Later Lists Like Liked12:48
Play Later Play Later Lists Like LikedIt 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…
H
Healthy Developer
1 A Product Manager Is A Programmer’s Best Friend! 28:44
28:44 Play Later Play Later Lists Like Liked28:44
Play Later Play Later Lists Like LikedSoftware 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…
H
Healthy Developer
1 Are You Refactoring Code For The Right Reasons? 15:31
15:31 Play Later Play Later Lists Like Liked15:31
Play Later Play Later Lists Like LikedIt’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…
H
Healthy Developer
1 Accepting What You Can’t Change On A Software Project 15:27
15:27 Play Later Play Later Lists Like Liked15:27
Play Later Play Later Lists Like LikedHave 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…
H
Healthy Developer
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…
H
Healthy Developer
1 I Can't Stop Thinking About Programming After Work! 8:03
8:03 Play Later Play Later Lists Like Liked8:03
Play Later Play Later Lists Like LikedThere’s something about software development that makes it hard to stop thinking about programming after work. Earlier in my career when I’d be obsessing over programming, I would get home and right after coming in from the car jump into a video game or play some music. But it didn’t last very long. I quickly became a workaholic programmer. When I wasn’t thinking about code, I would sometimes wake up in the middle of the night and start thinking about it them. I even had dreams that I was in a whiteboarding session. Have you found healthy ways to stop thinking about programming when you get home? 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…
H
Healthy Developer
Why does it seem like no matter how strong your argument, some programmers never agree with you ? In software development we often focus on practices like agile development, unit testing, or code reviews. But these are actually driven by underlying principles that guide the practices we select. Some good communicators will be able to say what their principles are. But even then, you’ll come across someone who just will not agree with you no matter how well you understand their principles. This is because there is usually a core limiting belief that lies beneath their stated principles. The only way to find these beliefs out, is to have an authentic relationship with the person. As a software developer, engineer, or consultant we often spend most of our day in front of the computer. So getting to know someone personally can be socially awkward and feel like it’s taking away from our productivity. We can ask “why” questions, as described in the “5 whys” concept popularized by Eric Ries, author of the lean startup, to get to root beliefs. Armed with this information, we can broaden our belief system to understand the other person better, or help them get rid of a limiting belief that may be holding them back! 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…
H
Healthy Developer
1 Impact Mapping: What's Your Software Development Worth? 11:49
11:49 Play Later Play Later Lists Like Liked11:49
Play Later Play Later Lists Like LikedIf you’ve ever been on a software project and wondered: “what’s the impact of the work I’m doing?”, impact mapping will help you immensely. Knowing what your code is worth, or any other assets we create on software projects across any discipline (UX, QA, Infrastructure, Operations etc.) is crucial to both getting the rewards you want, and steering the company in the right direction. In this episode I share how impact mapping can be used to identify a goal from a business model canvas (described in detail in my prior episode, link below) and map it to work team members do. With a better understanding of the impact of your work, you can communicate things like “ why are we doing this? “, “ what is this work going to enable? ” and “ how do we know when we’re successful? “. Impact mapping can be used not just with software development activities like programming and testing, but also with any activities, features, or tasks a team might consider to impact the business. Advertising, partnerships, cost reduction, and other aspects of a business also benefit from having a map of impacts. If your company hasn’t shared this information with you, have a conversation with your product manager or CEO to see if they can provide some insight to your work’s impact. An important point I highlight at the end of the episode, is to not budget only for a single experiment identified through an impact map. Most software development investments fail to fully realize their goals, so budgeting for multiple experiments will help. This way you won’t have to go back to the business for more money after a “failure”, and instead get multiple attempts to reach the goal through trying several things that have an impact. 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…
H
Healthy Developer
1 How A Business Model Canvas Helps Agile Teams 16:36
16:36 Play Later Play Later Lists Like Liked16:36
Play Later Play Later Lists Like LikedIf you’ve ever thought “who came up with these ideas?”, you probably need a business model canvas on your agile development team. Even if you don’t consider yourself able to steer the direction of a software product (you’re a programmer, in UX, operations, QA etc.) it’s critical that sound decisions are made about the business. Without a comprehensive plan forward, ego can easily take over your agile backlog. In this episode I share what a business model canvas is, examples of common software products and how the canvas (also known as a lean canvas) can help you as a software developer or any other discipline on your team. The business model canvas, business canvas, or “lean canvas” has been popularized by Eric Ries , Alex Osterwalder , and Ash Maurya . It divides up the aspects of a business into 9 sections that a software company should experiment with to increase profit. When your team is deciding “what features should we build in our software?” the business model canvas should be the first lens through which decisions are looked at. Any user stories your team adds to their backlog should tie back to these sections of the business model canvas, otherwise they can easily be “gut decisions” with no sound business backing. The canvas can provide your software development team with an array of potential opportunities to explore, other than just “cranking out features”. 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…
H
Healthy Developer
1 Is Your Software Company A Feature Factory Or A Lean Startup? 11:11
11:11 Play Later Play Later Lists Like Liked11:11
Play Later Play Later Lists Like LikedWhy do some software companies build exciting products with the freedom of a lean startup, while others deliver boring products like a feature factory run by control freaks? In this episode I ask this question: “ Does Your Company Feel More Like a Factory, or a College “? Whether you’re using agile methods like scrum, kanban, or any other process – up front design is still alive and well in many companies. To truly build innovative software products that cause your company to profit so you can get the rewards and recognition you want – people must let go. When features are identified has a big impact on success. Many companies focus mostly on the features for their software that they can think of or hear from customers ahead of time. But it’s those features discovered only after you release your product to them using devops and continuous delivery approaches, with an agile budget, that cause you to profit greatly. This is the approach popularized by Eric Ries book “The Lean Startup”. Companies run like a factory try to predict value, while companies run like a college discover value. Companies run like a factory control people, while companies run like a college trust people. Companies run like a factory use burn-down charts to measure progress, while companies run like a college use learning milestones. Companies run like a factory use a project budget, while companies run like a college use a monthly budget. Companies run like factory focus on measuring expenses, while companies run like a college focus on measuring profit. Do you work at a company that feels more like a software factory (or feature factory), or a college? 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…
H
Healthy Developer
1 Leadership Skills for Lean Software Development 10:40
10:40 Play Later Play Later Lists Like Liked10:40
Play Later Play Later Lists Like LikedIt takes special software leadership skills to learn what customers want through lean software development. In this episode, I share 7 key traits that will help you, or someone else you know who’s leading, to build the most profitable software ideas for customers. 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…
H
Healthy Developer
In the first decade of my career, I would get angry at everyone around me and turned to the Internet to vent my frustration. It seemed like managers and other people who didn’t understand software development had caused me to lose hope in my future. In this episode, I share what caused me to lose hope, and many programmers I run across struggle with these symptoms as well. If you’re a programmer who has turned to escapism and joining the chorus of complainers – I implore you to reconsider! 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 (3:00) We're Forced to Cut Corners (4:33) Cognitive Overload (5:17) Low Perception of Value (6:50) High Income Forces Deeper Goals (8:31) Learned Helplessness (10:38) Say No With Grace (12:45) Communicate Uncertainty (15:28) Ask for Help Earlier (16:48) Develop Empathy (18:24) Surround Yourself with Positive Devs Visit me at thrivingtechnologist.com…
H
Healthy Developer
If you want to be a calm programmer, you may want to consider cutting down on caffeine. On a project that’s truly agile, most people need extra patience. Especially if they have high anxiety from using coffee or other stimulants to get through the day. In this episode, I share some things you may want to know if you want a sustainable career in software development. Though you may not be able to completely cut out caffeine, it can wreak havoc on you and your team’s ability to work together well. When work is already difficult, and people are under stress, caffeine only tends to make things worse. I hope these tips for avoiding caffeine withdrawal help you to stay a healthy programmer! 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…
H
Healthy Developer
Have you ever had an idea for something on your software project, but someone else takes the credit? Plagiarism can be extremely frustrating, and it’s typically caused by narcissistic personality types. In this episode, I share why this happens, how to prevent it – and how to cope with it. I also share a personal story of when this has happened to me. This sucks, there’s no way around it. But if you’re creative enough to come up with new software development ideas, you can do it again ! I hope this episode helps you avoid this situation in the future, and have a healthy mindset if you unfortunately do get plagiarized. 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…
H
Healthy Developer
Looking at what decisions others make about their career in software can be a big mistake. Though having a career in software development can be exciting, there is also cause for serious caution. In this episode, I share the 5 biggest lies I have bought myself, and I hope you don’t about your career in software development. With healthy decisions and a realistic mindset, you can advance quicker than others and not get stuck in common traps. 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 (1:40) Technical Skill Determines Your Success (2:40) Harder Work Gets More Done (4:16) Past Success Determines Future Results (6:27) Bigger Companies Have Better Practices (8:56) Promotions Are Proportional Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 An Agile Budget Keeps You From Being A Code Monkey 20:25
20:25 Play Later Play Later Lists Like Liked20:25
Play Later Play Later Lists Like LikedIf you feel like a “code monkey” with pressure to work fast – you need an agile budget. It took me many years, but I finally figured out the reason why. Companies that try to build software like a manufacturing plant budget the wrong way. This creates pressure on workers, and produces boring products that barely keep a software company profitable. At companies that understand this, you’ll be more creative and spend less time trying to estimate. If the leaders at your software company don’t understand this, they may still have a (barely) profitable business, but they’ll be wasting tons of money. In this episode, I share hard learned lessons about the software industry that every company should build their foundation upon. Agile budgeting is a key to healthy software development company culture – 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 . Visit me at thrivingtechnologist.com…
H
Healthy Developer
If you’ve ever had to estimate software development work, you may have engaged in “planning poker”. This method of estimating brings with it some potential benefits. But depending on the culture of your team, it can also cause big problems. In this episode, I hope to avoid you falling into using this common practice if it isn’t right for your team. Planning poker might be just what your team needs – but you need to make the smart choice! 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…
H
Healthy Developer
I gained weight quickly from programming and needed help with weight loss early in my career. I took part in the corporate events that provided unhealthy food because it was “there”… I was accepted easier by my coworkers because I would eat the same fatty and high calorie meals that they chose… And I fell into emotional eating, because the stress of software development was depleting my diet of nutrients. So I started to tell myself “losing weight is vanity – I’m not one of THOSE people “. But in this episode, I share my personal story of weight loss after ballooning up to over 210 pounds. I hope my story helps someone else out there who is struggling with the lifestyle of programmers that can make it hard to stay in shape. Corporate culture won’t always make it easy – but you’re worth it! There is hope for you – losing weight is not impossible, but you’ve got to stand your ground! 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…
H
Healthy Developer
1 Say NO On A Software Project - So They Will Listen! 12:12
12:12 Play Later Play Later Lists Like Liked12:12
Play Later Play Later Lists Like LikedIt's bound to happen that at some point you'll be asked to do some work that you know will have a negative outcome. How you say no on a software project can build resentment if you don't establish clear boundaries - and decline the request with grace. In this episode I share some tips I've found work well for diffusing resistance to your desire to do the work some other way. When you understand the person making the request better, you'll do a better job aligning your message with their needs. You will need to help them overcome the pressure they already feel to meet any commitment they already made to their boss. 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…
H
Healthy Developer
1 What To Do When Your Software Tasks Will Be Late 10:49
10:49 Play Later Play Later Lists Like Liked10:49
Play Later Play Later Lists Like LikedNo matter how experienced you are, sometimes your software tasks will be late. How you handle this often has far reaching implications on your career and your health. In this episode, I share some insights I've had from doing this well - and not so well. Learning to be transparent, reset expectations, and refuse to be strong-armed into releasing low quality work will ensure you have a sustainable software development career. You can also watch this episode on YouTube . Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards…
H
Healthy Developer
1 Democratic Software Architecture - Sharing Technology Decisions 29:34
29:34 Play Later Play Later Lists Like Liked29:34
Play Later Play Later Lists Like LikedDo the teams you work on have an "elite few" that are looked to for making technology decisions? Are there times you wish people would work together more to drive software architecture? In today's episode I share both good, and bad experiences I've had with team structures that effect software architecture. It seems logical at first to only allow people with more experience to make these decisions about tools, processes, and frameworks. But only teams that have an inclusive technical culture bring out the best in people by giving them shared ownership over the process. Included are some tips I've found useful over my career to speed up the rate of adopting new technologies as part of your product's stack - and making it everyone's job. 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…
H
Healthy Developer
1 Software Project Burnout: Is It Them Or You? 24:15
24:15 Play Later Play Later Lists Like Liked24:15
Play Later Play Later Lists Like LikedIt's easy to blame your company when a software project seems to require so many hours, that you suffer from software project burnout. And there certainly are companies that haven't figured out how to set deadlines in a way that expectations can be reset if things go wrong. But you can also burn yourself out, if you don't set healthy boundaries. I've actually worked overtime at the BEGINNING of a project! This would happen when I wanted to try and "make sure" we wouldn't be late. Or sometimes when I was just so excited to learn new technologies I DIDN'T WANT TO STOP. In this episode, I encourage you to do whatever you can to prevent working any sort of overtime. Even if you love working with software and technology, you need to consider the precedent you set. If employers know you will sacrifice your well being to meet deadlines, it's too tempting for them to abuse again! 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…
H
Healthy Developer
1 Can Imposter Syndrome Help Software Developers Grow? 23:04
23:04 Play Later Play Later Lists Like Liked23:04
Play Later Play Later Lists Like LikedImposter syndrome is something software teams often talk negatively about, but it can actually be a sign of growth. The feeling that you don't know what others think you do can cause a lot of stress and anxiety. We all put up with this feeling when we're new, because others expect that we don't know what we're doing. But after a few years in software development, we can forget that feeling. When asked to do work that requires us to grow, it's critical that we get comfortable with it. There are a few reasons why software professionals tend to be especially susceptible to this. One is that other egotistical, narcissistic developers can make fun of us. But this says more about THEM than us. Another is that we worry that we'll be "found out" by management for needing to learn something. But emotionally intelligent managers and leaders see through the false wall of lies that some developers can put up when they try to appear infallible. In this episode, I encourage you to look at imposter syndrome as a healthy sign that you need to grow. If you can be honest, detach from what others think, and learn to reset expectations with others - you don't need a reason to worry that you're an imposter. 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…
H
Healthy Developer
1 Your Software Project Is Failing - Now What? 35:43
35:43 Play Later Play Later Lists Like Liked35:43
Play Later Play Later Lists Like LikedWe all hate that sinking feeling when we realize we're on a failing software project. What you do then will have a bigger impact on your health than your reputation. Earlier in my career, I would try to avoid blame as my number one priority. As I got more experienced, I saw the folly of this and realized I needed to follow through with my best work. How we deal with tough times says more to others than how we behave when things are going smoothly. In this episode I share the story of two clients I worked with that had failing projects. Sadly - I've been on more failed projects than successful ones, but I felt these two might help you think about how you cope with this situation. Remember just because a project fails - it doesn't mean YOU are a failure. It's OK to accept circumstances, accept your limitations - and do what you can. Your family, relationships, and health will thank you for 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…
H
Healthy Developer
1 Can You Be Agile - Even When Your Company Isn't? 17:26
17:26 Play Later Play Later Lists Like Liked17:26
Play Later Play Later Lists Like LikedStop getting angry that you're company isn't more AGILE! It's human nature that causes digital transformations to fail. I spent most of my career trying to help companies be agile. But people in positions of power are often driven by greed and the illusion of control, and they won't support efforts that require them to change. I had a nasty bout of insomnia in April of 2017 where I had to resign from my job. I spent the 8 months that followed healing, researching, and trying to understand where I went wrong. I'm no "guru" and I certainly don't know everything about this industry - but after working with 30+ companies I've seen some patterns. This year I want to help you avoid the pain I went through by having a healthier, more sustainable career in software development! 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…
H
Healthy Developer
1 5 Signs Your Software Business Is Led By Amateurs! 15:20
15:20 Play Later Play Later Lists Like Liked15:20
Play Later Play Later Lists Like LikedDo you ever get that sinking feeling that the people running your software business don’t really know what they’re doing? Here’s 5 signs your software business is led by amateurs! It can be practically a sport to make fun of leadership for not understanding modern software development and its implications. That’s not the purpose of this post. If you’re working at a company where several of these signs are present, you have three options. Put up with it, try to change it for the better, or move on. Here’s 5 signs your software business leadership needs help: Failure To Invest In Better Tools and Services Too Much Power In The Hands Of A Few Customers They Can’t Say “No” To Any Customer They Have A High Customer Acquisition Cost They Commit To Deadlines Without Understanding The True Cost If the place you’re working at has these problems, do you have the courage to move from complaining to having some serious conversations? Even if you consider yourself just a cog in a huge machine, you can help your leaders make better decisions that keep the company profitable! 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…
H
Healthy Developer
1 How To Confront Difficult Software Developers About Their Behavior 13:31
13:31 Play Later Play Later Lists Like Liked13:31
Play Later Play Later Lists Like LikedHave you ever been on a software project with someone who does great work but is difficult to work with? Here’s some strategies for confronting difficult software developers about their behavior. Before you even think about having this conversation, go into the conversation detached from the outcome you want. If you go into it thinking “If I don’t get this person’s behavior then I’ll be upset” – the other person will pick up on it. Here’s 6 tips for this conversation: Keep The Conversation Private Ensure They Are Well Rested Reinforce Their Value Listen For Struggles Future-Pace The Benefits Discuss Their Reservations Don’t give the person an ultimatum! They will make the change but resent you for it! Don’t attach rewards to the change. They will expect rewards for future good behavior! 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: "Sonic Drifting" by Ron Gelinas “All The Beauty (original ambient version)” by Jani R “Ambient Theme No. 1” – Steven O’Brien Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 Needing To Be Understood Makes Software Professionals Dislike You 8:41
8:41 Play Later Play Later Lists Like Liked8:41
Play Later Play Later Lists Like LikedDoes it seem like others are turned off by you before you’re even able to fully explain yourself? Today I’d like to share 4 behaviors that stem out of our fear of being misunderstood. These can cause other software professionals to dislike and not want to work with you! Demanding Re-Explanation A parent will sometimes ask a child “OK, tell me what I just said” to make sure they understand. If you do this to an adult on your project, it sends the signal that you don’t think of them as very intelligent. It also comes across as condescending. Instead, make sure the other person understands the essence of what you’re saying. If they know enough to take action, move on. Nitpicking It’s tempting when we’re insecure in some way about our skills to take apart what others say and demand it to be phrased how you would. This comes across as needy, and though you might think it demonstrates your mastery of the knowledge, it turns people off. As with the above point, when the other person chooses to use different words than you, but they are basically saying the same thing, let it go – they get it. Over-communicating In our desire to make sure we’re understood, we can sometimes verbally vomit our ideas onto a person and overwhelm them. It takes a lot of energy to have technical conversations, so plan wisely and only communicate the minimum information needed to get the other person to take the actions needed. Abusing Apologies In our desire to help other people feel comfortable with us, we can sometimes abuse apologies. Saying “sorry” for a mistake you made, and owing up to it, is a good idea. But if others are upset with you about something you didn’t do or had no control over it, never apologize. If you do, it sets the precedent they can use you as a punching bag. 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: "Free Ambient Loop" by Sweet Wave Audio "Sonic Drifting" by Ron Gelinas "All The Beauty (original ambient version)" by Jani R Visit me at thrivingtechnologist.com…
H
Healthy Developer
Does it frustrate you when you see other software professionals get recognition or opportunities you want? Are you stuck in a software project situation where it feels like you’re unable to grow? Let me share some information that will help you advance, but in a healthy way. I’ll list 4 tips at the end. Growth and Perks are Abundant Early On When you first start working in software, you’ll have rewards that will keep you satisfied for the first 2-5 years: Lots to Learn (Everything is NEW!) Casual Environment Good Benefits After time spent on spent on projects that aren’t letting you grow, you may hit some barriers: Continued growth may not be important to your employer The path to advance may appear to be “blocked” by other ambitious professionals The reality is that the way to grow is to contribute more . You’ll always progress faster in your software development career when you serve others with something for which you have become particularly skilled. Why Software Professionals Struggle to Grow You may be familiar with Tony Robbins’ 6 human needs. He breaks human behavior down into things that drive us and are necessary for our survival. Certainty Variety (or Uncertainty) Significance Love and Connection (or Team/Community belonging) Growth (Personal skills) Contribution As software developers, we have particular dynamics to the job that cause us to get into trouble with these human needs: Problem #1: We seek certainty, but then get bored. Problem #2: We try to be significant (get promoted, recognized), and sacrifice connection with others. Problem #3: We focus on growing our skills, and sacrifice contribution (helping others). 4 Tips for Healthy Software Career Growth How can you balance these human needs better, specifically in your software career? Tip #1: Set Deadlines for Career Changes Don’t wait until you get frustrated. Plan for when to make career decisions if situations don’t improve. Tip #2: Respect Resistance to Change from Others There will be times you want to grow and others don’t. You want to get support from other people on your projects in a way that’s healthy to your relationship. Visit the post about How To Win Trust For Your Software Ideas for some tips. Tip #3: Contribute to Other People’s Career Growth When you help others get recognized, they will return the favor. You also get an opportunity to learn from others when you let them lead you in doing new work when you want to grow. Tip #4: Allow Others to Be “The Expert” When you let others teach you, instead of just learning from the internet, you strengthen your relationship. This is because people appreciate when you show that you value their opinion enough to defer to them for their expertise. It also helps you learn faster from their experience than scouring StackOverflow and Google . Being able to become a “newbie” again is an invaluable skill! 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: Tony Robbins TED Talk (He Discusses The Human Needs) Tony Robbins Website Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 Overcome Attachment: Discover the Mindset for Lean Software Development 16:46
16:46 Play Later Play Later Lists Like Liked16:46
Play Later Play Later Lists Like LikedAre you trying to get other people to use agile or lean software development methods, but they can’t seem to break out of the mindset they’re stuck in? Today I’d like to offer some strategies to overcome attachment. Building What Customers Want Takes Failure And Learning Traditional management at many companies focus on predictability. They want to know how long things will take, and how much they will cost. Unfortunately if your software company wants to be innovative, you may already know that you can’t measure performance this way. If you want to deliver truly disruptive and valuable ideas to your customers, you need to experiment and make small investments to see how customers receive them. Establishing the Mindset for Failure and Learning I talk often about how important experiments are to the success of your software company, and how you can sell and introduce the changes needed to work this way to leadership and other stakeholders. Assume for a moment you’ve already convinced people of the benefits of lean software development methods that let your company experiment (DevOps, Continuous Delivery, Lean Startup techniques etc.). Yes, people now understand the mechanics of these approaches. But it can be frustrating at first to help others have the courage to take risks and actually experiment. This is because experimenting and then learning from the results, often requires failure. The Uncertainty of Innovation Can Cause Anxiety One of the technology capabilities I have said in other articles is crucial to a company sustainably releasing valuable software, is Continuous Delivery. This lets your team release your software to customers as frequently as multiple times per day. If you’re going to let the customer take a larger role in deciding what’s in your product, and release it multiple times per day — you’ll have an increased set of feedback. Also subject matter experts like Product Managers will find out their ideas aren’t as valuable as they’d hoped when trying new things. These two changes alone introduce uncertainty that needs to be handled with care. Without addressing this, your team will start blaming each other and going back to what they’re comfortable with when their first few experiments don’t produce the results they anticipated. Overcoming Attachment to Enable Learning If you celebrate Christmas or your Birthday, you’ve probably experienced being attached to a gift or outcome you wanted as a child. You and your team need to overcome these feelings of attachment at your company to use lean and agile methods for developing software. Without detaching from outcomes, people will feel threatened when things change. We Must Be Comfortable With Uncertainty to Take Risks The more comfortable you can be with trying things and not being able to guarantee that the outcome is something that you want, the more you can take risks. This is exactly the mindset needed to be more innovative with software development. Strategies for Practicing Detachment Since you know people need to be more comfortable with uncertainty, and they need to be less attached to outcomes — what are some strategies you can use to cope with this? Thinking About the Possibility of Other Outcomes Most people in corporate America don’t want to do this. Typical work structures are all about certainty and planning for outcomes we expect. Instead, thinking about the possibility that what you’ve planned might not work out ahead of time primes you for a healthy mindset for taking risk. When you’re working with a team to experiment, remind them at every opportunity that everyone is looking forward to seeing the data to help them steer the product in the right direction . If the data behind a release shows that a change wasn’t positive, that is not a failure. It must be clear that there will be no reprimanding for theories the team held about what would be valuable, as testing those theories will inherently prove when our ideas aren’t good. This is the nature of the scientific method! Beware of Catastrophizing Once you begin to allow yourself to entertain the possibility of uncertain outcomes, it’s tempting to think of the worst case scenario. This is known as catastrophizing, and creates anxiety by focusing your thoughts on negative situations that haven’t even happened yet! When I’ve caught myself catastrophizing, I often realize I’m tensing up and experiencing the same emotions as I would if the event happened — but it hasn’t. Spending significant time thinking about the worst possible outcome will cripple your team with fear, and cause them to lose the courage needed to present their best ideas to your customers. Yes, there is a time for risk management — but innovation is not that time. Overcoming Resentment to Past Failures If you hold on to negative feelings about what may have happened in the past, you won’t have the open mind necessary to try new things. Examples might be working with a person who made a mistake before, a business partner who didn’t hold up their end of the deal, or a software development task that was more complicated than first thought. Resentment is another form of attachment. You should consider practicing forgiveness and using whatever healing tools work for you or your team to let go of any resentment. These could be simple things like giving someone a personal apology if you played a part in the situation. Or something that lets you face the situation and let your feelings with it rest such as meditation. Whatever physical, emotional, or spiritual activity you can find that works to help you or others involved emotionally detach from the experience, use it. Let the past go so your team can try new things with a clean slate! Challenging Limiting Beliefs If someone told you something about yourself as a child, or perhaps a co-worker made a statement about your skills — you may be walking around carrying an inaccurate picture of yourself. You should challenge thoughts held about what is really true with respect to the limitations you or your team may perceive about their capabilities. I once worked with a Fortune 500 client who only released their product at night when no customers were using it. They were convinced it was impossible to release it during the day even though the technology needed to do so was common. Until I challenged this belief, and did not back down until I heard a logical answer for why it couldn’t be done — no one had considered it a possibility. Once everyone moved past this limitation in their thinking, they were easily on board and supportive of working with me to plan for the change. Separating Our Identity From Outcomes In most companies if someone makes a “bad” decision, they are held accountable. What this can do though is cause you to place your self-worth in your decisions and their outcomes. To have the courage to innovate, you need to separate these two. People on your teams should strive to treat each other kindly especially at the times when they make mistakes. But when they slip up and get upset at you or someone else for a decision that they didn’t like, it’s important to not take it personally. You can’t control how the other person will react — but you can control your reaction to their being upset. Practicing Delayed Gratification Your company may need to build and release five small versions of an idea to your customer before you hit the ideal solution, when delivering a product in a lean fashion. Because of this, the management team may be lacking in the necessary patience at first to see things unfold with the product this way. Delayed gratification is simply waiting longer to get something you want. This might sound like a silly thing to recommend, but you’d be surprised how many people I come across in leadership positions who are still very attached to immediacy. If you have people like this in key positions at your company, this may be the reason why you’re having a difficult time getting support for the changes you want made. Practice this yourself, and with your team, to relax your feelings of urgency so you have the patience to try several iterations of an idea before settling. Permitting Others to be Frustrated with Uncertainty It’s natural that when trying something new, such as to not be as attached to outcomes, you and others will make mistakes. It’s crucial that everyone be willing to forgive each other when unpredictable negative outcomes occur. Without this safety net, there can be no loyalty, transparency, or ability to take risks. These are the attributes of relationships at your company that can make or break the long term health of the software development culture. 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…
H
Healthy Developer
Do you need to get people to agree and come to consensus so you can grow on your software project, or in your career? Today I’d like to share a few resources, and some simple concepts to consider, when influencing others to make a decision. When I started out in my career, I was a good software developer and could write code and work with many complicated pieces of technology. But I didn’t become good at influencing people until I began consulting a decade later. The Circles of Influence Stephen Covey’s famous book The 7 Habits of Highly Effective People , introduces many powerful concepts for better work. I’d like to mention his concept of circles of influence, which is important for thinking about how to build consensus. The first circle is the circle of control, and typically only includes yourself. If you have children, or subordinates, you may consider them within this circle. In most cases however, there is little you can actually control. The second circle is the circle of influence, and is comprised usually of people on your software team who you already have good relationships with. These are people who will take your advice seriously, and expect you to influence them. The last circle is the circle of concern, and includes people that we have no direct control over OR influence with. Influencing these people usually takes indirect influence through another person. Who Can I Influence Already? It makes sense, especially within the context of Stephen Covey’s book and recommendations himself, that we focus on those we can influence first. If we already have great relationships, those should be the first people we bring over to our side with a decision. Identifying Stakeholders of Your Circle of Influence Because it often takes getting agreement from people outside our circle of influence, we next need to identify who these people are. We can typically influence them indirectly through the relationships we already have. If not, we can look to someone else we know, that knows this person already, to open a door to a conversation. You May Need to Influence “Up the Ladder” Many software companies can grow into a structure with multiple levels of people. Even when using agile development methods, communication across people continues to be a challenge. In addition to building consensus across our circle of influence at our level, we may need to get agreement UP the “ladder” of people in the company so we can reach consensus. Beware of Team Dysfunctions While attempting to influence others, it’s common that due to past failures or trust issues, you may run into politics. The book by Patrick Lencioni, The 5 Dysfunctions of a Team , is a great resource to help you win back the support of difficult people and get everyone talking honestly again. 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 7 Habits Of Highly Effective People (Amazon) The 5 Dynsfunctions Of A Team (Amazon) Visit me at thrivingtechnologist.com…
H
Healthy Developer
Are you developing software under pressure like a “feature factory”, but there never seems to be any economic benefit to the changes? Today I’d like to share some strategies to begin shutting this unhealthy work approach down. The term “feature factory” was coined by John Cutler , a Senior Product Manager who's worked for several high profile companies. He wrote an article in the Hackernoon publication on Medium that introduced the concept to the masses. When you read his article, you may, like me, find yourself nodding your head “YES!” to all of it. Anyone who has worked to produce software on a team that is a feature factory will immediately recognize many of the symptoms. What is a Feature Factory? I’d encourage you to read all of John’s articles for more details, but when you really boil it down a feature factory is a team or company that doesn’t know how to measure the business impact of their changes. Set a Measurable Business Impact Goal for EVERY Change When we’re in school many of us learn the scientific method. At a high level – you have a theory, you decide how to measure it, you design an experiment, and you record the results. Often our theories are proven wrong. Unfortunately, when it comes to developing software many of us assume we can’t be wrong and do very little to handle that very real possibility. One of the first things that is necessary to shut down a feature factory, is to only make changes that can be measured as being successful or not in reaching an outcome. Move Further Towards Cross-Functional Teamwork When the people who work together to produce software are in separate departments, it often leads to people deferring design decisions to a UX, Product Management, or other design person. A cross-functional team actually strengthens the ability to deliver “the right thing” and NOT be a feature factory, because everyone can contribute to design ideas because they are dedicated to the success of ONE product. Celebrate Outcomes Instead of Releases When we start releasing software several times a day using things like DevOps and Continuous Delivery, we often will not hit a positive business outcome with each release. Because of the chance of failure, we should celebrate as a team when we reach a business outcome – not every time we release. John calls this “success theater”. Cultivate a Culture Safe for Failure and Learning When we plan a project that takes a long time to deliver, during that period there are assumptions about the value of what’s being built. There are no ramifications or learning until the end, and on some teams if the product doesn’t deliver on it’s expectations people are FIRED! To allow teams to be innovative and discover what they truly want, you must release small changes with the expectation that these may be “wrong”. This requires making it safe for Product Managers and others to take risks so they can learn. Focus on Value NOT Efficiency / Utilization This one is pretty self explanatory. If a team is constantly pushed to be as efficient as possible, they won’t have the relaxed and creative mindset necessary to make changes that contradict our initial assumptions! Release Smaller Changes, More Often To enable failures (learning) to have a smaller impact and cause less waste when it comes to budgeting – designing changes (experiments) that can run as FAST as possible and give us feedback EARLY is crucial. 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: John Cutler on Medium Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 5 Ways Dishonesty HURTS Your Software Development Career! 14:00
14:00 Play Later Play Later Lists Like Liked14:00
Play Later Play Later Lists Like LikedDo you find it hard to be honest with others about some aspect of developing software? Or maybe you find others are withholding truths, and you wonder why? Today I'd like to share some ways I have been dishonest earlier in my career, and I now see are common in our industry. Not Admitting Being Unfamiliar With Something In short time, we can gain a lot of knowledge about technology and software development processes. If we're not careful, this leads to a "big head" or inflated ego, and we can feel embarrassed if we haven't heard about "the new hotness". If we're honest with others when we don't know something, they trust us more to be transparent, and they know they can share things they are excited about without us shutting them down in an attempt to be seen as the expert. Saying "Yes" To Work You Don't Understand It is often that on software projects we are asked to estimate work based on the information another has captured for us. If we don't fully take the time to understand it, or have a self-inflated sense of our level of skill, it doesn't take much to agree to work when we shouldn't. I learned to say "No" more strongly and honestly about 5 years ago, and it has helped me on numerous occasions. When I didn't do this, I would often put myself under extra pressure, and have to reset expectations with the other party who is now upset that I can't deliver what they expected. Not Admitting We've Overlooked A Process Step Software development is inherently complex and often requires many moving parts to be changed in a very specific sequence to accomplish work. As humans, we will inevitably make mistakes. Under pressure, I have failed to be honest with others that I simply forgot a step in my desire to be seen as the expert. I have become MUCH better about being honest about this now, but it is very common in more junior technologists. When we take responsibility for forgetting something, we build trust with others who know we will hold ourselves accountable for our actions. Making Generalizations About Others In our desire to be seen as the expert, we can sometimes have just a few interactions with another person and then paint them as incompetent or lacking in skill to others. This thinly-veiled attempt to make ourselves appear smarter than we are casts doubt in all but the most unsophisticated of people. If the person you made a generalization about meets the person you said this to, they will find out that you are quick to judge and make inaccurate statements on a whim. Just don't do this! Not Being Honest About Your Level Of Contribution We work hard to produce quality deliverables and value for our team and customers on software projects. And few things feel better than a customer or someone else at the company saying "great job!" But I have not always been as forthcoming about the work others did to support me in successes, and since getting better at this my ability to motivate others and build trust has gone up tremendously. When you check yourself when receiving a complement and remember to include others who were part of the success, you build a positive emotional connection between you and them, and deepen the trust and loyalty necessary to keep a strong team together. 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…
H
Healthy Developer
1 The Secret of Scrum Nobody Wants To Talk About! 7:17
7:17 Play Later Play Later Lists Like Liked7:17
Play Later Play Later Lists Like LikedToo many companies and agile coaches keep the secret of scrum from people! When agile methods of software development were first brought on the scene, they led to abuse. Managers “cherry picked” the practices that gave them more control, but software products didn’t actually get any better! In fact, when you ask most programmers or other software professionals Scrum seems to add MORE pressure and problems. In this episode, I share the secret of Scrum. If your company doesn’t know this secret, you’re wasting your time because the word “agile” means NOTHING! If you don’t understand why scrum doesn’t work, I hope this episode offers some insight. Using a sprint in scrum can cause more problems than it’s worth – without the right mindset to learn from failure. 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…
H
Healthy Developer
1 Is Your Software Development Leader a Narcissist? 14:26
14:26 Play Later Play Later Lists Like Liked14:26
Play Later Play Later Lists Like LikedAre you on a project with a software leader who’s a narcissist, and criticizes everything you do? Did they treat you like a “rockstar” developer at first, but now it seems like you can never please them? Working under a narcissist can be one of the most frustrating experiences in your software development career. In this episode, I share some key traits and behaviors to look for in identifying if you’re working under one. Though people can exhibit several of these traits and NOT be a narcissist, if you see a pattern of several of these behaviors – BEWARE. I hope this information helps you identify whether you’re being abused emotionally – and cope until you’re able to get out. 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…
H
Healthy Developer
1 How To Find The Best Software Project For Your Personality 20:29
20:29 Play Later Play Later Lists Like Liked20:29
Play Later Play Later Lists Like LikedEver get the feeling the software project you’re on clashes with your personality? Does the way people work together seem very different than you? Have you had a great experience on one project, only to start enough and feel miserable? If this has ever happened to you, I hope today’s episode helps you avoid this. Depending on the stage of a software product’s life cycle, you may or may not be the right fit for a team. This has nothing to do with the programming technology stack, operations procedures, or software development process. It has more to do with your goals and preferences at this single moment in your career. I explain how the early, growth, and sunset stages of a typical software product’s profit life cycle impact your happiness. Armed with this information, you can make the best decision in your software development career and hopefully find the perfect software project. 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…
H
Healthy Developer
I hear a common complaint that programming has gotten harder over the years. The more years I spent in software development, I fell into getting frustrated and blaming other people, or the technology. But I realized that I was a big part of the problem – though it was hard to admit. In this episode, I share some things I didn’t realize at first that I was doing to make my job harder than it needed to be. 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…
H
Healthy Developer
1 What Happens When Software Products Reach End Of Life 17:47
17:47 Play Later Play Later Lists Like Liked17:47
Play Later Play Later Lists Like LikedDo you have a feeling that the software product you’re working on is reaching its end of life? Every software product goes through a sunset stage as part of its life cycle. This is a natural progression of your software business, but it needs to be handled carefully. In this episode, I share some considerations your development team can apply to navigate this stage better. If you want to ensure that your software development career keeps moving forward, you need to understand this stage of the life cycle. 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…
H
Healthy Developer
Have you seen the signs that your software company is profiting and may have reached market fit? The way teams work together needs to change when a software product reaches this critical point in its life cycle. That doesn’t mean innovation stops, but a focus on moving towards partnering and stability of technology becomes increased. In this episode, I share some insights I’ve had about how software teams can go about navigating this difficult phase in the life cycle of a software product. 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…
H
Healthy Developer
Are you concerned that your software company isn’t setup for growth? In working with over 30 companies, I’ve come across many that don’t understand the software business life cycle. This episode offers some essential information you can use to understand how your company is being managed. The foundation I provide here can help you determine where in the life cycle of your software products the team you might be working on is at. This will help you make better decisions about technology and software processes – and I’ll expand on it in future episodes. 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…
H
Healthy Developer
Why do software companies try to innovate under a culture of fear? Does the software company you work at frustrate people with a focus on cost savings over GROWTH? In this episode, I share some critical insights to how many companies strangle innovation by managing to fear! Armed with this information, you can stop feeling like a cog in a wheel – and help the culture at your software company improve. If you’ve had agile coaches, DevOps experts, and other “gurus” try to help your company and it still feels like a pressure cooker – this might be why! 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…
H
Healthy Developer
1 Programmer Flow State: “In The Zone” Coding 17:07
17:07 Play Later Play Later Lists Like Liked17:07
Play Later Play Later Lists Like LikedHave you solved programming problems easier when “in the zone” or “flow state”? If you’ve experienced this, once achieved it’s hard to work any other way. In this episode, I want to share some strategies you can use to avoid getting interrupted. These will also help you get into the flow state more often so you can enjoy productive and creative sessions of work regularly. If you follow the tips in this episode, you can help others understand why getting into a flow state is more important than letting others interrupt you at will while programming. It will take setting expectations and creating healthy boundaries for yourself, but can result in breakthroughs in efficiency and your enjoyment of software development. Avoiding interruptions can make one of the biggest differences to your satisfaction over your tech career, whether you’re a software developer or a consultant. 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…
H
Healthy Developer
1 How To Earn Respect On A New Software Project 19:15
19:15 Play Later Play Later Lists Like Liked19:15
Play Later Play Later Lists Like LikedAre you joining a new company, team, or project? Do you want to make sure others respect you so you can use the technologies you want – and get your skills used? Early in my career I thought the best way to do this was to impress others with my technical acumen. But I learned quickly that this only causes frustration and delayed me being accepted. In this episode, I share stories and tips that will help you approach a new team with a positive attitude. You’ll overcome walls people can put up and instead have others welcome your suggestions for improving their software project. 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…
H
Healthy Developer
In this episode, I want to ask you a question that might make you defensive: “ Are you a perfectionist programmer? “. I can tell you, after many years of being a software developer, I’ve gotten much better at this. But one of the things I want to help you with in this video is to maybe think a little bit about how you work with others – and maybe make better decisions about what kind of expectations you have from software developers, technologists, and other people on your team so that you don’t get into a situation where you turn people off and you can’t really get their best work and cooperation because you might expect them to work exactly how you do . 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…
H
Healthy Developer
1 “New Framework Disease” (NFD) in Software Development 21:49
21:49 Play Later Play Later Lists Like Liked21:49
Play Later Play Later Lists Like LikedTechnology addiction hurts your software development career if materialism makes you chase shiny objects. When I was a child, I used to like looking through the magazines my father got with all kinds of gadgets in them. As an adult, I often got caught up in obtaining the latest cars, guitars, or other material possessions. And though you may have a handle on materialism in your personal life - it can become prevalent in a software development career. We suffer from technology addiction when we get bored from repetitiveness - this is pretty obvious. But we also suffer from envy - and this is common because many companies don't keep their software developers growing. We can also put on "rose colored glasses" and deceive ourselves into thinking a new framework, API, or other technology will solve our problems. Failing to master a language or technology puts you at a serious disadvantage in your tech career. It's highly important that you develop the ability to match technology to the business. The only way this will happen, is if you both master your current tech stack - and develop an appreciation for what is unique in the business of your current software project. Ultimately, you need to be able to deliver results. Hiring practices in the industry make this an ongoing problem, but you can avoid some of the snares by thinking about the insights I share in this video. 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…
H
Healthy Developer
1 What Is DevOps REALLY About? (Hint: NOT CI/CD) 15:29
15:29 Play Later Play Later Lists Like Liked15:29
Play Later Play Later Lists Like LikedThere's plenty of "fake news" from the software industry, so beware of the DevOps lie. There's a lot of confusion - just follow the money to see why. In this video I help you discover the real answer to "what is DevOps?", and why it may not be working for you. Though automated deployment technologies, cloud infrastructure, and other "fun" tools are exciting to talk about... ...DevOps is really about getting people to work together. I hope this episode helps you understand the core reason why DevOps came to be, and how it's a subset of Continuous Delivery. Though both of these terms ultimately seek to allow your company to release quicker (and more often) - I've seen them fail when gone about the wrong way. You can help your company achieve the promises of DevOps by following the tips in this episode. If you can help others answer the question "what is DevOps?" correctly - you can help your company achieve the cross-functional teamwork 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: "Continuous Delivery" (Amazon) "The Phoneix Project" (Amazon) Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 Pull Your Software Project Out Of A Death Spiral! 14:37
14:37 Play Later Play Later Lists Like Liked14:37
Play Later Play Later Lists Like LikedBeing on a software project death spiral can be extremely stressful. It usually happens when your company is doing FAKE Agile software development. People feel despair, and it looks like there's no end in sight? In this episode, I share some practical tips to help you correct this situation. Though it's never easy to recover from a death spiral, don't give up when there's hope! 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…
H
Healthy Developer
1 Programming Estimation – Estimate Software Tasks With Caution 13:07
13:07 Play Later Play Later Lists Like Liked13:07
Play Later Play Later Lists Like LikedWhen someone comes to you for an estimate of a software task, do you feel uneasy? Programming estimation is a dangerous activity that should be approached with caution! But people make estimating software tasks more stressful than needed. In this episode, I share some tips that will help you have better success rates when estimating software. Though you may not be able to get out of estimating altogether ( #noestimates ), you can minimize the damage. 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…
H
Healthy Developer
Would you like to know a little more about who I am, and how my successes and setbacks shaped me into someone who is so passionate about doing less at one time, and embracing uncertainty as part of a lean software development mindset? Today I’d like to share part 3 of my software development journey with you. Agile Theater: Alive And Well What my consulting experience had shown me so far, was that many companies still struggle to do agile development. They use some of the technologies and processes, but they have a difficult time transforming the minds of leadership and key players to support true agility. First Startup: Social Network / Time Tracking For Home Schoolers I got the idea for and began building a social network for home schoolers about 6 years ago. The product was built in ruby on rails for speed to market, and being a Father of 3 home schooled children myself, my wife and I knew some of what we thought others would want. Unfortunately, I fell into the classic “Subject Matter Expert” trap! I had a “knowing / doing gap” where I could help OTHERS do lean software development, but when it came to MY ideas, I was just as stubborn! In the end I stopped working on the product as I had built too many things that were not useful to my customer, and market analysis had me wanting to pursue a different market. Becoming (Unwillingly) A Firefighter Around this time my day job in consulting began sending me in to help fix issues at projects with our clients that were in trouble. I got good at this, but it began to burn me out as I started seeing the same quality issues from both our consultancy and the client. The root problem was that the way we engaged with our clients did not embrace agility, and so when things changed or we learned we’d failed in some way, it was costly and slow to adapt. Resistance To The Shift Towards Lean I began to put together a set of content and team that would have the skills at my consultancy to start delivering in a more lean fashion, but the leadership did not yet have the courage to support me even after numerous presentations, discussions, and wins. By the time they began to invest, it was too late – our competition had a several year lead on us. Second Startup: Public Health Data Analysis A friend of mine whom I’d worked with for many years brought an idea to me for a product and was gracious enough to ask me to be involved. There were a number of problems as we began building the company though. First, we both had day jobs and children, and the personal investment was too high to be sustainable for our initial offering. Second, we weren’t clear on our lines of responsibility and so our relationship was taxed. Third, the technology landscape around the “big data” tools we were using were too immature, and there was too much rework we needed to do to deliver the minimum viable product (MVP). Lastly, we failed to deliver small enough ideas before getting feedback, and fell again into the “Subject Matter Expert” trap by overbuilding. A Burning Desire To Be Lean I finally read The Lean Startup by Eric Ries and it opened my eyes to some of the things I had been doing wrong. As I began trying to apply these techniques with clients, I came up against confusion created by vendors in the industry who focus on technology that is “lean” or “agile” but don’t help companies truly adopt the lean mindset. Battling this became the current focus of my career. Using Small Batches To Improve Product Management I wanted to help the people driving the direction of the product to learn whether they failed or not with less investment, and faster, so they wouldn’t make the same mistakes I did. To do this however requires creating the psychological safety necessary for failure and learning. And to get support for transforming the culture to support this safety, consulting skills are necessary. Supporting Your Lean Transformation Eventually, I started a membership program to help mentor software professionals to get the support for consulting and lean skills necessary to help them transform their company’s culture, or use lean techniques for their own startup ideas. I am focused on helping people use the scientific method, as described in the Lean startup; relationship skills and personal development to become a better communicator and persuader; and Continuous Delivery technologies such as the cloud and automation technologies – all in an effort to be more 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 . Related resources: The Lean Startup (Amazon) Visit me at thrivingtechnologist.com…
H
Healthy Developer
Would you like to know a little more about who I am, and how my successes and setbacks shaped me into someone who is so passionate about doing less at one time, and embracing uncertainty as part of a lean software development mindset? Today I’d like to share part 2 of my software development journey with you. Letting Go Of “My Baby” After my first project that was both a product I designed and an opportunity to lead, I was given the opportunity to start a new one. It was difficult to let go of the success I’d had, and hard work I’d done, of this first project so early in my career. Release Deadline Sabotage! Soon the head of the company mandated that all products across the company release on the same day every 6 months. He had no idea what this took, but at the end of the day my team’s project was the only one ready. For political reasons, it was sabotaged by changing the name the last week of the deadline! Following The Leader To New Opportunities After our project was sabotaged, my boss was unfortunately fired and took the fall, and he moved on to a new company where I followed shortly thereafter. This new company was in the pharmaceutical space and needed the kind of help my old team at the prior company could provide, so many of us switched over. Pioneering Agile We built a simple web portal that let us track our sprints and other artifacts related to agile. This was before tools like JIRA, Pivotal Tracker, or Team Foundation Server were available. It was crude, but we learned a lot and through our mistakes and successes became very early proponents of Scrum. Family Conflicts Of Interest Unfortunately there was a miscommunication between my boss and his, and my boss took the fall AGAIN due to company politics wrapped up in family ownership. I was extremely frustrated at this point after seeing my boss, who I considered one of the best leaders I’d worked with, continuing to be sideswiped by politics. My First Architecture Consulting Experience I followed my boss again to his next company, and got a chance to provide architecture consulting services. We helped them ship a late product, and created a prototype of a new one in ruby on rails over that year. Moving To Austin, Texas Eventually my Wife and I wanted a change, so we moved to Austin, Texas. The lifestyle and career options were more in line with what we wanted at the time, and we’re still here today as of 2017. Moving Into Consulting Shortly after arriving in Austin I was contacted about a consulting opportunity. Though it was a little less than I wanted compensation wise, I was excited about the chance to learn a different way of providing IT services and took the offer. Getting An Ego Check-Up I frustrated several clients in the first 2 years I was a consultant, and had a reality check. During my performance review I was criticized (rightfully so) for my inability to talk and relate well with clients. Setting The Intention To Improve My Soft Skills After the deflating performance review, I emboldened myself to learn what I needed to “get” this consulting thing. I came across the book Flawless Consulting by Peter Block after my wife purchased it to help her with Nutritional Health Coaching. Learning To Be A Trusted Advisor The first time I applied the info in Flawless Consulting was a game changer. I could win the trust and advisor status with a client almost immediately through these strategies! Discovering Continuous Delivery While working for a large international grocer based in Austin, I read the book on Continuous Delivery by Jez Humble . This had a huge impact on me and caused me to focus my career almost solely on mastering it. Teaching Clients About Continuous Delivery After creating a framework in Windows PowerShell that helped me implement Continuous Delivery at clients, I began to be frustrated that though we helped them release multiple times per day, their planning and budgeting process still didn’t allow them to BENEFIT from this new capability. Discovering Lean Startup Product Management This led me to learn more about Eric Ries , and eventually read his famous book The Lean Startup . I’ll talk in Part 3 about how I discovered how important this information was through 2 startups I failed to find market fit for. 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: Flawless Consulting (Amazon) Continuous Delivery Amazon) The Lean Startup (Amazon) Visit me at thrivingtechnologist.com…
H
Healthy Developer
Would you like to know a little more about who I am, and how my successes and setbacks shaped me into someone who is so passionate about doing less at one time, and embracing uncertainty as part of a lean software development mindset? Today I’d like to share part 1 of my software development journey with you. Lead-up To My First Development Position Though I’d learned some BASIC programming on “old school” Apple computers in middle school, when I attended college to become a “Microcomputer Specialist” *cringe*, I didn’t know exactly what I wanted to do in technology. One of my first teachers had me do some web development side work in college, and soon my Mother met someone at her church that would give me my first job. I came into the organization with no idea of what to expect but excited to do front end testing of software components using Visual Basic at the time. This was my first professional IT experience. Finding My First Mentors I explicitly sought out older, disgruntled software professionals at my company and asked for them to teach me. It gave them something to be excited about (teaching others), and I learned tons! It’s easy to be a skeptic today with all the information previously hidden from the public that’s come out in the past decade or so online. Though we’ve all become more distrustful of the government, corporations, and the news – we should be careful not to let opportunities to learn from other individuals pass us by. One of the biggest mistakes I’ve made in my career is trying to “shortcut” learning by asking mentors to only describe things I “don’t know”. Often the most revolutionary insights I learned from others were about what I already considered myself an “expert” on. Envisioning And Prototyping A New Product A little over a year into my first position, my wife was pregnant with my second son who would go to bed at 7 PM. I was around 21 at the time, so I didn’t feel right going out and partying while she was at home. So I would stay home and read books about the latest new technologies. Eventually I created a prototype of a new product that simplified 5 existing products we had acquired from other companies to simplify the user experience. My boss showed it to the CEO and within a short time I was the technical lead (Application Architect) over a team of 12 people. Inventing an XML Message Protocol For Manufacturing At the time, web applications were written about but hardly anyone was doing them. SOAP and REST were not out yet, but I recognized that the application needed to use a messaging protocol to talk to applications and manufacturing devices. XML was popular at the time, so I invented and patented a messaging protocol allowing this to happen. Getting Executive Sponsorship Somehow my boss showed a prototype of what I was working on in my spare time to the VP (who would eventually become the CEO). He recognized it as “the most strategically important project in our portfolio” and asked us to pick 12 people from anywhere across the company to build a project team. On the surface, it was an amazing opportunity – new technology, a new product, a new team, full sponsorship. What could possibly go wrong? 🙃 Recognizing My Limited Understanding Of Development Process At the time, there was no agile manifesto, and many companies did “waterfall” but didn’t call it that. I realized quickly that I was unprepared for all of the process nuances related to successfully leading the team. I was good at producing artifacts, but I was horrible at estimating being both new, and working on new technology. Luckily, the company was aware of the need to relax predictability to innovate and take risks so they could grow. Recognizing My Lack of Relationship Management Skills I was leading many people who didn’t know me very well and were 10-20 years older than me. I didn’t understand how to setup our relationship with respect for them so we could work together well. Half of my team was inspired by me and loved my passion and ability with the technologies. The other half couldn’t stand me and soon conspired to get rid of me. This was all due to my inexperience with company politics, knowing how to treat people, and relationship management in general. The IT Industry Needs To Focus More On People Our industry is driven by gadgets, tech, and whatever helps engineers be intellectually stimulated. But understanding people, how to get consensus, and how to win trust from others is JUST AS important if not more so to your career. My first job was a great example of how not having these skills led to a lot of friction with my colleagues. I Hope This Channel Helps You Be Less Anxious I’ve made a lot of stupid mistakes in my career when I let fear and anxiety get the better of me. As this channel’s videos progress, I hope hearing more of the story of my career, and the tools I’ve used more recently, will help you have less anxiety as your career moves forward. 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…
H
Healthy Developer
1 How Failure Produces BETTER Software Projects 35:48
35:48 Play Later Play Later Lists Like Liked35:48
Play Later Play Later Lists Like LikedDo your projects move forward with many assumptions that turn out to not be true as things progress? Today I'd like to share how learning of a team failure produces better software when you plan to exploit this ability. The overall assumption that most projects operate under is that the project will be successful. However there are several smaller assumptions upon which this one is built. Often these smaller assumptions need to be verified to make decisions that keep the overall state of progress moving in a sustainable direction for the product. Assumptions About The Skill Of The Team If the team isn’t as skilled as assumed, projects will take significantly longer and more brittle to change. Assumptions About The Quality Of The Release If the team hasn’t put the appropriate quality checks in place, changes assumed to have a certain level of quality that don’t cause rework. Assumptions About Full Understanding Of Scope If the team is assuming requirements are complete, they look at scope change as failure. Assumptions About Value Of Features & Changes If the team is assuming changes being released are valuable to customers, but there aren’t measurable ways to know whether that’s true, waste could be being released. Doing Less At One Time Is THE KEY To Learning Through Failure Overall, the key to learning that we’ve “failed” in some way and need to adjust direction based on what we’ve learned FASTER is to do less at one time! Doing Less Between Releases Minimizes Risk If we make a mistake to a small change, the impact of that change should be smaller than releasing a large change. This minimizes the impact of rework or breakages. Doing Less Between Releases Motivates Realignment If a team iterates on a backlog that hasn’t been significantly changed since the project starts; the business has low motivation to realign. If a team is taking action on the feedback of rapid releases, the business must be more responsive. Doing Less Between Releases Improves ROI For every day that development continues without a release, there’s no return on investment. By releasing more frequently, the team has the opportunity to provide value to the customer with less capital. Doing Less Between Releases Improves Skill If we do a production release every 6 months, how good are people going to be at it? Doing less between releases forces the entire team to practice release practices more often. This results in a team with higher delivery skill. Fail Faster By Having Artifacts That Provide Feedback Having tools and processes that give us the state of a change at any time lets people know a failure to some process has occurred early. This enables people to take action on issues as they emerge and catch them before the change makes it out to customers. Fail Faster By Using Cross Functional Teams The lag time that occurs between separate departments for disciplines needing something and sub-contracting “as a service” causes releases to take longer. If we want to fail faster, we need to have all the people needed to release the product dedicated to it and working together so there is no lag time to service outside of the immediate group. Fail Faster By Holding Retrospectives Have a meeting to talk about what went well and what didn’t over the past release (Scrum) or several releases (Kanban). This is an easy way to learn earlier that the team is failing to follow processes that are working for the project. Fail Faster By Releasing To A Limited Audience Rather than learning that there’s an issue with a release from a large number of voices from your customer base, have a system in place to release to only a small subset of total customers. This is known as ring releasing or canary releasing. Fail Faster By Having a Measurable Pass/Fail Many projects release a large number of features. If some KPI changes positively, it is difficult then to know which of those features or changes caused the positive change. Use A/B testing to verify that investments actually impacted a KPI. Fail Faster By Focusing On Valuable Outcomes Most projects have a large number of features. Rather than keeping everyone busy “burning down” a large list, figure out how much money the business is losing by NOT having each story (cost of delay). Work on the highest cost of delay ideas with FOCUS since those are the most economically viable! Fail Faster With Justin-In-Time Scoping If a team does detailed requirements on a large quantity of work, it creates psychological attachment and wastes money. Teams should instead only get the details of the top items on the list periodically. Fail Faster With Monthly Budgeting If we assume that we’ll learn we need to change what’s built every release, we need to re-budget every release with project % complete accounting. Rather, budget monthly to provide the capital needed to take action on changes to customer needs with less pain. 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…
H
Healthy Developer
1 How UNCERTAINTY Impacts Software Development Processes! 45:50
45:50 Play Later Play Later Lists Like Liked45:50
Play Later Play Later Lists Like LikedDoes it ever seem strange how when talking to other software developers they insist that the processes they use are “the best” but they don’t seem to make any sense as to how they could work in your company? Today I’d like to share how uncertainty impacts software development. Whether they realize it or not, many people in companies select processes based on their tolerance for uncertainty. The experience they’ve had developing software in the past, and existing beliefs they have about how the rest of the business and the customer will use the product influence decisions. Changing Market, Customer Needs, and Technologies Require More Adaptability Today Technology changes faster today than it did 20 years ago, so being able to respond to change is more important. We need to be careful of fortune telling, and that we aren’t over-confident in our ability to see what’s coming. When we use agile processes for software development, one of the big benefits is that they help us adapt to changes in the market and optimize for handling disruption. How Responsive Is Your Company Willing To Be? The big question is – how responsive is your company or team willing to be? The more uncertainty people at the company can tolerate, the more adaptable and responsive you’ll be in serving your customer. There are a wide number of decisions that can be made about how you develop software that stem from the tolerance for uncertainty, but in this video I’ll talk about some major attributes of the two extremes. Uncertainty Of Scope and Budget A company or team with a lower tolerance for uncertainty may use % complete budgeting to track progress on the project. A team with a higher tolerance for uncertainty may set a monthly budget to allow the customer to influence what’s delivered more. Uncertainty Of Cost and Measuring Progress A company or team with a lower tolerance for uncertainty may focus on cost and estimation. A team with a higher tolerance for uncertainty may track learning milestones to measure progress. Uncertainty Of State Of The Code A company or team with a lower tolerance for uncertainty may create source control branches for developer changes. A team with a higher tolerance for uncertainty may use feature hiding instead, with everyone collaborating on one branch to follow continuous integration. Uncertainty Of Customer Needs and User Experience A company or team with a lower tolerance for uncertainty may make more investments in the UX up front. A team with a higher tolerance for uncertainty may use lean UX practices that provide a minimum viable experience, and adapt as they go. Uncertainty Of Software Architecture A company or team with a lower tolerance for uncertainty may make more up-front architecture decisions. A team with a higher tolerance for uncertainty may simplify the architecture to increase the speed of refactoring, and let the architecture evolve with product growth. 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: Principles Of Lean Product Management By Jez Humble Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 What MEN Need To Know About Software Developer BRO CULTURE! 32:34
32:34 Play Later Play Later Lists Like Liked32:34
Play Later Play Later Lists Like LikedAre you confused or frustrated by the amount of energy spent discussing sexism in the workplace and how men are to blame? Today I'd like to offer some insights and opinions that might help men make smarter decisions about how we treat people to make sure we're not damaging our careers and making it difficult for people to work with us. Disclaimer: These Are MY Personal Opinions First a disclaimer. I'm a heterosexual man and these are just my opinions after many years working in the industry that I've observed and experienced. I'm not qualified to talk about what makes the workplace safe for women, but I can share how my own shortcomings and observations of other men's behavior makes it hard for everyone. Purpose: Get You To Think More Seriously About This Issue The purpose of this video is not to tell you what the solution to all of these issues is, but to get you to think about how software developer bro culture affects all of us. My hope is that this will lead to you spending some time researching the issue to reach your own conclusions with intention. What's It Like To Work With "Bros"? First I'd like to share what it's like to work with other "bros". On an all male, or male-dominated team like I've been on several times, unchecked aggression, free exchange of ideas regardless of how they make people feel, and shaming are prevalent. The people who do this don't always intend for this outcome, but as the team grows and these behaviors are left unchecked, it becoming "the norm" is the result. Men Can Feel Threatened By Women's Support Of Each Other I share a story about how a man approached a group of women discussing their lives in the park while my wife was at Yoga teacher training in Boulder. He made the crude joke "what is this the man hater's group?" which underscores how men feel threatened by women's support of each other. Because we can often feel it is a sign of weakness to support each other, we can lash out and say and do stupid things when we are uncomfortable. Men Fear Losing Relationships If They Show Vulnerability I also read a brief passage from "Daring Greatly", a New York Times Best Seller by Brene Brown , speaker, PHD, and researcher on shame and vulnerability in modern culture. In the passage, I describe the real struggle men feel when they don't have a safe place to express vulnerability. I've included a link to the book at the bottom of the page. The conclusion I draw is that men can become afraid of losing relationships that are important to them if they show vulnerability. Misery Loves Company So why do men continue to behave this way? One reason is the concept of "misery loves company", or the phenomenon where men engage in behaviors and ways of relating that make them feel worse about each other just because it feels good to be part of a social group. Standing up for ourselves to not engage in this behavior and instead hold ourselves to a sustainable, higher standard is the first step in rejecting this attitude. Domination Focus Will Limit Your Career Progress We also behave this way because we're modeled from a very early age to dominate others. However, domination will severely limit career progress as we move from company to company, or team to team, as our "bubble" of acceptable behavior is broken and we're forced to interact with wider, more diverse groups of people. Lacking Empathy Can Cause Others To Abandon You A lack of empathy will ultimately cause others to treat us with low respect. When things inevitably go south in any shape or form on a project, and leadership looks for someone to blame, if you treat others like objects of your will and not people you will be at the top of the list to take the fall. This is another form of short-term thinking and it doesn't take long for your career reputation to catch up with you - making a sustainable plan for growth much more painful than necessary. Compromising Work/Life Balance Makes You Easier To Replace In our quest to advance in our careers, we unfortunately often compromise work/life balance with the expectation that this will help us get ahead. In reality, though it might result in a short term promotion or advantage, we actually make it EASIER to replace us with younger, naive employees that will do the same when we inevitably grow tired. Men can do a better job than this and stand up for a fair balance of work by refusing to contribute to the workaholic mindset. Industry Veterans Owe It To Younger Colleagues To Improve Culture Since we will be working with the next generation as we progress, we owe it to our younger colleagues, regardless of their gender or ethnicity, to improve the tech culture. If we accept software developer bro culture as the default way teams interact, we are simply destining ourselves and others to a short career filled with disappointment as we're not prepared with the social skills and empathy needed to progress. 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: Daring Greatly (Amazon) Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 How To Earn Trust For Your Software Development Ideas 30:05
30:05 Play Later Play Later Lists Like Liked30:05
Play Later Play Later Lists Like LikedDo you want to try something new that requires other people to support you? Today I'd like to help you understand how to earn trust for your software development ideas. Honestly Evaluate Your Current Skill Before you begin to win trust for a new idea, you need to be critically honest with yourself about how skilled you are with implementing the idea. It’s fun to try new things, and we’re never “good” at them when we do them for the first time, but we should be careful not to “over-sell” our abilities. Consider A Time-Boxed Research Spike To Determine Effort You might want to consider using a time-boxed research “spike” to explore the true effort to try an idea, and to learn more details about what you just don’t know enough about yet. A time-box is simply a fixed period of time during which discovery of the idea or problem will take place before re-visited again. Make sure you set the expectation with others that the conclusion of this spike will not be everything needed to move forward, but that it’s a chance to regroup and decide how much additional time to spend. Establish Your Role In Collaborating Critically important to getting your skills used so you can win trust with others is to establish your role when working with them. This isn’t the same as your job title or the skills you contribute to an effort or team, but rather what role you play in serving another. Role 1: The “Expert” The first role is the “Expert”, where you essentially swoop in, do the work, and vanish. Though this can be tempting for the person doing the work as you are essentially “not bothered” but the person you’re working with, you miss the opportunity to get feedback and really deliver excellent work that meets both your needs and draws from both your skills. Role 2: The “Pair Of Hands” The second role is the “Pair Of Hands”, which is somewhat the opposite of the “Expert”. In this role, the other person directs your every move, and it’s common in companies with a command-and-control structure or where micromanagement is the norm. This can provide more control to the other party, but it misses out on their ability to have more feedback from you while doing the work. Role 3: The “Collaborator” The third role is the “Collaborator”, which is what you want to try and shoot for with anyone for which you want to gain trust. In this style, the two of you do the work together and have an opportunity to both contribute ideas, provide feedback, and make progress. It may help to share these definitions with others to get them to understand the value of the collaborative style. Align Motivation For Ideas With Others It’s crucial that you align the purpose for the changes you wish to make to the motivation of the other party when “selling” the change or idea. You won’t know this without really knowing the person and their struggles, and so you should consider following my advice from other videos to get to know people on a more authentic, personal level. This will give you the ammunition you need to make sure the other person “gets” why the change is important – to THEM. Use Incremental Wins Towards A Larger Goal Though the idea you have might be of immense benefit in some way, it’s quite possible that the work involved, and changes to the mindsets of those effected, is too much to take on in one go. To get around this, slice up a large change into small increments and only “sell” the first piece. When you’ve successfully delivered this change, it will get easier to win support for future changes. Eventually you’ll get permission to make a larger change in one go. Plan Your Detachment From Success It can be tempting to be seen as the expert or guru around a particular change you helped make on a team or at a company from your ideas, but if you want to continuously innovate in your career, it’s better not to. Plan how you will detach from the success you make on a project or with a company so you are not a bottleneck that must be the “go to” person for that change from then on. You will want to explicitly bring others into the fold, make sure they are trained and understanding the change as well as you do, and able to step away when the change is complete so you can pursue your next big idea. 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: "Flawless Consulting" (Amazon) Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 5 Ways To Cope With The ANXIETY Of Software Development! 21:26
21:26 Play Later Play Later Lists Like Liked21:26
Play Later Play Later Lists Like LikedAre you feeling worried that you won't get what you want out of your career? Today I'd like to share 5 ways to cope with the anxiety of software development. Overcoming Past Failures The first way software development can cause anxiety is when another party you're working with, or perhaps even you, have experienced failures in the past. If you can learn to be OK with having to prove yourself again, and that others may look at you with scrutiny because of what went wrong before that was totally outside of your control, you'll find greater peace. Battling Forced Commitments The second way software development can cause anxiety is when someone is obligated to a commitment for which they were unable to influence the terms. A common example of this is when a software developer estimates work for another. Do whatever you can to help leaders understand the value in the creative ways individuals solve problems, and commit to less without involvement from the person who will actually do the work. Overcoming Impatience In our quest to achieve our goals, we can often become impatient. When we rush to reach our career goals and dreams, we don't enjoy the journey and often make poor decisions in our haste. If we can calm down and savor the moment when we achieve a goal, we won't jump to start the next one without actually slowing down to enjoy what we just worked so hard for. Permitting Yourself To Heal I've personally had many tragedies in my life and failures on the job, and when I don't take vacation or whatever time is needed to fully heal - I'm never at my best. Permitting yourself to take time off to heal is crucial to doing your best work and enjoying software development. If you want to feel less anxiety, you must take care of yourself and put your needs above whoever at the company has expectations for you. If they don't understand, tough! Your health and well-being are more important than trying to keep yourself "together" if you're experiencing anxiety because you need to take care of anything going on in your personal life. Rejecting The Scarcity Mindset In our society today the perception that we don't have enough money, a high enough social media score, aren't attractive enough, or won't get the opportunities we want can result in crippling levels of anxiety. Rather than let this completely FALSE mindset effect us, we need to be realistic about the abundance of opportunity available in this industry. The sooner we can take a step back and realize just how many options there are outside our current situation, and have the courage to explore these while embracing uncertainty - the sooner we can calm down, try what might be more fulfilling, and steer in a direction that's better for us. 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…
H
Healthy Developer
1 How To Be A Servant Leader On Software Projects 32:49
32:49 Play Later Play Later Lists Like Liked32:49
Play Later Play Later Lists Like LikedDo you want to help the other people that work with you so they are more fulfilled, and get an opportunity to inspire them? Motivations To Consider Let’s start with some of the motivations I think it’s important to consider if you want to go about servant leadership. Improve Quality Of Delivery Ultimately, however you serve people still needs to result in improving the quality of delivery. While we’ll focus on how to be a servant leader on software projects by serving the needs of others, this fact is important to still keep front and center. Support Career Goals Of Colleagues As you go about serving others, you might adopt a motivation to see others’ careers advance. This doesn’t mean you stop caring about what happens to you, but that you share the burden for those around you being recognized. You Don’t Need A “Leadership” Title You don’t need an “official” leadership title to be a servant leader on software projects. You may be the boss of your colleagues already or not, either way, the goal is to inspire and help others – regardless of your job title. Don’t Rely On Skills To Inspire As you attempt to lead others by serving them, you may need to shift from relying on demonstrating how skilled you are as a primary motivator. Instead, utilize some of the other tips in this video to be a servant leader. Avoid “Siding” With Individuals Be wary of siding with individuals. Do whatever you can do to avoid being sucked into political games, or disputes between people on your team. This doesn’t mean to not have empathy – far from it, empathy is crucial. Rather, don’t be an ear to lend when someone wants to criticize someone else and join in on it with them. Detach From Personal Advancement You may find detaching from your personal advancement helpful if you want to be a servant leader on software projects. The moment you start considering whether your efforts are advancing your own career, conflict can arise that makes it harder to take altruistic actions. Tips For Better Servant Leadership So what are some of the things you could start doing immediately to demonstrate your desire to be a servant leader? Show More Than You Tell The first thing I’d recommend is to show more than tell. When you delegate work or information to others, taking the time to show them how its done will go further than just conveying the steps. You won’t always be able to do this, but err on the side of demonstration whenever possible. Get To Know Colleagues Personally Next I’d recommend you get to know your colleagues personally. More than just what technical or other work related skills they prefer, get to know what makes them tick personally. This will make it easier to support them and their needs and desires. Organize Opportunities To Socialize If you can organize opportunities to socialize with your immediate group, you will show your colleagues that you care about them as people and are willing to share of yourself outside of work. Don’t rely on company happy hours and events as the sole way for your immediate colleagues to get together. Recognize Individual Contributions It’s important to recognize individual contributions, and not attribute them always to the entire team. When providing status or communicating “wins” of the team, put a name to each gain and give props freely to those who did the work. Advocate For Solutions To Colleagues’ Pain Listen for pain and advocate for solutions. If you get to know your colleagues personally, they will share their struggles and whatever you can do to ease it or help shift the burden to someone else will help them be more fulfilled and effective. Advocate For Growth Of Your Colleagues As a servant leader, don’t rely on people with explicit management titles to be the only ones to look out for your colleagues careers. To avoid seeing great people you’ve built good relationships leave, do what you can to remove roadblocks and enable them to grow. If they want to leave because they aren’t getting the opportunities they need, support them in that as well. Get Excess Capacity To Support Serving You will need to negotiate excess capacity in your schedule so you have the time needed to be an effective servant leader. This may be difficult depending on the management style of your organization, but if you can do it – it’s well worth it. Struggle With Them It says more about you when others see how you help during times of stress than when things are going according to plan. Share in the struggles with your team. If you really want to demonstrate the attributes of a servant leader, this is an easy one. Be As Transparent And Open As Possible Though this can be controversial, I believe servant leaders should do what they can to be as transparent with their colleagues as possible. If you wish to serve others above the company, part of that is being open and honest with them about information you know. Do not divulge information you’ve been asked to keep private, as this is being dishonest – but I encourage you to get permission to be as open as possible with your colleagues from whoever you report to if 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 . Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 Why Software Developers DISAGREE - And What To Do About It! 16:56
16:56 Play Later Play Later Lists Like Liked16:56
Play Later Play Later Lists Like LikedAre you frustrated that other software developers often belittle each other or have a hard time coming to agreement on seemingly trivial issues? Today I’d like to talk with you about why software developers disagree – and what to do about it! The Fear of Being Misunderstood The first reason I often disagree myself, or see others do so – is due to a fear of being misunderstood. We strive to have others respect us and understand where we’re coming from, and sometimes this results in us disagreeing simply to clarify our stance. An Inflated Sense Of Experience Another reason we can disagree is an inflated sense of experience. When we’ve worked on a particularly wide variety of technologies and at many companies, we can think we “know everything”. I personally struggle with this and have to constantly strive to keep myself in check, being realistic about what I do and don’t know. A Byproduct Of Detail Needed To Be Successful We can also disagree simply as a byproduct of the detail needed to be successful. The interview process, and the fragile nature of software development tasks can cause us to become nit picky or too particular with each other. Though we should always strive to have a better understanding of what we mean, I try to leave it alone when I feel someone has “got it” even if their explanation may be different than mine. Projecting Prior Frustrations Onto Others Sometimes we have a bad experience on a project or with a person, and when we feel our self in proximity of a similar situation – we fall prey to projecting prior frustrations to others. This survival instinct can be helpful, but it can also damage our ability to see people for who they truly are and not cast an unfair perspective of them through the lens with which we’ve been hurt before. Focus On Mechanics At Expense Of “The Big Picture” I also experience disagreement if I or others focus on mechanics at the expense of the “big picture”. When we split hairs on the “how” without agreement on the “why”, it’s very easy to get distracted and spend unnecessary time working out the details of detailed tasks without having consensus around purpose. How Can We Handle Disagreements Better? What can we do about these easy ways with which we disagree? Get To Know Others Authentically The first one would be to simply get to know each other more authentically. When we have real relationships with people and not just “fake” work relationships, people will be less likely to feel misunderstood. Assume Good Intent And Reason For Disagreeing We also come to agreement easier if we approach others and assume their good intent and reason for disagreeing with us. Though it’s tempting to rely on our prior experience to control and color our perspective of another’s stance, learning to be more patient and understand their unique situation can quickly get us back to agreement. Try Not To Take Disagreement Personally Putting explicit effort into trying not to take disagreement personally is hard, but opens up the ability for others to feel safe with us and to not feel like they must “walk on eggshells” any time they communicate. This fosters the relationship needed for creativity and consensus to flow naturally. Be Selective With What To Disagree About You’ve heard the expression “pick your battles” and this certainly helps with disagreements. By being more selective about what we must get agreement on, we trust the major outcomes of a project and don’t have to be so anxious about every little detail going our way. Get Consensus On “Why” vs “How” If we can get consensus on “why” vs “how”, disagreements are less common since few will argue a high level business or project goal. This gives everyone the fresh perspective needed to look at their own stance more objectively in light of the overall goals being targeted. Appreciate When Others Learn What You Know Lastly, appreciating when others learn what you already know will diffuse many disagreements. Many of us learn best by sharing, so our ability to be patient and hear someone explain what we know helps them learn, and be committed to the work we know they will need to do to take on the tasks at hand. 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…
H
Healthy Developer
1 The Journey To CROSS FUNCTIONAL Development Teams 20:00
20:00 Play Later Play Later Lists Like Liked20:00
Play Later Play Later Lists Like LikedAre you looking for a way to get people with different disciplines to work together better when developing software? Today I'd like to talk about the journey to cross functional development teams and some of the considerations on your way to integration. What Is Cross-Functional Teamwork? Cross-functional teamwork is simply taking people who used to be in separate teams or departments and putting them on the same team. To get there people go through a series of phases or stages. Phase 1: Ad-Hoc The first phase is what I call “ad-hoc”. Someone at the company has done some work that would typically be thought of as associated with a discipline (Operations, QA, Support, UX as examples), but they don’t think about how all the things associated with that discipline should be handled. Phase 2: As-A-Service The second phase is “as a service”, or what most people in medium to large companies often experience. This is where there is a dedicated department that does Support, Operations, UX, or QA; as examples. When a product team needs help with one of the skills of these separate teams, they use their expertise as a service. But these teams are still independently managed and measured. Phase 3: Embedded The third phase is “embedded”, and what most people think of when they hear terms like DevOps, Embedded QA, or Embedded UX as examples. Folks who were on a separate team are now integrated with the product team itself. They are dedicated to using their skills to achieve a single outcome for the business such as a product or deliverable. Embedding Sometimes Uses An Office / Center Of Excellence During the embedding phase, it’s common to see companies create a center of excellence, or office, who’s purpose it is to help make sure good practices are followed by those embedded in the teams. A “Project Management Office” is a common example of these. An important consideration is, does the person leading this new office have the skill with coaching, documentation, patience, and establishing measurable outcomes necessary? Leading Center Of Excellence Requires Additional Skills Also during the embedding phase, it’s important that all of the people working together on a cross functional team now share in the risks and rewards. If we’re going to expect people to work together towards a shared outcome, and not look out only for themselves and do work in silos, we need to spread the results of everyone’s actions across the team members. Phase 4: Infused / Integrated The final phase of cross-functional development teams is when the skills that used to be primarily sought by a dedicated member of the team around a discipline (again, Operations, QA, UX, Support as examples) are disseminated across team members. This is hugely beneficial since multiple team members can now provide help with more than one discipline, and it avoids bottlenecks due to individuals who are thought of as “the person” for a particular skill being unavailable. 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…
H
Healthy Developer
1 Software Developer vs Consultant - What's Better For YOU? 34:57
34:57 Play Later Play Later Lists Like Liked34:57
Play Later Play Later Lists Like LikedToday I’ll share what I’ve learned over 10 years of first being a developer working directly for software companies, and then 10 years working as a software consultant. I hope this helps anyone evaluating the trade offs of a software developer vs consultant, and figuring out what’s better for your career. Influence The first consideration is influence. As an employee, your influence can sometimes be restricted by the position you hold. As a consultant, it tends to lend itself to you having whatever influence is necessary to solve the problem you were brought in for – at least at first. Business Perception Of Value Another thing to consider is how the business will perceive your value. As an employee, you can be looked at as a cost center, or a profit center depending on the business model of the company. As a consultant, your value to the business is typically a solution provider – you’re there to solve a problem, and ultimately to leave. Perception By Peers How will you be perceived by peers? As an employee, you should be treated as one of the family since you share the same benefits and struggles as the rest of the company’s people. As a consultant, peers will often look at you very skeptically at first – you must learn to be comfortable with this to fit into their culture. Key Traits and Skills What are some of the key traits and skills needed? As an employee the focus is often on your technical skills. Though soft skills and process understanding will help, most hiring managers focus heavily on technology above all else. Additionally, you’ll be considered for “culture fit” – which can be a real thing, or a wild card used to reject candidates in my experience. As a consultant, there are very different skills that will tend to help you be successful in the position. First, likability – people must like you to enable you to get the influence necessary to become a trusted advisor. You also need to be above average at communicating clearly, and tailoring information to different audiences. Lastly, an appreciation for and desire to understand the business in which the software development is done will help tremendously. Rewards Next think about rewards. As an employee, you’re usually going to make some adjusted version of the market rate for your skills, and optionally some options or equity. As a consultant, you’re either billing your clients at an hourly rate, or can charge a percentage of the opportunity you’re enabling. Growth As an employee growth will happen when the company needs it. So you need to grow on the side if things aren’t moving as fast as you’d like. A consultant has the potential to grow with each contract, but it can be stressful and fast paced. An employee can get recognition whenever they work on a successful product effort. A consultant gets less recognition that turns into a reward short term, since they depend on their firm rewarding them and they don’t always directly see the work. Ability To Change Work Processes Employees can change whatever work processes they want within the realm of their responsibility with reasonable ease. Consultants must prove themselves before they are allowed to change processes, but once proven it can be easier than an employee. 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…
H
Healthy Developer
1 Why Software Development Change Initiatives FAIL! 12:02
12:02 Play Later Play Later Lists Like Liked12:02
Play Later Play Later Lists Like LikedAre you asking team members or maybe your entire company to change the way some aspect of software development is done? Today I'd like to share why software development change initiatives fail all too often. The first thing people are most familiar with around a change is the communication. This can often happen in a meeting where leadership or a project manager states “what” the change is. Though this is a necessary part of the process, it’s bare minimum. The second thing people are familiar with is “how” the change occurs. What training, documentation, and other materials are needed to equip people with the tools or assets they need to make the process change? Next, you’re probably familiar with how interested most teams and companies are in governance. That is, how do we know how many people are making the change, and how successfully? Though it’s important when doing software development that change initiatives are accompanies by measurable goals or metrics, the biggest piece of the puzzle still needs to be tackled. To have the highest chance of a successful change, we must answer the question “what’s in it for me”? But from the perspective of each INDIVIDUAL we’re asking to make a process change or a tool or technology change. Before we can do that, we need to know people on a personal level. And to do that requires spending TIME with people and getting to know their unique circumstances, history, and life struggles and goals. When asking someone to make a change that in no way benefits them, often the best chance of success is to motivate them with some sort of reward. It’s a companies way of saying “we’re sorry you need to do extra work or work differently, so here’s something we want to share to show how we take into consideration to burden this adds to your workload”. In all other cases, understanding each person’s motivation, and what outcomes they might want to be supportive of a software development change initiative, is most often the key, CRITICAL factor in the success or failure of widespread adoption. People change most successfully when the reason for the change is not just communicated, not just understood, but aligned with their own goals! 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…
H
Healthy Developer
1 Evolving Software Architecture To Adapt With Product Growth 22:29
22:29 Play Later Play Later Lists Like Liked22:29
Play Later Play Later Lists Like LikedAre you making decisions about what technologies and patterns are used in your software product? Today I’d like to talk about some considerations you may wish to entertain when you select technology for use on a product being delivered to customers with software. Evolving software architecture to adapt to product growth can help your team deliver faster and accommodate refactoring needs easier as the project progresses. We should determine how mature our product is in the market first. Geoffrey Moore’s famous book “Crossing the Chasm” describes how a product goes through segments of customers along the maturity of a product’s timeline in the market. In this video I talk about how to change the software architecture depending on where you are along that timeline as you chase market fit. Are you selecting technologies that are appropriate for how mature the product is? If you have team members who’s only work experience was on more mature products, they may need help with making technology decisions that are simpler and support the speed of change necessary for a less-established, exploratory product. If we select a comprehensive, full stack set of technologies for our minimum viable product (MVP), we can be susceptible to over-architecting. We can never make perfect decisions, but I recommend considering the maturity of your product in the market, and if choosing simpler architectural patterns and technologies might be better. Once a product has growth needs, the business should be profitable enough, with enough additional revenue, that updating the architecture to meet the new growth needs can be afforded. This takes pressure off the team early on as they are able to product changes for early customers to validate business ideas quicker. We should also consider the skill level of our team members, and whether they’ve mastered the foundational technologies upon which pattern and stack decisions are based. If a team is especially proficient choosing a more comprehensive stack may be appropriate. If not, it may make more sense to select the minimum viable set of components needed to simply produce changes to get that market feedback as you’re still crossing the chasm. It’s worth considering whether to innovate with our own frameworks or libraries when we select technologies for a project and how their patterns might benefit the software architecture. If we go this route, we should consider whether we really have the time and support from the business to train people on it, document it appropriately, and provide support for it. We might consider spending more time fully researching all available options for existing components and frameworks that meet the needs of the product first before innovating ourselves. Whether using nodejs, C#, Java, python, ruby – or any other core language, there are a huge number of available packages on the community to implement most concerns of a modern architecture. The exceptions to this are the “secret sauce” where your product provides its core value – but this is what you should probably spend the bulk of your time building – NOT architectural building blocks. You might consider resisting the temptation to select patterns and technologies that allow for future flexibility until you actually need them if ANY additional complexity is necessary to do so. Though this leaves you up to the chance to need to refactor at a later date, it also eliminates any waste spent supporting possible needs down the road that aren’t capitalized on. Emotionally detaching from having to think the architecture is “right” and will “never change” helps us have the mindset necessary to be more lean in how we develop software. I’d encourage you to educate stakeholders whenever possible on the realities of the architecture’s suitability for the product at any point along it’s market adoption curve. When businesses understand the implications, they are often very supportive, and will feel less frustrated when changes to the architecture are recommended by the team at a future time. Simple Strategies For Identifying When To Evolve So if we know evolving software architecture allows us to gain efficiency by being deliberate about it, how do we know when to actually make changes? The first thing I’d recommend is to bake monitoring of components and infrastructure into the development process. Whenever a change or feature is being designed, think about how to monitor its performance and anything else about it that might indicate a need to change the architecture. The second thing I’d recommend is to monitor the throughput of the team, and watch for any fluctuations. Though a team delivering slower than they had before can be for a variety of reasons (most often technical debt), it can also signal a need to make revisions to the architecture. 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…
H
Healthy Developer
1 5 Software Redesign MISTAKES By Software Companies! 10:42
10:42 Play Later Play Later Lists Like Liked10:42
Play Later Play Later Lists Like LikedAre you getting ready to redesign a new version of a digital product with software? Avoid the top 5 software redesign mistakes by software companies I see made all too often. #5 – Focusing On Current Customers It’s tempting to focus on what current customers of the product have wanted at the expense of NEW customers. If the goal of a redesign is growth, it makes sense to do market research and look at the product with an open mind. Do new customers have completely different needs than current customers do? #4 – Trying To Include All Features Of Prior Version Many companies spend too much budget and time trying to design a product that does everything the prior product did. A redesign is the perfect point in a product’s life cycle to look at it with a fresh set of eyes before making a reinvestment. Throwing off the shackles of the existing product’s feature set might be exactly what your team needs to envision a dramatically more compelling, simpler, and BETTER product for the market. #3 – Budgeting Too Little For Marketing As a digital software product becomes more established, many teams focus too much on the engineering side of the product. Is it possible that you might be better off budgeting a larger percentage of the investment in the redesign towards marketing? If you’re not doing Facebook advertising, Google Adwords, or Instagram posting to reach today’s audience you could be missing out on an extremely effective way to reach customers that you used to via a different source. #2 – Failing To Consider A Rebrand Though the benefit of an existing brand name and marketing message can be an advantage, depending on the age of your product and the needs of new customers, it may make sense to rebrand. This allows a team psychologically to detach from the prior product more wholly and look at the new version through a completely different lens. Might this be a strategy your company could use to bring life back to a product that’s no longer as compelling and exciting for the market as it once was? #1 – Failure To Establish Measurable Outcomes The biggest and most common of the software redesign mistakes I see made is unfortunately the failure to truly establish easily measurable outcomes for success. As a project gets underway, unless design decisions were made to accomplish easily measurable goals, it’s easy for the team and management to lose sight of the purpose and simply look at the redesign as a “project” to be completed. It’s a huge opportunity to reach some exciting goals for everyone, and it provides cause for celebration to all those who were involved as they discover what the market wants! You can also watch this episode on YouTube . Related resources: How To A/B Software Development To Find What Customers Value Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards…
H
Healthy Developer
Let me share some stories today that will present at least 5 ways pride kills a software project. At the end of the video I'll share three strategies I've used to fight pride. The first way pride can kill a software project is when we become too proud of an opportunity to lead. At the beginning of my career, I had an amazing opportunity to lead a team to build a software product using a new technology. I was inexperienced, and my pride caused me to be resistant to work with more senior people. It didn't take long, but half my team was resistant to my changes and they wanted to see me fail. Ultimately I was given the opportunity to work on a different project but it was really because I was so difficult to work with. The second way pride can kill a software project is when we become too proud of a select group of people. On a project where I was able to work at a new company with many people I'd worked with before, we created a clique and didn't respect and work with the existing teams at the company very well. In short time our project's success was at risk because we didn't get buy-in from the others on the team. We were too proud of those we trusted, and didn't work hard enough to get the others we should collaborate with to understand that we respected their value. The third way pride can kill a software project is when we become too proud of past successes and efforts. I was helping a client at the consultancy I worked for, and there was a person there who was very senior and experienced, but he wouldn't change. Everyone in the company respected him - and they wanted to see him rise to the occasion, but he just wouldn't budge. When we become too proud of the work we've done to gain skills, we can start to get resistant to doing the work it takes to stay relevant and GROW. Eventually this individual did come along to his senses, but it was painful and wasteful for a long time and caused work to be difficult for many others until that happened. The fourth way pride can kill a software project is when we become too attached to our ideas and their potential value. I was helping another client where they had asked our consultancy to build a product. We warned this client that what they wanted to build was too risky, and that the budget they had allocated put too much risk in all of their ideas being good. Though we tried hard to convince the client of the importance of our approach, and how software development is different from manufacturing, ultimately we did the work the way they asked. The end result was that the business folded, because they didn't profit enough off their ideas to pay back the investment in the development. The fifth and final way I've seen pride kill a software project is when people have too much pride in the way a process was done before. At a company I worked with, the process that was used for selling needed a change. Many of us at the company had seen a shift in the industry, but key people in the sales department refused to entertain our ideas. Though it was understandable that as not being in sales outside "technologists" trying to influence their process may have felt off-putting, it was out of our genuine concern for them. We wanted them to see that customers now wanted lean software development, and our company culture had to change to continue to deliver what the market wanted. There are a few ways we can also fight pride. The first thing we can do to help fight pride getting in the way of our career growth and successful software projects is to simply cultivate gratitude. By being more grateful of what we have, we have less attachment in being right, rewarded, or having certain outcomes - and this gives us the courage we need to try new things. The second thing we can do to help fight pride is to see the potential in other people and the value of their ideas. If we always look to others to do things how we do, and we only evaluate others based on how often they are supporting our ideas, we miss out on the ability to benefit from what they might bring to the table. It helps us be more humble when we keep an open mind to the value of others at all times. The last thing we can do to help fight pride is to encourage risk taking at our company and with our people. With risk comes reward, and working at companies that only take small, calculated risks only produces minimal improvements. It also creates a culture where people are unable to be as creative, and produce the innovation and efficiency breakthroughs necessary to really move to the next level. A leader of a team who knows the importance of this will harvest the best ideas from their 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…
H
Healthy Developer
1 How To A/B Software Development To Find What Customers Value 23:29
23:29 Play Later Play Later Lists Like Liked23:29
Play Later Play Later Lists Like LikedCompanies need to start to A/B software development to find what customers value. Relying on planning up front based on customer feedback and research just isn't competitive anymore! Software development is not like manufacturing. We don't have to make sure it's perfect before we start to build. In fact, that's not a very agile approach - and we'll too often build things that waste money! When we do lean software development, we look at a lean canvas, or a business model canvas, and figure out which aspect of the business we want to impact through a change. We need to design an experiment to test that change, and part of lean product management is setting up these experiments so we can test whether the experiments we run are pointing us towards the impact to the business we want to make. We need to choose a measurable outcome to impact first, and figure out how to measure it. What will constitute success? Next we need to make sure we know how we will serve both the old (pre-change) version of the product, AND the post-change version to an audience of the same size to see which one "wins". This is known as cohort analysis, and will help us avoid vanity metrics (measurements that don't really represent an improvement). When we serve both versions of a product (with and without a change) to a cohort, we need to determine how long the experiment will run. When the experiment ends, we have a learning milestone where we look at what was gathered, and decide whether to pivot or persevere. Traditional project accounting looks at % complete to determine how efficiently a team is using budget to complete an effort. In lean software development, we need a new approach. This new approach is called innovation accounting, and it instead measures the business on how effectively it is learning about where its assumptions about what's valuable are right and wrong. To use innovation accounting will require getting leaders on board. Unless we change budgeting to account for this, and convince anyone who was involved in the prior software project budgeting approach to use innovation accounting - we'll continue to deal with "change requests" or asking for more budget after we learn, and it looking like a failure on our part. Innovation accounting is a concept introduced by Eric Ries , author of "The Lean Startup". 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 Lean Startup" on Amazon Principles of Lean Product Management by Jez Humble Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 Continuous Delivery Best Practices For Infrastructure As Code 32:19
32:19 Play Later Play Later Lists Like Liked32:19
Play Later Play Later Lists Like LikedTo release software smoothly, avoiding time wasted troubleshooting infrastructure issues - you might consider automating your infrastructure as code. To achieve continuous delivery requires thinking about how technologies like chef, puppet, ansible, docker and the like might serve this need for your team and organization. The first step is to determine an approach for using images. If on premise, you might create one that can be used when initializing a virtual machine. In the cloud, this image might be used somewhere like docker hub, or in windows azure or amazon web services (an ec2 image). Jez Humble refers to computing resources and environments that have not had their infrastructure controlled as "works of art". I love this term, it accurately describes the confusion around how a node of infrastructure got into a state. To avoid this, we should use infrastructure provisioning tools against the computing nodes we "stand up" from an image. These tools will run a series of steps against a node to put it in a given state. An important thing to consider when embarking on the journey towards infrastructure automation is whether the company has the discipline to not make manual changes. If this is a new concept, a tool like puppet, ansible, chef, or the like can help by checking to see whether a node is in a given state and only applying the necessary changes. These checks come with additional processing power (and hence time) however, so in a company that's more mature in how it uses infrastructure as code and automated deployment, it may make more sense to use something that doesn't perform these checks - instead assuming nodes are already in a state. A common practice is A/B releasing, which can be used to switch between an active and passive set of nodes in production, or any other environment. This makes deployment faster, and also allows rolling back a problematic deployment easier. A/B releasing is different than A/B testing - the former helps with deployment, the latter with validating that changes had the business impact we theorized. I'll talk about A/B testing more in a future video. I recommend in this video to use powershell, bash, or a similar technology as the "trigger" of any automated deployment or infrastructure provisioning process. This avoids vendor lock-in and provides the most future-proof flexibility in combining the many tools modern vendors can use to make changes as the product evolves. Though there are fantastic tools such as terraform that have a wide reach, able to make changes in cloud AND on-premise environments in both amazon web services (AWS) and windows azure - I've yet to find one tool that can do everything. Regardless of the technologies you choose to use, select a language or syntax that will be most comfortable for your team's existing skillset. For example, if those who will automate infrastructure are object-orientated programmers - a tool like C#, ruby, or python may be sufficient. On a team with a more "traditional operations" set of skills - bash or powershell is probably going to be more approachable. 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…
H
Healthy Developer
1 How to Use Configuration Management For Continuous Delivery Of Software 30:33
30:33 Play Later Play Later Lists Like Liked30:33
Play Later Play Later Lists Like LikedAs described in the video on isolating customers from your changes, there are typically a minimum of three environments into which software can be deployed. There are configuration settings used by your application, service, or product with software that need to change depending on the environment. These are called environment-specific configuration settings, and this video describes an approach for managing their values. You may have configuration settings in several files like the web.config (.NET), database.yml (rails), or .json files (nodejs) as examples. The settings in these files that are specific to an environment need to be set appropriately whenever your product and its components are deployed. Though there are utilities and tools often available that will set these appropriately for each type of file, this makes deployment more complicated since there is still duplication. The same database connection may exist in multiple files that all need to access the same database, but are for a different technology for example. Rather than using these technology-specific approaches, a more efficient method that will help your team be more agile is to centralize all environment specific configuration in one master file or list. Then you need to use some script or technology that can read those settings and overwrite the values in the source code or configuration files once deployed to an environment to the correct setting. The more configuration settings your application has, the more important it is that you create automated tests to verify that they work properly. One of the most costly ways to deliver software is to have an extremely flexible set of configurations and not have an automated way to test all of the combinations. The time spent manually testing this is much less than the investment necessary to build out the automation - and will pay you back time and again in time to market with future changes. 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…
H
Healthy Developer
1 Development Environments - Isolating Customers From Your Changes 12:28
12:28 Play Later Play Later Lists Like Liked12:28
Play Later Play Later Lists Like LikedTo release software to your customers, you'll probably need several development environments. To allow a team to make changes to software without disrupting paying customers, we need a way to isolate them. Software developers and engineers working on an agile software development team need an environment where they can make changes under development. The development environment might be a copy of a website, database, or API on their computer. This is sufficient for a product with a minimal footprint. In a larger and more complex software product, cloud or server resources in a datacenter may be needed to support development environments. In addition to a development environment, most teams need somewhere separate from development and production to do additional testing. This can be known as the "test", "user acceptance" (UAT), or "staging" environment and allows the team to more closely inspect a version of the software slated to release. The final environment that is always required is production itself - or the place where your paying customers use the software. In addition to a development, test, and production environment - there are two other environments that can be fairly common. One of these is a demo environment, who's purpose is to provide a playground or sandbox where a limited audience can "kick the tires" of the software without disrupting the development team. The other common environment is a capacity test environment, who's purpose is to determine whether a potential release of the software will stand up to a real load. Capacity test environments should have the same hardware or cloud processing power as production, to provide testing results that are representative of real traffic on the same computing power. Regardless of which environments your company or team uses to release software, you'll need configuration management to automate releases through these environments. I'll talk about configuration management tomorrow, and how you can use it to make sure releases of the software in a given environment don't accidentally point to the wrong environment's resources. 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…
H
Healthy Developer
1 Continuous Delivery - Are You Missing The Big Picture? 21:13
21:13 Play Later Play Later Lists Like Liked21:13
Play Later Play Later Lists Like LikedYou probably know you need to use Continuous Delivery to release software to your customers. There's much confusion in the market around Continuous Delivery. How does it relate to Agile Development? How does it relate to DevOps? In this video, I'll demystify Continuous Delivery by helping you understand the big picture. It's a capability - not a technology. The key innovation is reducing your cycle time. This is the length of time from when the business or customer has an idea, until it's available to users. To reduce cycle time, we often need to use automation technologies so less manual work is done between releases of our products. Operations personnel, in a traditional software company, are the keepers of production and have the keys to that environment. These folks are typically motivated by keeping the system stable, since they are measured on uptime and performance as examples. Developers are often measured on their ability to introduce change, and so their motivations are often at odds with operations. DevOps is about bringing these two disciplines together to overcome this psychological barrier so companies can truly be more agile. In a lean company, that's delivering software frequently to its customer for feedback - automation may not be necessary however. You can achieve continuous delivery for a small product or project through manual deployment - assuming the appropriate quality checks and process are in place. The most important thing about continuous delivery is reducing cycle time, so whatever you need to do to achieve that is getting you closer to that capability. Try not to get caught up too much in whether your team is using the right technologies to achieve continuous delivery. It's about cycle time - period. If you are in software product management, understand that this capability is what will help your team deliver software in a lean fashion. This capability is a necessary practice if you wish to get feedback from your customers in a fast enough time to take action on it. One of the most common aspects of releasing a software product that increases cycle time is automated testing. You don't need to do test driven development (write the tests before the code), but you absolutely must have whatever tests /are/ written be AUTOMATED. 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…
H
Healthy Developer
1 Creative Software Development - Explosive Growth By Letting Go 21:26
21:26 Play Later Play Later Lists Like Liked21:26
Play Later Play Later Lists Like LikedWhy are some companies able to engage in creative software development, while others treat it like manufacturing? Since the work we do to develop software is “knowledge work”, it benefits from the ideas and experiences individuals bring to each problem. Many companies look at the envisioning phase of an idea that’s developed with software as the primary process that benefits from creativity. Selecting the solution used to develop a feature or idea, equally benefits from creativity. So how can we maximize this? Inspiration is the spark that someone gets when exposed to something created by someone else. A piece of music, a fine painting, a software technology etc. Creativity is the work we do to form and shape that inspiration into something tangible in the real world. Being creative takes energy, so many of the things we can do to maximize energy, will also maximize creativity. People are less creative when constraints are placed on what they can change. Freedom allows for more creativity. We can provide technologists with more freedom by encouraging them to make healthy lifestyle choices. We can also provide technologists with more freedom by not allocating them to high levels of utilization. More free time = more opportunities to explore different solutions. These different solutions can have explosive impacts on efficiency. When teams are free to think outside the box and bring their full intuition to bear, problems once slated to take months can be solved in days or even hours. When making decisions about how we plan work, or what the culture at our companies is like – are we optimizing for creative work? Are we focusing on the illusion of predictability and control, using mathematical equations to feed our ego so we can feel like we’re getting the most out of people? Or are we creating an environment for software development that breeds creative ideas, treating people as sources of creativity and not just productivity units? Management and companies historically do a poor job motivating individuals to make better lifestyle decisions to have more energy so they can cultivate higher levels of creativity. You as an individual on a team must decide how important being innovative in your problem solving in your career is, and possibly make some lifestyle choices if you wish to reach your maximum potential. 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: Principles of Product Development Flow (Amazon) Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 Scrum vs Kanban - How Do They Help You Be More LEAN In 2017? 38:36
38:36 Play Later Play Later Lists Like Liked38:36
Play Later Play Later Lists Like LikedEmbarking on the journey to let customers lead YOU to the most profitable solutions? You’ll probably need to decide between the two most popular ways agile teams work, and I’m here to help you make that decision. Scrum is a great process when your team needs a scheduled checkpoint for how well they are doing. It is also great when the customer can only respond to change every couple of weeks. Kanban is superior when trying to use your resources to their fullest capacity. It’s also superior when your team needs to adapt to change without time wasted waiting on each other. My vote: Kanban! BOTH processes can be used in a lean fashion, but I just find Kanban supports adapting to uncertainty more fluidly. Kanban also lets team members work at their own pace, and do the work they enjoy most – not forcing people to attempt to work at the same speed and rely heavily on estimates being so accurate. Caveat: If you’re going to use Kanban, schedule a regular checkpoint to continuously improve processes by having a retrospective. REGARDLESS of which process you use, the same rigor you’d use on a waterfall project must be followed before any kind of estimate should be communicated. Requirements (or user stories), ACCEPTANCE CRITERIA, infrastructure changes, user interface assets, technical documentation, support & monitoring needs – figure it all out first! If this seems like a lot to figure out for one story – it is! That’s why stories must be small… A team that is learning to truly “continuously deliver” value to their customer in small batches must reduce the business’ expectation of the RATE of product change. There will be less released at once, but what is released will be HIGH QUALITY and ready to go to production immediately! So how does a team prevent changes that aren’t ready for production from going out with those that are? Feature Branching! *BZZZT* JUST KIDDING! Use /Feature Hiding/… Use configuration settings to hide work underway so it doesn’t block releases to production. When a feature is ready to go, just switch the configuration change on the next release! This forces everyone to continuously integrate changes into the trunk (or “master” branch) which is a key principle of *cough* continuous integration (yes, the name means what it says). 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: Continuous Delivery (Amazon) Introduction to Scrum - 7 Minutes Kanban 101 - What is Kanban? Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 Software Estimation - Trading Perceived Effort For Outcomes 56:08
56:08 Play Later Play Later Lists Like Liked56:08
Play Later Play Later Lists Like LikedIt’s human nature that businesses have a desire for software estimation. For projects with a fixed scope, typical estimating methods can be off by as much as 70%. And that’s a product that doesn’t adapt to user needs. If you desire the economic growth that comes from building winning products for customers, the numbers will be even worse. The short of it? Don’t bother! Pick a budget for what you can afford each month, and let a qualified development team or consultancy tell you if they can build a minimum viable product (MVP) in 1/6th to 1/12th of that budget. This will produce your core theory of value and two delighting features early, with monthly budget left over to adapt to changes. If you find that the product needs to change spend some budget on those changes. If you find that the product needs to improve in quality, spend some budget on beefing up testing. Software projects don’t fail because the product couldn’t get built in time – they fail because they DON'T DELIVER VALUE high enough to justify the investment. To reach this high level of value means spending less time envisioning, and more time ADAPTING. The only way to do this is with a laser focus on the core theory of value, and a budget that will last through several feedback cycles. Any time a product owner/manager or non-technical person of any sort asks for an estimate, they create anxiety in those doing the work. Experienced technologists know the number of variables in software development is ridiculous, and systems that have been created so far to account for all possible outcomes fall far short of being helpful. Though we may need to estimate whether we can deliver the core theory of value within a time frame short enough to get feedback, ongoing estimation should be unnecessary if budgeting of software is done on a subscription-based, value-focused basis. Software businesses must ensure that insights about how the product is being used are recorded with every release of the product. Minimal change must be introduced each release, to allow for A/B testing to determine whether a change had the desired impact on business outcomes. How business outcomes are measured is specific to each business, but these must be determined and agreed upon BEFORE development of any feature that will impact them starts. The effort of a successful software project focuses on measuring whether each release is getting the business CLOSER TO AN OUTCOME, not closer to completing a FIXED SCOPE OF WORK! This paradox can be hard to wrap your head around, but it must be fully appreciated to operate in a truly lean fashion. Determine what you can spend per month, get started, and adapt… TRUST THE MARKET, not your ego! 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: Principles of Product Development Flow (Amazon) Visit me at thrivingtechnologist.com…
H
Healthy Developer
1 Agile Project Management - Is It STOPPING You From Being Agile? 15:48
15:48 Play Later Play Later Lists Like Liked15:48
Play Later Play Later Lists Like LikedCompanies can miss out if they don't have the right mindset for agile project management. If your team is pursuing agile practices but doesn't feel that the benefits to the company are delivering on the promised industry hype, this video will explain some of the reasons why that may be the case. I discuss how traditional project management techniques are often applied to software development projects, and the "agility theater" it can cause for teams. It's important for teams who are new to using agile development that executives, customers, and all other staff that work on the project understand the implications of the new approach. The most common misunderstanding I come across is a lack of appreciation for the trade off of agility (a positive effect) for predictability. If a company wishes to adapt to the changing needs of their customer and the market quickly - they must become comfortable with uncertainty, and LET GO of the illusion of control. Estimation specifically is an activity that can cause a great deal of confusion, wasted time, and unmet expectations when working on products that choose to have some form of Agile Project Management. I'll discuss this in more detail in a later video. Regardless of how far along the agile journey your company is, beginning to have the tough conversations with stakeholders about WHY we choose agility, and how treating projects like a traditional work effort such as constructing a physical building doesn't apply, can be the breakthrough you might need in becoming a lean organization. During this video, I also briefly mention a traditional software project management tool known as Gantt charts - which I believe are practically USELESS on agile teams. The number of times a project goes according to the chart is practically zero. I'm sorry to report that over the past 17 years of my career (since agile development was introduced) - teams that are held to Gantt charts can easily fall prey to "faking" deliverables as being done just to make it look like they hit their schedule! You can also watch this episode on YouTube . 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…
H
Healthy Developer
1 Minimum Viable Product - Letting Software Customers Help YOU Profit 30:31
30:31 Play Later Play Later Lists Like Liked30:31
Play Later Play Later Lists Like LikedWhether producing a software product for a new market in a startup, or introducing a major change in an enterprise - planning a minimum viable product is a good idea. When building a minimum viable product (MVP), you should select a feature that shows users your core value proposition, as well as two features that "delight". The core value proposition is a part of the Business Model Canvas, a visual tool created by Alex Osterwalder that you can use to determine which aspect of the business is being effected by a change. The "delighting" features provide something sexy for users that attracts potential customers due to it's sleekness, innovation, or ease of use. When planning what goes into an MVP, don't budget for only the MVP. Budget for enough to build software for 6-12 months that will adapt to feedback. Spend a small portion of the total budget to release the MVP, and use the majority of the remaining budget to adapt so you can deliver exactly what customers want - and in the way they want to buy it. These other "ways" than the product's features itself are the other aspects of the business model canvas. If you only budget enough for the MVP, you won't have money left over to adapt. Adaptation is the difference between a product that "meets needs" and one that "exceeds expectations". It is this latter category of products that cause companies to be leaders in their market and cause substantial growth. When selecting technologies for the MVP, don't box yourself into feeling you need to use technologies already familiar to the development resources you might have. Hiring a specialist in a technology that is faster to build prototypes and minimal products in can save substantial money. Should the market lead you to find that what you've built is successful, you can always change the technology used down the road to meet scaling challenges, if the original technology can't handle the volume. This is a GOOD problem to have, and means you've found a large user base - but until this happens, don't spend the time and money planning for it! You need as much budget as possible to simply ADAPT at first, and so your money is better spent with excess funds for adaptation than building out an infrastructure or technology stack that assumes a size of user base you don't yet have. You can also watch this episode on YouTube . 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…
H
Healthy Developer
1 Lean Software Development - It's About Uncertainty! 13:35
13:35 Play Later Play Later Lists Like Liked13:35
Play Later Play Later Lists Like LikedIn the first video in my series on Sustainable Software Development, I explain how Lean Software Development avoids a company becoming irrelevant in today’s shifting technology market. If you’re looking for the reason why lean software development can be the difference between software projects being fun and innovative, or grueling and underwhelming – this video will provide you with some guidance. I discuss how the software development industry has focused on agile software development methodologies like Scrum, DevOps, and Continuous Delivery but that these don’t get the results companies are looking for if not used with a lean mindset. I discuss the fact that working in the industry continues to be highly uncertain, and so we need strategies that deal with anxiety and reduce pressure to help us sustain our careers. I mention how the industry’s focus on technologies and process distracts us from value. A business must always be profitable, and without a focus on customer value and a culture of learning – you’re dead in the water. I don’t want to see passionate technologists and successful companies fall into the trap of thinking they only need to add features to a technology product or service to sustain profitability and innovation. Lean software development will ensure that the way teams work, and the way changes are rolled out to customers, puts the market in the driver’s seat to direct us where we’re headed. Developing software is more like steering a ship than building a skyscraper. We chart a direction to go, but we ASSUME that the winds will blow us off course. So we need to use tools and techniques that let us steer quickly. As I share strategies for sustainable software development on this channel, we will choose tools and techniques that allow us to adapt and respond gracefully as things change. You can also watch this episode on YouTube . 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…
Welcome to Player FM!
Player FM is scanning the web for high-quality podcasts for you to enjoy right now. It's the best podcast app and works on Android, iPhone, and the web. Signup to sync subscriptions across devices.
Daily Deals
Daily Deals
Similar to Healthy Developer
Call them changemakers. Call them rule breakers. We call them Redefiners. And in this provocative podcast, we explore how daring leaders from across industries and around the globe are redefining their organizations—and themselves—to create extraordinary impact in today’s rapidly changing world. In each episode, Russell Reynolds Associates Leadership Advisor Hoda Tahoun and former CEO Clarke Murphy host engaging, purposeful conversations with leaders in and out of the business world who shar ...
…
continue reading
Big tech is transforming every aspect of our world. But how, and at what cost? This season of Land of the Giants – The Disney Dilemma – focuses on Disney’s ability to weather the ups and downs of the business cycle and changing tastes and explores what has kept it successful for over 100 years. The entertainment giant has leveraged nostalgia and its intellectual property to build a beloved brand, but after an acquisition spree that included Marvel, Lucasfilm, and 20th Century Fox, can it sus ...
…
continue reading
Some Goodness is hosted by Richard Ellis, a seasoned sales leader passionate about inviting top business minds to share their wisdom. Each episode is only 15-20 minutes, perfect for your commute or workout.
…
continue reading
T
The Brutal Truth about Sales and Selling - We interview the world's best B2B Enterprise salespeople.
1
The Brutal Truth about Sales and Selling - We interview the world's best B2B Enterprise salespeople.
Brian Burns
11k279
No BS Allowed - Are you sick of empty suits telling you to work harder? - Learn about The Maverick Selling Method, which models the world's best salespeople and what they do differently. If you are in sales and are passionate about selling, you will like this podcast. The focus is on b2b sales and selling. If you are selling or in sales, this podcast is for you. I cover cold calling, spin selling, challenger sale, solution selling, and advanced selling skills. Strategic selling, LinkedIn, sa ...
…
continue reading
T
The Influence Factor by The Influencer Marketing Factory
1
The Influence Factor by The Influencer Marketing Factory
The Influencer Marketing Factory
37k130
Alessandro Bogliari, CEO and Co-Founder of The Influencer Marketing Factory, a global influencer marketing agency, talks with great guests about influencer marketing, social media, the creator economy, social commerce and much more.
…
continue reading
It didn’t all change in March 2020. Not really. The UK high street has been in the throes of a gradual revolution for decades. From the rise of ecommerce, to the birth of mobile, social commerce, and a growing emphasis on experience, change has been underway for a while. In fact for many, the pandemic has acted as a wake-up call. Digital transformation was no longer a ‘nice to have’ but a matter of survival. Necessity sparked innovation and customers are enjoying more flexibility and conveni ...
…
continue reading
Rachel Cooke is your guide to leadership and communication, helping you craft a workplace environment you can feel good about. She’ll share tips to help you balance your work and personal life, effectively invest your time, and be mindful about where you’re devoting your energy. Let Rachel help you navigate your path to success—however you define it.
…
continue reading
The fun email marketing podcast. Sell more of your online courses, grow your membership and bring in more coaching clients with email marketing that doesn't stink. Sound good? Then join your fellow Email Marketing Heroes for your weekly dose of fun, practical, yet brutally honest email marketing advice. You can listen in to a piping hot, fresh episode every 'Email Marketing Wednesday' or if you prefer learning with your eyes instead of your ears, we turn each episode into a full written blog ...
…
continue reading
Hosted by productivity strategist Mike Vardy, A Productive Conversation offers insightful discussions on how to craft a life that aligns with your intentions. Each episode dives into the art of time devotion, productiveness, and refining your approach to daily living. Mike invites guests who are thinkers, doers, and creators to share their strategies for working smarter and living more intentionally. From practical tips to deep dives on mindset shifts, this podcast will help you reframe your ...
…
continue reading
Career Tools is a weekly podcast focused on specific actions you can take to grow and enhance your career, whether you are a manager or not. Career Tools won the Podcast Awards Best Business podcast in 2010 and was nominated every other year it has been eligible. Whether you are interested in jump-starting a stalled career, or sharpening your edge, Career Tools is the podcast for you. Go to http://www.manager-tools.com/testimonials to read what others are saying about the impact Career Tools ...
…
continue reading
Player FM - Podcast App
Go offline with the Player FM app!
Go offline with the Player FM app!
