I remember my first engineering class pretty well. My teacher had a lot of great one liners. She always said things like “Efficiency is the key” or “Stability is the key”.  We ended up with lots of keys.

One thing that stuck with me was her emphasis on problem solving. By her definition, engineer simply meant problem solver.

Fast forward to today.

On many tech teams, software engineers are handed features that they are supposed to build – no questions asked. This is more akin to being a technician than an engineer.

So what? Why does this matter?

Back in our discussion on the only 4 ways to reduce development time, we looked at how problem complexity causes work to move more slowly. When you are deciding what to build, you should have engineering minds present so that they can help you navigate to the simplest solutions.

In virtually every scenario when a non-technical person has given us a blueprint for a feature they want us to build, it turns out more complicated and time consuming than what we would have come up with for the same problem.

Because of this experience, when we are asked to build a feature, we always take the time to pry into what the underlying problem is that we are looking to solve.

Understanding the problem itself – not just the desired feature – helps us to look at the problem from different angles to see if the approach provided is the one that makes the most sense.

This has helped us provide our clients with more innovative products and to move much more quickly than we could have done otherwise.

Need Help?

We are a full service software engineering firm. We can help you with everything from design to project management to development.

Got a project you’d like to talk about? Get in touch at info@centralstandard.tech.