Curated Content May 2024

Articles

Investigating the Central Claim of Agility - Does Frequent Delivery Create More Value

While this article doesn't gather empirical evidence for agile product and software development, it does provide a mathematical basis that shows that it should logically follow, and that one was interesting, because it does it on the same throughput basis that Eliyahu Goldratt puts forward in all of his works.

A fun read, even if it's something that just confirms a pre-existing belief of mine.

Make It Work, Make It Right, Make It Fast

This, and the following, come from the c2 wiki, which is a great resource that I would hope you're already familiar with, but if not, this one highlights the order of operations I want software engineers to assume when building.

Often they'll cut right to making it right or fast, before verifying it works, and end up throwing out a lot of code that isn't fit for purpose.

In this case works, means works for the user, followed by right, which would be "good code", before bothering with fast.

Do the Simplest Thing That Could Possibly Work

This is another one I find software engineers can struggle with. Rather than trying to make the simplest possible solution to a problem, we can get fascinated in engineering our own complexity, under the guise of "just in case" or "when we scale".

Don't worry about tomorrow's problems today. They'll either be there tomorrow, or they won't. If you're a startup, the much more likely scenario is they aren't (either because you're not around, or they weren't the real problem).

If SaaS Products Sell Themselves, Why Do We Need Sales?

Some people think the sales force’s job is to communicate value to customers. To these people, sales is about buying a bunch of search ad words or mouthpiecing a company’s message.

They’re wrong.

The true purpose of sales is to create new value for customers

...

Because of course there was no budget for data center automation back then — the market hadn’t been established yet. Our job was to go out there and show customers a different but better way of doing business.

Books

Code Review Anxiety Workbook

While I believe pairing is almost certainly a better bet than async code review, it's still a practice widely used in the industry, and something I'll use somewhat frequently as well personally.

Given that the above is true, this workbook to reduce code review anxiety is an extremely worthwhile read for individual engineers and teams.

Conf Talks

No conf talks this month.

Podcasts

No podcasts this month.

Microposts

I certainly had some posts I liked this month, but I neglected to save, so once again I'm letting you all down this month. Hopefully June will be better that way.