|
|
|
|
|
|
by Delmania
3786 days ago
|
|
|
How well do you understand an internal combustion engine? Do you know it well enough to be able to diagnose an issue ad then fix it? Can you listen to it, identify when it's not performing well, and then make the tweaks to it in order to get the most efficiency?
If you say yes, I would be very surprised, and yer every day, people all over the world rely on these things to get them to the place they need to go. There is nothing wrong with these developers, they don't know these things because they simply do not need to. The tools have abstracted away those details, as they should. There is simply too much in the domain of writing software to know, and even in web development, there is too much to know. Most people focus on what is needed to get the job done because in most places, you are judged by your results and not your knowledge. What good is know what a singleton is if you never use it? Why do people need to know what the doctype does when <!DOCTYPE html> is good enough for the browser to interpret? By abstracting away these details, people can focus on higher level problems, like solving the actual requirements. If people need to learn those things, they will do so. Good developers seek to learn about their tools. Great developers learn to separate out the wheat from the chaff and focus only on the knowledge that is important. |
|
|
He is not hiring drivers; he is hiring mechanics and manufacturing engineers. And yes, they both absolutely need to know how an IC engine works.
Yes, tools are doing their job, yes they will only keep getting better and I want them to keep getting better. But that is no excuse to not know how they work, and what are the tradeoffs of using one over the other. e.g. There are plenty of ORMs for PHP. Why would you use one over the other? If one ORM generates more efficient queries at the cost of some programming discomfort, I'd much rather have you choose that.
By definition, tools solve generic use-cases. i.e. you can get away with tools as long as you're solving simplistic generic problems that have been solved before. But the moment you transcend that boundary and need to do anything custom, especially at scale, you will totally need to know how things work under the hood. You may still end up modifying an existing tool, but you'll only do a good job at it when you understand the insides.
Also, the urge to look under the hood is simply a proxy to curiosity. That is exactly what starts to separate better engineers from mediocre ones.
[About me: http://InterviewKickstart.com]