The Daily Developer

A few thoughts on hiring

Join me as I talk through some hard-earned lessons on hiring and recruiting. Links: * The Daily Developer [https://thedailydeveloper.substack.com] * Firing Well [https://mondaynote.com/firing-well-32bcc929b888] * The Five Dysfunctions of a Team [https://www.amazon.com/Five-Dysfunctions-Team-Leadership-Lencioni-ebook/dp/B006960LQW/ref=sr_1_1?crid=1OG4EBB8PM46T&dib=eyJ2IjoiMSJ9.m-S3In8lXHSPxHFwaOT8Tc02zw7IcGxTr1PqQzSdt5ar_r6ZeapT2fX3yBQSvhIj3JwYxuD5SJo8n5HZBjEYN4KPBswpdY6yuosVTHh_RX1LhVL4L1oox2Vnw8bnfEqrYiHUQqsOc5t6GKgFC3IvJVn3U4dcEsbtnS14qPrLGYs0K6doiGoeRn2j38uuZdc23dc3UVUMbscCoRrX9qhCwF4qEJupVGUE3e54SuQLm0Y.zgVQGp7ZFrq96nXaH8Zr32Oa6b0uNRHvhdfqPqE55mA&dib_tag=se&keywords=5+dysfunctions+of+a+team&qid=1710331475&sprefix=5+dysfunctions%2Caps%2C119&sr=8-1] This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thedailydeveloper.substack.com [https://thedailydeveloper.substack.com?utm_medium=podcast&utm_campaign=CTA_1]

Is duplication complex?

Links: * Why are non-DRY specs more maintainable? [https://thedailydeveloper.substack.com/p/why-are-non-dry-specs-more-maintainable] * The Maintainable Software Podcast Episode with Jeanine Soterwood [https://maintainable.fm/episodes/jeanine-soterwood-helping-clients-understand-maintenance-work] * Simple Made Easy by Rich Hickey [https://www.infoq.com/presentations/Simple-Made-Easy/] * Patterns of Software by Richard Gabriel [https://archive.org/details/PatternsOfSoftware] * The Psychology of Computer Programming by Gerald Weinberg [https://www.amazon.com/Psychology-Computer-Programming-Silver-Anniversary/dp/0932633420] * Sandi Metz: Duplication is better than the wrong abstraction [https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction] and POODR [https://www.poodr.com] This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thedailydeveloper.substack.com [https://thedailydeveloper.substack.com?utm_medium=podcast&utm_campaign=CTA_1]

The one about standup meetings

Ah, yes, the standup meeting. Love them or hate them, there’s a 100% chance you’ve encountered this in your career. Most standups are done very poorly. They often feel like useless checkins designed to ensure that you’re around and paying attention. The worst feel like an enforcement of attendance at work - a virtual version of “butts in seats” type of management. However, when done well, they are essential to keeping a high performing team making progress every day. The goal of a standup meeting is to optimize the probability that we hit our goals. So: it’s an optimization of probability. From both sides, we must acknowledge that merely setting goals does not mean we will reach them. And many times a poor standup meeting process will sort of forget about the goals and “focus on the process”. (I do have an opinion on focusing on processes over goals, but for the sake of argument, let’s assume setting goals is a good practice. Crazy idea.) Standups, done well, should act as milestones. Rather than "what are you working on", a small tweak in language could be: what did you do since the last standup? what do you intend to do before the next standup? Instead of viewing these as meaningless “check-ins”, view them as a perpetual way to course correct. (If you think you don’t need to course-correct, or you think that nobody else can help you with such an exercise, or that managers should butt out of your work, you haven’t seen s**t.) When you treat standups as milestones, you provide the opportunity to revise your estimates. If that feature will take twice as long, you have a professional responsibility to disclose that to your team. Holding a standup meeting is a time-proven way for your team to learn about these disclosures and updates without relying on each team member to proactively send out such an update to everyone involved. It just happens at standup. Standup is an expensive meeting. It follows that you should be as succinct as humanly possible. Literally nobody enjoys hearing you explore your current approach out loud in a stream-of-thought manner, meandering through your architecture decisions and explorations. AFTER standup is the time to dive deep into technical details. Don’t waste everyone’s time by using up a ton of oxygen. And be positive. Remember to thank anyone who’s helped you and take every opportunity to reinforce good practices that you see elsewhere. It’s so embarrassingly common to see this done poorly. If you master the art of the effective standup, you will earn the respect of your colleages and manager. I guarantee the leadership of your team will sit up and take notice. @dpaola2 [https://twitter.com/dpaola2] https://thedailydeveloper.substack.com [https://thedailydeveloper.substack.com] This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thedailydeveloper.substack.com [https://thedailydeveloper.substack.com?utm_medium=podcast&utm_campaign=CTA_1]

Define your own role

One time, when I was a little bit desparate for some cash, I took a gig writing some ruby code for a nontechnical team. This team had a founder and a separate ceo. In my first week, my gut told me the CEO was probabaly not going to be very effective. I couldn’t have told you why, it was just a gut feeling. After a month or two, it became very obvious that the founder didn’t want to relinquesh control over the product, and the CEO was process oriented, to the point of vanity. The CEO was sort of a figurehead - responsible for the running of meetings and the taking of notes, and sort of responsible for closing new sales, although he was not an experienced sales person. It turns out, my gut was right. The founder, while smart and driven, was not giving the CEO the level of autonomy to succeed in the role. And the CEO was not honest with himself or others about his ability to deliver growth. The psychological ownership of his role wasn’t his - it was the founder’s. The founder sort of knew that he needed a CEO, and gave the CEO the rope to prove himself, but the CEO didn’t feel that he had that rope, that he could prove himself. If I had to guess, I’d guess that the CEO came from corporate life at a larger company, where the rules and expectations are clearly laid out for you. This is not an excuse for the founder - in fact, he’s at least partly to blame for his inabilty to define what he wanted in the role. But, generally, it’s up to you to define your own role.  If you don’t know what’s expected of you, figure it out for yourself. Turn any opportunity with your higher-ups into an interview, or even a sort of anthropoligical study. What do they SEEM to expect of you? Do they know that? Do they know the implications of those expectations? Discuss this with them. Do it candidly, respectfully, but firmly. If you can figure out what’s expected of you, even when it’s ambiguous, and exceed those expectations, you’ll go places. If you can figure out how to deliver results regardless of your role, you’ll go places. thedailydeveloper.substack.com [https://thedailydeveloper.substack.com] This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thedailydeveloper.substack.com [https://thedailydeveloper.substack.com?utm_medium=podcast&utm_campaign=CTA_1]

Always deliver value

You have tech debt you need to address. If only you had dedicated time to fix that one longstanding issue, that one bug that you hate, or redo that thorny part of your data model. The list goes on. It’s a tale as old as time. Here’s the thing. Your role exists only because the business is alive. And the business lives because your customers are getting value from your software. Asking the business to “hold on” while you go fix something that doesn’t directly deliver value is going to be a tough sell. And it SHOULD be a tough sell. That means someone, somewhere is holding your feet to the fire on a cost/benefit decision. Instead, nest your tech debt into your feature work or your bug fixes. This will keep you grounded and help you prioritize. It will also help your stakeholders understand the value of the problem you’re solving. Fixing your whole data model to address a low priority bug that nobody will ever see is a real questionable use of your time. Furthermore, even if you are granted permission to work on your tech debt, you should absolutely still nest it under some kind of deliverable value anyway. If you don’t do this, you run the very real risk of balooning the scope of your work. And it’s especially true if you have a manager who isn’t experienced with such projects, maybe doesn’t have the air cover to hold you accountable, or a myriad other reasons. Engineering is often the most expensive team in a company. Be a good steward of those resources and always deliver value when you ship code. Thanks for reading The Daily Developer! Subscribe for free to receive new posts and support my work. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thedailydeveloper.substack.com [https://thedailydeveloper.substack.com?utm_medium=podcast&utm_campaign=CTA_1]