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.
In my experience, consensus is tricky. Usually, the loudest or most aggressive team members, or someone with authority, will voice an opinion and the less aggressive team members will back down. At this point, everyone will pretend there is consensus. But the ones that backed down will secretly feel resentful or controlled.
I would like to think there is a better way than pretending that you can always reach a consensus. I would rather let people "agree to disagree," and pick a reasonable way to move forward when they do.
Sadly, at the last few places I have worked, I have been forced to use Microsoft Teams. It does a poor job sharing code snippets, which, as a programmer, is one of the main things I need it for. Besides that, it is buggy and the interface is awkward.
Is everyone switching off of Slack (which is far superior) to Microsoft Teams because Teams comes free with a Microsoft license? Is Teams the new Internet Explorer?
Or is it some kind of security compliance thing?
Discord is free. Why don’t more businesses us that?
I am curious what other people are using, and if they have managed to escape the Microsoft Teams trap.
What I just can't understand is how you can have someone as well respected and central to the agile movement as Martin Fowler make the following statement, and managers the world over will still continue to mandate their own versions of agile processes on software developers. Some managers I have encountered even fancy themselves real agile experts. They'll say things like, "I really like that Martin Fowler guy. He knows his stuff. I trust him." But anything Fowler or any other prominent figure in the Agile community says about giving choice and autonomy to developers goes in one ear and out the other. What gives?
And yet what I'm hearing so much is the Agile Industrial Complex imposing methods upon people, and that to me is an absolute travesty.
I was gonna say “tragedy”, but I think “travesty” is the better word because in the end there is no one-size-fits-all in software development. Even the agile advocates wouldn't say that agile is necessarily the best thing to use everywhere. The point is, the team doing work decides how to do it. That is a fundamental agile principle. That even means if the team doesn't want to work in an agile way, then agile probably isn't appropriate in that context, and [not using agile] is the most agile way they can do things in some kind of strangely twisted world of logic.
So that's the first problem: the Agile Industrial Complex and this imposition of one-best-way of doing things. That's something we must fight against.
https://martinfowler.com/articles/agile-aus-2018.html
Programmers (all knowledge workers really) ought to be forming co-ops to escape the plight of modern day wage slavery. We know how to self-organize. In co-ops we can have more autonomy and higher wages. What is holding us back?
Wage slavery is a term used to criticize exploitation of labor by business, by keeping wages low or stagnant in order to maximize profits. The situation of wage slavery can be loosely defined as a person's dependence on wages (or a salary) for their livelihood, especially when wages are low, treatment and conditions are poor, and there are few chances of upward mobility.
https://en.wikipedia.org/wiki/Wage_slavery
Gary Hamel and Michele Zanini make the case for more market forces and autonomy at work--exciting ideas for the future of work.
https://fortune.com/2020/11/21/capitalism-entrepreneurship-economic-inequality-us-bureaucracy/
I love the Hacker FAQ. It’s a classic:
https://www.seebs.net/faqs/hacker.html
A fictional dialogue that (hopefully) highlights some inequalities in business today—which I believe can be rectified by migrating to employee-owned and managed organizations.
Has AI replaced everyone’s rubber ducks yet?
In software engineering, rubber duck debugging (or rubberducking) is a method of debugging code by articulating a problem in spoken or written natural language. The name is a reference to a story in the book The Pragmatic Programmer in which a programmer would carry around a rubber duck and debug their code by forcing themselves to explain it, line by line, to the duck.
Here is an honest question that got me in trouble at work:
“Are code reviews supposed to be like proofreading a paper, where you are allowed to choose which suggestions to use and which you will disregard, or are they like a gate where the reviewers are the gatekeepers and every suggestion must be incorporated before the code is accepted?”
Management thought this question was inappropriate, because it “assumes that we aren't all on the same team.” I thought my question was fair, because it's only natural for people to disagree in which case you need to have a way to determine who “wins.” When I used the word “win,” it really set management off.
What's your take?
I’m looking forward to trying out Ghostty. Mitchell Hashimoto always does great work.
I'm ready to take a deeper look at Zig. I have wanted a C alternative and have felt like Rust was too complicated. Zig feels like a nice middle ground. The built-in build system is one of the things I am most pumped about. Anyone else using Zig?
“Founder mode” is to a startup as “Benevolent Dictatorship” is to an open source project. Both work really well -- and neither of them is micromanagement.
Founder Mode: Elevating Individual Contributors
Contrary to many circulating opinions, Paul Graham's founder mode is a good thing—especially for individual contributors, and it certainly doesn’t mean you should micromanage anyone.
Peter Norvig mentions a fascinating discovery made at Google:
One of the interesting things we found, when trying to predict how well somebody we've hired is going to perform when we evaluate them a year or two later, is one of the best indicators of success within the company was getting the worst possible score on one of your interviews. We rank people from one to four, and if you got a one on one of your interviews, that was a really good indicator of success.
--Peter Norvig (Coders at Work - oreilly.com/library/vie…)
Something very interesting is going on here…
The most dangerous way to lose time is not to spend it having fun, but to spend it doing fake work.
Things that are radical are by definition not evolutionary from the state of where things are at.
Today “where things are at” is that big companies are pouring immense resources into ecosystems and editors and profilers and tools and programmers and skills and all that kind of stuff. The mainstream is, by definition, deeply practical. Meanwhile this radical and elegant stuff of functional programming has much less of that deep, infrastructural support. But at the same time that doesn't necessarily make it self-indulgent to pursue it. Because, after all, unless some people are working on radical and elegant things you're going to end up in a local optimum, incrementally optimizing the mainstream but stuck on a low hill.
-- Simon Peyton Jones (Coders at Work - oreilly.com/library/vie…)
I feel the same way about literate programming as Simon does about functional programming. It has the potential to radically change how programming is done, especially when paired with AI. But the industry is optimized locally in a different domain.
I like to spend time over on literate programming hill, even if the tooling isn't all there yet.
The Joy of Literate Programming
Intro Literate programming is a lot of fun. It's a great way to document your source code, and its macro capabilities are powerful enough to greatly enhance the coding experience itself. However, to be honest, it’s hard to convey the joy of literate programming without demonstrating it. So, in this post, I’m going to walk you through a simple example tha…
Enjoy your week!