The Map Is Moving. Don't Get Lost.

My dad had a cross-stitched banner that said “Engineer, Faultless, Accurate.” My mom made it for him, which was funny in its own way because she was not especially crafty. This was not a house full of hand-stitched inspirational decor. But she made that sign, and it moved offices with him for as long as I can remember.

It was a joke. Sort of.

My dad was originally an electrical engineer. I remember going into his electronics lab when I was quite young. He also showed me a board that was important to how ink was applied on newspaper printing presses. Later in his career, he became a systems engineering consultant. One summer, as I was graduating, I worked as a data collector on a US Postal Service project he was involved in as they were adding more sorting machines at mail plants. I got to see him as an engineer at work.

With all these engineering projects he worked on, “engineer” was never only a job title. It was how he moved through the world. It was how he made decisions. It was how he understood himself.

When he died, we had to decide what to do with the sign. What do you do with a cross-stitched banner that says “Engineer, Faultless, Accurate” after the engineer is gone?

We buried it with him. That and the ashes of his favorite dog.

That is what it looks like when a profession is not just employment. It is identity.

I’m an engineer

I remember asking my dad a question during his cancer treatment. I do not remember the exact decision. I remember his answer: “I’m an engineer.”

That was it. Not “I looked at the evidence.” Not “I trust the doctor.” Not “I made a spreadsheet,” though he may have done that too. It meant: this is how I think. This is how I evaluate risk. This is how I make sense of the world when the world has become unreasonable.

I used to have that type of professional identity, “Geographer.” Conveniently, geography is a big place, and I tend to think about it more as a systems-thinking approach to the world. I also rarely work on problems where the map is the point anymore. I have dabbled in tying up my identity in my profession, though.

I have also been around people for whom the work is not just what they do. It is who they are. And I have seen what happens when the role changes underneath them.

My dad struggled when he retired. Not because he had no hobbies or no family or no life outside work, but because work had given him a place where that identity made sense. It had somewhere to go. When the work changed, the self had to change too.

That is hard. And I keep thinking about that as I watch software developers respond to AI.

The map was moving before

This is not the first time I have watched a technical profession argue about a changing map.

In 2010, after the earthquake in Haiti, a search-and-rescue team loaded OpenStreetMap data onto a GPS unit and used it for search and rescue. They were not a GIS analyst. They were not asking for a peer-reviewed data quality assessment. They were trying to answer a much more immediate question: is there a road here, and can I get where I need to go?

That is a different question than “is this dataset authoritative?” And for that purpose, OpenStreetMap was useful.

This was the thing a lot of people struggled with. The debate around OpenStreetMap was often framed as accuracy. Was it accurate enough? Could volunteers really make good data? Could you trust it? Many traditional GIS people turned their noses up at it for a while.

But a lot of the fight was not really about whether OpenStreetMap could answer a particular question in a particular context. It was about what OpenStreetMap meant for the people whose professional identity was built around being the ones who knew what counted as real geographic data.

The data was not only data. It was authority.

Fit for purpose beats perfect

Later, in Indonesia, I worked on disaster preparedness where scientific models already existed. The problem was not that no one had thought deeply about hazard modeling. The models were there.

But models need something to land on. If you want disaster managers to use model outputs, they need base-level information: roads, buildings, and the things that turn an abstract impact model into something someone can act on. OpenStreetMap helped fill that gap.

The scientific model was not enough by itself. The crowdsourced map was not enough by itself. The useful thing came from putting them together with enough domain knowledge to understand what each part was good for.

That is the point people often miss. Fit for purpose beats perfect. If you aim for perfect, then you might not get any data, ever.

Accuracy was not the whole argument

Muki Haklay’s 2010 research on volunteered geographic information found that OpenStreetMap data could be quite accurate where it existed. There have been updated studies since, but the 2010 study is where GIS hackles started going up around identity. The story was about completeness and coverage. In normal human language: the stuff that was mapped could be accurate, and the bigger question was what was missing. Just because an area was blank on the map didn’t mean there were not people there.

The discomfort was not only about evidence. It was about identity.

If you had spent years becoming a GIS professional, gone to the conferences, learned the tools, internalized the standards, and built a sense of yourself around knowing what real geographic data looked like, then a messy volunteer map was not just a new data source. It was an insult.

Not always consciously. Not always fairly. But emotionally, it could feel that way. Here were people making maps without permission from the profession. Worse, sometimes those maps were useful.

The map was moving. Some people got curious and asked how this fit into the system they already understood. Some people got defensive and asked how to prove it did not count.

Those are very different questions.

The LinkedIn version

I saw a smaller version of this recently on LinkedIn. I said code review should be optional.

Not gone. Not forbidden. Optional. A tool teams should use when it helps, not a ritual they preserve because it proves seriousness.

People reacted.

Some of the pushback was practical and fair. Code review can catch defects (though not as many as people often think). It can spread context. It can help junior developers learn. It can slow down a risky change long enough for someone else to notice the weird thing. I am not against code review. I have reviewed code. I have had my code reviewed. I have been saved by another person’s eyes on a change.

But some of the reaction felt bigger than the claim. It was not only about code review. It was about what code review represents: professionalism, rigor, the senior engineer’s role, and the idea that careful humans are the final checkpoint between software and chaos.

AI coding tools poke the same bruise.

If a model can generate a decent first pass, if tests can catch more than a reviewer skimming tired diffs at 5 p.m., if the valuable work moves from typing code to shaping systems, then a lot of developers have to renegotiate what “being good” means.

That is not a small thing.

The first experience may be the wrong evidence

One of the other hard parts about AI coding is the gap between early adopters and those who tried it once and decided it sucked.

If you tried early tools and they were bad, that experience was real. And the experience today is real too. Models and tools have changed quickly. An experience from 2022 or 2023 may not tell you much about what is possible now. Even an experience from six months ago may not tell you much, depending on the tool and the task.

That does not mean everyone should become an AI coding maximalist. It means “I tried it and it was bad” needs a timestamp.

What were you building? What model were you using? What context did it have? What tests existed? What judgment did you bring? Were you asking it to replace expertise, or were you using expertise to aim it? How much spec and planning did you do?

Those questions matter. They are the software version of fit for purpose.

The old proof is not the expertise

This is where I think developers have a choice. You can attach your identity to the old proof: I write the code, I catch the bug in review, I know the syntax without looking, I am the person who can make the machine do the thing from scratch.

Those are real skills. They still matter. But they may not stay at the center forever.

Or you can attach your identity to the deeper expertise: I understand what should exist. I know what failure would cost. I can tell when a system is lying to me. I can turn a vague need into a working shape. I can ask better questions because I understand the domain, the users, the tradeoffs, and the systems.

That identity survives more tool changes. It may even get stronger.

The people who do well when the map moves are not the ones who abandon their expertise. They are the ones who stop confusing the old proof of expertise with the expertise itself.

Don’t spend all your energy on the skeptics

I do not think you can out-evidence a person out of an identity problem. Perfect data did not silence the OpenStreetMap skeptics. Research did not silence them. Years of disaster response work did not silence them.

Eventually, enough people had adopted it that it was harder and harder to downplay the usefulness.

At some point, you have to notice what argument you are actually in.

If someone is asking good questions, answer them. If they are trying to understand where the new tool fits, help them. If they are worried about real risks, take those risks seriously. Quality matters. Security matters. Maintainability matters. Apprenticeship matters. The future of junior developers matters.

But if someone has already decided the new thing cannot count because counting it would unsettle who they are, you may not be having a data quality debate. You may be standing next to a moving map while they defend the old legend.

Spend your energy with the curious people. The ones asking questions. The ones playing. The ones with good humor.

Those are the people I want to build with.

The map is moving

I still think about that cross-stitched sign: Engineer. Faultless. Accurate.

It was funny because no engineer is faultless. No human is accurate all the time. But it was also loving. It named something my dad valued in himself: precision, responsibility, care, and the desire to be useful by being right.

There is nothing wrong with that. The hard part is what happens when the world changes the terms of being useful.

Roles change. Tools change. Proof changes. Whole professions shift under people’s feet. Some people adjust, not because they care less about quality, but because they understand that their value was never only in the old ritual. Some people get stuck, not because they are foolish, but because the change asks them to loosen their grip on a self they worked hard to build.

I have sympathy for that. I also do not want to get stuck there.

The map is moving. The question is not whether we can keep it still. The question is what we are trying to protect while it moves.