Engineer Or Problem Solver?

Reading Time: 3 minutes

Certain people in the industry believe that Engineer means (or meant to be) a problem solver, no matter what kind of problem is given. I believe this misconception “Engineer can do anything” is widely propagated after a movie named ‘3 Idiots’, story of which in itself is highly paradoxical. I meant misconception, because anyone could do anything, but whether one should or should not do certain things should be only driven by thoughts of a sane mind.

By definition, an Engineer is meant to design and build things. Not anything, but certain specific things. An engineer of steam engine is not going to make an earth-quack resistant building. He could learn, but will not be able to compete an expert in that field. Even if he does, whats the point? Why would you want to trash his skills of building a steam engine, unless those engines are out of demand.

If you have a misconception that an Engineer, who is being able to solve a geekforgeeks problem with difficulty level of 3+, is a ‘generic’ problem solver, then you are wrong. It’s just contextual mathematical problem. It does not define him being an Engineer. A mathematician can solve most of those problems. Thus, that is just problem solving. Even an auto-riksha wallah is a problem solver in his own context. That does not make him an Engineer though. Every expert in it’s field can solve problems within their own respective fields, which is what get them paid. But not all of them can be called Engineer.

To put all this into context, let’s talk a bit about where new-gen Software Industry gets it wrong. With the emergence of ‘high paying’ startup market, companies want to ensure their high-investment in an engineer gives them multi-fold benefits. So they start deploying them in fields which are not their expertise. Sure, they must learn new things, but it only makes sense to learn technologies which are capable of making the older ones obsolete. But when, for example, a back-end engineer is put up into building front-end or databases, the term Engineer loses its meaning. This process will only produce full-stack developers not engineers. If a high-traction company can not afford expert engineers, they should look to be downgrading their per-engineer hiring budget, so that they get experts in a specific domain, may be with little less exposure. But at least they will be able to justify their expertise.

This is where most companies go wrong. Spending on random experiments like newer technologies or full-stack development in their initial stage, but when it comes to sustainable growth, they realize it was all wrong. They either get stuck with higher maintenance cost, or end up rebuilding whole thing. That is also alright. But without the lesson learned, you will again build an ephemeral trash.

Leave a Reply