A Professional Engineer Navigating Through A Developer World

I started out in the professional world as a Biologist. I was taught how to think analytically, ask a lot of questions, create hypotheses, make detailed observations, and only draw conclusions once there is enough evidence. If you started with a hypothesis and the evidence didn’t support it, that was just as strong an outcome as if the evidence did support it. You simply adjusted your thinking based on what you were observing and moved forward. No big deal.

This is the basis of an engineering mindset.

As my own career aspirations changed and I entered into the world of software, I had many of the same expectations of being able the leverage engineering principles to solve problems and create opportunity. My hypothesis that software development requires an engineering mindset was initially reinforced based on the information being presented to me in the classwork I took. One really needed to fundamentally understand mathematics, some physics, circuit design, and, of course, many different programming languages. I was involved in advanced activities such as designing neural networks and building 3D virtual worlds for students to immerse themselves in and learn human biological processes.

As I entered into my first real job of professional software engineering, I was fortunate to get involved with an extremely motivated and talented group of mechanical, electrical, and software professionals who were true engineers. This continued to provide evidence that software development was an engineer’s game. I was hooked and spent all my days (and nights) focused on providing well thought out software solutions.

I continued to work for my first software employer for nearly 10 years which is not very common in this industry. During those first 10 years of my career, I was (almost always) working amongst true engineering professionals. Yeah, we had a fair bit of run-ins with 3rd parties that just didn’t seem to “have it together” but I always assumed that, because our company was small, we often ended up working with external teams that weren’t “top notch”. How wildly inaccurate my conclusion was…

The Cake Is A Lie…

As I entered a new chapter in my professional career, I also entered into what turned out to be the “norm” software ecosystem which I didn’t realize was so rampant. I was suddenly surrounded by an overwhelming majority of inexperienced and somewhat reckless individuals who claimed to be software professionals. They didn’t think about logging levels, they didn’t write unit tests, they hot fixed in production all day long, they never finished their sprints, they didn’t do root cause analysis when issues arose, they stored credentials in plain text, they hard coded their configurations, they didn’t version anything, and they didn’t seem to care about any of it.

I literally couldn’t accept that this was the way things worked. Must be a fluke. Must be a weird moment in the organization’s evolution. Can’t be this way. So, I soldiered on, focusing on applying the engineering wisdom I had gained to this totally new and very foreign set of problems. Over time, the software space I could influence began to “flicker” with some engineering professionalism. Software releases became reliable (and boring), large scale, real-time data feeds “just worked”. APIs were documented well and versioned. Services “auto-discovered” each other. However, those small successes began to draw attention from individuals in leadership who were struggling to create success. They wanted to know what the “secret sauce” was. What thing did I buy and install that made it all better. Of course, the answer was good old engineering discipline and work ethic which seemed to be a foreign concept. Everyone was instead into “quick wins” that could be easily communicated in a bullet point slide deck with pictures of people giving each other high-fives.

So, I went back to a small company again. Back to where the engineering fundamentals can be applied. Amazingly, the same lack of engineering patterns/practices existed. They were “awash” in a non-engineering mindset.

The observations I have repeatedly witnessed have led me to conclude that, today, software is overwhelmingly filled with people who do not have an engineering mindset. Yes, there are islands of engineering minds in software. Some are fortunate enough to be in an entire organization of engineers. Many, however, are but a handful in a large organization filled with inexperienced software developers who are managed by leaders who want quick wins. Some engineers in this situation simply “fill their engineering itch” during non-work hours, often stripping the professional engineering community of their creative contributions. Other engineers constantly “jump ship” from one organization to another, never making a significant contribution in any of them. This is unsustainable for both individuals and organizations.

What To Do

Why, ensure software is treated as a true engineering discipline of course! Here are some great ways to start down that path.

As A Software Engineer

Ensure Constant Observational Feedback From Your Consumers

You must understand what the consumers of your software product are doing with it. They may be using it in ways you never expected. They may be getting frustrated and walking away. They may not use it at all. As an engineer, it is your responsibility to observe this behavior so you can understand where you should logically make changes to improve the product. There are a lot of approaches to automating this feedback (which you should have in place) but it cannot take the place of true, direct interaction with the consumer.

Too often, I see the people who are creating software either unable or unwilling to interact directly with the consumers. As engineers, we must demand this interaction take place on a continual basis.

Unit And Automated Functional Testing To Reduce Risk When Making Changes

Successful software goes through constant change. As it goes through change, you want to keep it healthy. This is where automated testing really shines. Yes, unit or automated tests are very useful to ensure the code you just wrote works as expected; however, where these tests truly show their value is when you need to modify the software’s behavior, often asking it to do something it isn’t designed to do. Without a very solid, comprehensive set of automated tests in place, it is very difficult to know what will continue to function properly and what will behave outside acceptable tolerances.

Think of testing as the way to document the true behavior of your software while also ensuring it stays healthy whenever anyone makes changes.

As A Software Organization

Treat Failure As Part Of The Process To Creating Success

Software organizations must be setup to expect failure just as much as success. Keep in mind that new features, concepts, etc are simply hypotheses which need to be tested. Not every hypothesis, when tested, is going to be correct and that is totally normal. You simply learn and move on.

Where I see things go astray is when organizations do not understand that failure cannot be avoided when blazing new trails of opportunity. This causes organizations to spend too much time not creating and not experimenting which is a huge waste of resources.

Require Software Mentorship

Becoming an excellent software engineer requires experience. This takes time. However, once this experience has been obtained, it is HIGHLY valuable. One of the main goals in your organization must be to spread that highly valuable experience to as many other engineers as possible, which dramatically increases everyone’s value.

You must specifically assign mentors to mentees and allow time for teaching/learning to occur. Don’t just say you support mentorship/teaching. Take an active part in making it happen.

Set Aside Actual Time For ‘Creative Flex’

Engineers are constantly solving problems while under fairly tight deadlines to push solutions out the door. If there aren’t specific times where engineers can try new things without being under that constant pressure to release, they will often take that creative energy and focus it away from your organization or “stay late” to spend time on creativity, thus burning themselves out. I have even seen engineers try new concepts/ideas directly in production because they had no designated creative time, which dramatically decreased the overall health of the product.

You want creative engineers. You look for that when recruiting. Ensure that when they arrive in your organization they are consistently allowed recurring times to be creative. Keep in mind, it is in those moments of true unstructured creativity where innovation often takes root.