Healthy Developer

If 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

If 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

It 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

Why 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

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

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

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

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

If 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

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