DEV Community: adegiamb

The "Internal Consultant" Framework: Engineering Your Career Sprint by Sprint

adegiamb — Wed, 25 Feb 2026 12:38:20 +0000

The Sprint as a Contract: Earning Your Next "Gig"

In a traditional job, you assume you’ll be there on Monday. In consulting, you’re only as good as your current engagement. Treat every two-week sprint as a fixed-term contract.

The Statement of Work (SOW): Your Sprint Backlog isn't just a list of chores; it’s a legal agreement of deliverables. If you miss a deadline without communication, you’ve "breached" the contract.
The "Rehire" Test: At the end of every sprint, ask yourself: If I had to pitch for the next two weeks of work based solely on my performance in the last two, would this "client" (my manager/PO) hire me?
Reliability is the Product: Consultants get rehired because they remove uncertainty. Be the person whose "In Progress" column never hides a surprise.

The Retro: Your Quarterly Business Review**

Most people use Retrospectives to vent or stay silent. Use them as a Strategic Feedback Loop to improve relationships:

Positive Feedback (The Value Add): Don’t just say "Good job, team." Frame it as a successful process. "Our new CI/CD pipeline reduced our deployment 'cost' by 20%." Proves you understand the impact of the items you are working on.
Improvement Feedback (The Gap Analysis): Frame friction as a business risk. Instead of "I hate these long meetings," try: "The current meeting structure is a bottleneck that reduces our engineering throughput."
Consultant’s Edge: Use the Retro to show you aren't just doing the work—you are optimizing the machine that produces the work.

The Self-Review: Mirror, Mirror

Honesty is the consultant’s greatest tool. If you were a CEO paying $200/hour for your own services, would you be satisfied?

The Consultant’s Audit:

Did I provide a solution, or just a list of problems?
Was my communication proactive, or did the client have to hunt me down?
Did I leave the codebase (the client's asset) better than I found it? If you wouldn't hire "you," it’s time to pivot your strategy.

Beyond the Code: The Relationship Equity

The biggest mistake "order-takers" make is thinking the code is the only deliverable. The code is the commodity; the relationship is the bridge to the next project.

Stakeholder Empathy: Understand what keeps your Product Owner up at night. Are they worried about a demo? A bug? A board meeting? Solving their stress is what gets you remembered.
The "Liking" Factor: People hire consultants they like and trust. Taking five minutes to understand a teammate’s workflow or offering to help a junior dev isn't "distraction"—it’s C*lient Success Management*.
Visibility: If you do great work but no one sees it, did it happen? Ensure your "client" understands the complexity you navigated and the value you delivered.

Summary Table: Employee vs. Consultant

Feature	The "Employee" Mindset	The "Consultant" Mindset
The Sprint	A cycle to get through.	A contract to be fulfilled.
Communication	Responds when asked.	Proactively manages expectations.
Feedback	Complains about blockers.	Proposes systemic optimizations.
Goals	Close the ticket.	Deliver value and build trust.

Legacy Without the Ego

adegiamb — Mon, 02 Feb 2026 01:23:44 +0000

Reviewing legacy code is often treated like a chore, but it’s actually a sign of success. If a codebase lives long enough to become "legacy," it means the product survived. As we navigate the layers of old logic to implement new features, our most excellent tool isn't a debugger—it’s empathy.

1. Evolution is Mandatory

Applications are living organisms. Feature requests, scaling needs, and market shifts mean that code which was perfect two years ago might be a bottleneck today. Reviewing legacy code isn’t an "extra" task; it is a fundamental part of the development lifecycle. When we revisit old features, we aren't just looking at "old stuff"—we are observing how the application has grown and where it needs to go next.

2. You Don’t Have the Full Picture

It is easy to be a critic with the benefit of hindsight. When you encounter a "hacky" solution, remember that you are looking at the result, not the process.

The Invisible Constraints: That "weird" logic might have been a hotfix for a critical production bug at 3:00 AM.
The Moving Target: The requirements might have changed many times during development.
The Human Element: The team member might have been a newbie and learning on the fly, or a senior dev juggling five different projects under a tight deadline.

3. The Prime Directive: Assume Excellence

Regardless of what you discover in the files, operate under the belief that the person who wrote that code did the best job they could. They worked with the information they had, the skills they possessed at the time, and the specific tools available to them.

When you assume the previous developer(s) did their best, your mindset shifts from blame to curiosity. Instead of asking, "Why did they do this so poorly?" you start asking, "What problem were they trying to solve that necessitated this approach?"

4. Git Blame is for Context, Not Conflict

The git blame command has an unfortunate name, but it shouldn't be used to find a target. Instead, use it as a bridge to tribal knowledge.

Identify Resources: Check if the author still works at the company. If they do, reach out with curiosity: "Hey, I'm working on the checkout logic you touched last year—do you remember if there was a specific reason we handled it this way?"
Find the "Why": Use the commit history to find the original Pull Request. Often, the discussion in that PR contains the specific business logic that explains the implementation.
Respect the Timeline: Seeing that a piece of code hasn't been touched in years tells you it’s stable, even if it’s not "pretty."

5. Move Forward with an Open Mind

The goal of a code review is improvement, not a trial. Once you understand the "why" behind the legacy logic, focus your energy on the "how" of the future.

Understand first, refactor second: Never delete what you don't fully understand.
Leave it better than you found it: You don't have to rewrite the whole module, function. You can make small, incremental cleanups to make it easier for the next developer to improve the code.
Document the context: When you update the code, leave a comment explaining why the change was made so the next person doesn't have to guess.

The Power of the Duo: Why Strategic Partnerships are the Secret to Resilient Teams

adegiamb — Mon, 12 Jan 2026 12:19:38 +0000

In the modern workplace, we most often focus on reducing the bus factor, but one-on-one partnerships/partner-in-crime can inspire leaders to see their role in nurturing resilient, high-performing teams.

1. The Tactical Advantage: Speed and Support

High-functioning partners develop a "short-hand." You don't need a 20-minute preamble; you can get straight to the "meat" of the problem because your partner already has the context.

The Ultimate Sounding Board: Test radical ideas in a safe space before presenting them to the broader group.
A Safety Net in Every Meeting: When a meeting gets heated, or you hit a technical wall, your partner steps in to provide context.

2. Real-World Resilience: When Life Happens

The real test of a partnership isn't when things are going well—it's when things get difficult. These two personal experiences illustrate how having a partner in crime can support you and affect your team/pod.

Case Study A: The Peer Proxy (Tech Lead + Tech Lead)

When I had to take sudden leave to help my mother with a health issue, I didn't even have to ask my partner—another Tech Lead—to help. He stepped in immediately. Because the team already viewed him as my "partner in crime," they trusted him implicitly. I could focus entirely on my family, knowing the team was on track, and my responsibilities were in the hands of capable people as capable as I was.

Case Study B: The Two-Year Anchor (Developer + PM)

A long-term family crisis tested this partnership. My father was ill for two years, and during that time, my PM was my rock. Our partnership survived a year-long gap while she was on maternity leave; once she returned, the partnership hadn't aged a day.
Two moments stand out that defined this partnership:

The Meeting Shield: During a particularly diffcult time, I had a brief breakdown in a meeting. Without missing a beat, she took over the discussion and moved the agenda forward, giving me the space to collect myself and rejoin when I was ready.
The Advocate: She helped me raise my situation to my manager and the POD to ensure I got the full support and flexibility I needed to balance work and family.

3. Developers are Partners, Not "Minions"

The most successful pods I’ve seen are built on shared ownership, which fosters a sense of value and commitment among developers and leaders alike.

Example 1: The "Minion" Model (Command and Control)

I once sat in a meeting where a Product Manager said, "Remember, developers, you work for me, so make sure everything comes through me." The moment that was said, the air left the room.

Item	Description
Friction skyrocketed	It became an "us vs. them" dynamic.
The Dictatorship Feel	Meetings became heated and defensive.
The Blame Game	hen things went wrong, *finger-pointing occurred immediately.* Because there was no shared ownership, everyone looked for someone else to blame to protect themselves.
Chaos by Proxy	Last-minute requests became the norm, often arriving without any detail or "why."

Example 2: The "Partner" Model (Co-Creation)

Twice in my career, I’ve seen the opposite. When the product team treats developers as equals from day one, they adopt a powerful mantra: "We rise and fall as one."

Item	Description
Safe Discussions	Conversations are easy and focused on the issue, not titles.
Full Ownership	The team feels like they are part of the solution, not just the code. When things go wrong, they fix it together instead of looking for someone to blame.
Proactive Support	Team members jump in to create tickets or action items for each other.
The "Fun" Factor	The team is actually having fun because they aren't just working—they are winning together.

Comparing the Two Worlds

Feature	The "Minion" Model	The "Partner" Model
The Mindset	"You work for me."	"We rise and fall as one."
When things fail	Finger-pointing and blame.	Shared fixing and learning.
Communication	Top-down and filtered.	Equal, safe, and open.
Personal Crisis	Seen as a "blocker."	Met with advocacy and "taking the mic."
Longevity	Trust is fragile; high turnover.	Survives leaves and long-term challenges.

4. A Note to Leadership: Embrace the Duo

There is sometimes a management instinct to rotate people frequently to "prevent silos." However, breaking up a high-performing partnership is often a strategic mistake.

Item	Description
Trust is Faster than Process	Partners move quicker.
Institutional Knowledge	Partners act as two keepers of the flame, reducing the risk of knowledge loss.
Retention	People don't leave jobs; they leave people. When employees feel supported by a partner during life's hardest moments, their loyalty to the organization triples.

5. Your Challenge: Who is your "Partner in Crime"?

Partnerships don't just happen; they are built through trust and shared wins. To foster this, consider observing which team members naturally collaborate and support each other, helping you identify existing or potential strategic alliances within your pod.

Who is my sounding board?
Who has my back in a meeting if I need to step away?
Am I treating my cross-functional peers as equals or minions?

The Bottom Line: Don’t fear the duo. When two people find a rhythm that survives two years of life's challenges, the entire organization becomes more resilient, more efficient, and more human.

You’re Not Alone — You Have an Army

adegiamb — Thu, 16 Oct 2025 00:59:43 +0000

Stop carrying the world on your shoulders. You don’t have to.

Too many people believe everything rests on their shoulders. They carry the weight of deadlines, deliverables, and expectations as if asking for help is a sign of weakness.

That mindset is wrong — and unsustainable.

When you feel pressure, look up. Your leads and managers understand the same stress, often multiplied. They’re not there to judge; they’re there to support and help you navigate it. Talk to them. Share what’s heavy, causing the stress.
Great organizations move forward because people use their levers — teammates, leaders, and tools that lighten the load.

Try First, Then Ask

Before reaching out for help, spend focused time working through the problem. Write down:

What the issue is
What you’ve already tried
What’s blocking you
What do you think might help

This prep sharpens your understanding and helps others support you more effectively. It shows initiative and makes collaboration smoother.

Do a Rubber Ducky Session

Sometimes, you don’t need an immediate answer — you need clarity.
The “rubber ducky” method is simple: explain your problem out loud as if you’re teaching it to someone (or something). It could be an actual rubber duck (mine is a Yoshi stuffed toy my nephew got me), your notes app, or a teammate willing to listen.

Walking through the issue forces you to slow down, organize your thoughts, and often reveals the solution to you.

Better yet, talk it out with a colleague. Saying things out loud — and having someone reflect or ask a few simple questions — often uncovers what’s missing. It’s not about someone solving it for you, but helping you see it differently.

Bring in the Army

When challenges get big, remember — no one wins a battle alone. An army succeeds because everyone knows their role and works together toward a shared goal.
Your team army works the same way:

Your immediate team is the front line. They move fast, share knowledge, and adapt together when things shift.
SMEs (Subject Matter Experts) are your specialists — the engineers, analysts, or experts who step in when precision matters most.
Leadership acts like your command unit — setting strategy, clearing roadblocks, and securing the resources needed to win.
Cross-functional partners are the support divisions that strengthen your position — offering fresh perspectives, connecting systems, and helping align the bigger picture.

An army wins by coordinating — by communicating clearly, sharing intel, and trusting each other’s strengths. The same is true for your team.

You don’t need to handle every problem alone — you need to know which unit to call in, and when.

Final Thought

You’re not alone. You have teammates, leaders, tools, and experts — an entire army ready to move with you.

Use them. That’s how real progress happens.

Remember

When the pressure builds, don’t isolate — activate your army. Together, we move faster, stronger, and smarter.

Dropping database column and Microservices

adegiamb — Tue, 22 Jul 2025 02:48:43 +0000

Most of the time, you don't think a lot about making database changes, but when dropping a column, some serious effects on your application can happen if not handled carefully.

As you see in the diagram below, when you deploy a new version of your service with a drop column migration, you have a race condition of the existing micro service (v1) may try to access the column that was removed, causing:

Existing deploy micro service to crash.
Random errors to appear in logging.
Alerts to be raised if you have monitoring in place.

Use a Multi-step Deployment Strategy

Step 1: Deploy New API Version v2

A version of your service that doesn't access the database column you want to drop

Step2: Keep Old Column but Stop Using It

Leave the column in the database. This will ensure that the existing version (V1) does not encounter an issue if it continues to attempt to access the database column.

Step 3: Wait Period for confirmation of no side effects

Leave the column you want to remove in production for a short time to verify that everything is working fine. Usually, a week or two is more than enough.

Step 4: Drop Column via separate Migration

Create a new deployment that should only contain a migration script that drops the unused column.

Optional 1: Ensure All Services Use v2 or greater of the API

Before deploying to production, confirm that all running versions contain your previous changes to remove access to the field you want to drop.

Optional 2: Run DB Backup + Validate Logs

Depending on your environment's setup, you should create a database backup before dropping the column.

note: In most cases, if you leave the column in production for a week, dropping should be fine. But as the saying goes, it's better to be safe than sorry.

Safe Deployment: No Crashes, Clean DB

Now that you know that all running services don't access the column, you can safely deploy the migration to drop the column without worrying about causing an outage.

Mermaid code

Below is the mermaid code to generate the diagram above

graph TD

%% Problem Path
A[Deploy New API Version + Drop Column in Same Release] --> B[Race Condition: Some Services Still Use Old Column]
B --> C[App Crashes / Data Access Errors]

%% Solution Path
A -. Best Practice .-> Best1[Step 1: Deploy New API Version v2]
Best1 --> Best2[Step 2: Keep Old Column but Stop Using It]
Best2 --> Best3[Step 3: Wait Period for confirm no side effects]
Best3 --> Best4[Step 4: Drop Column via sperate Migration]

%% Optional Checks
Best4 --> BestOptional1[Ensure All Services Use v2 API]
BestOptional1 --> BestOptional2[Run DB Backup + Validate Logs]

%% Final State
BestOptional2 --> Z[✅ Safe Deployment: No Crashes, Clean DB]

style A fill:#fb9902,stroke:#c00,stroke-width:2px
style C fill:#f66,stroke
style Z fill:#099,stroke

You Are Important

adegiamb — Mon, 31 Mar 2025 01:55:02 +0000

We sometimes forget that we are as important as or more important than the projects we work on.

Doing overtime or prioritizing work for a short period is okay, but when it becomes the norm, it becomes a problem.

Signs of Overworking

When I am mentoring other team members, here are some signs I tell them to look out for:

You are working through your lunches.
Every night, you work a bit late.
Your sleep routine changes.
You cancel or do not attend events in your personal life.
You stop doing your hobbies.
At work, your fuse is getting short with team members.
You are saying to yourself, "If I don't do this, I will block other team members, or the project will be late."
Your stress and anxiety are higher than usual.

If you start noticing the impact of overworking, you must raise this to your lead or manager and see how to bring things back to normal.

You need to figure out what options exist:

Can other team members support you?
Confirm your tasks' priorities and ensure you are working on the correct ones.
Can the deadline change, or what is included?
If overworking is a pattern, raise it in a retro and keep the task accountable.

Gauges

You need to find some gauges you can watch to see if you are making work more vital than yourself.

You should check them often. I usually do mine at the end of each week, and if they seem to be trending toward overwork, I check them more often until they are back to normal.

Gauges are unique for each person, but here are some of mine:

Work interferes with me spending time with my niece and nephew. This is a hard stop for me to do a reset.
I make work an excuse for not going on a hike.
I can not do my woodworking.

Prioritization yourself

This section will most likely not resonate with some leaders and management. But you must always put your mental and physical health before what you are working on.

If not, it will impact your work.

Understand your role and IDP

Over the years, I was put into poorly defined roles and was not aligned with my direct manager, which caused tension between us.

You need to work on defining and aligning the role as soon as possible to ensure that your work aligns with it since this impacts your day-to-day IDP and promotions differently.

Once you have the role clearly aligned, work on your IDP (independent Development Plan) and make sure:

Understand how items are measured.
Where you are currently in each section in your IDP.
What is needed to get to the next level?
What are the timelines to get a promotion, and are you aligned?

One-on-Ones

One-on-one meetings are for you and the lead/manager to focus on items related to you, not project updates. That is what standups are for.

If project updates are asked in your one-on-ones, ask to do it at the end if time remains or book another meeting.

When I was a lead, I made sure I outlined that we should discuss:

What went well, and what needs to be improved?
Any crucial topics you want to raise.
Any feedback to give or given from others.
Review your IDP (this may not happen all one-on-one but should try to be every other).

Raising Concerns

If you face issues or concerns and can not resolve them, raise them for support. Do not set on them and let them grow; there is a high chance someone else is facing the same concern.

If you have to provide some details that another team member provided, ask permission to speak on their behalf since they may not be comfortable sharing, and you don't want to lose their trust.

Good Days vs Bad Days

No job or role is perfect, and you will always have some bad days. However, when your bad days start outweighing your good ones, it can be a sign that you must begin reviewing and prioritizing yourself.

Some techniques I use to help me understand how I feel about the role:

Outline what I enjoy doing.
Outline what items I am not enjoying.
What is not rubbing me the right way in general (company, projects, interaction)
Do I see a path of items not enjoying being fixed?
Reach out to someone I trust and get their input.

Self Care

Here are some items I do for self-care to make sure I am prioritizing myself:

I booked a meeting at lunchtime that auto-declined. Everyone needs to have lunch and a mental break. If the meeting is that important, I will let the organizer DM me the context and see if I can give up my lunch.
If I do overtime through the week here and there. I will end my week earlier.
I disable notifications after work hours. However, if there are trusted team members, I will add them to the expectation list (e.g., Slack VIP).

Support is missing

When you work for a company for an extended period of time, things can get a bit clouded due to friendships and feeling comfortable.

However, if most of the items on the list are happening, it can be a sign that the current environment is not for you:

When you wake up and dread going to work.
Going to work because of just friendships.
You are not learning anymore.
Your role and IDP are not set, and the path to get a pay raise or promotion keeps changing.
You are promised clarity on items, but they never happen, or the timeline changes often.
You raise concerns multiple times, and nothing is happening to improve them.
Working at 125% is the norm.
Your physical and mental health are getting impacted.

Conclusion

Remember, you are more important than the project, and prioritize your mental and physical health.

A quote I often use is, "Is someone going to die if this is not done today?" 99% of the time, the answer is "no."

Meaning that the work can wait until tomorrow. :)

Happy deving.

Importance of Communication

adegiamb — Thu, 13 Mar 2025 02:23:04 +0000

In general, people think communication relates to when writing or having a discussion; however, it is more than that:

Priorities and deadlines.
Meetings
Requirements
Disagreements between team members

Priorities and Deadlines

When a team or even an individual has a clear understanding of priorities and deadlines, it lets them:

Work on the most essential items for the Business.
They can move to the next item without input when completed or blocked.
The team will know what is next on the action list when leadership is unavailable.
Ignore and escalate work that is not part of the priority or deadline.

Unclear Priorities

When priorities are unclear or change often, this can cause stress for teams or individuals. There is a high chance that deadlines will be missed and extended.

If every request is considered highest, important, or business-critical, it will dilute the importance of having priorities. Team members will start ignoring priorities and working on items they enjoy more.

Having a definition of priorities across the organization will make sure everyone is aligned.

P1 (Critical): These are your “drop everything” tasks. They are urgent and vital, often involving crisis management or critical deadlines.

Customers having difficulty accessing the system(s).
E-commerce site and can not check items.
To on-board a new client, we need to support XYZ.

P2 (High): Important tasks that are not immediately urgent. These often contribute significantly to long-term goals.

A new line of Business.
Improving the overall system to support future growth.
3rd party integration.

P3 (Medium): Tasks that are urgent but less important. They require attention but do not contribute as much to overall objectives.

Improvement of user experience (internal and external).
New feature(s) that bring some value.

P4 (Low): Neither urgent nor highly important. These tasks should be done but can be scheduled for later.

Improving logging or metadata for troubleshooting

P5 (Lowest): Tasks with minimal impact that can be eliminated if necessary.

Minor UI improvements (colour, spacing, spelling errors)

Missing the deadline

Most people get nervous that they will not make a deadline and try to do anything, not raise it until the due date. It is usually due to the fear of getting into trouble, feeling inadequate to do the task, or thinking people will judge.

However, waiting until the due date causes many issues:

Putting your Lead, PO, and manager in a bad spot with the Business.
It also reduces the options they can offer. This causes other team members or teams to miss their deadlines.
We lost the chance for team members to support you
A loss of trust can occur between team members.

However, if they raise the risk sooner:

The team lead, PO, and manager have more options to use.
Team members can help jump on and support each other.
Other priorities can be adjusted.
Credibility begins to build.

Do not just raise, "I am not going to make the deadline." Provide context into why:

What is the current status of the tasks?
What is causing the doubt that the deadline is not achievable?
What support is needed?

Moving Deadlines

We all know the deadlines can move, but if all initial deadlines are unrealistic or move multiple times, teams will start not trusting them and assume they will change. Leadership can be in a bad spot when the deadline can not be moved (i.e., Father/mother's Day).

Here are some examples of sources that can cause deadlines to move.

The Business does not clearly understand what it wants/needs.
The Discovery phase is short or is happening at the same time the implementation is happening.
Making decisions takes too long or too many chiefs in the kitchen.
Business and management not listening to SME estimates. The estimates should still be challenged and understood.
Ownership is not clear.

Meetings

As we know, meetings can be helpful or a waste of time depending on their size and organization. (I will not go into this here but in a future posting)

However, how people communicate in the meeting will affect the effectiveness of the meeting.

The way people act and communicate can make a big difference.

Seen meetings that went sideways:

Individuals were rude and disrespectful.
Screaming and shooting.
Naming calling.
Taking over the meeting and making people feel dumb.
Meetings are not safe space

For example, I was in a meeting when 2 or 3 individuals presented possible solutions to a business problem. However, one of the team members attending the meeting disagreed with the solution:

This is not how we present it here. You should have presented it like this.
Why is it like this? It does not make a scene. The team member didn't read the supporting documentation like others, and the presenter had to do it during the meeting.
Said, "I do not care about the deadlines. We should do it like this".

The outcome of the meeting was not a pretty one:

It was a waste of time for everyone on the call since, most of the time, 1 team member derailed the meeting.
Moving forward with a solution did not happen.
Team members became uncomfortable attending meetings with that team member. They felt they would be attacked and felt unsafe raising thoughts and ideas.

However, when attending positive meetings:

Everyone feels safe and can speak freely.
Working on a common goal.
Open discussions can happen.
Everyone is equal; roles and tiles don't matter.

For example, our CTO raised a production issue and needed people to join a war room. A handful of team members jumped on the call. He outlined our issue and then said, "What does everything think the issue is, and how can I support you?". What happened next:

One team member managed the meeting.
SMEs discuss the possible issues and remove unknowns.
Determine a temporary solution to allow us time to implement a proper solution.
We gave tasks even to our CTO.

The meeting's outcome was that the solution was resolved, and trust was built between team members (side-by-side and upper management).

Future meetings with the same team members were more manageable because we knew they would be in a space where everyone was at the same level and focused on one goal.

It is an effort to create a safe space culture, but it takes one bad meeting to break the trust. It is everyone's responsibility to protect it; if people see team member(s) breaking that culture, fix it instantly or you take the risk of losing it and have to rebuild it.

Requirements (Discovery Phase)

In a competitive world, every company wants to be the first to market, which is understandable. However, if the discovery phase is rushed, skipped, or even happening during the implementation, a pattern will occur:

Frustration: Different departments will be frustrated with each other. Usually, the Product team suffers the most because they get caught in a cycle where some details are shared with engineering, new questions are raised, and the cycle is repeated.

Lost of trust: Team members will start getting the impression that others are incapable of their role.

Implementation of incorrect solution: Since the requirements are changing, it can be challenging to implement a solution that will scale with future changes, as past decisions limit options.

Deadlines missed: Since the entire project is not understood, constant changes and new requirements/features are added, making it hard to define clear milestones.

Everyone wants to start on the new idea that the Business wants, but do not jump the gun. Invest in understanding the idea's short-, medium-, and long-term vision will:

Create clear milestones.
Help organize the discovery sessions.
Informed decisions on solutions.
Reduce the frustration between different business units.
Reduce the back and forth and rework between milestones.

A former VP made us think: Imagine this is the last $25,000 we have to spend. Do we have everything that is needed to be successful?

Disagreements/misunderstandings between team members

From time to time, disagreements and misunderstandings will occur between team members. If this happens, the team member who thinks a misunderstanding occurred should offer an olive branch and resolve the misunderstanding.

I will use an example that occurred to me. I was working on a new part of the system, proposed a solution, and recommended including certain team members to review it.

One of my team members left a message: "How many times do we need to repeat this? It breaks stuff for us. Stop trying to use this."

It was surprising and confusing to see that comment. So I had a meeting with that developer the next day, and before going into the topic, I asked for clarity on his feedback, but there was a total misunderstanding.

My co-worker took a moment to review the comment, and he realized how I misunderstood it and why I was uncomfortable in the current meeting.

The comment was directed to another person on the document who knew this was impossible but didn't inform me.

He was frustrated because a different department kept trying to sneak it in, and I got caught in the crossfire.

He apologized and took ownership of the misunderstanding. We both aligned that everyone was cleared up.

After this, we set up a 1:1 every three weeks to see how we can improve communication between the two different streams we work on.

We have a good partnership. We lean on each other if we have questions and know we can help each other.

However, sometimes, this is possible, and if there are disagreements, you may need to be a third party to help clear the water. That is okay, too, but you make sure that both sides are heard. A meeting does occur with everyone to make sure everyone is on the same page.

Also, it is possible that some people do not get along, but interactions need to be civil and professional.

Code Coverage - Aim for 100% but not 100%

adegiamb — Mon, 24 Feb 2025 02:27:05 +0000

Testing your code is an essential part of software development. But many developers fall into the trap of thinking, "I need to cover 100% of my code."

This can lead to a couple of issues:

Developers write tests to hit the 100% target, create poor tests, and do not focus on testing business logic.
Spending extra time, reducing the velocity of sprints, and delaying projects.
Not taking the time to ensure tests are easy to follow and maintain.

Developers should aim to achieve 100% code coverage of the application's business logic. The business/client cares about this and usually considers it the most critical part of the software.

When you cover all your business logic, it helps improve:

Understanding the side effects of future changes
You can refactor your code more efficiently and confidently; everything still works afterwards.
Reduce whack a mole between changes and deployments.
Business requirements were met.

First-class citizen

In many organizations, testing is treated as a second—or third-class citizen when high estimates or deadlines are approaching.

Some common phrasing we hear:

Phrase	Reality
We will return to adding unit testing after the launch.	There is a slight chance this will happen since the next priority takes over. Only a short period of time between projects.
They are not necessary, so we will do everything manually.	The number of manual tests is growing, and deployments are beginning to slow down. Not all tests are run between each release, causing a chance for issues to be introduced.
It's a small change; don't worry about it.	Many minor changes were added, and now you have a Jenga problem. One future change causes things to come crashing down.

It's with good attention to try to get the feature or release out quickly, but that can cause team members to focus on the short term and not think about the long term.

We have to help educate our partners and give them analogies to see the importance:

Analogies	Question	Risk
You are doing a reno, and the plumber installs the sink and dishwasher.	Would you let the plumber leave without testing if any leaks exist?	The pipe leaks and causes water damage in your house.
You are shopping for a used car/motorcycle.	Would you give the seller thousands of dollars without a test drive?	Vehicle engines have issues or need tons of work before becoming street-legal.
The cable company comes in to hook up your internet/TV.	Wouldn't you want to test if you can connect and browse the web before they leave?	The internet doesn't work when trying to join a meeting.

When picking an analogy, make it simple and a topic for the audience.

Over the years, I have been asked if I can split my estimate between development and testing; I usually won't do that since it is set up for the abovementioned issues. I remind them that testing is a step that needs to be done before the change can be reviewed and deployed.

Unit tests

When testing, developers spend a lot of time creating unit tests to ensure the business requirements are met.

In many cases, this will not cover all the code paths. You should take the time to test both happy and sad paths.

Ignore any option

You often use a mocking library to mock your repository and third party and call other services. Usually, the mocking framework allows you to use any for a parameter to make testing a bit easier. Try to avoid using it since it introduces a blind spot in your tests and gives you a false impression of testing.

Bugs

When a bug is logged, try to use Test Driven Development and first confirm you can duplicate the issue. This way, you can prove you fixed and resolved the problem, and from now on, you know that the bug should never come back.

Integration Tests

Over the years, while reviewing technical assignments, I have seen developers write integration tests using an in-memory database instead of the actual one.

Yes, 95% of the time, this will be faster to run, but you are trading off speed vs accuracy. If you are not using the same database as your production environments, you will be missing the following:

Is your migration script written correctly?
Could you tell me how your queries will perform?
If you need to use SQL vendor-specific features.
ORM can generate different queries, causing unexpected behaviours in production

To increase your confidence, use the same database and possible version your code will use in your environment. Everything will work the same.

Usually, when we do unit tests, we mock the repository layer and test it during integration tests. If the repository layer has business logic, you should test the business logic (branches) to ensure everything works correctly.

Not only happy Path

In most cases, pods focus on the happy path only for integration tests, and this shouldn't be the case. Add the needed tests if a layer can only be tested through integration tests and contains business logic.

Speeding up tests

As we all know, integration tests can be slow sometimes. Running them all during a build can slow down deployments and frustrate developers.

At some previous companies, I saw that they could tag critical path integration tests and run them on every build. Then, they had a scheduled task that ran against the main branch twice daily, ran all their tests, generated reports, and tagged the service owners with any issue they found.

It wasn't perfect, as some issues occasionally occurred before the scheduled task ran.

Input and Golden files

I was introduced to Golden Files when I started working with golang and becoming my go-to way of testing.

A good article is Testing in Go Golden Files.

In the past (I guess a lot of us), we would assert the properties of an entity to see if everything was okay. Over time, things can drift:

New properties are added and are not part of the assertion.
If we are not validating everything, side effects from changes are not always seen.

With input and golden files, you get a clear picture:

You get a version history since changes are committed to your version control system.
You can do a DIFF comparison on the files and see the change(s).

However, there are some drawbacks:

Date/time fields add minor issues; in most cases, you must scrub them to a fixed value.
Sometimes, changes can cause a lot of golden files to be updated at once, making PR look larger than they are. Most tools allow you to filter on file types, making it easier to see the actual changes.

Code Coverage Metric

Code coverage metrics are not the best way to understand whether you cover every u-case or the quality, but they give you a good idea of what has been tested.

What is more critical is taking the time during code reviews to check and understand the tests' actions and ensure that all branches are validated.

General tips:

Aim to get as close to 100% for business logic.
Make testing 1st class citizens.
Don't focus on the 100% but on the quality of your test(s)
Make sure your golden files are pretty printed to make DIFF easier.
Name your tests to be straightforward to search for.
If testing is challenging, it hints at a code smell, and you should rethink your implementation.

A Merge Strategy using reset --soft

adegiamb — Wed, 12 Feb 2025 13:58:04 +0000

While working on a feature or code change, we may need to commit debugging statements or PR comments to the branch where the changes are made.

However, once all the changes are completed and approved, we want to clean up the commit history to help keep the destination branch neat and with helpful commit messages.

While working with a coworker, they cleaned up their comments before merging them into the final branch using the git reset—-soft strategy.

Steps

First, make sure the <destintion branch> is up to date git pull origin
Confirm the source branch is checkout out (git checkout <branch name>). If the branch was checked out locally, ensure all changes are synced by git call.
Next we are going reset the ref pointer to <destintion branch> by running git reset --soft <destintion branch>.
Running git status will show what has changed.
Note: This is optional.
Depending on what makes a scene, we can now commit our changes in the logical group(s) or one commit.

Please review the git commit command to see the different options.

Once all the changes are committed, we will not push them back to the origin branch git push origin <branch name> --force-with-lease

That is all that is needed, and now we have a clean and neat commit(s).

Example

working branch -> feat/adg-01-sample
destination branch -> master

git pull origin master
git checkout feat/adg-01-sample
git reset --soft master
git commit -am "ADG-O2 Sample reset"
git push origin feat/adg-01-sample --force-with-lease

reset --soft master -> A soft reset in Git allows you to undo changes to your commit history while keeping the working directory intact

-force-with-lease -> is a safer option that will not overwrite any work on the remote branch if a team member adds more commits. It ensures you do not overwrite someone else's work by force-pushing.

Non-hostile PR Reviews

adegiamb — Tue, 28 Jan 2025 12:33:13 +0000

What Is a Pull Request?

A Pull Request (PR) is a crucial step in software development. It ensures the code base is thoroughly reviewed and approved, confirming that it aligns with business requirements and coding practices.

Importance of PR
A mostly overlooked thing is that PR encourages collaboration and open communication between developers. This helps the developers and code base in many ways:

Help level up developers by learning from experienced developers.
Business knowledge is spread across more team members, reducing the bus factor.
Company coding standards can be introduced or re-forced.

But often, PR can become a part of frustration/hostility for developers:

Developers can feel they are getting attacked.
Personal opinions can cause clashes.
Comments can be misinterpreted.
pressure from timelines.

Hostile PR and Impacts

When PRs are conducted in a supportive manner, they can significantly enhance future work and collaboration, making developers feel valued and part of a cohesive team.

Developers will start thinking about what they must do to reduce frustration in PR reviews, not what is best to resolve the problem.
Reduce cooperation among developers.
Slow down growth and improvement of developers and codebase.

A significant problem is that a hostile PR can lead a developer to leave the company. The constant exposure to a hostile environment, mainly when PRs occur multiple times a week, can be a significant deterrent.

Hostile PR can also start impacting other parts of development interactions:

Developers will not want to work with or be part of a project that they know other team members are known to be hostile in previews.
Developers will not raise an idea/improvement since they think they are treated the same way in PRs.
Will not raise questions or concerns in meetings.

How to Improve a PR

Comment standard

Many companies focus on coding and branch standards but don't take the time to develop PR / comment standards. These standards are crucial to coding standards since they can protect the health of your engineering department and reduce misinterpretation. Also, make it easier when you are a new team member.

I use https://www.conventionalcommits.org/en/v1.0.0/ or slight variation since it's straightforward and quick to learn.

I see other developers use emojis to help describe the comments.

It doesn't matter what approach you use. Just align to a standard.

Short and sweet

Keep your comments direct and to the point to reduce the chance of misinterpretation.

If you notice that you are writing long comments or many comments on PR, having a rubber ducky session with the developer and reviewing the PR together is worth it. It has many benefits:

Help build stronger bonds between team members.
You can better understand why the developer did something a certain way.
It can be faster since it will reduce the back and forth on PR.

Coding standards

Having coding standards documented is essential for PR comments.

You can link to the standard that is not being followed.
Help reduce introducing personal preferences or opinions.
Coding standards need to be documented for all developers to reference. If not, how can they be a standard? How will a new developer know a standard vs. someone's preference?

The coding standard document should outline:

Why does this standard exist
What is trying to solve
Example of the standard

Also, having coding standards helps remove some hostile comments from appearing:

"I said this 1000 times ..."
"This is not how we do it here."
"Why are you doing this?"
"I don't get why you are doing it like this. We do it like.."
"As I stated before, I prefer .."

Remember that each developer is at a different level, and PR is one way to help someone grow and improve. Use that opportunity to help them out.

Logs - your secret weapon

adegiamb — Fri, 24 Jan 2025 00:59:06 +0000

Most developers don't take the time to consider the log messages' importance when adding them. However, logs are not just a formality; they are your secret weapon, helping you understand the flow of operations and simplify troubleshooting. Neglecting to provide detailed and context-rich log messages can significantly hinder the troubleshooting process, leading to longer resolution times and potentially impacting the user experience.

Most of the time, the developer will add generic log messages such as:

Created account successfully.
An error has occurred.
Updated preferences.
Invalid Type.

The above message gives you a rough idea of what has happened, but it does not provide context for what account was created, what error occurred, or who/what preferences were updated.

However, with some little changes, you can improve the message by providing some context:

Account test@example.com was created.
Error creating an account for test2@example.com
Preferences updated for test@example.com
The product type is invalid.

With those changes, at a glance, you have some context of what happened.

An account was created using the email address test@example.com
When trying to create an account, test2@example.com failed
The preference for test@example.com

Log Levels

Most logging frameworks have different log levels; you can control which level is visible in your environments.

Debug

Detailed information about your application's internal workings can be helpful for debugging. For example, essential logic is applied when processing a request.

You should treat debug log messages as unsafe for production environments and only have them for non-production environments.

Information

A critical step in the application has started or been completed. This is useful for tracking its progress.

Warning

Something unexpected happened, but the application can still be continued.

For example, if you check a user's preferred language and it has not been set, you default it to English.

Error

A single operation (like processing an HTTP request) has failed.

Fatal

A very serious error has happened, causing the whole application or system to crash.

Formatting your message

A typical pattern I follow when creating log messages is the wrap dynamic values between square brackets for a couple of reasons:

It is easy to identify what value(s) are dynamic
You know the start and end of the value. Helpful with string values.
You can parse messages more quickly since you can ignore anything between the brackets.

Examples

Account [test@example.com] was created.
Error creating an account for [test2@example.com]
Preferences updated for [test@example.com]
Error creating an account for []

High-volume systems

While having details is a valuable tool, logging every event could overwhelm your storage and processing systems and log messages. You can sample a subset of logs (for example, 1 in X requests); this will still allow you to troubleshoot most issues.

Secret detailed logs

To help debug production environments, you could implement a feature that allows more detail log and remove sampling when debugging an issue:

custom header
query string parameter
dynamically-generated tokens for the param value

Note: If you use microservices and want the feature to work across different services, you need a way to transport the feature across different requests so you get the full picture.

This can/should be protected from bad actors from abusing the feature. This can be done by whitelisting specific IP ranges like your company's VPN.

Structured Logs

To enhance your logging, you should use structured logs. Stackify has a good article on structured logs.

Stackify article

Depending on your logging framework, you can add fields that provide more context about the message and where you are processing your request.

When adding additional fields, keep a couple of things in mind:

Think about PII and other sensitive data that should not appear in logs.
Include a request/trace ID to help you see the whole picture.
Build up the additional field while you process the request. This way, you don't know to jump between different logs to see the details you need
If you are processing a batch, include a batch ID. Include your service version; this can help identify if an issue was introduced in a specific version.

You can import structure logs to tools like New Relic, Data Dog, sentry ... to make searching, filtering and alerting easier

Pointers to improve log messages

When developing/testing your code, if you wished you had some data when troubleshooting, include it in your log message
If troubleshooting a missing log message would make future changes easier, add it to make future debugging sessions easier.
Think about what metadata, such as:
- Record ID
- Request ID
- Data of the entity (Person name, product details)
- The source of the request (which application)
- Make your message self-documenting
What log level to use? It can help with filtering.