Bi-Weekly Notes
November 2, 2024 - November 16, 2024
For those of you who are subscribers but not signed up with Substack, here is a compilation of some notes that I’ve been sharing lately online. Notes are my way of making media suggestions, sharing experiences, and trying out the goofy ideas bouncing around in my head. If you are on Substack already, you may have seen a lot of these in your feed. You can safely disregard this email.
If you want to see comments or reactions to an individual note, click on the time-date stamp at the top of the entry. This link is also useful if you wish to share a specific item.
Agile is not a better way to estimate.
Building software is unpredictable. Agile practices mitigate this fact by establishing teams and software that can quickly and easily adapt to changes.
So when something unexpected happens or something takes longer than it should, you are better prepared respond.
The key is to respond to what is happening now, not predict what will happen in the future — “Responding to change over following a plan“.
Trying to plan everything out ahead of time is called Waterfall. We tried that already. It tended to produce rigid projects that ran past deadlines and exceeded budgets.
How to foster self-management instead of dependence in the workplace. Definitely worth reading.
"Walk right side, safe. Walk left side, safe. Walk middle, sooner or later, get squish, just like grape." - Mr Miyagi
So much of software engineering (and life) is like this. You can do it one way or the other. Both work. But when you try something in the middle, you get the worst of both worlds.
While compromise can be good, sometimes it doesn't benefit us, because it forces us onto the middle road.
The next time you are tempted to compromise and come down somewhere in the middle, consider a different type of compromise: pick one way this time, and the other way the next. That way you can see which way is really best, without watering down your experiment.
If your company is practicing shared code ownership, meaning everyone on the team works together on the same set of code repositories, then there is too much code for any one person to understand. Collaboration is required.
In that environment, if your boss gives you a ticket, and leaves you alone to "figure it out," they are doing it wrong.
And as you work on that ticket, if you get stuck, don't feel bad. It's not your fault.
Being stuck means your team is not collaborating enough. It doesn’t mean you’re deficient.
Don’t spend any more time stuck in the mud, wondering how you’re going to explain why you still haven’t finished your Jira ticket.
Ask someone to pair program with you—and if that’s not an option, ask lots of questions. Unapologetic and unrelenting questions.
Don't feel bad about interrupting people. If they get upset, it's their problem, not yours.
When programmers (or more often their managers) decide to work as a collective, with a shared team stewardship, collaboration is part of the deal.
If you want team members to be able to work in parallel with minimal interaction, you should give people individual code stewardship and let them become expert in their specific domains. This was a lot more common in 90s and it works fine if you do it right.
But if you are all sharing the code, you've passed on that option. And you've passed on the option of expecting programmers to all work in isolation.
It will not yield good results.
Pull Requests don’t make much sense for a team that is collaborating closely. They are most useful in projects where external contributors are submitting code for consideration. This article explains in more detail.
https://infrastructure-as-code.com/posts/pull-requests.html
I admire Donald Knuth's ability to avoid distraction. Famously, he doesn't even read email.
Email is a wonderful thing for people whose role in life is to be on top of things. But not for me; my role is to be on the bottom of things.
https://www-cs-faculty.stanford.edu/~knuth/email.html
I agree with Jon too!
In an episode of the podcast "The Problem With Jon Stewart" published this month [January, 2022], Stewart described meeting Bezos at a dinner at the White House with President Barack Obama, then-first lady Michelle Obama, the billionaire Mark Cuban, and an unnamed guest whom Stewart described as the "inventor of the Oculus" virtual-reality headset.
Stewart said Bezos discussed what he saw as the economy of the future, one that would rely on service workers to perform tasks. Stewart said he told Bezos he disagreed, adding that people wanted to feel proud of their work and like they were contributing to society, not just "running errands for people that have more than you."
"I think he views everybody as like a part of a fulfillment center," Stewart said. "And so I said, 'I think that's a recipe for revolution.' And then, like, kind of a hush falls over. And then you hear Obama from across the couch go, 'I agree with Jon.'"
https://www.yahoo.com/tech/jon-stewart-once-told-jeff-173808154.html
Building Software is unpredictable. Because of this inherent unpredictability, you should never constrain both a ship date and a feature list for a projected release. Not even adding more people to a project will get around this law. As Fred Brooks famously taught, “adding manpower to a late software project makes it later”
This a hard, inconvenient truth about software, and it makes many activities very difficult (marketing future releases, negotiating contracts, creating product road-maps), but ignoring it causes conflict and dysfunctional behavior.
Legacy code is a beast—especially when it is sufficiently large. I find it almost impossible to infer what the origin design/intent was. I found this article from Eric Raymond that is a pretty reasonable approach to diving into a new code base:
Essentially, his approach is (I have modified it a little here to make it apply better to legacy code at work, instead of just to open source projects)
Learn how to use the program.
Pick a small feature to change or add.
Search the code until you find the part you need to modify. (Do not try to read the entire program)
Make, test, debug, and document your change.
return to step 2
Raymond says, “As you go through this loop several times, you will gradually develop a more complete representation in your mind of the way the whole program fits together. At some point you will reach a threshold where you understand it all — or anyway enough of it for whatever your final purpose is.”
Does anyone have a better approach?
http://www.catb.org/esr/faqs/hacking-howto.html
Enjoy your week!