Created with Sketch.
Healthy Software Developer
51 minutes | Jun 6, 2019
My Recovery From Programmer Anger
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! You can also watch this episode on YouTube. Related resources: Are You A Perfectionist Programmer? The De-Corporatization Of Jayme Software Project Stories (Playlist) Is It Safe To Make Mistakes On Your Software Project? Colin Zera - Sister (Home Acoustic Video) My Software Developer Career Journey (Playlist) Why Do So Many Programmers Lose Hope? Can You Be Agile When Your Company Isn't? What MEN Need To Know About Software Developer BRO CULTURE! Why Do Some Programmers Never Agree? Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards
85 minutes | Mar 15, 2019
Scott Nimrod on Personal Reputation vs Teamwork
Scott Nimrod is an experienced Software Consultant based out of Miami who specializes in Test Automation, WPF, Functional Programming, and a variety of other technologies. In this interview, Scott and I discuss the balance between strengthening your reputation through your personal brand as a developer, and the teamwork necessary to be successful in your career. We also touch on concepts in the interview with Woody Zuill about mob programming and the "noestimates" movement. Scott also runs a YouTube channel with great interviews and live programming exercises. You can also watch this episode on YouTube. Related resources: Woody Zuill on Mob Programming and Influencing Change How Agile Teams Grow Toxic! Ep. 4 Commitments Scott Nimrod on Consulting and Software Craftsmanship How to Disagree With Your Manager Respectfully How Agile Teams Grow Toxic! Ep. 3 Forecasting Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards
68 minutes | Mar 12, 2019
Woody Zuill on Mob Programming and Influencing Change
Today I have a special guest, Woody Zuill, who's one of the leading voices 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. Follow Woody on twitter at https://twitter.com/woodyzuill. Watch the video and access resources related to this episode on my website: https://bit.ly/2RQLOeB
25 minutes | Mar 8, 2019
How Agile Teams Grow Toxic! Ep. 4 Commitments
Does it ever feel like you'd get so much more done if it weren't for how much work people have you do to make commitments? Today I'd like to help you understand whether the development team you're on is using commitments in a way that makes sense, or will stress people out and put the software project at risk! Since most teams I have worked with aren't really agile, I'm concentrating on helping you understand the risks with commitments between the wrong people which often happens in "traditional" software development companies. Whether your a programmer, in UX, or maybe operations - commitments that are too strict, or too unrealistic, put your job and the success of the project in danger. First I will teach you some insights I've learned about how commitments can cause agile teams to grow toxic. Afterwards, I'll give you some actionable tips on what you can do to cope with traditional (non-agile) teams that require unrealistic commitments. I hope this information helps you select the best project for your career, or if you're on an unhealthy team - protect yourself so you have the best chance of being successful! You can also watch this episode on YouTube. Related resources: The Secret of Scrum Nobody Talks About An Agile Budget Keeps You From Being A Code Monkey What REALLY Gets Software Developers Promoted? How Agile Teams Grow Toxic! Ep. 3 Forecasting Why Do So Many Programmers Lose Hope? Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards
13 minutes | Mar 5, 2019
Response to Comments on "Sprint Planning is Bullshit!"
Over the weekend I posted a video clip from episode 3 of my series on this channel "How Agile Teams Grow Toxic!" to reddit. The full video is about how teams can become unhealthy due to how % complete forecasting is done on most projects. In the clip I posted, I spoke specifically about the unpredictability of our work as software developers. There were over 100 comments on reddit alone with some other great ones here on the channel. In this video, I respond to several of these comments to provide further clarification on the concepts of healthy software development. I'm going to do a future video called "My Software Development Philosophy" in which I'll go into many of the things I touch on in the response in more detail. But for now, I hope you enjoy the responses. If you don't agree, let me know why! If you do agree, how can we get this information out to more people? You can also watch this episode on YouTube. Related resources: How Agile Teams Grow Toxic! Ep. 3 Forecasting Is It Safe To Make Mistakes On Your Software Project? Iain Lowe - Healthy Developer Interview #2 Spot A Fake Agile Team In Under 7 Minutes! Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards
13 minutes | Mar 1, 2019
3 Embarrassing Software Developer Stories From My Career
With all the challenges in the software industry with languages, frameworks, and processes... It's easy to forget we're human. I've been making some really serious level 301 agile nerdgasm content lately, so I made this episode to just have some fun. Here are three stories of times I was embarrassed in my software development career. 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
18 minutes | Feb 21, 2019
How Agile Teams Grow Toxic! Ep. 3 Forecasting
Deadlines! "Drop dead" dates! Changing the schedule to meet "new requirements"! Do you ever think there's gotta be a better way to do this? Well there is, and today I want to share with you some information about a topic that often bores software developers... But in my experience of working with many teams and companies, when developers are frustrated on their project - it is this topic that's often the culprit. In this video I discuss how people who pay for software development projects forecast. Before you bail, if you hang with me on this video you'll know more than many agile coaches and product managers about why investing in software projects is unique! I'll share the dangers of traditional forecasting on software projects - and an alternative way to give investors confidence. You can also watch this episode on YouTube. Related resources: An Agile Budget Keeps You From Being A Code Monkey Eric Ries: The Lean Startup | Talks At Google Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards
25 minutes | Feb 17, 2019
How Agile Teams Grow Toxic! Ep. 2 Hiring Talent
Be careful not to mirror the person interviewing you too much for your next software development job!
14 minutes | Feb 11, 2019
How Agile Teams Grow Toxic! Ep. 1 Founder Values
The core motivating value of the company's founders shouldn't be ignored when you join a software project.
20 minutes | Feb 8, 2019
I Quit My Software Project To Get Healthy!
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? You can also watch this episode on YouTube. Related resources: The ModernAgile YouTube channel Spot a Fake Agile Team in Under 7 Minutes! Why Do Some Programmers Never Agree? New Software Project? Earn Respect From Your Team! Are Developers Being Misled About DevOps? Lead Software Developers Better By Letting Go! Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards
12 minutes | Jul 16, 2018
Scrum Got 3 People Fired From A Software Project!
Over my career I've seen many software projects fail spectacularly due to political infighting between team members. Blame-shifting and improper application of scrum got people fired on this one! I prefer a simple definition of politics: when people tell each other what they want to hear instead of the truth. I'd like to share the story of a software project I worked on, where the client was a non-profit company with a big budget. They wanted to redesign a major application used to help struggling educational institutions. But the staff were inexperienced with agile. And multiple contractors on the project were fighting. In this episode, I share how inexperience with software development processes can actually get people fired. Especially when there's politics. You can also watch this episode on YouTube. Related resources: Are User Stories Making Your Project Late? Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards
9 minutes | Jul 13, 2018
How To Get Support To Fix A "Disruptive" Problem
Ever had to get the team to STOP to fix a problem?
14 minutes | Jul 9, 2018
They Watched Us With Webcams And Rewrote Our Code!
The story of a consulting project where the client's founders reacted surprisingly to our advice. 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
11 minutes | Jul 6, 2018
Lead Software Developers Better By Letting Go!
Over the years I've had to lead many software developers, and it's become much easier since letting go of being seen as "the expert". Even if I’m only leading a few people there’s always too much work and I have to choose really carefully what I do. If you’ve watched any of my other videos you know I’m a big fan of teams where there’s less management. But whether someone is officially recognized as a “lead developer” or not, most teams usually have people on them who are more experienced. And people naturally seem to take ownership for areas of the product they’re most interested in and can start being seen as a leader around that idea. Maybe that’s you, or maybe you’re considering stepping into a role where you’ll be leading developers to do something with the software. In my career I’ve found it’s really easy to get overwhelmed when I’m leading other developers. Meeting with the business, supporting developers, and still trying to get work done on the product myself can feel impossible. You’ve probably heard the saying “give someone a fish, feed them for a day. Teach someone to fish feed them for a lifetime”. But even though I know this, it can be hard to let other developers do more to help you if it’s going to take longer than just doing it yourself. In this video, I share how I’ve had more time to support my team when I let other developers have more responsibility, and you can too. You can also watch this episode on YouTube. Related resources: Is It Safe To Make Mistakes On Your Software Project? Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards
8 minutes | Jun 25, 2018
It’s Hard To Keep A New Team Doing Continuous Delivery
Sometimes I get an opportunity to show a team how to use a technology that not only solves a business problem, but I really like! In this case it was continuous delivery to deploy business intelligence dashboards to production. When a client of mine was burned by a prior vendor that couldn't deliver their software project, they needed to see progress made quickly. The software product was supposed to be a set of complicated visual dashboards that pulled in data from a bunch of different healthcare systems. At the time deploying these types of software systems was a manual, error prone process. So I had built a framework to automate releases. This would help us follow continuous delivery. But the lead on the project was resistant at first, and the client wasn't sure they were ready. In this episode, I share how the continuous delivery framework I used earned trust at first...but was eventually abandoned. I still had many things to learn about how to support my own software frameworks! 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
11 minutes | Jun 22, 2018
How To Stop Comparing Your Career To Other Developers
Stay calm while people around you jockey for money, fame - and other people's dreams...
45 minutes | Jun 18, 2018
John Cutler on Agile Skepticism and Making an Impact
John Cutler is a brilliant product manager who joins me as a special guest to discuss agile's controversial position in the market, and developer soft skills.
7 minutes | Jun 15, 2018
Can User Stories Make Your Software Project Late?
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!! 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
8 minutes | Jun 11, 2018
We Were Hired For A Hidden Agenda
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! 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
8 minutes | Jun 8, 2018
Is Your Team Really Measuring Software Projects Correctly?
Sure, progress seems like an innocent thing to measure. *rolls eyes*
Terms of Service
Do Not Sell My Personal Information
© Stitcher 2021