WORKING WITH ENGINEERS - HAPPINESS, AGILE, AND GIT.

[THE WEB EXPLAINED: PART 10]

Over the years, I've been blessed enough to work with a wide variety of organizations, each with its own quirks, culture, and personalities. Unfortunately, one universal thing I've observed (and the driving force behind me writing this series) has been the relative discomfort emanating from non-technical people who are simply trying to find the best way to operate effectively surrounded by a veritable lion's den of critical-minded engineers.

I totally get it. And it sucks.

At the end of the day, engineers are humans, and sometimes we can display a number of human traits that are less-than-desirable, often due to our own insecurities. These flaws often present themselves in a myriad of unhealthy manifestations that can lead to toxic interactions if not addressed and understood for what they are, a basic dysfunction in the relationship.

---

Simply, as with any relationship, the foundational precondition for a healthy relationship with your engineers is trust.

So, how do you foster trust with your engineering team? Well, it's a multi-faceted answer, but because you're awesome and have read this far, I've got time to throw out some ideas...

---

🏆 Purpose. Autonomy. Mastery.

Daniel Pink's book, "Drive", dives deep into what motivates people to do their best work. Put in the frame of reference of many engineers, it's really quite simple:

1. Purpose - "I know that what I'm working on matters and is providing value to those that are using it." vs. "I have no idea why we're building this thing; it's pointless."

2. Autonomy - "I'm able to solve hard problems without being micromanaged or questioned about areas that I have demonstrated expertise in." vs. "I feel like I'm being questioned about every inch that I want to move down the metaphorical well-worn road I've traveled thousands of miles before."

3. Mastery - "I'm given reasonable space and time to produce quality solutions that I'm proud of, as well as an environment that allows me to grow in additional areas of interest." vs. "I'm not proud of my work. I have neither the time nor the remaining energy to nurture my own growth, and I'm being forced to cut corners at work daily."

Pretty simple, huh? Take a minute and think about your present role, as well as any previous roles that you've had. In jobs you loved, how were these 3 grounding principles supported and extolled as a virtue? Now, think of some places where you might not have been satisfied. How were these 3 guideposts ignored, admonished, or violated?

Over the years, I've been able to counsel literally hundreds of students, comrades, and friends regarding their careers. In nearly every interaction I've had with someone unhappy at work but unsure why, going through the exercise of mapping back to purpose, autonomy, and mastery seems to bring the clarity needed for an imprisoned soul to name its captor.

When you look at how most well-run software companies produce innovative work with motivated and engaged employees, you can see how many standard-practice interactions help reinforce purpose, autonomy, and mastery.

---

🤸‍♂️ Agile (or whatever works for you)

The various flavors of Agile (when not onerously dogmatic) provide wonderful feedback loops for the core tenets of satisfaction:

• A well-thought-out epic should provide the purpose and reasoning why we're investing in this work.

• A team should be able to break the epic down into stories and determine how the work will get done. A good cross-functional team will also swarm on tasks and pick up the next one on the stack, but sometimes engineers will call "dibs" on the one story that just looks fun, which provides an element of free will and autonomy.

• The process of committing your code to version control, soliciting feedback from the team, and ultimately seeking acceptance from stakeholders allows a team to continue to improve their skills and work towards mastery in many areas. Sometimes, getting that ticket moved along can be painful, but often those are the ones we grow the most from.

While written long before Drive, The Agile Manifesto authors knew that a light process that empowered engineers to be their best would lead to happier engineers, more cohesive teams, and better products.

---

🐙 Git: Collaboration and Healthy Soul-Crushing.

Another lens to look through is a tool that engineers potentially use hundreds of times a week to commit and review code: Git.

If you don't know what Git is, it's a version control system that provides teams ways to simultaneously work on the same code base, track changes over time, and manage any conflicts that may arise from a kitchen full of cooks. It arose out of a need for the thousands of open-source contributors to Linux to have a way to collaborate asynchronously from all over the globe, with a dedicated focus on quality and stability.

Git works in a distributed fashion, meaning that every developer has checked out a copy of the repository (repo) on their development machines. In addition to local repositories, many popular websites such as Github, Bitbucket, or Gitlab exist to host repos in a central location and allow for collaboration around features and fixes.

How does something as simple as a code storage application foster something like autonomy or mastery? Let's look at a core piece of the git workflow: the mighty pull request.

Pull requests are a way for a developer to make changes to a repository and literally say "hey team, here's my request to pull my code into the main codebase." This works by utilizing a feature of git called branches, which we can visualize like a tree with a main trunk and many offshoots emanating outward.

When you check out code to work on a feature, you generally create a new branch off the production mainline (often called master or main). With your own branch, you're free to make whatever changes you want with absolutely zero fear of breaking anything. You have complete autonomy to try radical changes that you think can solve the bug, clean up the code, or provide the user's requested functionality.

It's quite common to cut a branch and try some off-the-wall-bonkers stuff, only to delete that branch and create a new one if it all doesn't work out. Having your own sovereign sandbox to play in is like an endless world of imagination full of crazy possibilities, like the MTV show Pimp My Ride, but with code...and hopefully better taste.

When you have finally decided that your branch is ready for primetime, you technically could merge it right into master, which would likely release it to production, depending on your team's setup. This would widely be considered to be a bad move with most teams and is pretty much synonymous with the somewhat derogatory term cowboy coding. Yee haw.

To make sure that you're not introducing breaking changes (I'm often guilty) or just stupid ideas (I'm definitely more guilty), you need to submit a pull request (aka "PR") and have one or more members of your team do a code review. If you want actual footage of my team giving me a code review, I have a short clip here:

Kidding aside, putting yourself out there for the team to comment on your code can be a real soul-crusher, especially if you're new. As with any creative pursuit, the hardest part is sometimes the last part, baring it all for the world to throw tomatoes at. Over time though, submitting code for review becomes routine for a majority of developers, and it's a major contributing factor to some of the matter-of-factness that you'll find with many devs.

PR reviews can be brutal, and they can sometimes hurt. You might think you have the best idea, only to have Sean tell you that you can do better. And you know what, Sean is usually right. You can do better, and you do, over and over again. Almost just to prove to Sean that you still have a purpose on this world, that those things your mother said about you aren't true, and that gosh darnit, people like you. Wow, that got a little personal there. Sorry.

Anyway, as you begin to acclimate to your team and the company culture, you will grow to appreciate terse comments about your code and learn to stop taking it personally. This crucible is not unlike the design critiques I was subjected to in design school. When done right, they are not destructive but rather instructive. When not taken as an indictment of who you are as a human being, a good review can add rocket fuel to your growth as an engineer. If you trust the process, you will find that you can gain increasing levels of mastery in a very short time thanks to your team's collective wisdom.

🧠 Learn more about Git:

Atlassian: What is version control?

Github: Git handbook

Learn Git Branching