The Finger and the Moon

Nov 13

Build the ladder. Keep your eye on the moon.

By Mike Moegling

The Commute

I'm on my way to work, sharing the road with everyone else who is busy driving to school, driving to work, driving to appointments. We're all busy. And it's a beautiful fall day here in Northeast Ohio. About half the leaves are down, and the ones still up are gorgeous. It's a crisp day, but not too cold.

It's a good day to think. I do my best thinking in the fall, and I enjoy it immensely. Maybe it's the sweep of the weather, maybe it's mostly apple cider, probably both.

One of the things I've been thinking about lately is the work I do. It's my trade, and it's what I love: software development, building solutions, creating things that make work and life better for people. Continual improvement. Taking a great idea and making it something tangible, something real, out of nothing. Software development has changed immensely for me, and if you're a developer, probably for you too. Let me start with a few of the shifts I'm noticing.

The Ground Is Shifting

1 Security and the stack underneath us

Dependencies buried deep in our software stacks are now under scrutiny because of security exploits. Most of what I build isn't exposed to the outside world, but I pay attention to anything that rises to the surface, or even gets near it. Take PHP. Everyone sneers at it, yet the often-quoted figure is that roughly 70 percent of the web runs on it. I'm not here to twiddle over a particular PHP bug. The point is how many familiar systems sit on stacks that are intertwined with the Internet.

Even Microsoft Word is quietly reaching out. I open Word, the professional edition I get at work and subscribe to at home (maybe not for long), and there is a big Copilot prompt across the top, eating the room I need for my document. I didn't ask for that. I don't want to see it, and I'm going to figure out how to get rid of it. The same goes for the endless plug-ins that add AI to everything. I understand the appeal. AI has been a tremendous help to people trying to get things done. But every time a program decides it wants to do something on the Internet, that's a door, and a door can be an open hole into your computer.

We saw how costly that can be in a recent, enormous theft from a company working with cryptocurrency, where the root cause was a compromised developer laptop. I listened to the details and didn't take notes, because I hope I'm never in that position. My thinking is simple: in the rush to ship more features, companies have pushed their crucial big-iron systems closer and closer to the Internet boundary, and I'm not a fan. The outside world needs a place to connect and touch. But the important things belong behind locked doors, with only the required transactions allowed through. Those transactions are sacred, and it's our development work to keep them safe.

2 The constant churn of layoffs

Developers work hard to become developers. They gain experience, they work to land at the best companies, and then they get let go and migrate somewhere else. It's difficult, and it carries a hidden cost. Spending a decent amount of time at one company builds intellectual property in your head: you come to know the software, the systems, the practices, and how things really work. Your thinking stops being rooted in the codebase and becomes rooted in how things should go together and which pieces matter most. You start thinking architecturally, across teams. If people are constantly pushed around, that domain knowledge never develops, and domain knowledge is often what separates a superior product from an average one.

And these are livelihoods. This is how we pay the bills and feed our families. We need to work. It isn't good.

3 AI and the question of reviewing the code

The last shift is AI itself. There's a lot of debate: should we read the AI's code? Should we review it? We are throwing the principles we've used as a shield against floods of bugs at a technology that works very differently from the way we do. After many years in this field, I can see why we do it. But it's worth remembering that there can be value in methods we're not fans of. Not being a fan doesn't mean there's no value. Which brings me to one of the most beloved and belittled methods in software.

The Plan That Defends Versus the Plan That Defines

Waterfall, with all its permutations: stage gates, big plan up front, Big Design Up Front, BDUF. A mastermind, or a few of them, build an elaborate plan full of requirements and specifications, declaring every object that needs to be built. Quite often, once development is under way and someone opens the hood and exposes how things really work, that plan becomes irrelevant. And these plans are often written not by senior developers but by product managers, project managers and business analysts. I'm not criticizing their work. It's good that we thought about it.

But here's the trap. By the time the big design reaches the project manager, who builds the project plan and schedules the meetings, we've done work that is aimed more at defending the project than defining it. That is a big difference. When you approach something that needs to be done, it matters that no assumptions are hidden, and also that none are carried forward unexamined.

What the Agile Manifesto actually said

After decades of big design up front, a group of practitioners wrote the Agile Manifesto in 2001. As I understand it, and as those who were in the room tell it, it was written for developers, not project managers: look at what needs to be done, find the best path to a minimum viable product, and chart a course forward. Seventeen people met in Snowbird, Utah, and wrote four values:1 2

Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan.

The key word is "over," not "instead of." The authors were explicit that there is value in the items on the right; they simply valued the items on the left more. The manifesto stands behind twelve principles, including early and continuous delivery, welcoming changing requirements even late, measuring progress by working software, and regularly reflecting on how to get better.3 4

Since then we've torn it apart, put it back together in different forms, and bolted on Scrum and more. It got very big. Most companies now seem to practice a muddle of waterfall and agile: here's the project plan, and here's the documentation to cover our backsides. That's still extremely ineffective.

Judgment over ceremony

Scott Berkun's The Art of Project Management, later revised as Making Things Happen, argues that good project management is mostly judgment: sound decisions, clear priorities, and leading people rather than just maintaining schedules. 5 6 Several of his lessons sit comfortably next to agile thinking:

Prioritize ruthlessly, and say no to protect the important work .7 8
Be optimistic about the vision and skeptical about the schedule. 9
Plan for change. The more volatile the project, the shorter the milestones should be. 9
Find the critical path and remove the obstacles that actually determine progress, including slow decisions and team process, not only technical tasks. 7 10

I'd add one thing from the trenches. Project managers sometimes don't realize how driven developers, designers and analysts are. Give them a mission and they will reach it, and they will uncover every single dead body along the way. The project manager's real job isn't to soften those findings. It's to deal with the bodies and keep the new work moving.

Berkun's weekly review, borrowed

What are our most important outcomes, in order?
Does current work clearly support them?
What should we stop, defer, or decline?
What dependency or undecided question is blocking progress?
What have we learned that requires changing the plan?

A Wormhole, Not a Miracle

I've been working with AI for about a year and a half, which is not long, and maybe not as intensively as many people. But I've found a sweet spot for getting my work done, and I keep exploring ways to get better at it. I work with a lot of legacy, older software, and I'm writing a lot of brand new things too. I have a big project of my own that is, in many ways, new ground for me.

I'm getting bigger and bigger wins, and not just from AI doing the typing. It gets me from point A to point C much faster. I describe it as a wormhole, or a time machine: it covers great distances of time and space, and in software development that's the whole game. I know the goal, and I can go start to finish. But it's work. AI works me hard. Think about how to phrase this prompt, dig into this, capture that, stop, pause, come back, work and work and work. One of the biggest misconceptions about AI is that you ask a single question and receive a magnificent miracle. That almost never works.

It also changed how I see myself. Coding is part of it, because there's no way around that, but I'm looking at the work as a developer: how do I get something built across technologies and code paths I may never have taken before? I'm a subject-matter expert in some things, not in everything. I only have so much time and effort to take a new area from zero to one hundred. That's what AI has done for me.

My 29 Pages

Here's my confession. On my own project, which I think is an important software offering and which I hope to release soon, I took my usual path: big waterfall, big design up front. I wrote 29 pages. But it wasn't only about how the application works. It included my core principles as a developer. It included what a person who buys software is entitled to: ownership of their own data, security, how they're charged. A lot of us are tired of the bleeding of subscriptions and SaaS products. It covered people who want the application on their desktop, portable between computers. It also listed what I do not want in the package, and, importantly, why.

I reasoned that these AIs are built on large language models, so I wrote one of my own. (I'm joking.) What I really did was think it all the way through, because I'm merely a human with a bowl of mush between my ears, and nobody gave me an instruction manual.

Looking back, I'm very conscious that I may not have needed all of it to get the AI started, settle on a technology stack, and decide where the security layer goes. I could have started earlier and moved faster. I think some of that was my own insecurity in this new world. I'm there with the rest of you, learning hard, and if you're not learning right now you're falling behind. That's just reality.

Still, notice what that document was. It wasn't written to defend a project. It was written to define one: the principles, the purpose, and the reasons. That's the difference I was talking about earlier.

My Son and the Ladder

I've had some really good conversations with my son, who I think is brilliant, an entrepreneur's entrepreneur. His trade is remodeling. He's exceptionally detailed and very good at designing and delivering to his customers. He has done work for me, and every time I walk into a room he's finished, it feels like walking into a brand new house. But like me, he has a back and knees, and at his age, which is the age I was when the check-engine light came on, you start to realize you can't do this physical work forever.

So he took some well-thought-out ideas and started a software startup. As he shared things with me, I stood back thinking: this guy is expressing lessons that came to me in droplets and small streams. He's using local large language models, telling them what he wants. He has applications out in pilot with hundreds of users, and he's being more productive than most of the developers I know.

He isn't writing code. He says he doesn't care about the code. He cares about the tests. He cares whether things are structured and done right, and he cares about security. He points multiple agents at different pieces, studies the results, comes back, and keeps working. He shared one thought that captured it, which I'm including below. You may want to argue with it. I can't.

I saw this video the other day that said if you tell a worker and a genius to build a ladder, the genius will sit and write a plan of exact materials and rung spacing, and engineer it to work better than any ladder before.
The worker will find immediately available materials and get to work. He will have a crude ladder built before the genius even has his plan and research finished.
The idea is to build a ladder fast, learn what didn't work, fix it on the next run, and repeat. The moral was: don't sit idly and plan. Get busy and find out what works.
— Justin Moegling

Notice how closely that sits next to everything above. It's the Agile Manifesto in one paragraph. It's Berkun's short milestones. It's working software over comprehensive documentation. And it's the reason I wonder whether my 29 pages was the genius's plan.

The Finger Is Not the Moon

Which brings me to the saying I keep returning to: the finger pointing at the moon is not the moon. It has roots in Mahayana Buddhist scripture, especially the Lankavatara Sutra, generally dated to around the fourth century, and it later became closely associated with Zen. In D. T. Suzuki's translation: 12 13

As the ignorant grasp the finger-tip and not the moon, so those who cling to the letter, know not my truth.

Its original meaning is about language. The finger stands for words and teachings; the moon is the reality they point to. The warning isn't that the finger is useless, since it tells you where to look. It's that you can cling to the letter and miss the truth entirely. A later text, the Shurangama Sutra, says it more fully: someone who looks at the pointing finger and mistakes it for the moon loses not only the moon but the finger also. 11 12

To be fair about the history, these scriptures attribute the teaching to the Buddha but were composed centuries after his lifetime. It's a traditional Buddhist teaching, not a verified quotation, and the modern one-line wording is a concise rendering of the older metaphor. 11 12

Getting Things Done, Another Finger

Here's a finger that has served me well: David Allen's Getting Things Done. Its central idea is to get tasks and commitments out of your head and into a trusted system, so you can focus on doing them rather than remembering them. It has five steps: 14 15

Capture. Write down everything that has your attention, without organizing it yet.
Clarify. Decide what each item means and what the next concrete action is.
Organize. Put reminders where they belong: action lists, calendar, projects.
Reflect. Review regularly so the system stays trustworthy. The weekly review is the heart of it.
Engage. Choose an action and do it, rather than reconsidering your whole plate.

What I like is the emphasis on the next physical step rather than the vague outcome. "Sort out my finances" becomes "download last month's bank statement." And if something takes two minutes or less, do it now. 16 17 That is the worker's ladder in miniature: find the nearest material and start. Notice, too, that Berkun's weekly review and Allen's weekly review are cousins. Good methods keep landing on the same few habits: small steps, honest reflection, and regular course correction.

So What Is the Moon?

Waterfall is a finger. Agile is a finger. Scrum is a finger, and so is GTD, and so is Berkun's book, and so, honestly, is my 29-page design. Even the ladder story is a finger. Every one of them points toward something, and none of them is the thing.

The moon, for the work we do, is simple to say. It's a minimum viable product, or something that is safe, secure, robust, accurate, working, complete and well done, and, when there is a problem, something you can quickly address. Isn't that what we are really trying to do?

That is why I can't argue with my son. The method matters only to the extent that it gets someone to the moon. For him, it's agents plus tests plus constant study of the results. For me, it has been the wormhole of AI, with discipline about security, and a design document that defines rather than defends. Plan enough to know where you're headed and what must never be compromised. Then build the crude ladder, learn what failed, fix it, and climb again.

So I thank you for enjoying this commute with me. When we think about projects, remember: the finger points to the moon, and the finger is not the moon. Let's shoot for the moon, and let's hit something today.

Honor your heritage. Engineer your future.

Quick Takeaways

Security: keep the crown jewels behind locked doors, and let only required transactions through.
Plans should define the project, not defend it.
AI is a wormhole, but it works you hard. One question never produces a miracle.
Build the crude ladder, learn from it, fix it, repeat.
Methods are fingers. The moon is software that is safe, secure, robust, accurate, complete, and quick to fix.

References

The Finger and the Moon

The Commute

The Ground Is Shifting

1 Security and the stack underneath us

2 The constant churn of layoffs

3 AI and the question of reviewing the code

The Plan That Defends Versus the Plan That Defines

What the Agile Manifesto actually said

Judgment over ceremony

A Wormhole, Not a Miracle

My 29 Pages

My Son and the Ladder

The Finger Is Not the Moon

Getting Things Done, Another Finger

So What Is the Moon?

Quick Takeaways

References

The Agile Manifesto

Scott Berkun, The Art of Project Management / Making Things Happen

The Finger and the Moon

Getting Things Done

Red Light Fever