Microwaves, Mazdas, Pallets and Packets
Microwaves, Mazdas, Pallets and Packets
Back in business
Hey there! It’s been a little bit since the last newsletter. After taking a break to get myself back to good health, I’m ready to pick up where we left off. We have a bunch of new subscribers this week, and even got a shout out from Andy Baio!
I’m going to be experimenting a bit with the content of this newsletter over the next few weeks. I’d love any feedback you have!
“Code is only 60% of shipping a new feature”
This is what my team manager told me recently during one of our 1:1’s. We had a problem with a project that ended up being delayed by a week. We ran right up to the deadline and just weren’t able to deliver on time. It happens. But what I had never really given thought to was that because we didn’t deliver on time, that meant that marketing, sales and other involved departments that handle the other 40% had to push their timelines back on very short notice. That also meant shifting their other project timelines.
We’ve all been frustrated by tight deadlines, shifting goalposts and last-minute design changes, but I think we sometimes forget that when we don’t hit our deadline, it affects other departments in the same way. Marketing has to publish copy, sales needs to loop their clients in, as well as other moving parts.
The solution isn’t to always hit the deadline on time. That’s not always possible. Emergencies happen. Production servers go down, a team member gets sick, the project scope changes. What is the solution, is good communication.
As someone who struggles with imposter syndrome, I’m sometimes nervous to tell my manager that I’m having a problem with my work. What I’ve been learning is that when I communicate problems to my team early and often, we’re able to make helpful adjustments. That could be brainstorming solutions, re-scoping the project, or maybe even pushing the deadline back a little bit. No matter the decision, communicating lets everyone know what’s going on, and how we can move forward.
60% isn’t completely accurate, it will be different depending on the project, how your business is structured, what other teams are involved, etc. The point is that we shouldn’t forget that even though we’re building the feature, the work is not done after we push it to production. We need to communicate any problems early and often so that other departments down the line can shift accordingly.
SPONSORED
Digital Ocean offers a developer-friendly cloud infrastructure designed for the needs of modern software projects, with straightforward pricing and powerful compute options. Experience the performance and support tailored for software engineering success by trying Digital Ocean today.
This Week’s Bug Stories
☔️ The Wi-Fi only works when it's raining - A great reminder that we are always bound to the law of physics.
🚗 The Roman Mars Mazda Virus - [Podcast] - This is a wonderful investigation of a strange bug in the hardware of a car stereo.
🍴 Microwave oven to blame for mystery signal that left astronomers stumped - A mystery solved 17 years later.
🧴 Black magic causing database server timeouts - This is a long-time favorite that I somehow lost and re-found recently. So many suspects in this one.
Being A Better Software Engineer
I will be posing a weekly question to you, dear readers, on how we can be better software engineers. Your responses will be added to next week’s newsletter.
My question this week: What are your tips for effective code reviews?
See You Next Week
If you have a great story or just want to drop a message my way, you can respond to this email, or send me an email at submissions@500mile.email.
Bye! 👋
- Harley