Maturity and Engineering

One of the questions that I have been pondering many times over the past year or so is what makes a good engineer, what makes a good senior engineer.

I have been wondering about this when interviewing engineers and when interacting with my team and other teams, specially the later. And until recently I could not clearly explain what I was looking for, this article “On Being a Senior Engineer” help me immensely to get my thoughts a bit more organized, and is a gem in itself, I highly recommend reading it more than once. I will try to not repeat from that article, so really: go ahead and read it.

In short: more than seniority or years of experience, maturity is what I think is the key.

Maturity comes from a different place than just years of experience, and I suspect everyone’s path to maturity is fairly unique.

In my case, I think has come from: (notice my ego while I think I am a somehow mature engineer) a few different areas.

Cultural background

I grew up in Venezuela, which is a in different state of development than the US or many of the developed nations. What this afforded me was the need to do multiple things, I was never able to be just a developer writing code, I had to figure out and help with things like setting up email systems, or networks, interfacing with old IBM System 360, understand constraints in physical space, budget, time, and interact with a great variety of people ever since my earlier projects.

Having to deal not only the code, but also the environment and the people using the systems we were developing at the time, gave me an ever clearer view of the role of the end user to a system and the environment physical and computational where a system was the be deployed.

I think having this exposure so early made it part of my foundation of thinking, to the point where is hard for me today to just ignore those aspects of the engineering side, and I do consider those aspects of almost any project an integral part of the engineering solutions.

Exposure to a variety of projects

I am a Mechanical Engineer by formation, I particularly enjoy the area of mechanical design, specially when combined with the constraints needed for each project.

In my Software Engineering career I have done projects in many areas starting from helping my dad early on on graph theory, chromatic polynomials, prime number generation and validation, projects on billing and administration systems for utilities, accounting software, tax software, factory automation, analytics, online games, databases, and others that my not so good memory forgets.

I have done projects distributed via web, installed by professional services, shrink wrapped, send as code via email, and even have come in to some for a quick ninja fix when needed for projects I am not fully familiar with.

I believe this variety has allowed me a broader understanding of software development, and allowed me to also understand that not all projects have the same tenets, sometimes price, or performance or availability or time to delivery, or reusing existing “Stuff” will be a driving force for a project, and more generally all of these will place competing priorities for most projects.

Multidisciplinary interactions

I’ve worked as a Mechanical Engineering and was a University Professor long time ago, I have worked in Software Engineering for most of my adult life, I have work at times in farms, picked fruit and corn when I was young, and lately I have developed an interest for electronics and even more recently for drawing and sculpting.

In my mind these are not disjoined activities, many times I find myself using analogies on other fields to explain something, I can easily relate to how others are trying to approach a problem or decision and use their background to make an explanation easier to understand.

I tend to carry knowledge from one to the other, and I think a key value and skill I have developed because of this is: empathy. I can, most of the time, understand the problem being addressed from the customer’s perspective, I can relate to what they want to achieve, and that is a skill I use almost every day, not only with customers but with co-workers, bosses, customers and other services in and out of my company.

Closely working with mature engineers

This is likely the most important one, but I suspect it is not enough.

I have had the luck and pleasure to have worked with many great engineers at all levels, bosses, peers and people reporting to me. Likely because of the previous points, I have always had an open mind and keen eye to learn from them.

I make an effort to understand the feedback I receive from them, I’ve found that many times, the feedback I do not agree with, or more likely don’t fully understand tends to be pretty valuable down the road.

I see how to they interact with others and try to understand the good interactions, but also learn from the ones that do not work out so well

Much of what is described in the original post, or this writeup cannot be achieved but with the passing of time, but is not enough.

Many of these items are not technical achievements, and in many cases are not technical at all, but I think they are all good skill to be found on an engineer and I do think that a Senior level person, in particular Engineers should have some or most of them.

So keep your open mind and find how to cultivate yourself to achieve that role or a Senior Engineer.

(Originally posted at https://webclimber.wordpress.com/2013/12/12/maturity-and-engineering/)