[deleted]
Do you strive to understand your tools, or simply “make it work”?
31–40 of 44 posts
Re: Do you strive to understand your tools, or simply “make it work”?
#32If you don't understand how something works, you will never understand why it stopped working. Lesson #1 from my car hacking hobby.
Just out of curiosity, what kind of car hacking? I used to do a bit of Honda ECU hacking. It was a lot of fun.
Re: Do you strive to understand your tools, or simply “make it work”?
#33You can ask these same questions about a lot of things we use every day. Do you have deep knowledge of how your car works, or just a superficial understanding of the basics to keep it running? How about your refrigerator? Household plumbing? Your computer? And how deep is "superficial"? Another question to ask yourself is, "If it breaks, could you fix it?" And what is fixing it? Swapping parts, fiddling with function…
The difference between appliances and tools we physically use and programming tools is that the abstraction for physical tools is necessarily as simple as possible. Cars being one of the most complex tools we interact with, it still has a very basic and well defined set of abstractions to learn. Software tools on the other hand have a way of spiraling in complexity. We're so good at using physical tools because this…
In the context of the tool analogy, you're right: we should pick libraries and not frameworks.
However, many software projects are complex machines---and like real world machines they're made of parts.
It'd better then to have a framework because the framework assures you that all these parts ought to work together, or at least have been designed to a certain abstract standard.
Imagine building a car but rather than being able to order Ford-fitted parts or Toyota-fitted parts, you'd just get generic parts that you then have to machine yourself in order to make work. Every part, every screw, everything. It'd take tens times as long as if you only had to machine rare parts (e.g. a 1965 engine block to fit a 1973 model frame).
Re: Do you strive to understand your tools, or simply “make it work”?
#34If you don't understand how something works, you will never understand why it stopped working. Lesson #1 from my car hacking hobby.
Just out of curiosity, what kind of car hacking? I used to do a bit of Honda ECU hacking. It was a lot of fun.
these days I'm driving a 1989 YJ wrangler. it's a hilariously impractical vehicle (not off roading yet), but it's unbelievably fun to work on, despite being carbureted. everything's just so accessible and simple.
before this I was all over the vws (1.8t, tdi, and then an idi), with all the usual vw stuff (especially diesels. I love diesels).
I think my next step will be either a subaru (track car), or a honda/bmw (just a get-around car).
I'm pretty limited tho since I live in Ottawa and have no garage. ask me if I've looked into starting a garage co-op here, and I'll tell you terrible insurance related woes.
Re: Do you strive to understand your tools, or simply “make it work”?
#35Why it's very useful for developers to learn assembler, know computer at hardware level, know how instal Linux From Scratch, compile their own webserver/db/etc, sysadmin stuff.
Know that first. Then, if you choose, go use turn key systems/hosting environments.
Re: Do you strive to understand your tools, or simply “make it work”?
#36This seems like a false dichotomy.
We all just want to make things work. Oftentimes with programming, having a better understanding of your tools helps you become better at "making it work."
Re: Do you strive to understand your tools, or simply “make it work”?
#37I find there's a lot of hand-waving that goes on when you initially learn something. Just the other day I was talking to a friend about learning programming. I said to him that I'm quite capable of teaching someone who knows the basics of programming more as long as there's the initial foundation to build on but I'll be damned if I know how to teach someone who doesn't know how to program at all how to program. I don…
You may be interested in "The Camel Has Two Humps": http://www.eis.mdx.ac.uk/research/PhDArea/saeed/paper1.pdf and other work by Saeed Dehnahdi: http://www.eis.mdx.ac.uk/research/PhDArea/saeed/ He thinks that only about a third of the populace can learn programming at all, and that may be the difference between teaching someone who knows the basics of programming vs teaching programming to a non-programmer.
That paper has done a lot of damage.
I also think that if you write a paper like that, that it should include a lot of qualifiers as to what you think you've discovered and what research might be done in order to validate/disprove your findings.
Broadly binning a large part of the population as far as a fairly basic ability is concerned (the ability to instruct another entity, which is the essence of programming) based on some extremely flawed tests is not the way science should be done.
Try the 'test' they give to people on a population and then try this test on another population of similar size and observe the difference:
move 10 to a
move 20 to b
move contents of b to a
Note that I'm not saying that the conclusion of the paper is wrong, I simply object to the hidden assumptions behind the design of the test. Removing those assumptions would be pretty tricky thing to do with 100% accuracy, and in the end the conclusions reached in the paper might still stand (but I doubt that they would be the same in magnitude).
Re: Do you strive to understand your tools, or simply “make it work”?
#38Yes, we did! That is why we love Erlang but not Node.js, Lisp/Scheme instead of Java, Python3/Ruby instead of PHP, C but not C++, Postgres instead of MySQL, postfix, but not sendmail, Emacs instead of Eclipse, vim in terminal window and never use mc! ^_^
Re: Do you strive to understand your tools, or simply “make it work”?
#39Earlier quoted context omitted.
You may be interested in "The Camel Has Two Humps": http://www.eis.mdx.ac.uk/research/PhDArea/saeed/paper1.pdf and other work by Saeed Dehnahdi: http://www.eis.mdx.ac.uk/research/PhDArea/saeed/ He thinks that only about a third of the populace can learn programming at all, and that may be the difference between teaching someone who knows the basics of programming vs teaching programming to a non-programmer.
That paper has done a lot of damage. I also think that if you write a paper like that, that it should include a lot of qualifiers as to what you think you've discovered and what research might be done in order to validate/disprove your findings. Broadly binning a large part of the population as far as a fairly basic ability is concerned (the ability to instruct another entity, which is the essence of programming) bas…
///Even just the assumption that statements are to be executed in a particular sequence greatly affects the outcome of tests like this and you may have to specify such a thing up-front if you expect people to be on a level playing field.
I was guilty of forgetting this in a programming interview and gave an answer from algebra.Needless to say interview went downhill very soon.
Re: Do you strive to understand your tools, or simply “make it work”?
#40For bowling, the underlying is basic physics, something that is never going to change, never go away.
For technology or tools, the underlying specifics are going to change insanely fast, so if you are learning it, you will need to unlearn soon (and learn something else).
So should you learn internals of libc? STL? JVM, bytecode? rt.jar? .NET CLR? V8 JIT?