I was enjoying an episode of “So you think you can dance?” where they demonstrate their dancing skills. The title struck me as brilliant as the show itself, and later on I was wondering – how about “So you think you are a good engineer?”
If you have been around in the industry for some years, I am sure you have heard the exclamation “Hey it’s working!” a few hundred times. Many times it is followed by “but … well … under certain circumstances … not that way … not sure … etc.”. The rules of the game have changed a lot over the years. These are considered unpardonable in today’s tough competitive world. One needs to equip oneself with a lot of knowledge, practice, and attitudes, to qualify as a good engineer.
What does it take to be a good engineer? Do you think you are one?
The phrase “engineering solutions” have a somewhat negative connotation in the industry, where someone makes something work without fully understanding how. Here, I put down some of my thoughts about what I feel makes one a good engineer. My background and experience may make this post lean towards the attributes of a software engineer, but I feel in spirit it is applicable in general to all engineers.
- You need to know how the full system works.
You need to understand how the entire system works, not just your part. You should be able to explain it to someone outside the field, even a layman.
- You need to know the big picture and its intended uses.
Without knowing the uses of the system, one can’t really make it well. Well, one can. But not as good as how good engineers make it.
- You need to know who/what is the customer for you.
Everything has a customer. Whether it is a product or a service or a small software module, or a small action. The customer may be the general public, a company, or the adjacent modules which interface with yours. Knowing the customer well is critical to your success.
- You need to know the inside story well.
Can you model the system behavior mathematically? Without a thorough grip on the relevant math, you really can’t put your finger on the system’s limitations or diagnose failures well.
- You need to know what it takes to execute the system.
It is one thing to build it and quite another to make run. Further, it is one thing to make it run, and quite another to make it run well under severe constraints. Further, you should know how much system resources it needs to run (like CPU, memory, bus-speed, etc). Inversely, if it is required to run with a given performance, you should be able to determine what system resources you need for that.
- You need to handle changes well.
Do you know the impact of changes? What if the objectives (of the system/feature/module/service) are changed a little? Can you update the design suitably? Are there trade-offs to handle? In order to achieve something, are you compromising on something else? Should you?
- You need to prove that it works predictably and desirably.
This, for many, is a tall order. Unless you are thorough with the under-lying math, the theory, the domain knowledge, etc. you can’t prove that your system works well for all the intended (and unintended!) scenarios. And in today’s tough world, unless you prove things, you are nowhere. This includes proving it theoretically as well as testing the system out.
- You need to design it to ensure that it is testable.
Testing, most of the times, is not “the test engineer’s job”. It is yours. There may be any number of scenarios and boundary conditions that you need to take care of. Also, it is paramount that you design the system to help testing itself.
- You need to be quantitative in your work.
Gone are the days where we could get away without numbers. Now, numbers are everywhere. You need to have context-dependent and meaningful performance metrics. You should know the impact of these numbers on the user’s experience. You should know what changes impact which numbers and how.
- You need to take ownership of and accountability for your work.
This is now a world of ready-made stuff. There are hundreds of libraries, open-source, off-the-shelf components, etc. available which say you can do pretty much anything with them. But the world looks to you for what you deliver. You need to use others’ work, if you need to, ethically and legally, and yet deliver your stuff. You can’t say “well, that third-party provider is not giving me these numbers so I don’t know how my system works”.
This list is surely not exhaustive. Depending on the particular situation at hand, it can change considerably. It is very practical and imperative for every engineer to have such attributes. I wish I had read some such list when I started out in the industry.
So again, you think you are a good engineer?