What is a Software Engineer — Solves problems

As I was walking down the hall, I heard “Hey Nate!  Come in here!”

I walk into my coworkers office and he asks “Do you  have any idea how to open a FoxPro database?”

“Did you look for a FoxPro viewer online?”

“Yeah, I can’t find one.  Any idea how we could crack it?”

“What are you trying to do? We don’t even use FoxPro here.”

“Well, we’ve got this date field, employee_birthday, on the site.  And sometimes, when HR adds new people to the CRM they don’t put the birthdate down, so it show 1/1/1800.  I want to look at FoxPro and see why it’s set that way.”

“But why FoxPro?”

“Oh, we have a 3rd party client for this page and it stores some stuff in FoxPro.  It’s an old system.”

“But we have control over the page right?  This is one of your pages on the HR Portal?”

“Yeah, yeah, we’ve got control over it, but I don’t know how to set the default date in FoxPro to not be 1800.”

“Tell me something, can you grab the date between when the user submits it and it goes to the database.” 

“Absolutely”

“So couldn’t you just check the date, if it’s null, or empty set it to something reasonable like 1/1/2007?”

“Yeah, I guess I could do that.”

“To be honest, though, I don’t see the point, what’s the difference in thinking everyone at work is 200 years old or 1 year old?  They’re both WAY off.”

This trait of a software engineer, “Solves Problems”, as well as the next one, may seem obvious.  But when you sit down and look at what goes on in the software world you begin to realize that it’s far from 100% true of everyone writing code.

It was at this same job that I came to understand how important solving problems really is. There was a handful of us at this job, all working on custom solutions for other areas of the business.  For example, we had custom software for the finance team, sales team, manufacturing team, hr team, engineering etc.  It was software that largely assisted the way this company ran.

Our value was not in writing code, per se.  We were paid fairly well, and no doubt could have found some code-monkeys.  Our value was in solving problems.  Our finance department was great at what they did.  But they didn’t think about automating tasks, or streamlining workflows, that’s one area we could help.  The code involved was largely data access code with a pretty UI on it.  We weren’t doing any complicated calculations, or difficult algorithms.  We were usually taking data from one state to another and then re-persisting in the database.

Not everyone has the same problem domain, but part of what we do is needing to be able to solve a problem effectively.