I worked for a couple years on control systems software without any kind of experience or formal training. We would get source code, with some initial tuned parameters, then take our robot out into the field, and re-tune our control loops based on reality.
Here was my takeaway: an engineer has to understand the domain and algorithms involved at a deep level, or they will not be productive. Or, you will need to have both an engineer and somebody with the domain knowledge and experience.
It doesn't really matter what your problem domain is. If you're an engineer, and it's your job to make changes to a system, whether code or config, you need to understand it at a deep level. And your manager needs to understand this requirement.
Otherwise, you will be guessing at changes, so your productivity will be horrible or non-existent.
Very true but the post makes a more subtle point: you don't have to have a model that explains everything as long as your model is predictive for the problem you're trying to solve. You can build a good telescope without understanding quantum mechanics. I guess that's the difference between science and engineering, broadly speaking.
A strange thing about deep learning, is that sometimes you're creating a model that generalizes beyond a particular domain. You might be tuning parameters to improve computer-vision and your tuned solution happens to also outperform the original at translation or partial-knowledge navigation. And your goal may very well be to create something that behaves well under all of those domains, while only having any real domain knowledge in a few of them.
I thought based on your opening sentence that you were going to say having no understanding of the problem worked out okay. So are you saying you were unproductive at your old job?
In the beginning, I was definitely not productive at tuning or making changes to a PID loop. Over time, I learned via looking at the code, reading online, and getting training from very experienced automation software engineers. I'm by no means an expert now, but we were able to turn changes around in minutes and be confident in the outcome, instead of hours/days with some doubt as to what would actually happen in the physical world.
Here was my takeaway: an engineer has to understand the domain and algorithms involved at a deep level, or they will not be productive. Or, you will need to have both an engineer and somebody with the domain knowledge and experience.
It doesn't really matter what your problem domain is. If you're an engineer, and it's your job to make changes to a system, whether code or config, you need to understand it at a deep level. And your manager needs to understand this requirement.
Otherwise, you will be guessing at changes, so your productivity will be horrible or non-existent.