I am continuing work on "Tidy First? An Exercise In Empirical Software Design" as a
@SubstackInc
. No paid tier yet, but that's where book chapters will be appearing. Sign up here: .
I’ve been reluctant to try ChatGPT. Today I got over that reluctance. Now I understand why I was reluctant.
The value of 90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x. I need to recalibrate.
My vote for most valuable programming skill? Walking. I spent 15 minutes going and picking up my laundry and figured out how to avoid 10 hours of programming. 40:1!
A 12-month roadmap is like a box of a dozen donuts & you can only eat 1 a month. By the time you get to 10, 11, 12 you'd really rather eat a fresh one. But no, you're in the Clean Plate Club so you choke 'em down.
The goal of software design is to create chunks or slices that fit into a human mind. The software keeps growing but the human mind maxes out, so we have to keep chunking and slicing differently if we want to keep making changes.
If there’s one lesson I would like the next generation of developers to learn, it is to spend less time doing hard things and more time making hard things easy. Customers benefit from the former. Customers and peers and we ourselves benefit from the latter.
Spotify didn’t implement the Spotify model by copying Spotify. Why do folks at other companies think they can implement the Spotify model by copying Spotify?
@DeanPreston
As a resident, you answer does not meet my needs. I want to park my car free from fear. If you can't help me do that, why exactly are you in office?
My code can’t be tidier than my thinking. The purpose of my tidying is to clarify my thinking by manipulating the code. The code ends up better, but because I understand more not because I somehow forced it to be better in spite of my confusion.
When you try to make fewer mistakes by making fewer mistakes you slow feedback, learn less, and make more mistakes. When you speed feedback you learn more and make fewer mistakes.
Pardon me,
@Twitter
, can you take my check mark off and give it to these folks? Nobody is trying to harass and impersonate me,
so they need it more than I do.
Don’t assume you need a big solution just because you have a big problem. Even that big solution will be built one step at a time. Choose a feedback loop that also operates at the scale of those steps.
I’ve long said that the goal of interviewing for a job is not to get hired, it is for both parties to make fully-informed decisions.
Turns out this philosophy is easier to apply when you haven’t just gotten turned down 5 times in a row.
Re: FP & TDD. More important than tests vs types is the principle of double checking. If you say something twice in independently derived ways, you're more likely to be correct than if you just say it once. Tests are a form of double checking. So are types.
Talking with a senior engineer I noticed a pattern. There were bugs. Nobody knew how many. They weren't on anyone's roadmap.
So the engineer dug in. Discovered curious & horrifying facts. Discovered a lack of organizational urgency. Fixed stuff. Encouraged others to fix stuff.
"How long is it going to take to drive?"
"Drive where?"
"Nobody knows, we just need to know how long it is going to take."
...I'm too sad, you finish this...
The purpose of your conference paper abstract is to get your paper in the A Pile and keep it out of the B Pile.
The sentences are:
* The problem
* Why the problem is a problem
* One Startling Sentence
* The implication of the One Startling Sentence
If we’re using technology X poorly and are frustrated, then moving to Y won’t help. We won’t experience frustration for a while, but only because we are distracted. All the same dysfunctions will reappear. Instead, start working better and then re-evaluate the technology.
Software design thought for the day: just because two elements are *connected* that doesn’t mean they are *coupled*. Reducing connection isn’t an effective goal. Reducing actual coupling (where changing one element necessitates changing another) is.
I've seen people trashing Mark Zuckerberg as evil and greedy. A simpler story works for me. He is profoundly unprepared for the power he wields. I'm not sure who *would* be prepared. At this critical juncture he is making mistakes with worldwide consequences.
And the tale of his days at Facebook were two thousand five hundred and ninety three. Time for some career exploration as an independent. Expect to see me try some wacky stuff.
There needs to be a word for "experiment whose outcome was not what was hoped for". Calling them "mistakes" or "failures" weakens the meanings of those valuable words.
Let's say you interested in TDD but you just can't figure out how to write a test before you write the code. Here's a foolproof exercise that let's you experience the TDD workflow in spite of that block:
P1: Aren't you ashamed of writing code like this?
P2: What do you mean by "this"?
P1: Sky-high cyclomatic complexity, inconsistent naming, & duplication.
P2: Oh, I thought you meant "profitable", and the answer is no I'm not ashamed.
Dear Software Architects,
If you want to write ADRs, write ADRs. But please also include tracking. If no one reads the ADRs, consider not writing them in future. Time spent writing ADRs incurs opportunity cost. Make sure you're getting something for the price.
I unexpectedly have two weeks free before I start my new job (more on that later). I decided to time-box write the book on software design that’s been ripening in my head for a decade or two. Here’s the outline:
Pushing The "Hardcore" Button.
There are times in my career when I would have already pushed the Hardcore Button. My self-image was based on out-working, out-intensitying everyone. I wouldn't push it now, but I can understand if someone else does. Here are 3 strategies.
Does everybody not know the trick of coding backwards? Start coding with "return result". Then the previous line "result = ...". Then the previous line and so on back to the beginning. Try it! Would make a great TikTok.
I made a big mistake when I called them "iterations". I should have just said, "weeks". Then the whole iteration length debate, where there are weird incentives encouraging too-long feedback cycles, would just be absurd.
Layoff announcement 101: do *not*, under any circumstances, ever ever mention how difficult the process or decision has been for you. No. One. Cares. No one is going to feel sorry for you. People will blame you more, not less. Just say you made a business decision and here it is.
The most entertaining aspect of
#GameStop
for me has been watching the hedge funds who thought they were the casino suddenly realize that nope they are punters too.
Writing tests is an exercise in reversibility. We put tests in place so making mistakes in the behavior of code has ~0 cost. It’s expensive, but compared to what?
It's easier to get an idea out of my head than let it ruin my weekend rattling around. Here's one: my take on why moving to micro-services is neither quick nor easy.
1. Change the code as usual
2. Write a test that only passes after the change
3. Revert to before 1
4. Type the test again (copy/paste is cheating & invalidates the warranty of the exercise)
5. Make it compile by changing the code
6. See it fail
7. Change the code to make it pass
I saw an old friend who is terminally ill. They are just doing their thing. I thought, “Why aren’t you out living it up?” That’s backwards. The question is why am I not doing something I would continue doing if I was diagnosed?
DON'T LOOK AWAY.
The cop groped her and when she tried to break away, she was beaten while standing still.
THIS IS AN ATTEMPT TO CRUSH DISSENT LIKE A DICTATORSHIP
Hey,
@Medium
. Why would I want my writing to be part of your "metered paywall"? I can see the benefit for you if it was, but I want everyone to be able to see what I write. Are you promising me millions of dollars for my 1000 readers? I don't get what's in it for me.
Drives me bonkers to see a function that takes a handful of arguments also take “args”, a hash with fixed keys.
Yo, your function takes 15 arguments. Be explicit about it. There’s lots you can do once you admit you have a problem.
Mystery: "Get it done faster/sooner/more" Why?
What happens after we get it done faster/sooner/more? I need to remember to ask this question. If there's no good answer then this is just someone pushing their anxiety down a power gradient.
Given the cost of blocking, asynchronous code reviews, I'm surprised more teams haven't experimented with eliminating them.
What bad things would happen if you just integrated changes? Are those bad things happening already? What else could you do to avoid those problems?
Experts seldom solve problems by stretching their skills to the limit. First they spend considerable effort decomposing the problem into tasks that can be solved with ordinary skills.
Whenever you push a button and the light doesn’t come on there are 3 options:
• The button is broken
• The light is broken
• You didn’t actually push the button
All the talk about the Four Rules of Simple Design got me inspired, so I added a reference card to my Etsy store: (For those of you not following along at home, my Etsy store is a sample 3X Exploration.)
I'm not proposing to charge you $X for an hour, day, week of my time. I'm proposing to charge you $X for the influence *you* asked *me* to have on you and your team. I'm happy to recommend good people who work for less.
Coupling vs cohesion.
Coupling:
• Can be hard to find
• Can be really hard &/| expensive to eliminate.
Cohesive sub-elements are:
• Usually easy to find
• Cheap to achieve, &
• Help you find de-coupling.
Just learned a beautiful new phrase: execution through momentum. When a team finds its rhythm you don't have to work to keep it going, you just have to work to keep it from being disturbed.
Mark this day on your calendars: I agree with Mr. Alan Cooper. The foundation of agile is programming together. Don’t build the house without first laying the foundation. (Once you lay the foundation you may not need a fancy house.)
When I started programming, it was a solo skill, performed by individuals, with little or no sharing and virtually no collaboration. A culture was built around those facts. 1
Big difference between being confident in your decisions and being confident in your decision making. Confidence in decision making means you believe you couldn’t have done a better job right now, but you have a feedback loop (and data/story gathering) to review the decision.