In this episode, Dave and Jamison answer these questions:

1. I’ve been a Staff Software Engineer at my company for 1 1/2 years. We have about 120 engineers company-wide. I’ve had 4 different bosses during the last year and our team has moved around a few times on the org chart.

   I lead a team of 2 engineers. My boss told me I shouldn’t be doing any of the coding but should spending my time working with the product manager, doing research for upcoming features, doing code reviews, managing the Jira board, mastering jellyfish metrics, reviewing architecture documents, setting up measurement in our logging tool and coordinating deployments of our features.

   Because my team is small and our product roadmap is pretty well defined, these tasks do not take 40 hours per week. I feel like I have nothing to do. I’ve tried to improve the velocity of the team by doing some coding and triaging on bugs. I miss doing the technical work and feel like I could do more but I also want the other 2 engineers on the team to own most of the big, bulky tasks.

   What do you suggest I do? Should I enjoy my light load or should I be looking for other ways to add value?

2. I am the lead developer on a few projects with developers that have 20+ years of experience compared to my eight years. I have been made lead of the projects, but I’ve never actually had management tell the team that I am the lead or that I have any control whatsoever on the members of the team (typical ‘all of the responsibility, none of the power’ scenario). One of my teammates is tough. He writes unreadable but working spaghetti code. He also works in the field and will often times push to master and then leave to perform fieldwork, leaving the team in the lurch for several days before he can come back and fix his broken code. He habitually fails to push code, often holding the source on his own computer for months before pushing. I have mandated using pre-commit hooks to guard against breaking the build, but as IT has control over the repositories, these become “optional” and appear to be disregarded. I have brought this up with management, to no avail; the behavior continues. I have also expressed my concerns with management, and provided data on the impact this has to the project via tickets and time spent between the remaining team members.

   How do I rein in this unwieldy developer? What else can I do?

Show Notes

• https://www.gamasutra.com/view/feature/4111/dirty_coding_tricks.php?page=4

In this episode, Dave and Jamison answer these questions:

1. My boss keeps recommending bad movies. I watch most of them but I feel bad because they’re not good and I don’t want to disappoint my boss. They are ‘okay’ but are really mediocre. Do I just ignore my boss’s suggestions or should I keep watching these terrible action-heist movies even though I don’t like them?

2. Does it matter if my emails are well written?

   I’m a software engineer. I asked my partner how I should word a part of my email. After reading my email they were appalled. They said that it was “abysmally written and lacked refinement”. I’ll admit that it wasn’t my best written email, but who cares? It was just an email letting a team member know that I had followed up on a ticket a while ago, so it wasn’t like this was going to a client or something. Plus I felt like the email conveyed the message that it needed to.

   In my mind as long as the email isn’t offensive or covered in grammatical errors and conveys the message, isn’t that good enough? My partner argued that I should write my emails more eloquently since my “terrible” emails will reflect poorly on me. I told other engineers care more about the content and less about how well-written any given email is, but they wouldn’t budge. In addition to that, some of the emails I’ve gotten from our senior and staff engineers seem like they were written with someone who has the English skills of a middle schooler and they seem to do fine for themselves.

   Thoughts?

Show Notes

This episode is sponsored by Compiler, and original podcast from Red Hat. Check it out

Reference to the Dragon book on Wikipedia

Robustness principle: Be liberal in what you accept and conservative in what you send

In this episode, Dave and Jamison answer these questions:

1. Listener Casey asks,

   My team has built an internal framework for continuous delivery that enabled a key product release last year. The tooling has gained widespread adoption and popularity throughout the org, to the point that some leaders are requiring teams to use the framework for any new services. Things are generally going great, except that “my team” consists of only 2 people including myself, and we have so much work that the soonest we can look at new features is ~18 months from now. Some individuals, who are being required to use our framework, are frustrated and protesting loudly about how the framework doesn’t work exactly the way they think it should. How can I shelter my team from the outbursts of unhappy users? Or bolster their resolve so they don’t take on the anxiety of growing pains?

   P.S. We’re all remote so this happens 99% in chat channels and DMs.

2. If something goes right, product takes credit. If something goes wrong, engineering takes the blame. How do you change that organizational dynamic? (Other than your usual answer.)