The learning snowball

Every Civil 3D tool I have written lives in one folder. Every Forma tool lives in another. The point cloud work sits in a third.

I did that because that is how my head files things, not because I had a plan for it.

The question I did not expect

I started a new Civil 3D plugin a few months in, and instead of a blank slate I got a question:

There are other Civil 3D projects next to this one. Should I read them first, and should I use the skill that was written for one of them?

I sat there for a second. Yes. Obviously yes.

But I had not asked for that, and I had not set it up. It noticed the neighbors on its own, because the neighbors were there to notice.

What I had been expecting

A blank room every time.

I assumed each new project meant explaining the same things again. Which framework the dialog is built in. Why every write belongs in one transaction, so the user gets one undo instead of forty. Which references must never be copied into the output folder.

None of that is hard. It is just tedious, and tedious is the kind of cost we pay over and over without ever noticing the total.

The folder was doing the work

Here is the part that took me a while to see.

Look next door is only a good idea if next door is relevant.

Because I grouped by the application the tool runs inside, the neighbor shares the API, the build, the conventions, and the whole set of decisions that only make sense in that one world. Reading it is worth the time it costs.

If I had grouped those same projects by the month I built them, or by which customer asked for them, next door would be noise. A parking lot tool sitting beside a spreadsheet exporter teaches you nothing about either one.

Same projects. Same agent. The folder is the difference.

Two things carry across

One is working code. Not a snippet from a forum post written for a version that no longer ships. A plugin sitting ten feet away that I have loaded into Civil 3D and used on real drawings this month.

The other is the skill. I keep one per application family, and it holds the answers that are already settled. How it builds. What the project file needs. The transaction rule. The dialog choice.

I did not write those from scratch either. They came out of the first few projects, once the same decision had been made three times and it was clear it was not going to change on the fourth.

The snowball

Look at the dates and it shows.

The crosswalk striping tool, the curb return placement tool, and the intersection generator all landed within a few days of each other in February. The first one paid for the framework. The second and third did not.

By the time I rebuilt the parking lot layout tool in June, how does a Civil 3D plugin get built around here was not a question anymore. The effort went into the actual problem, which was making the layout redraw live while you decide. None of it went into scaffolding.

That is the snowball. Each project leaves something behind, and the next one gets to start partway up.

If you are starting your own pile

Do not sort by date. Do not sort by customer. Do not make one folder called tools and pour everything into it.

Sort by what the projects have in common: the application they run inside, the API they call, the framework underneath. Put the ones that share an answer where they can see each other.

Then, when it asks whether it should look next door, say yes.

Be Better - Put like things together.