Ask “Why?” First
The histories of the Turkish word “mühendis” and the English word “engineer” differ in a way that interests me. Mühendis is related to “hendese”, which means geometry in Arabic; the word’s past reaches back to the Persian senses of measure and measuring. Engineer, on the other hand, shares a root with engine. Engine here does not only mean a motor; its history includes mechanical contrivances and war machines. Further back, the Latin “ingenium” carries the meanings of talent, intelligence and skill. It does not derive directly from the word “invent”.
In one, measuring and calculating come to mind more readily; in the other, designing a device. It is easy to conclude from this that “we build, they invent”, but that would be unfair. One of the important beginnings of modern engineering education in Turkey has to do with shipbuilding and nautical charts. The history of the English word also includes military needs. Real life is more tangled than the associations of words.
Still, the difference makes me think: what do we expect from an engineer? To complete a given job with the right calculations? Or also to think about why that job is to be done?
I think the first question we should ask when starting engineering work is “Why?”
Yet our minds usually go straight to “How?”. Which part will we use, which language will we write it in, how will we set up the connection, how many days will it take? I find myself inside these questions too. While a problem is being described, I can start thinking of a solution before the other person has finished speaking. If it resembles a job I know, my mind moves even faster.
There is a good side to this; experience is useful. But along with that speed I also end up accepting certain things. That what I was told is the whole problem, that the requested solution is necessary, that no information is missing…
Once we move straight to how we will do it, it gets harder to ask, “Is something missing here?” We have already chosen a path. Our later thoughts mostly serve to move along that path.
Imagine a business asking for a new report. We define the fields, write the query, add the filters. The report works perfectly well. But when we talk a little about why it was requested, we may learn that the user cannot trust the figures on two existing screens. The real need is not a third report but to be able to understand why the figures differ.
We may have done the requested job completely and left the problem right where it was.
For me, this is roughly where original engineering begins. Examining the problem with your own eyes, trying to understand what you are told, describing it again when necessary. You do not have to invent every part yourself. You can develop an original solution with off-the-shelf components and well-known methods too. As long as you know why you chose that solution.
Working across software, electronics and field systems, I feel this need more strongly. A device sends data, the software stores it, a number appears on the screen. At first glance everything is fine. But what if the data arrived half an hour ago? What if nothing changed on the screen even though the connection was lost? What if the user looks at that number and makes a decision?
At that point, a technical detail that looks small affects someone else’s work. It is not enough that we know how the system works. The person using it must also be able to understand what they can rely on.
That is why what is expected of an engineer is, for me, a sociological matter as well. If an organisation constantly rewards getting the job out on time and treats looking into the cause of a problem as a waste of time, people learn to work accordingly. If the question “Why are we doing it this way?” causes unease every time, after a while it is asked less often.
Then we expect those same people to be innovative.
For someone to voice an idea, the idea does not have to be accepted right away. But they need to know they will be listened to. If they think that pointing out a gap they have noticed will only bring them trouble, they may choose to stay silent. From the outside they look indifferent. Perhaps they tried hard enough before and got no response.
I think this is where we should look when we assess an engineering culture. How we treat the person who asks questions matters as much as which word we use. Do we give the engineer only the responsibility of implementation, or do we also want them to take part in forming the decision? When an experiment does not work out, can we talk about what we learned?
Of course, we need to ask ourselves the same questions. Seeing the gap in someone else’s request is easier than seeing the one in our own idea.
When you put effort into a design, you grow attached to it. You know why you did it that way and which difficulties you overcame. When someone comes along and points out its weak side, sometimes the first reaction is to defend it. Instead of listening to what is being said, you want to explain how hard you worked.
I find this human. But making technical decisions with that feeling can cause problems. The fact that we worked hard on a solution is not evidence that it is right.
This is partly where I see maturity in engineering. In being able to look at your own decision again. In being able to ask, “Why did I do it this way?” Because the need required it, or because this is the method I am used to? Do I have a measurement, or a strong guess?
The same care is needed when a fault appears. The problem may disappear when the system is restarted. But if we do not know why it disappeared, we should not feel at ease. Under what conditions did it appear, what did we assume wrongly, how will we know if it happens again? We may not find an answer to everything straight away. We can at least separate what we know from what we guess.
There is also the part of the work that is left to someone else. If everyone has to call me whenever a problem comes up, part of the system still lives only in my head. We need to write code someone else can understand, record decisions and leave error messages that actually help. Sometimes dealing with these is not as enjoyable as building a new feature. But the person who one day sits down in front of that problem will need them.
I still love the moment something works for the first time. A reply coming back from the circuit, the data being read correctly, the function you have been struggling with for days finally behaving as you expected. I know that relief.
Now I want to pay a little more attention to what comes before that moment. To not missing the question in my eagerness to find the solution. To not starting right away just to show that I can do the job.
First, let us understand why it is needed. If something is missing, let us talk about it. Let us decide how to do it after that.