



We learn how to apply the concepts of The Pragmatic Programmer to teams while Michael uses his advertisement voice, Joe has a list, and Allen doesn’t want anyone up in his Wheaties.

In case you’re using your podcast player to read these show notes, you can find this episode’s full show notes and join the conversation at https://www.codingblocks.net/episode114.

Sponsors

Datadog.com/codingblocks – Sign up today for a free 14 day trial and get a free Datadog t-shirt after creating your first dashboard.

get a free Datadog t-shirt after creating your first dashboard. O’Reilly Velocity Conference – Get expert insight on building and maintaining cloud native systems. Use the code BLOCKS during registration to get 20% off of most passes.

during registration to get 20% off of most passes. Educative.io – Level up your coding skills, quickly and efficiently. Visit educative.io/codingblocks to get 20% off any course.

Survey Says …

Anonymous Vote Sign in with Wordpress What's your favorite type of swag? Stickers, because they make my laptop go faster.

Shirts, because I wear them pretty often and they make me look pretty.

Water bottles. Gotta stay hydrated. And then run to the bathroom inbetween talks.

Coffee cups. Coding requires coffee.

Hats, because everyone has a bad hair day every now and then.

Socks. Everyone loves super cute socks. Except Florida man.

Bags, because they cost the most.

Pens/notebooks, in case I need to write something down super quick! vote

News

A big thank you to those that took a moment out of their busy lives to leave us a review: iTunes: SimplyManuel, Eric Shin Is Strong, WwHG10 Stitcher: AwesomeWithLawson, Glen Moyes, SimplyManuel, codesfrcoffee, RedPeril, TGibson, Lecherouscthulhu

Come see us at Atlanta Code Camp 2019. Allen will be giving his Real Time Data with Kafka Streams talk, And Joe will be giving his What’s this crazy JAMstack? talk.

Joe was a guest on episode 10 of the Backend Bear.

Building Pragmatic Teams

The methods learned so far from this book can be applied to teams in addition to the individual.

By working on a “pragmatic team”, the advantages of practicing the methods of the book are multiplied many times over.

However, these methods are only a starting point. Pragmatic teams will evolve, adapt, and refine these practices to best fit their environment.

No Broken Windows

Everyone on the team should care about quality.

Pragmatic teams can not accept broken windows.

Quality needs to come from every team member.

Boiled Frogs

It is easy for an individual to overlook the overall big picture environment while in the heat of a project’s development. It’s even easier for teams. Team members can easily assume that someone else is addressing a bug, or that some environmental change was OK’d. Keep in mind, environment changes don’t necessarily have to mean hardware or configuration. It could mean, bringing in a new technology for example.

Everyone should be on the lookout for changes to the environment. The authors suggest appointing a chief water tester to monitor scope creep, timelines, and environments … anything that wasn’t originally agreed upon.

Keep metrics on new requirements.

Pragmatic teams shouldn’t reject new feature requests outright. Instead, be aware when and that they occur. Otherwise, you might be the one boiling.



Communicate

Pragmatic teams need to communicate clearly to the everyone else as one voice.

The worst teams are those that bad tempered or difficult to get information from. Their meetings have no structure. No one wants to talk. Their documentation is awful. No two documents have the same format and each use different terminology, i.e. no ubiquitous language.

Great teams have a personality. You look forward to meeting with them because they are organized. Their presentations are well-prepared. Their documentation is consistent. Current. Accurate. Concise. All members of the team use the same ubiquitous language and speak with one voice. Externally. Internally, they have lively debates, where strong opinions are expressed. Good developers are passionate developers.

The simple marketing trick to communicate as one: generate a brand. Create a team name and logo. When communicating with others, use the name/logo. It builds an identity for your team to build on. As well as something memorable for others to associate your work with.



Don’t Repeat Yourself

Duplication is wasted effort.

This duplicated effort can create maintenance headaches.

Good communication between teams can help reduce duplication.

A project librarian can coordinate documentation and repositories. Other’s can go to the librarian when they’re looking for something. And the librarian can spot duplication when they’ve been given something new.

However, if the project is too big for one librarian, appoint a few people as the primary contacts for various functional areas of the project.

And don’t forget the value of online user groups, mailing lists, forums, wikis, etc. for archiving questions/answers, and discussions.

Orthogonality

Traditional teams are organized such that individuals are assigned roles based on their job function. The Rational Unified Process: An Introduction (Amazon) identifies 27 different roles within a project!

Roles have an implicit hierarchy: the closer the role is to the user, the more senior the role.

Some development environments have strict divisions of responsibility. You might not be able to talk to the testers or the chief architect, for example. To make matters worse, some organizations might have different sub-teams report to different management chains.

Don’t fall victim to thinking that the various tasks for a project can happen in isolation, because they can’t.

Analysis, design, coding, testing – These are all different perspectives of the same problem.

Developers that are two or three levels removed from the user will likely not be aware of how their code is used and therefore not able to make informed decisions while developing it.

Tip 60

Organize Around Functionality, Not Job Functions.

Team Division

The authors prefer to split teams up by functionality.

Each (small) team should be responsible for a small aspect of the overall system.

And each team is responsible to each other.

Commitments change with each project and so do the people per team.

Splitting the teams up by functionality doesn’t need to translate to use cases though. The DB can count as a team. The help subsystem can count as a team.

Look for largely self-contained groups of people. This is similar to how we’d break up code into modules. Use the same techniques, such as by contract, decoupling, and orthogonality. By doing so, we help isolate the entire team from changes outside it.

When done properly, this can reduce interactions, reduce time scales, increase quality, and reduce bugs.

Developers will be more committed.

Teams will feel more ownership because they know they alone are responsible for their part.

But this approach will only work with responsible developers and strong project management.

Two heads

Each project has two heads: one technical and other other administrative.

The technical head is responsible for the development style, assigns responsibilities, and arbitrates discussions. All that while always keeping an eye on the big picture, removing unnecessary commonality among teams to maintain high orthogonality.

This person is the lead architect.

The administrative head is the project manager. They schedule necessary resources, monitor and report on progress to the stakeholders, and might also act as the PR representative when communicating outside of the teams.



Additional Resources for Larger Teams

Librarian – Indexes and stores code and documentation.

A tool builder – Someone that provides the tools, environments, and support.

Automation

The best way to ensure consistency and accuracy is to automate everything that can be automated. That bash script, makefile, etc. isn’t going to change itself. Typically. And it can be versioned.

Automation is an essential element of a Pragmatic Team.

Appoint one or more people as the tool builders to build and deploy tools that automate the project’s boring parts.

Know When to Stop Adding Paint

Pragmatic teams give each member the opportunity to shine.

They provide team members with enough structure to support them and ensure the project delivers against those requirements.

And then resist the urge to add more paint.

Resources We Like

The Pragmatic Programmer by Andrew Hunt, David Thomas (Amazon)

The Pragmatic Bookshelf (pragprog.com)

lagniappe (Wikipedia)

Spotify engineering culture (part 1) (labs.spotify.com)

Tip of the Week

Git tips: Undo your last commit: git reset HEAD~ (Stack Overflow) Undo all of your current changes and reset the environment back to the last commit: git reset --hard HEAD Remove all untracked files: git clean -f Remove untracked directories, too: git clean -f -d

Joe’s reasons to use Kotlin (in no particular order): Reason #147 – Using natural language test function names with backticks (discuss.kotlinlang.org) Reason #136 – Higher-Order Functions and Lambdas (kotlinlang.org) Reason #17 – fold, reduce, Map

Overview of Microsoft Authentication Library (MSAL) (docs.microsoft.com)