Healthy Developer

It's bad enough when you're working on a software project and you run into a problem.

But it's even worse when you know that problem might block other people from getting work done!

It's always blown my mind how some managers try to keep everyone working as if nothing's wrong when this happens.

Software projects are getting more complicated every day and so it's easy to get to a point where you're blocked.

And I've been in the situation many times where I've had to explain a problem I'm having to my boss or managers.

But when the problem blocks other people, I've had bosses at times pretend there is no problem!

Especially if there's pressure, blocking multiple people to fix a problem can feel horrible for management – if they're focused on how much people are getting done.

I talked with you in another episode about how focusing on how much work a team gets done actually hurts how much money a product makes for your company.

So in this episode I want to help you get your manager or boss to support you when you need to make a change that will disrupt other people.

Join my Patreon: https://thrivingtechnologist.com/patreon

Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide: https://thrivingtechnologist.com/guide

You can also watch this episode on YouTube.

Visit me at thrivingtechnologist.com

One of the most frustrating software projects I've been on involved webcam spying and finding the people who hired us rewrote our code!

A large company that bought out two young entrepreneurs hired me and other consultants to help them.

But the entrepreneurs didn't really want help.

Soon it was apparent that they had no desire to listen to our advice, or treat our opinions as worth anything whatsoever!

In this story, I share how software developers can act irrationally when they are under fear of being shown something "they don't know".

Join my Patreon: https://thrivingtechnologist.com/patreon

Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide: https://thrivingtechnologist.com/guide

You can also watch this episode on YouTube.

Visit me at thrivingtechnologist.com

Over the years I've had to lead many software developers, and it's become much easier since letting go of being seen as "the expert". Even if I'm only leading a few people there's always too much work and I have to choose really carefully what I do.

If you've watched any of my other videos you know I'm a big fan of teams where there's less management. But whether someone is officially recognized as a "lead developer" or not, most teams usually have people on them who are more experienced. And people naturally seem to take ownership for areas of the product they're most interested in and can start being seen as a leader around that idea. Maybe that's you, or maybe you're considering stepping into a role where you'll be leading developers to do something with the software.

In my career I've found it's really easy to get overwhelmed when I'm leading other developers. Meeting with the business, supporting developers, and still trying to get work done on the product myself can feel impossible. You've probably heard the saying "give someone a fish, feed them for a day. Teach someone to fish feed them for a lifetime". But even though I know this, it can be hard to let other developers do more to help you if it's going to take longer than just doing it yourself.

In this video, I share how I've had more time to support my team when I let other developers have more responsibility, and you can too.

Join my Patreon: https://thrivingtechnologist.com/patreon

Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide: https://thrivingtechnologist.com/guide

You can also watch this episode on YouTube.

Visit me at thrivingtechnologist.com

Sometimes I get an opportunity to show a team how to use a technology that not only solves a business problem, but I really like! In this case it was continuous delivery to deploy business intelligence dashboards to production.

When a client of mine was burned by a prior vendor that couldn't deliver their software project, they needed to see progress made quickly. The software product was supposed to be a set of complicated visual dashboards that pulled in data from a bunch of different healthcare systems.

At the time deploying these types of software systems was a manual, error prone process. So I had built a framework to automate releases. This would help us follow continuous delivery.

But the lead on the project was resistant at first, and the client wasn't sure they were ready.

In this episode, I share how the continuous delivery framework I used earned trust at first...but was eventually abandoned. I still had many things to learn about how to support my own software frameworks!

Join my Patreon: https://thrivingtechnologist.com/patreon

Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide: https://thrivingtechnologist.com/guide

You can also watch this episode on YouTube.

Visit me at thrivingtechnologist.com

As you grow, it can be tempting to start comparing your career to other developers.

It's only natural that as you notice other people getting promotions, recognition, and opportunities to lead exciting efforts – you consider: "Would I like that too?"

But it's a slippery slope from discovering some new worthy goals to chasing someone else's!

In this episode I share some ways I've come to cope with many projects where I ask myself: "How do I feel when someone else gets recognized?"

Join my Patreon: https://thrivingtechnologist.com/patreon

Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide: https://thrivingtechnologist.com/guide

You can also watch this episode on YouTube.

Visit me at thrivingtechnologist.com

John Cutler is an experienced Product Manager, writer, and consultant.

You can read his many popular articles on Medium where he discusses a variety of topics related to software development in the hacker noon publication: https://hackernoon.com/@johnpcutler

In this video, John and I trade some thoughts around the perceived decline of agile in some areas of the industry.

We also discuss the challenges surrounding balancing making changes with accepting things as they are.

You can also find John on twitter here: https://twitter.com/johncutlefish

Join my Patreon: https://thrivingtechnologist.com/patreon

Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide: https://thrivingtechnologist.com/guide

You can also watch this episode on YouTube.

Visit me at thrivingtechnologist.com

Over my career I've seen more projects fail due to misuse of user stories than any other practice commonly used on agile teams.

You probably already know that user stories are just a simple format for writing requirements on scrum or kanban agile teams.

Today I want to help you avoid some bad advice I see out there about what user stories are and how they can help (or hurt) you.

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.

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.

If your stakeholders (product managers, customers etc.) are focused on cost, you are much better off creating detailed acceptance criteria that describes a user story in detail before you give out any estimates. Acceptance criteria reads like a test script and describes exactly how someone can use the software, or write an automated test, to verify it's done and works right.

If you don't have acceptance criteria, the rough estimate you give out for a user story will change. And every time it does, you'll lose trust with your stakeholders because you'll look like you estimated wrong.

So match the level of detail in your design and requirements on your project with your stakeholder's tolerance for uncertainty. If they are focused on costs, certainty, and predictable deadlines - writing only user stories and committing to estimates without acceptance criteria is foolish.

It's like committing to a waterfall project with 10% of the documentation necessary to really estimate it!!

Join my Patreon: https://thrivingtechnologist.com/patreon

Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide: https://thrivingtechnologist.com/guide

You can also watch this episode on YouTube.

Visit me at thrivingtechnologist.com

Ever been on a software development project where one team is putting pressure on another because of a hidden agenda?

I was once asked to investigate two teams that worked together to build a software product for doing taxes.

The first team contacted us and said they needed help with releasing software better. So I planned to use an interview I'd come up with over the years. It had questions I could ask people about how they work together. Things like how they gather requirements, test the software, and approve releases for example.

While interviewing the first team, it became clear that they did't like the second team. The second team wasn't following scrum, while the first team was. The first team was convinced the problem was with the second team.

However after interviewing many people on both teams, we realized the second team was following kanban. But they were doing it for a good reason - to respond to unpredictable changes in tax code.

So eventually we presented our findings, and though many people were pleased - our client was disappointed that we hadn't only found issues with the second team.

In this episode, I share the story of how I had to avoid being used as a pawn in corporate politics at my client. I hope it helps you avoid being put into a situation where you're pressured to side with a group of people to force another to change unwillingly!

Join my Patreon: https://thrivingtechnologist.com/patreon

Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide: https://thrivingtechnologist.com/guide

You can also watch this episode on YouTube.

Visit me at thrivingtechnologist.com

There's an old saying "you improve what you focus on, and you focus on what you measure".

There are just way too many software companies I run across focused on the wrong things – because they're measuring the wrong things.

In this episode, I'll show you how you can help your company make more money with the software you build by measuring the right things.

When your company makes more money, you'll get the opportunities and rewards you want.

Join my Patreon: https://thrivingtechnologist.com/patreon

Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide: https://thrivingtechnologist.com/guide

You can also watch this episode on YouTube.

Visit me at thrivingtechnologist.com

One of the most frustrating software projects I've been on was when we designed a product that never got built!

A couple different things happened on this project that made it difficult...

First, the project was being sold to use an agile process, but then was suddenly switched to fixed cost at the last minute.

Secondly, there were too many people in management positions. It created confusion where team members were getting conflicting instructions. The client was telling each manager different things!

And lastly the client had never designed a software product before. We tried to warn them to design a simpler product than their entire vision, but they wouldn't listen. Because they tried to design the product up front, they designed a product that was too complex for a first release.

Though we did what we could to keep the project on track, it ultimately was too expensive for them to build.

I hope this episode helps you avoid some of these mistakes on your software projects.

Join my Patreon: https://thrivingtechnologist.com/patreon

Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech: https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide: https://thrivingtechnologist.com/guide

You can also watch this episode on YouTube.

Visit me at thrivingtechnologist.com