Healthy Developer

Are 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

Are 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

Today 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

Are 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

Are 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

Are 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

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

Companies 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

To 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

As 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