Tag Archives: Programming Culture

Engineering Teams

What makes a meaningful standup update?

Leave a comment

Hey there! I know it can be difficult to know what to say in standup. One of the most important things you can do to keep your team in the loop is to share a meaningful standup update on your progress. Think of it like a relay race – each team member needs to know where the baton is, how fast it’s moving, and whether there are any obstacles ahead.

When I enter standup and giving my update, I like to ponder: “What info can I give to the team that might be meaningful for a standup update?”

Tips for sharing meaningful standup updates

  1. Update the team on your current work status
    Let your team know how close you are to meeting milestones, deadlines, and if you’ve encountered any issues. For example, “I’m 85% complete with the License/phone selector for site settings and should have it ready for review by tomorrow morning.”
  2. Communicate any changes that may impact others
    Let your team know of any changes to your work that may impact or unblock the work of others. For example, “I’ve finished the API bits for both site and account phone/license, which should now unblock the UI stories for the rest of the team.”
  3. Customize your updates
    Tailor your updates to your team members’ interests and needs. For example, provide more details on a technical challenge for a team member who’s interested.
  4. Be proactive in sharing updates or asking questions
    Don’t wait for someone to ask for an update. For example, “I wrote up a bug I believe I noticed a bug in production, I would like to see if we should address it now or a future sprint.”
  5. Provide context
    Share not only what you’ve done but why you’ve done it. Providing context can help non-technical team members better understand the value it brings, and how it fits into the overall vision. For example, “I’ll be starting work on the date pickers, this is part of the new reporting view we’re building.”

Why do Good Standup Updates matter, you ask?

Well, here are a few reason:

  • Keep your team up-to-date
    Regular updates help everyone stay informed about the progress of the project and any potential roadblocks.
  • Identify and address issues early
    Sharing updates on any issues or challenges you’re facing can help your team address them early on, preventing them from becoming bigger problems down the line.
  • Foster team cohesiveness
    Sharing updates can help your team understand each other’s work and goals, leading to better communication and collaboration towards a shared vision.

“The single biggest problem in communication is the illusion that it has taken place.”

– George Bernard Shaw (1856 to 1950)

So, the next time you’re in a standup meeting, don’t just rattle off a list of tasks you completed – instead think of your standup updates like a baton in a relay race – an opportunity to keep everyone informed, stay on track, and work together to reach the finish line.

Ask yourself: “What info can I give to the team that might be meaningful for a standup update?” and you’ll build a strong team culture that values open communication and collaboration, leading to more productive and successful projects.

Book Reviews

Debugging Teams – Book Review

Leave a comment

Debugging Teams is a short, clean, and to the point read. It’s a great book to pick up, read a page or two & set down and ponder. Every section speaks lightly, yet bluntly about team culture & being a great team member.

Debugging Teams Book Cover

Rating

(Higher is better, 5 is neutral)

  • Would I recommend? 9 / 10
  • Did I learn anything? 8 / 10
  • Did I learn anything I can apply? 7 / 10
  • High Information density? 8 / 10
  • Would I re-read? 7/10

Buy Debugging Teams on Amazon


Debugging Teams Overview

Debugging Teams speaks honestly and cuts to the chase. It provides practical advise with how to work with (and around) bad culture and defines what good culture looks like.

It reminds us that good team culture starts with ourselves. We have to be humble to grow ourselves to be an example of what good culture is.

Debugging Teams sets that bar of what that good team culture should looks like and thusly what bad culture looks like.

Who should read Debugging Teams?

Pretty much everyone! Specifically leadership, managers, and junior to senior devs.

I consider this essential reading for any of team member as an introduction to thinking about team culture.

My main takeaways

Culture is important from day 1, bad culture from one teammate infects an entire team and pushes away good talent. It’s hard & nearly impossible to override one toxic teammate with many good ones, it just doesn’t work.

Therefor don’t tolerate having the Brilliant Jerk on the team. They aren’t worth it. They set bad culture and diminish the team around them.

Be the example of the culture you’d like to see, be humble, you likely have faults as well. We need to be aware of our own ego.

If you liked this book, next I’d recommend:

Going deeper on team culture: Elegant Problem
Going deeper on leading with positive impact: Multipliers
Going deeper on project management: Waltzing with Bears
Going deeper on managing a team: Become an Effective Software Engineering Manager

Favorite Quotes

“Software development is a team sport”

“If you spend all your time working along, you’re increasing the risk of failure and cheating your potential for growth”

“Relationships always outlast projects”

“Understand the difference between constructive criticism of someones’ creative output and flat-out assaults against someone’s character. […] If you truly respect someone, you’ll be motivated to choose tactful, helpful phrasing.”

“Your self-worth shouldn’t be connected to the code you write – or any project you build.”

“When you stop learning, you get bored. It’s really easy to get addicted to being a leading player; but only by giving up some ego will you ever change directions and get exposed to new things. Be willing to learn as much as teach.”

“Admitting you’ve made a mistake […] is a way to increase your status over the long run.”

“A ‘strong culture’ is one that is open to change that improves it, yet is resistant to radical change that harms it”

pg 31

Coding

Why do we estimate stories?

3 Comments

There are two reasons we estimate stories: to understand scope and then to communicate that size of that scope to others.

Understanding Scope of Tasks

In order to be effective at anything we do in life, it’s best to step back and understand what it is exactly that we want to accomplish.

  • How hard is it?
  • How complex is it?
  • Are there unknowns?
  • How long might it take?
  • How well do we understand it?
  • Are there other tasks that need to be done first?

As an individual we ponder these questions ourselves. As a team we discuss them together during our weekly scope and grooming to refine our shared understanding.

It’s easy to dismiss small tasks as not worth any further scrutiny because they feel obvious. Asking these questions takes little time. Even the simplest tasks can hold surprises if we take a moment to ask these few simple questions.

A fool does not care whether he understands a thing or not…

– Proverbs

Communicating Effort

It’s hard to express how long or hard a task is to others that are not in our domain of knowledge. Perhaps they’ve never seen what code even looks like, much less tried to program.

Thus we point and estimate stories. I prefer to call them effort points or “oof” points. How much “oof” effort does something take to accomplish.

Here is an example with my household chores.

“oof” effortStory Points~Time
Take out trashLittle “oof”11-10 min
Wash the dishesSmall “oof”310-60 min
Mow the lawnMedium “oof”51-3 hrs
File taxesBig “oof”83-8 hrs
Remodel bedroomLarge “oof”132-5 days

What’s important to notice is that Story Points / Effort doesn’t mean a specific length of time but rather an estimated time rage.

Story Points are a valuable tool to roughly translate effort → time estimations.

This gives Project Managers a way of estimating a rough expectations of when a collection of tasks might be completed. This empowers Project Managers therefor to set a realistic estimated timelines & expectations with external stakeholders for when tasks and projects might be completed. I wrote more on Planning Roadmaps & Project Estimation in another post.

Personal Cautions & Notes – Estimate Stories

  • Lean heavily on higher end time values when trying to translate points to time; that is be pragmatic.
    • It’s highly unrealistic it only takes under 1 min to take out the trash & put a new bag in, probably closer to 8 min.
  • Project managers don’t mind hearing that something is complex, big or unknown, the sooner they know this the better.
  • Project Managers love the radical honesty, it helps them set realistic expectations with their stakeholders.
  • Always round up to higher point levels if something is on the fence.
  • Talk about estimating with your team and create a good Developer Culture when you estimate stories.

(cover photo credit: Jonathan Stassen / JStassen Photography)

Coding

Wait You Use a GUI for GIT?

Leave a comment

Yes, Yes I do!

I’m a firm believer in using whatever tool you need to get the job done.

Is there shame in using a GUI?

I’m don’t believe in shaming devs for using a GUI and not using a CLI in the Terminal.

Dev shaming is toxic. It hurts people, and that’s not what we want, we want to build each other up! We want to get excited at each others accomplishments!

The tools we use to accomplish the task don’t really matter, what matters is that we build amazing software. There is no elite-ism of using one tool over another.

“You’re not a real dev if you don’t use a CLI” is a myth. Never believe those words. You’re a real dev if you can write software that works!

Why do I use both?

Personally I really use a mix of GUI and CLI. Some tasks are quick and easy in one or the other for me. For you it might be a different mix of benefits.

I prefer GUI for

  • Quick glance context: Current branch, commits behind/ahead, conflicts, other branches status, changed file count.
  • Cherry pick lines to commit, discard lines
  • Interactive rebasing & squashing with ease
  • Scrolling through exactly what lines of code I’m committing

I prefer CLI for

  • Quickly switch branches
  • Hard reset easily
  • Pull new changes
  • Committing & Pushing
  • Adding a new remote

Let’s end the culture of Dev shaming!

Coding

Code Reviews on Closed Pull Requests

1 Comment

Good Code Review (CR) on Pull Request (PR) are at the heart creating high quality code. Code reviews on closed pull requests can feel awkward.

I believe we should welcome feedback on all PRs — even closed ones.

A coworker of mine came back from a short vacation and read over my PRs I had opened and merged while they were out. They spotted a bug in one of my PRs and they left a comment pointing it out. They however felt deeply guilty commenting on a closed PR and apologized to me. This is odd to me.

Merged PRs often get treated as code where the “Ship that has sailed”. Treating merged code as “untouchable” forgoes the ownership and responsibility we developers have for the code we create.

I suggest a cultural shift: To strive to produce high quality code, we ought to welcome and be open to Code Review feedback, before, during, and after the life of a Pull Request.

How we allocate time to address the feedback will range from team to team but could be new backlogged stories, re-opening a new PR, or just answering questions.

How do you feel about code reviews on closed pull requests?
Is there a better way to handle code feedback after it’s merged?