The Daily Developer

A daily meditation for new software developers

0.0 (0)
TECHNOLOGY
UPDATED DAILY

Meditations for software developers thedailydeveloper.substack.com

13/03/2024

A few thoughts on hiring

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

20 min
23/02/2024

Is duplication complex?

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

18 min
22/08/2023

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

4 min
21/08/2023

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

3 min
11/08/2023

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

2 min
10/08/2023

Being right vs. being effective

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

2 min
08/08/2023

Working hard

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

2 min
07/08/2023

The Long Term

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

3 min

Meditations for software developers thedailydeveloper.substack.com

Creator

A daily meditation for new software developers
Years Active

2023 - 2024
Episodes

16
Rating

Clean
Copyright

© Dave Paola
Show Website

The Daily Developer