Hacker News new | comments | ask | show | jobs | submit login

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.

"How well do you understand an internal combustion engine?"

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]

I think that's fine for developers starting out. But once you start writing software professionally that is for "the enterprise", it's important to understand the underlying stack. Knowing how your kernel's plumbing of pipes actually works (for example) is invaluable in certain cases. Knowing how your framework's black boxes work is very useful when you run into performance problems or find bugs. Yes, abstractions are good. But the higher you go up the stack of abstractions, the less you know about what's actually happening and thus the less you'll be able to do to actually debug it.

EDIT: Sorry, I didn't read the OP. Yeah, his requirements don't make much sense (unless he can do the whole industry a favour and explain what he means by "full stack" developer).

Hi, Thanks for comment. Personally speaking by "Full stack" developer, I expect someone who has enough knowledge of client as well as server technologies so S(h)e could understand (or better anticipate) problems or challenges usually s(H)e would face while working on it. It's not about working for "enterprise", even if it's an in-house product I expect a programmer to know what S(h)e is doing well. If someone do not know what tool/framework really doing while one using it,I wouldnt consider it ideal.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact