thoughtwisps One commit at a time

Why I cannot call myself an engineer

The word “engineer” appears in my job title, a title that I have held since graduation in August, but I cannot, in good conscience, call myself an engineer. If you’ve been following some of the posts on this blog you have probably figured out that I work in software. That is what I tell people I meet. “I work in software”. But I am not, nor will I ever be, a software engineer.

There are probably many ways to define what makes a software engineer, but here is what I think makes a good software engineer.

A software engineer is someone who can

  • comfortably navigate complicated systems
  • can formulate a well-architected solution to a business problem
  • can come up with a good testing strategy for code
  • come to grips with a fairly large and complicated code base quickly

Honestly evaluating my skills, I am none of the things above.

The first Hello World came too late

I sometimes wonder if things would be easier for me had I picked up computer programming earlier in life. I wrote one hello world at about 15 using C++, but I quickly gave up, because I didn’t understand how to work with the compiler. This was back in the stone age before Udacity, Codecademy et co came along.

My first real “hello world” was in Java. By that time I was already a senior in college. In software engineering terms, a mega old person to be starting off in the field.

Most of my colleagues have a Commodore-64 somewhere in their childhood. By their early teens, they were usually experts in C or another language. In college and postgraduate, they took courses called “Operating systems” and “Algorithms and data structures”. They can comfortably converse about UDP and TCP/IP. Occasionally they turn to me and ask, “Do you know what XOR is?”

I know what XOR is, but I had to Google it. I know something about algorithms and data structures, but I won’t be able to implement a Bloom filter. Hell, I’ll probably struggle with implementing merge sort or the like. I didn’t have a Commodore-64 growing up. I didn’t even have my own computer until I went to high school.

Know the Code-scape or get lost

My colleagues are experts at hiking the coding landscape. They have years of experience. Loops and libraries, functions and decorators, variables and pointers, familiar stuff. But I am the n00b of n00bs. I have barely gotten my feet wet in the code-scape. There are times when “being lost” is my default existence on every project I am asked to join.

Don’t get me wrong. I am the good girl scout. I do try. I take a bug ticket and I start looking at the code base. “I will figure out this bug”, I tell myself. “I will make it. I will find out what makes this code tick.”

But the map I’m holding is upside-down. I read the code and I hit one speedbump after another: the object references another object, which references a method in a library that I cannot even find. Within hours, I have drifted way off-course. I still don’t know what caused the bug.

Can you come up with a solution? I don’t think I can.

Ultimately, a software engineer is someone who sees a problem and comes up with a working solution. I see a problem, but I do not know where to start. I end up floundering for hours. I do some TDD and hit a roadblock. I do some crash-and-burn coding and hit a roadblock. I can’t call myself an engineer, because if someone gives me a problem and asks me to come up with a solution, I am absolutely lost. At best, I can give you sometimes that may work or might be brute force, but it won’t be elegant. I can build you a raft made of discarded wood, but a real engineer would build you a yacht.

So when I say, “I just work with software” that is exactly what it means. Regardless of what it says on my business card, I am not a software engineer.