Join me as I talk through some hard-earned lessons on hiring and recruiting.

Links:

* The Daily Developer

* Firing Well

* The Five Dysfunctions of a Team

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

Links:

* Why are non-DRY specs more maintainable?

* The Maintainable Software Podcast Episode with Jeanine Soterwood

* Simple Made Easy by Rich Hickey

* Patterns of Software by Richard Gabriel

* The Psychology of Computer Programming by Gerald Weinberg

* Sandi Metz: Duplication is better than the wrong abstraction and POODR

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

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://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

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

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

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

Everyone you work with will remember how you made them feel.

If you are remembered as someone who loves to engage in debate and grudgingly give in when you’re proven wrong, that’s a failure on your part to recognize the opportunity in front of you.

Instead of focusing on which person or idea is right and who’s wrong, try to realize that such classifications are often themselves misguiding.

Shifting to a strategy of being effective will quickly demonstrate how silly it is to try to be right all the time. Instead, you begin to focus more on the problem instead of the set of solutions. You learn to get at the root of the problem, talking to users or investigating root causes. This means you learn more about the domain and gain clarity and context surrounding the problem.

Then, when you get to the issue of identifying the solution, you can lead by example. Think about how to get the group to find the right solution together. You can even go so far as to not suggest any specific direction yourself, or lightly take on the socratic method. When the group finds a solution, celebrate the parts of the process that worked well. Retro on it with the group and help everyone solve the problems together.

The real win here is to become a concentration of great technical leadership within your group. Imagine the difference between that and being argumentative about your specific suggested solution. It’s no contest.

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

If you want to have an outsized impact on the world, on your team, on your product, or whatever, you will almost certainly have to work hard.

This isn’t a popular notion in the age of Twitter, where such an idea is often dismissed as “hustle culture”, labeling it as toxic.

But it’s true.

Whether you’re trying to make a dent in the world or climb up the technical ladder at your company, you can’t expect to sit back and just watch as accomplishments come to you. You have to go get them.

If you’re new to the world of software development, you might need to hear this the most. This job will be hard. You will have to sacrifice. You will encounter interpersonal obstacles that will challenge your morale and your energy.

It’s tough out there. In a world where we are all managing our public image on social media, marketing ourselves and conveying our strengths, it can be extremely deceptive to newcomers. When we tweet about our technical challenges, it makes us look more competent because we’re okay sharing our lessons with the world.

But you don’t see people tweeting about the PIP they were just put on, or the disastrous conversation they had with a colleague. We don’t generally share the negative consequences of our own actions when we’re embarrassed.

And you will be embarrassed. Technical mistakes are comparably easy to let go of, I’ve found. Interpersonal mistakes are much tougher.

Innoculate yourself against this by embracing humility, seeking feedback regularly, and fostering a growth mindset.

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

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

Have you ever heard anyone use this phrase to describe someone? I have.

It’s actually an incredible compliment. To describe someone as your favorite colleague means so many things to me - it conveys trustworthiness, professionalism, no-b******t, a certain level of skill, and so much more.

I think there’s one thing that every single developer can do to elevate themselves in the eyes of their colleagues, and it’s not hard: proactively update others.

Instead of waiting for your PM or boss to ask you how things are going, proactively communicate this to them. Whether it’s in a team setting or privately, I absolutely guarantee that it will be worthwhile.

It has secondary effects too. Shifting to proactive updates forces you to think through your status and plan of action. You can collect whatever questions you need answered or information you lack to make progress ahead of time and put them all into a single high value update.

You’ll be more prepared, your colleagues will respect you just a bit more, and you’ll be setting a good example for others on your team. So, you should just do it.

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

I learned so much from my first software engineering job. Some of the lessons make me squirm a bit.

When I joined this company circa 2010, they were using subversion.

If you weren’t around then, subversion is a version control tool that predates git. Indeed, git and github were still new kids on the block, and there was a competitive version control tool called mercurial that was compelling to many people as well.

Anyway, this team I had just joined was using subversion, hosted by a tool called Trac (another ancient history bug tracking and code repository system). And while my memory of the time is a bit hazy, I remember thinking that it was just crazy that a modern software team would be using subversion instead of git.

When I reflect on this experience later, there is actually no bad reason they had stuck with this tool. It’s just when they had used forever.

Well, I made it my mission from god to switch this team’s codebase over to git.

It was a python web app that had several years of history, and it spoke with a separate API and, if I recall correctly, a custom sort of data store. All hosted by subversion.

To my surprise, the team wasn’t immediately on board with this. And I was totally blind to this fact. I just could not understand that there was a reasonable perspective representing the view that staying with subversion was the right call.

I was not making a business case to anyone, I was not speaking with my manager (I don’t think they had hired a manager for the engineering team yet), and I was not really making an argument of any kind; I was simply doing what I thought was best for the team, based solely on my own judgement.

Well, after many badly run meetings, I got it done. I dutifully switched the codebase over to git and github. And I naively lobbed git tutorials over the fence into my colleagues inboxes.

(I say naive because, as we all know, git is so famously easy to learn.)

I will leave many of the lessons of this story for you to ponder. But I will note that this one has had a big impact on my career and I think of it more often than I care to admit when I see developers go off on a mission in their teams based solely on their judgement and without any real argument.

Anyway, this one affected my karma. Because of this experience, my name was attached to the initial commit for this git repository. So for years after, possibly even today, my name is attached to the entire codebase as original author (even though I was not). So for a long time, I would sometimes get messages from later engineers who joined the team asking me about why a piece of particularly hairy code was written so poorly. Justice was served.

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