From GIS Analyst to Software Engineer

A few years ago, Dan Mahr moved from being a geospatial analyst to a software engineer.

Why and how did he do that?

What was his thought process?

He’s here to tell you everything you need to know if you’re thinking of doing the same.

HOW DID YOU GET INTO GIS?

I started off as a GIS analyst, straight out of university, working for a medium-sized government contractor in the environmental sector.

I mostly did typical GIS analyst stuff using ArcMap and ArcGIS desktop — making one-off PDF maps for reports and visualizations and environmental justice analyzes using demographic data from the Census Bureau.

It was junior-level GIS analyst-type work mixed in with some non GIS entry-level consultant work — an unremarkable entry-level position.

WHAT WAS IT THAT MADE YOU THINK, “I DON’T KNOW IF THIS CAREER PATH IS FOR ME?”

I liked the geospatial component of things. I enjoyed solving a problem and then seeing the result. It wasn’t just a Microsoft Excel model or some database table. It was something I could visualize in GIS software.

If there had been a path to becoming a more in-depth GIS analyst at this company, I might have stayed on it.

But in this case, there wasn’t a lot of growth potential for a straight-up GIS analyst. If you wanted to move up, you had to move into project management, personnel management, or specialize in a relevant subject.

WHY PROGRAMMING? DID YOU KNOW PROGRAMMING BEFORE?

In my undergraduate studies, I had a small amount of programming exposure, but it was not from experts.

It was to support my undergraduate research, which was remote sensing. This was in IDL, an esoteric language that probably only the Earth observation folks recognize.

At this particular junior GIS analyst job, we used ModelBuilder, which, in ArcGIS is a graphical user interface — a drag and drop style pipeline of different processes where the output of one step is the input of another.

One of our models got too complex for this interface. I learned Python’s basics by opening ModelBuilder models, clicking the file menu, and then exporting to Python. This is also the strategy that Anita Graser mentioned when she was on the podcast last year.

Over time, I started writing little macros and custom tools in Python just for myself to speed up my day-to-day work and automate routine tasks.

As an example, I was continually doing spatial joins. It’s a classic geoprocessing tool GIS analysts use, but I was doing them just to get a single attribute. It’s a “clicky” process in ArcGIS — you have to click a table, join and export it.

It’s all over the place.

I wrote a script that automated these steps. It re-projected the data, so it was always in the same coordinate system. It performed the spatial join in memory relatively fast. It copied the column from the output feature class, pasted it back into the input feature class, and then cleaned up all the intermediate data in one go.

Writing handy little tools is an excellent way for a novice to get their feet wet. It has an immediate, meaningful impact on efficiency and productivity. It’s the best way to stay motivated and see an immediate payoff.

Eventually, these tools got noticed by my colleagues, and I started sharing them internally. It got to the point where I even helped win — a very modest — contract to write one of these ArcGIS Python toolboxes for an external client.

In hindsight, I did not know what I was doing. I was winging it. I was coding in Notepad ++, and I was using email attachments for version control because I didn’t know what Git was.

But everyone’s got to start somewhere. And that’s where I started.

DID YOU DO THIS IN YOUR OWN TIME?

For my first project, the ModelBuilder hack, I had some billable hours to learn the basics.

Other than that, I spent a lot of my own time outside of my billable consultant hours to get some level of competency with making Python toolboxes and so on.

It was something I did in my own time as part of my professional development.

WHAT WAS IT ABOUT PROGRAMMING THAT CAPTURED YOU AND MOTIVATED YOU?

I wasn’t trying to write some grand complex program.

I wasn’t following tutorials doing something abstract and computer science-y.

I was writing tools to make my day-to-day work more efficient and automate irritating, tedious tasks any GIS analyst would do, like automating and exporting maps.

For one project, we had a collection of 80 maps we needed to make for the report’s appendix.

There are ways to do that using data-driven pages in ArcGIS and other tools. Using the ArcPy mapping module, I wrote a script that batched 80 of these maps with different symbology and different extents in different coordinate systems, all in one script.

It took a couple minutes to run.

It was the fact that I saw a payoff that kept me motivated to keep going and keep learning.

WHAT MADE YOU DECIDE ON FORMAL EDUCATION IN SOFTWARE ENGINEERING?

It wasn’t an immediate decision. This is an important point to make.

Many folks out there hear about the Silicon Valley salaries and how much these engineers are paid. It’s easy for people to feel they should quit their job and jump into an expensive graduate program or the more recent programming boot camps.

It’d be like buying a car without ever taking it for a test drive. Not even that. Graduate schools in the US, especially master’s programs, cost way more than a car.

It’s advisable to start off with some self-driven learning from free or low-cost resources. There’s a lot of stuff you can get for just $50 or $100. That’s exactly where I started.

I watched online tutorials — a popular one back in the early 2010s was called “Dive into Python.” Today, you can read a popular book called “Automate the boring stuff with Python.”

These are low-cost resources to confirm to yourself that this is something you enjoy, and it’s something you might make a career out of.

I didn’t have an immediate lightbulb moment. It was over many months and years to confirm that to myself.

WHY WOULD YOU NEED FORMAL EDUCATION FOR THIS AT ALL?

If your goal is to become a software engineer with a geospatial focus and get offers from tech giants, like Google or Apple, or a smaller tech company like Drone Deploy, graduate school or formal education is definitely not a strict prerequisite.

But it helps in a few key ways.

If you understand those key ways, you can prepare yourself and position yourself better alongside the people who have gone the formal route.

There are three distinct groups of people you need to impress along this journey. The characteristics required to impress each group are different because they’re mostly disjoint and don’t overlap.

The first group is the recruiters.

You need to be attractive to recruiters just to get the interview. Having formal education like a computer science degree is an obvious signal to a recruiter that you’re worth interviewing.

Recruiters are not technical. They rely on signals because they lack the ability and the wherewithal to recognize a talented self-taught engineer. If you are self-taught, you need to tip the scales in your favor.

You’ll want to backfill your resume with part-time classwork, contributions to some open source projects, a cloud certification, and things along those lines.

The easiest way to bypass recruiters entirely is networking. It sounds icky and weird for people fresh out of college, but it makes all the difference.

Instead of trying to meet the recruiter, try to meet the hiring manager. They’re the people who can recognize self-taught talent at a conference or through a professional organization.

The second group you really need to impress, which requires a different skill set, is the interviewers.

For better or worse, most software interviews, especially at the big tech companies, involve answering arcane algorithms and data structure questions on a whiteboard or in a virtual code editor.

Computer science students who elected to take the formal education route have to learn a lot of this mathematical and theoretical material. But if you’re self-taught, you probably skipped a lot of this theory because it’s boring. And honestly, it’s not that useful day to day.

To impress the interviewers, you need to find a friend and practice the interview questions. There’s a book called “Cracking the Coding Interview,” which is very popular for this. There are websites with interactive code editors where you can practice these problems and see how you rank in your code’s quality and performance compared to other people on the platform.

The most popular one is called Leak Code. If you can answer the easy-to-difficult questions on Leak Code, you’re in good shape.

The third group you need to impress to succeed is your colleagues — once you’re in the job.

Unlike the previous two, the interviewers and the recruiters, self-taught engineers are at an advantage here because they’ve had to develop resourcefulness and practicality a fresh-faced college graduate hasn’t developed.

If you’re a bit older with some workplace experience, you excel in this category.

Unfortunately, it comes after talking to the recruiter and the interview itself.

Computer Science graduates are brilliant programmers. But schoolwork is done in a contrived environment. There’s always a correct answer that’s achievable in a reasonable amount of time.

But we all know that this is often not the case in the workplace.

Recent graduates don’t know how to work with others in an office environment. The most common complaint among students is having to work on group projects.

They complain of having to work with a bunch of slackers and procrastinators. Real-life office work is a giant group project. You need to learn to navigate that.

This needs soft skills that a self-taught engineer would likely carry with them from their days as a GIS analyst or whatever. And thus, graduate schools have less of an advantage here.

There are certainly benefits to having a formal education in computer science. But it’s not a strict requirement — about half of the engineers at Drone Deploy do not have a computer science degree.

And yet, they’re just as likely to be critical team members, top contributors, and leaders.

HOW DO YOU DOCUMENT YOUR SKILLS? ONLINE PROFILE? GITHUB REPOSITORY?

It depends on who your audience is.

If you’re trying to impress a recruiter, go the old-school route and put together a resume.

A lot of recruiters use automated software to look for keywords on resumes. Mention the various cloud platforms you use. Recruiters often type these into their software without knowing what they are.

They don’t always know what Kubernetes, AWS, or S3 are. If you have some experience in those areas, mention it in the skill section of your resume. There are many resources online about how to do technical resumes for software engineers, and I encourage you to look those up.

If your audience is a hiring manager, that’s where a GitHub profile or an open source contribution or a technical blog post where you talk about how you implemented something is more impressive.

You need to know who the audience is and tailor your message appropriately.

DID YOU DECIDE ON FORMAL EDUCATION FOR BETTER OPPORTUNITIES OR MORE MONEY?

There’s always a bit of both.

I saw the GIS analyst side of things as something interesting but didn’t pay particularly well. There wasn’t a lot of growth opportunity either in responsibilities or in compensation.

In the software engineering world, I saw the potential to be a technical person and a much higher ceiling for how high you can go.

I went for a master’s program in computer science after I had taken part-time computer science classes. I probably had the equivalent of a minor degree by then.

I applied to the master’s programs, not knowing if I would get in because I had such a non-traditional background. A lot of master’s students come in with a bachelor’s degree in computer sciences already. All I did was a couple of courses.

But I got in.

I moved to Pittsburgh, where Carnegie Mellon is, and went for it.

What motivated me for graduate school?

Sure, at that point, I probably could have found another stepping stone job where I could have leveraged both of my geospatial and programming skill sets. All the companies, organizations, and government agencies with GIS teams would typically also benefit from programming expertise.

The decent ones will compensate you accordingly because there’s so much demand for these skills out there.

But I decided that I — and this is a crucial distinction here — did not want to be a GIS analyst with a specialization in programming.

I wanted to be a software engineer who had geospatial subject knowledge.

I felt there was more job security, a bit more potential for growth on the software end of the spectrum than on the geospatial end of the spectrum.

These days that distinction is a bit of a false dichotomy because there are really cool data science and data engineering jobs that live in the gulf between those two extremes.

But six or seven years ago, it was a different story.

AS A SOFTWARE ENGINEER, DO YOU FIND GEOSPATIAL DATA IS AN ADD-ON OR BAKED IN?

Is spatial special or not?

There is spatial information all over the place, whether people know it or not.

What’s really curious is that software engineers are performing geocoding. They’re doing things that are spatial analysis, but they don’t think about it as such. There are software engineers who probably used more Google Maps API credits than I ever thought to.

But they’ve never heard of what a GIS is. They don’t know about that kind of software.

They’re solving spatial problems without realizing it.

That’s an ample opportunity for someone who has geospatial expertise to lend some of that subject matter knowledge and raise the stakes for the quality of the analytics. They know how to think thoughtfully about efficiently implementing these tools and how to go the extra mile when implementing their software.

HAVE YOU EVER SHOWN UP AND LOOKED AT A PROBLEM WITH YOUR GEOSPATIAL GLASSES ON AND SEEN AN OPPORTUNITY?

After grad school, I ended up at Drone Deploy, which is a truly geospatial product.

It allows people to capture data, upload it to a cloud platform and turn it into 2D ortho maps, 3D models, point clouds, and panoramas. It’s geo through and through.

I’ve definitely had opportunities at Drone Deploy to leverage my spatial experience.

One particular example is in multispectral data. My undergrad research was about looking at near-infrared data from satellites, vegetation indices over time — classic Earth observation, remote sensing, and one-on-one type topics.

A couple of years ago, someone came out with a drone with a five-band sensor; a narrow-band red, green, blue, a red edge band, and a near-infrared band.

Programmers have a passing knowledge of geospatial topics, but not an in-depth sense. Sometimes, those engineers won’t even know what to search for.

The idea of having five bands of color or false color was mind-blowing to them. They didn’t really know how to proceed with that.

For one particular example, we wanted to allow customers to have a true color tile pyramid, a true color ortho map, and a false-color one that incorporated the red edge and near-infrared.

I knew all image formats out there are designed for three bands. JPG typically only allows you to do red, green, and blue. PNG only allows you to do red, green, blue, and alpha.

How can we take these five bands of multispectral data and distribute them among the three slots that we have?

I designed a solution to create two separate ortho maps. A true color and a false-color you can switch between as necessary.

This way, you can continue using common image formats like JPG and PNG without having to reinvent the wheel or do some crazy TIFF thing.

That’s an example where my GIS and remote sensing background helped me do the technical design for a project that was moving over to GIS and spatial territories.

KNOWING WHAT TO SEARCH FOR IS KEY

It’s half the battle.

Being able to articulate a question and put it into Google search is a key skill to have.

IS LOW-CODE/NO-CODE LIKELY TO ENCROACH ON WHAT SOFTWARE ENGINEERS ARE DOING? IS IT A VIABLE MIDDLE PATH FOR GIS ANALYSTS?

There has been a lot of growth in low-code/no-code solutions.

There is no threat from low-code/no-code applications to the software engineers because it takes many software engineers to build one of these platforms.

There’s so much demand for software engineers that I’m not the least bit concerned about low-code/no-code.

The group I’d be more worried about is the analysts.

For many analysts, part of their work is to follow “recipes” they know for making maps, doing basic analysis, or doing a simple spatial join.

Even if a decision-maker doesn’t know what it’s called, a lot of times, that’s what they do.

GIS analysts need to learn about the low-code/no-code solutions to automate those processes for themselves because that’s going to be a threat to part of their billable hours in terms of what they’re doing for the decision-makers.

Some of what we do at Drone Deploy is simplifying collecting and processing drone imagery. In the past, that’s something that took a lot of expertise. Sophisticated software was required as well as a department of people who knew that software inside out.

We’re trying to simplify that process so that if someone is competent enough to fly the drone, they should get that 2D ortho map or that 3D model and 3D Point Cloud with no special training or expertise.

It’s a “no-code” product, even if we don’t call it that at face value.

IS THERE A NATURAL CEILING TO LOW-CODE/NO-CODE SOLUTIONS, AND DEMOCRATIZATION OF GIS ANALYSIS?

The best low-code/no-code solutions allow you to pull back the curtain and see the code that’s being generated.

Ultimately, no matter what the user interface looks like, there is computer code being executed.

For example, I mentioned how ModelBuilder allowed me to export to Python. There was no permanent connection, though, and you couldn’t go back from Python into ModelBuilder.

But there are some low-code/no-code solutions, where you can seamlessly switch between the two and see the underlying code. Make a minor tweak and then go back to the drag and drop view, where you have a friendlier user interface with nice bubbles and lines connecting them.

In that sense, there isn’t a ceiling. There’s actually a natural progression from the user interface into a coding environment. Those are the best solutions; they’re going to be the longest-lasting in the industry.

DOES AN ANALYST NEED TO UNDERSTAND CODE FOR TECHNICAL PROBLEM-SOLVING?

There is a vast diversity of GIS users and GIS analysts out there, from archaeology to ecology.

It would be presumptuous for me to say this is what an analyst has to do, or this is what they should not do.

Understanding what you can and can’t do with code, and ideally, knowing a little yourself, will be a major service to you for automating your work, making yourself faster.

And just as a safety net, because it’ll just be harder to get rid of someone who understands that code. Having that understanding may give you a sense of job security.

HOW DOES PROGRESSION LOOK FOR A SOFTWARE ENGINEER?

One way to move up is by going into management.

Instead of doing the programming yourself, you manage the teams that do the programming.

Which is exactly what I wanted to avoid doing as an analyst.

For software engineers, there is an alternate path, but it’s not ubiquitous.

At some companies, especially software-focused tech companies, there’s a separate thing called the Individual Contributor Track, or IC Track. It allows you to move up in terms of responsibilities and compensation without managing a team of direct reports.

You focus on the programming.

Partway up this ladder, there’s a mid-level role, which is Technical Lead. Different companies may have other names for it, but that’s one of the most common terms.

That’s what I’m aiming for next.

Tech Leads still do plenty of programming, but they’re more actively involved in designing how new features will be implemented.

I’m already the go-to person for many wonky geospatial topics like multispectral work, coordinate systems — everyone still hates coordinate systems even in the software world — ingesting shapefiles, DXF files, etc.

Higher up, there are more senior roles like Staff Engineer, Staff Architect, or Principal Engineer. The compensations for these roles are equivalent to Directors and Vice Presidents on the management track. Except these roles are on the IC Track. They’re focused on high-level technical aspects and not on managing teams or managing people.

The IC track is fantastic, but it’s not everywhere — yet. It’s going to be much more common at companies whose end product is software.

If you’re a GIS analyst with a specialization in programming, and your company is a consultancy or has a totally different end product — electric utility or something like that — then it’s less likely that they’re going to have the engineering culture and the resources to have an individual contributor track.

It’s not impossible, though, and it would be presumptuous of me to say one way or the other.

WHAT ABOUT HIGHLY SPECIFIC SPECIALIZATIONS?

The only downside to that is it may end up being very narrow.

I recall working with experts in my previous role who were specialists at using a particular flood model.

But what if that model is replaced by a different model? Or what if the funding dries up? A lot is riding on a very narrow specialization.

What’s different about individual contributors in the software world is that your purview is very wide at the Technical Lead, Staff Engineer, or Principal Engineer level. You need to think holistically about how various systems in your architecture talk to one another.

For example, should you redesign them because you have a new product with a different workload on them?

The individual contributor track in software is broad as opposed to expertise in a narrow niche.

ARE YOU STILL USING PYTHON IN YOUR DAY-TO-DAY WORK, OR HAVE YOU MOVED TO ANOTHER LANGUAGE?

Yes, I am still using Python, but that’s a coincidence more than anything.

I learned Python way back in 2011 because it was the easiest way to write custom processing geo tools for ArcGIS.

Python has continued to be popular because it has a relatively friendly syntax. The data science/data engineering world has grown so much.

In graduate school, I learned Java, JavaScript, MATLAB, C, C++. I had job offers to go to companies to work in some of those other languages.

I’m a software engineer; I’m not just a Python engineer.

And that’s a point I’d like to make for people who’re thinking about dipping their toes into this field.

The choice of your first programming language is not a crossroads.

It’s not like a video game where you have to pick wizard or warrior, and then you’re stuck with that decision forever.

They’re more like dialects of computer science rather than separate languages. I think people associate language as something that takes years to learn while you only focus on one — it’s definitely not the case.

Don’t dwell on the decision of your first programming language. Just pick one that’s going to be useful to you and get started. It’s easy to pick up new languages after your first.

There are many abstract ideas in QGIS, ArcGIS, or any other desktop GIS software package.

In the same way, there are common ideas between modern high-level programming languages. They all have variables, loops, and conditionals. They have classes, functions, and so on. The syntax will vary between these programming languages, just like the user interface might vary between ArcGIS and Q GIS.

The real big difference between programming languages is their ecosystems. Many before me have spoken about the different parts of the geospatial ecosystem. Each programming language has its own ecosystem for its open source libraries.

Once you learn one GIS package, it’s relatively easy to switch to another. The same is true with programming languages.

—————————————————

I thought Dan gave some fantastic advice in terms of recruitment.

The key to the advice was empathy for the person who is doing the recruiting.

What stage of the journey are you at? How are you applying? What kind of information do they need to see?

Tailor the message.

Who’s going to read this? Who’ll make a judgment call based on this information? How do you tailor it to them in terms of where they are in the recruiting chain?

Dan gave brilliant advice on that.

I admire people like him. People who realize their career isn’t taking them where they want to go and they do something about it. Too often, it’s easy to become stuck in our careers — stuck in geospatial.

Perhaps we reach a point where we realize that this is not the path that we want to be on. But the sunk costs that build up the professional capital we have gained over the years… it’s difficult to turn our backs on that.

The scariest thing about trying something new is it may not work.

I have experienced this in my career. I’m almost embarrassed to say it took me a long time to understand I was better off trying something that may not work than staying in a position where I knew it wasn’t working.