Afleveringen
-
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 -
Zijn er afleveringen die ontbreken?
-
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 -
When I first learned Java, I set to work creating a chatroom program.
Mind you, I didnât have any other friends who could run this program on their computers, so there was literally nobody to chat with.
I also didnât know how hard it would be. I used AIM every day, I thought - how complicated could it be?
I ended up writing what I now know as a new protocol. I used Sockets and Streams and wrote parsers for commands that would be issued over these streams and interpreted by the chat software.
I didnât know it was hard, so it didnât feel hard. I just figured it out. There was nobody to tell me I was naive or stupid for trying to build something that complex, that early in my career. I didnât know any better.
This sentiment has many echoes in the world, the most famous of which may be Jobs and Woz: when they made the Apple 1, they werenât trying to start a computer company; they were just trying to get a computer. If they couldâve gone out and purchased one, they would have.
Sometimes a bit of naivety is healthy.
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 -
Wilson sat across from me at one of my early programming jobs. I remember when someone would walk up to him, in person, usually stressed out, and urgently describe to him an issue they had encountered with the software.
What did Wilson do? Did he fume? Did he throw a temper tantrum at being interrupted?
No, he smiled. Smiled! He smiled and wrote down everything they said and told them that he would do his best to figure out the issue. Sometimes heâd ask a few clarifying questions.
Then he would get back to work.
Be Wilson. Be cheerful when someone interrupts you to report an issue. Theyâre giving you a gift to make your software better.
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 -
When faced with a challenge, we all default to use the tools we know.
For so many of us, thatâs code. Whether itâs needing a new blog, a solution to a parentâs tech problem, organizing photos, needing a personal organization system, or thousands of other examples, so many times we reach for software.
I remember the first time I met someone who, faced with a challenge like setting up a marketing blog or whatever, instead of writing code, would write up a job description and hire someone to fulfill the job. It blew my mind.
My brain immediately went into cost/benefit mode. Surely hiring someone is far slower, more expensive, and risky?
Actually his solution was better. The job got done, and it got done quickly. He delegated effectively, giving them context and control of the project. And it didnât take much of his time.
If I had used the tools familiar to me, it wouldâve taken my time away from other valuable projects. It would have probably gotten done halfway, then Iâd get distracted by some other more important thing, so the whole thing wouldâve taken longer. And, in pure dollars, a software engineerâs time is usually more expensive than a marketing managerâs time.
Be mindful of the tools that you know, and how that selection of tools influences your work.
Thatâs your Daily Developer meditation for today. Just a reminder that we publish to Substack every day, so be sure to subscribe to receive your Daily Developer meditation direct to your inbox.
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 -
Early in my career I worked closely with an extremely experienced engineer on a python project. I was headstrong and egotistical about how great my code was. He was quiet and unassuming.
Guess who wrote better code?
One time while I was observing him write code, I was struck by how much his version control system was interwoven into his entire process. After writing or changing a piece of code, he would constantly switch back to his terminal and look at the diff. Many, many times. He would make small commits, even within a file (git add âpatch) approximately 100 times more frequently than I ever would have.
At first I thought this was pretty strange, but after working with him for awhile, I realized how liberating it was. I copied his behavior without really understanding it, and Iâm very glad I did.
There is a sort of cognitive load that was lifted from my shoulders. Increasing my discipline with my commit strategy exposed all of the gaps in my knowledge of my tools and it increased the clarity with which I could hold my code in my head.
Give it a shot sometime - make your commits more often than you think you need them. Observe how it affects your work product.
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 -
Tension is required to make something wonderful.
Whether itâs a difference of opinion, perspective, or passion, the combination and debate between and amongst differences makes for a diverse garden of ideas.
Someone once explained this to me using the analogy of erecting a circus tent: in order to put a big tent up for everyone to enjoy the show, you must apply tension in exact opposite directions for the roof of the tent to raise. These forces need to be balanced, otherwise the tent wonât go up, it will flop to one side.
Next time you find yourself or your colleagues debating at work, remember how important it is to balance the tension.
Thatâs your Daily Developer meditation for today. Just a reminder that we publish to Substack every day, so be sure to subscribe to receive your Daily Developer meditation direct to your inbox.
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 -
In my first day on the job, I was tasked with synchronizing our python applicationâs user accounts into our support software via their API. Easy enough, I thought.
Like a disciplined engineer (I thought), I created a new sandbox account to test this API integraton against. Ran the thing like 100 times, fixing bugs along the way.
About an hour later, I got a message from our CEO informing me that all of our customers had been getting hundreds of email invitations to the support desk.
Whoops.
Turns out, sandbox wasnât so sandboxed. How could I have known?
This lesson is marrow-deep for me. Always, always double check external services (and development vs. production email configuration for good measure) when running them with production data. (Better yet, donât use production data.)
Luckily I got ahead of the problem and proactively wrote out an email that could go out to the affected customers. My manager appreciated that and, honestly, who hasnât made a dumb mistake like this early in their career? Iâm appreciative that they were so supportive.
Check and double check everything when using external services.
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
