Do you strive to understand your tools, or simply “make it work”?(kylewritescode.com)
kylewritescode.com
Do you strive to understand your tools, or simply “make it work”?
http://kylewritescode.com/post/10163606803/do-you-strive-to-understand-your-tools-or-simply-make
30 comments
I dig as deep as necessary to make things work cleanly, and generally no deeper. (The exception is innately fascinating topics, like compilers.) I can't stand kludging around aimlessly until things work, but I can't read the source of every library, either.
At the moment, I'm trying to build a drop-in blog engine for Rails 3.1, which involves reading a fair amount of source code. But I need to wrap this up today and start on a different client project tomorrow, so I can't afford to dive too deeply.
At the moment, I'm trying to build a drop-in blog engine for Rails 3.1, which involves reading a fair amount of source code. But I need to wrap this up today and start on a different client project tomorrow, so I can't afford to dive too deeply.
Agreed, I take the same approach. The world is not black/white, hacks/optimal. There is a balancing act to be had, including balancing time spent against future issues from that solution.
You 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 params, without knowing exactly what went wrong at a deep level? Paying someone to fix it for you? Is it "understanding" to know whom to pay for what repair?
I believe it is possible to have a thorough understanding of every aspect of every tool we use, but this would tend to limit the extent most of us would build up from it, as time spent learning these fundamentals is no longer available for deriving from them. If we assume humans have limited time and capacity for understanding what already is, it's by necessity that we use certain inventions as black boxes in order to build from them.
Or maybe the question is, "Should you be able to build your own toaster?"
http://www.ted.com/talks/thomas_thwaites_how_i_built_a_toast...
Another question to ask yourself is, "If it breaks, could you fix it?" And what is fixing it? Swapping parts, fiddling with function params, without knowing exactly what went wrong at a deep level? Paying someone to fix it for you? Is it "understanding" to know whom to pay for what repair?
I believe it is possible to have a thorough understanding of every aspect of every tool we use, but this would tend to limit the extent most of us would build up from it, as time spent learning these fundamentals is no longer available for deriving from them. If we assume humans have limited time and capacity for understanding what already is, it's by necessity that we use certain inventions as black boxes in order to build from them.
Or maybe the question is, "Should you be able to build your own toaster?"
http://www.ted.com/talks/thomas_thwaites_how_i_built_a_toast...
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 simplicity allows us to learn their use on an unconscious level, ie. muscle memory. The take home here is that we need to radically simplify the programmming tools we use. Unfortunately the trend towards frameworks rather than libraries is moving in the wrong direction.
Software tools on the other hand have a way of spiraling in complexity. We're so good at using physical tools because this simplicity allows us to learn their use on an unconscious level, ie. muscle memory. The take home here is that we need to radically simplify the programmming tools we use. Unfortunately the trend towards frameworks rather than libraries is moving in the wrong direction.
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).
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).
For me, it depends on the tool. If I think the tool is internally cohesive, and the underlying reasons for its behavior are sound, I'll learn about them it and try to figure out its behavior.
If I think the tool is a sloppy stack of hacks, I don't care how it works --- I actively avoid the nightmare. I don't want to spend my time figuring out which bad decisions, bugs, and corner cases made it behave in a certain way.
If I think the tool is a sloppy stack of hacks, I don't care how it works --- I actively avoid the nightmare. I don't want to spend my time figuring out which bad decisions, bugs, and corner cases made it behave in a certain way.
I think you make an excellent point.
Tools that are "internally cohesive" reward the effort put into learning them.
Knowledge gained learning one function of an internally cohesive tool can often be applied to others, opening up new functionality and encouraging you to learn more about the tool.
This way your understanding of good tools tends to grow organically instead of the jarring pile of rote-learning that a kludgy tool tends to require.
Tools that are "internally cohesive" reward the effort put into learning them.
Knowledge gained learning one function of an internally cohesive tool can often be applied to others, opening up new functionality and encouraging you to learn more about the tool.
This way your understanding of good tools tends to grow organically instead of the jarring pile of rote-learning that a kludgy tool tends to require.
// I actively avoid the nightmare. I don't want to spend my time figuring out which bad decisions, bugs, and corner cases made it behave in a certain way.
I usually do that too. But am beginning to wonder, if i should not. If only to understand bad design decisions made by others and be wary of making them my work.
I have found that I ALWAYS try to learn as much as I can to have a fully intimate understand of the tools that I use. However, I have also found that this has more often than not been a huge disservice to myself.
For example, yesterday I got fired from my employer on my 90th day for not being productive enough. I can't fault my employer because I understand his perspective. He needs employees that are productive. I spent most of my 90 days learning the tools and EXACTLY how they work, without much to show for it. This was my fault. I spent too much time learning.
This is true with many things that I learn on my own as well. For example, in the last few days I started teaching myself Kohana PHP framework. If some of MY applications are going to be using it, I want to know exactly how it works and everything about it. I want to be an "expert" at everything, but I'm not quite sure how realistic that is.
I think I am going to try to change my ways to only learn enough to "make it work". If the tool is worthwhile to use over and over again, it is inevitable to develop an intimiate understanding of the way it works over time. I think it is more important to be able to have awesome products to show for the time you invest in your tools.
For example, yesterday I got fired from my employer on my 90th day for not being productive enough. I can't fault my employer because I understand his perspective. He needs employees that are productive. I spent most of my 90 days learning the tools and EXACTLY how they work, without much to show for it. This was my fault. I spent too much time learning.
This is true with many things that I learn on my own as well. For example, in the last few days I started teaching myself Kohana PHP framework. If some of MY applications are going to be using it, I want to know exactly how it works and everything about it. I want to be an "expert" at everything, but I'm not quite sure how realistic that is.
I think I am going to try to change my ways to only learn enough to "make it work". If the tool is worthwhile to use over and over again, it is inevitable to develop an intimiate understanding of the way it works over time. I think it is more important to be able to have awesome products to show for the time you invest in your tools.
Yep... i know. it's kind of an information addiction. I have been there still working through it. but one thing i have found useful is trying to be aware of what am doing moment by moment. Rescuetime.com has been a great help in summing up my activities and gives me pointers to avoid things not to do.
Understanding your tools in detail is a great way to differentiate yourelf. I make it a point to understand my working subject matter in great detail. At one point in my career, I did a lot of telecom consulting. Work ranged from voice network design all the way down to troubleshooting. I could have done my job by simply being a "phone ringer" (someone who just calls someone else to solve problems), but I found that by understanding the technologies in detail, I could discern fact from fiction when dealing with third-parties. This made me extremely valuable to my clients. I don't think I worked with a company that didn't float me a job offer at some point.
Bottom line: Understanding your tools in depth allows you to differentiate outcomes that will be opaque to less knowledgable competitors.
Bottom line: Understanding your tools in depth allows you to differentiate outcomes that will be opaque to less knowledgable competitors.
Depends on how much respect I have for the tool.
The TCP/IP stack: strive to understand it.
Random Java SOAP abomination: get in, make it work, get out.
The TCP/IP stack: strive to understand it.
Random Java SOAP abomination: get in, make it work, get out.
Even the most trivial of applications today will depend on an incredible amount of carefully crafted, clever to genius code (operating systems, databases, compilers, VMs, ...). I'm always deeply humbled when I think of all the engineering smarts and effort that went into the stack I'm working with every day.
There's no chance in hell to understand all the tools. It's quite possible to understand the concepts and general principles these tools are built around (i.e., all the stuff you get taught in a proper computer science course), which I think is what one should thrive for.
Note that even understanding the concepts will not even nearly equip you to (easily) understand and re-implement these tools, there's a lot more to any properly crafted tool than just the rough concepts.
There's no chance in hell to understand all the tools. It's quite possible to understand the concepts and general principles these tools are built around (i.e., all the stuff you get taught in a proper computer science course), which I think is what one should thrive for.
Note that even understanding the concepts will not even nearly equip you to (easily) understand and re-implement these tools, there's a lot more to any properly crafted tool than just the rough concepts.
[deleted]
I think this is an important indicators of whether you should be an entrepreneur or a software developer. The best developers are fascinated by the processes that animate their work; sometimes they can't dig down all the way given time constraints but I find that they (and I) could happily analyze (and ideally rewrite) the entire gordian knot of a complex system.
Entrepreneurs have a totally different profile. Instead of the "how" and "what" of the project, they focus on the "why" and the "who cares". Will this project be valuable? Should I pivot this idea? Who is my first customer and what do they want?
These tendencies don't coexists very well -- they both want to be priority 1 in my mind. While I've been writing code, polishing scripts, reading kernel code, and accumulating my 5000 lines of emacs-lisp hacks, my friends chose different routes and started small businesses or pursued influence and high salaries. Now I'm a super-wonky developer and they're much better at sniffing out the real value in the world. Each of us has our place and on some days I'd rather be them. Somehow though, and somewhat mysteriously, when it comes time to choose I'd rather be rewriting the low level than pursuing meaning at the high-level.
Entrepreneurs have a totally different profile. Instead of the "how" and "what" of the project, they focus on the "why" and the "who cares". Will this project be valuable? Should I pivot this idea? Who is my first customer and what do they want?
These tendencies don't coexists very well -- they both want to be priority 1 in my mind. While I've been writing code, polishing scripts, reading kernel code, and accumulating my 5000 lines of emacs-lisp hacks, my friends chose different routes and started small businesses or pursued influence and high salaries. Now I'm a super-wonky developer and they're much better at sniffing out the real value in the world. Each of us has our place and on some days I'd rather be them. Somehow though, and somewhat mysteriously, when it comes time to choose I'd rather be rewriting the low level than pursuing meaning at the high-level.
If you don't understand how something works, you will never understand why it stopped working.
Lesson #1 from my car hacking hobby.
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.
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.
I ussually make it work first, then slowly begin to understand the tools through working with them.
I'm of the school that in many things, if you have to teach someone how to use it, you've done it wrong. Let the user learn by doing.
Probably can't apply to everything, but we should work as had as we can to try to get there.
I'm of the school that in many things, if you have to teach someone how to use it, you've done it wrong. Let the user learn by doing.
Probably can't apply to everything, but we should work as had as we can to try to get there.
[deleted]
Not only do I like understanding my tools, I build my own tools. I find abstractions and go after them whenever possible. There is always an upfront cost to this but the end result is a cleaner system.
The understand-your-tools side builds the tools that the make-it-work side uses. The feedback between both sides is important for improvement. The success of the make-it-work side helps to quantify the value of the ideas coming from the understand-your-tools side. It's unfortunate that these two points are often treated like opposing sides.
The understand-your-tools side builds the tools that the make-it-work side uses. The feedback between both sides is important for improvement. The success of the make-it-work side helps to quantify the value of the ideas coming from the understand-your-tools side. It's unfortunate that these two points are often treated like opposing sides.
For me, it's kind of the default state of mind, building models of reality, and I can go as far as doing it unconsciously. Just a few hours ago I was in a friend's office talking to him about 3D models and through no conscious decision of mine I started twiddling around with a perforator. The point where I realized what my purpose had been was when I broke the flow of the conversation with the complete non-sequitur, "oh, now I know what that twiddly part on a spring does - you pull it and lock the perforator making it more compact".
I know other people that do that too. For some of us, the immediate reaction to a new thing is "ooh, shiny, how does it work? Let's run some experiments." The scientific mindset is useful, I think, no matter what you wish to exploit.
I know other people that do that too. For some of us, the immediate reaction to a new thing is "ooh, shiny, how does it work? Let's run some experiments." The scientific mindset is useful, I think, no matter what you wish to exploit.
I had never considered it. I can't 'make it work' without understanding it, so I consider it a non-issue.
I mean, I suppose minimal projects could get completed, but I never work on minimal projects. Mine always have edge cases, and that requires knowledge.
I mean, I suppose minimal projects could get completed, but I never work on minimal projects. Mine always have edge cases, and that requires knowledge.
I would love it if documentation facilitating understanding was available for general technologies. Learning how != learning why. For example, I have many times tried to learn CSS and it would be _great_ if anyone would care to explain in broad terms what the theory behind it is. Why choose the primitives that they chose, it CSS 'turing complete' for layout? If so, why? Who came up with it? The same goes for many technologies. I would like to have some history, a theoretical backround, and the improvements that the tool tries to solve.
Powerful tools require a good understanding of them to get the most out of them.
The best powerful tools don't require an in-depth understanding of them to get started (think git, rails or Linux). But mastering them over time will make you better by orders of magnitude than the copy-pasters with no fundamental knowledge of the tools they use every day.
The trick is in figuring out which tools are good, and which of them you want to commit to.
The best powerful tools don't require an in-depth understanding of them to get started (think git, rails or Linux). But mastering them over time will make you better by orders of magnitude than the copy-pasters with no fundamental knowledge of the tools they use every day.
The trick is in figuring out which tools are good, and which of them you want to commit to.
If I can reuse the knowledge gained by understanding it, I go for it. In understanding, I can reduce complexity, or at least try, for future users.
Also if I find something that is complex, e.g. OAuth, I try to preserve the sources of information I used to reach a decent level of understanding for maintenance purposes.
If I'm just doing something quick and not worried about future usage, I just make it work.
Also if I find something that is complex, e.g. OAuth, I try to preserve the sources of information I used to reach a decent level of understanding for maintenance purposes.
If I'm just doing something quick and not worried about future usage, I just make it work.
I strive to understand the proper way to use the tool to make it work, most of the time I don't really care how the tool works as long as I understand the best and most efficient way the tool was indented to be used.
If later I have a strong desire to understand how it works I'll dive in, but most software tools I don't care to know.
I don't really care about the detail inner workings of my car.
If later I have a strong desire to understand how it works I'll dive in, but most software tools I don't care to know.
I don't really care about the detail inner workings of my car.
A lot of time these two options go hand in hand.
That said, a lot of the tools I use at work are built by myself or my team. I trust them, so "making it work" is enough for me, especially because I don't always have the time to understand everything 100%.
If I'm doing something as a hobby, I try to understand it, because time isn't really a factor there, and that's the fun part, right?
That said, a lot of the tools I use at work are built by myself or my team. I trust them, so "making it work" is enough for me, especially because I don't always have the time to understand everything 100%.
If I'm doing something as a hobby, I try to understand it, because time isn't really a factor there, and that's the fun part, right?
For 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?
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?
I try to understand as much as I can. Recently, I tried to deploy a rails app without capistrano (the manual way). But, People are saying, like why are you even doing that?
I don't know. I want to know what is going on? Know it first, automate next, thats what I try to do most of the times.
I don't know. I want to know what is going on? Know it first, automate next, thats what I try to do most of the times.
Why 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.
Know that first. Then, if you choose, go use turn key systems/hosting environments.
Yes, 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! ^_^
This 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."
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."
I know this is cliched, but it /should/ just work. It should be easy enough for the end user to have a basic understanding of that tool.
when I am working on my own project I try to dig as deeper as as I feel like. If I am a working on a client project I try to dig only as deep as I need to (with limited success)
I 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't even know how I learnt to program. I was a kid at the time and I guess I basically just typed in programs from books and then played around with them. I guess this model largely follows the idea of direct instruction [1]. It's one reason I like Zed Shaw's Learn Python the Hard Way [2] because it starts by just saying "type this in... actually type it don't copy and paste it" because for beginners this approach actually works (well).
One thing I find interesting is that many non-programmers I know are afraid to just start pressing buttons and messing around with stuff to get the computer to do what they want. They want to know how to do it before they start. I think this fits in with the theme of direct instruction as I've learnt the behaviour of doing something without knowing exactly what will happen. Without this willingness to try (fail) your ability to learn seems to be incredibly impeded to the point of being near-impossible (IMHO).
To bring this back to understanding your tools I would say I follow this pattern:
- If I can, I'll learn just enough to get by;
- I'll slowly accrue new techniques and knowledge as time goes by and I use it (studying this kind of thing without needing to use it is virtually useless for me); and
- For things that are most key to what I do I'll expend time and energy delving deeper into them but this applies more to languages, APIs, frameworks, platforms, etc than it does the tool. The tool is, after all, a means to an end not an end in itself.
For me I've found learning tools to follow a fairly similar pattern to learning (human not computer) languages: I can try and memorize things all I want but I seem to have this base rate at which I will accumulate "instinctive" knowledge that is a function of how much I use something with very little variation up or down.
YMMV.
[1]: http://en.wikipedia.org/wiki/Direct_instruction
[2]: http://learnpythonthehardway.org/
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't even know how I learnt to program. I was a kid at the time and I guess I basically just typed in programs from books and then played around with them. I guess this model largely follows the idea of direct instruction [1]. It's one reason I like Zed Shaw's Learn Python the Hard Way [2] because it starts by just saying "type this in... actually type it don't copy and paste it" because for beginners this approach actually works (well).
One thing I find interesting is that many non-programmers I know are afraid to just start pressing buttons and messing around with stuff to get the computer to do what they want. They want to know how to do it before they start. I think this fits in with the theme of direct instruction as I've learnt the behaviour of doing something without knowing exactly what will happen. Without this willingness to try (fail) your ability to learn seems to be incredibly impeded to the point of being near-impossible (IMHO).
To bring this back to understanding your tools I would say I follow this pattern:
- If I can, I'll learn just enough to get by;
- I'll slowly accrue new techniques and knowledge as time goes by and I use it (studying this kind of thing without needing to use it is virtually useless for me); and
- For things that are most key to what I do I'll expend time and energy delving deeper into them but this applies more to languages, APIs, frameworks, platforms, etc than it does the tool. The tool is, after all, a means to an end not an end in itself.
For me I've found learning tools to follow a fairly similar pattern to learning (human not computer) languages: I can try and memorize things all I want but I seem to have this base rate at which I will accumulate "instinctive" knowledge that is a function of how much I use something with very little variation up or down.
YMMV.
[1]: http://en.wikipedia.org/wiki/Direct_instruction
[2]: http://learnpythonthehardway.org/
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.
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:
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).
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).
But the predictor isn't whether the testee gets these problems right. The predictor is whether the testee uses a consistent mental model for the problem--that is, someone who interprets "a=b" as "move contents of a to b" will end up programming as well as someone who does the converse, but not someone who picks and chooses without being sure.
Yes, I read the paper.
Try coming up with a 'consistent mental model' that works with random execution sequences.
Then try again for one that works backwards. And so on.
At best this test determines which people are going to be 'easy' to teach programming. But just like sales start at 'no' teaching starts when the subject is having problems, not when it's easy.
Try coming up with a 'consistent mental model' that works with random execution sequences.
Then try again for one that works backwards. And so on.
At best this test determines which people are going to be 'easy' to teach programming. But just like sales start at 'no' teaching starts when the subject is having problems, not when it's easy.
///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.
I was guilty of forgetting this in a programming interview and gave an answer from algebra.Needless to say interview went downhill very soon.
Has this guy disassembled and come to understand the inner workings of the drill he used? Because that's the deep tool knowledge in this analogy, not the insight into the interaction between hole position and ball/player performance.
The problem is that learning to build/configure/use XYZ is almost always a wasted effort, it is not like learning a new algorithm that will be useful knowledge for decades, so if the effort is too big I consider it wasted time.
Examples of tools that are not easy to master but that I'm trying to learn well are vim (it's 15 years I use it), and git. Both tools pay back a lot, and in the case of git it is hard to learn not because it is hard per-se, but since you are learning general concepts about distributed VCS, so it's not a wasted effort.