i think there’s a delicate balance between “learn fast and break things”, and “learn from other’s mistakes”.
if you only ever learn from other’s mistakes, you might miss out on learning first principles. Making a mistake first hand oftentimes gives you a lot of valuable insight as to the first principles of “why is using google drive as a database not always good?”
on the other hand, you could waste a lot of time if you made every mistake yourself. ¯_(ツ)_/¯
It’s a little ironic the title is about shooting yourself in the foot, which is something most of us have learned to avoid WITHOUT actually experiencing it.
I think it works quite well as an analogy though, because one of the ways that we’ve learned not to shoot ourselves in the foot is by dropping things on our feet as children. We know that this hurts and so we extrapolate that a bullet would hurt more, but we have a visceral immediate reaction to the thing that will cause pain. Similarly, most of the things in this article aren’t real foot-shooting (they weren’t in production, they were quickly fixed) but they were toe-stubbing events that led the author to being more careful of his feet in the future.
I agree with your sentiment in general. I also find it idiotic when I read people write things like “We’ve done X, but it resulted in catastrophe Y, but we’ve learned from the experience and are now better for it” where, for any half-sane person, Y is an obvious outcome of X and nobody in their right mind would give it a try to begin with. However, IMO the points mentioned in this article don’t fall under this category. The things the author resisted at first are truly complicated and I agree that people shouldn’t accept such things as ground truth until convinced otherwise by strong evidence.
I’ll definitely agree with the Rust example there. I first tried to learn Rust while mostly being a Python/Go programmer, and couldn’t wrap my head around lifetimes. I then started a full-time gig where I wrote C++ and all the pieces about lifetimes started to fall into place.
The problem with OO education where you learn Dog is an Animal, etc. is that it’s not coming from a place of fixing a broken toe. The solution is just presented in the abstract, and then people apply it in the abstract as well. OO is much better when you start with “you know how you’re just writing functions top to bottom, but you have a big hairy if-statements in the middle that you’re afraid to touch?”
My first question whenever someone presents me with a tool - any tool - is, “What problem does this fix?” That is to say I agree with your assessment here. You cannot present a tool in the abstract and say, “Use this to hammer nails,” without first quantifying the problem of, “So you know how you want to join two boards together?”
Ignore the fact that the article is about blockchain, and Jon Stokes’s can opener problem is good here:
can opener problem (noun)
The problem you face when trying to explain the operation of a can opener to someone who has never seen or heard of a can. More generally, the problem of explaining a specialized solution to an audience for whom the corresponding problem is completely alien.
i find when i use oo to untangle a ball of ifs, i end up shooting myself in the foot. the functions get smaller and less indented, but the behaviour gets spread over more files, and gotos become comefroms, and it can be a nightmare to debug
mostly, i like them as commonly used types (list, set, etc.) that come in handy for algorithms (monomorphization is often faster at runtime, but compile times and code size suffer). and sometimes a top-level concept in your program makes sense as an interface
INTERCAL, a language designed to be difficult to use and implement, had come from statements. For extra fun. It had computed come from statements (come from any location when a particular expression evaluates to its line number). Somewhat amusingly, modern CPUs have hardware support for this, though they call them watch points.
The difference between knowledge and wisdom is PAIN. As you get older, hopefully, you observe others going through pain, and you then try to take the lessons to heart without desiring to go through the pain yourself. This is called “maturity”.
As an ‘experienced’ programmer (ie no toes left) there are points at which mentorship can be best done by saying “good luck!” even when you know the problem. It can be hard to distinguish between groundless advice and grounded without experiencing the pain. Even if that pain is brutally obvious to the more experienced person, a bunch of “do as I say” will never equal one a-ha moment from a programmer.
Can be necessary*, it is however necessary to fully understand the reasoning behind a certain decision. As you become more experienced you can reason before shooting
That being said I often stray from “best practices” but its because I understand their limitations very well from applying them many times, and exercise a lot of caution when doing so.
I wouldn’t call this “shooting yourself in the foot”. It’s a preference for simple over complex which is usually the healthy approach. It’s much easier to go from simple to complex than the other way around so it’s better to stick with simple until you understand the trade-offs involved in more complex alternatives.
It is occasionally possible, and vastly profitable, to learn from witnessing other people’s mistakes instead of making them yourself.
Too slow and rare a process. Better I shoot myself as many times as possible. Fail fast and break things.
Production servers fear me, people who want severance want to be me.
Rare and valuable
Also you brain to register it as much. When you suffer, you remember. Something in you will build a reaction to similar situation instinctively.
i think there’s a delicate balance between “learn fast and break things”, and “learn from other’s mistakes”.
if you only ever learn from other’s mistakes, you might miss out on learning first principles. Making a mistake first hand oftentimes gives you a lot of valuable insight as to the first principles of “why is using google drive as a database not always good?”
on the other hand, you could waste a lot of time if you made every mistake yourself. ¯_(ツ)_/¯
Yes, but it’s not an XOR proposition.
It’s more an “implies not”,
“learn from another’s mistake” -> ^“learn from own mistake”
It’s a little ironic the title is about shooting yourself in the foot, which is something most of us have learned to avoid WITHOUT actually experiencing it.
I think it works quite well as an analogy though, because one of the ways that we’ve learned not to shoot ourselves in the foot is by dropping things on our feet as children. We know that this hurts and so we extrapolate that a bullet would hurt more, but we have a visceral immediate reaction to the thing that will cause pain. Similarly, most of the things in this article aren’t real foot-shooting (they weren’t in production, they were quickly fixed) but they were toe-stubbing events that led the author to being more careful of his feet in the future.
I agree with your sentiment in general. I also find it idiotic when I read people write things like “We’ve done X, but it resulted in catastrophe Y, but we’ve learned from the experience and are now better for it” where, for any half-sane person, Y is an obvious outcome of X and nobody in their right mind would give it a try to begin with. However, IMO the points mentioned in this article don’t fall under this category. The things the author resisted at first are truly complicated and I agree that people shouldn’t accept such things as ground truth until convinced otherwise by strong evidence.
I’ve dropped plenty of heavy objects on it though!
I’ll definitely agree with the Rust example there. I first tried to learn Rust while mostly being a Python/Go programmer, and couldn’t wrap my head around lifetimes. I then started a full-time gig where I wrote C++ and all the pieces about lifetimes started to fall into place.
it is a way of learning, but not the only way
I’ve never seen someone learn without this. And I teach a lot.
It’s not the only way, but it’s part of the journey, unless you never do anything.
Embracing it just make you benefit from it more.
The problem with OO education where you learn Dog is an Animal, etc. is that it’s not coming from a place of fixing a broken toe. The solution is just presented in the abstract, and then people apply it in the abstract as well. OO is much better when you start with “you know how you’re just writing functions top to bottom, but you have a big hairy if-statements in the middle that you’re afraid to touch?”
My first question whenever someone presents me with a tool - any tool - is, “What problem does this fix?” That is to say I agree with your assessment here. You cannot present a tool in the abstract and say, “Use this to hammer nails,” without first quantifying the problem of, “So you know how you want to join two boards together?”
Ignore the fact that the article is about blockchain, and Jon Stokes’s can opener problem is good here:
i find when i use oo to untangle a ball of ifs, i end up shooting myself in the foot. the functions get smaller and less indented, but the behaviour gets spread over more files, and gotos become comefroms, and it can be a nightmare to debug
mostly, i like them as commonly used types (list, set, etc.) that come in handy for algorithms (monomorphization is often faster at runtime, but compile times and code size suffer). and sometimes a top-level concept in your program makes sense as an interface
Never heard this expression but I can see myself using it from now on.
INTERCAL, a language designed to be difficult to use and implement, had come from statements. For extra fun. It had computed come from statements (come from any location when a particular expression evaluates to its line number). Somewhat amusingly, modern CPUs have hardware support for this, though they call them watch points.
The difference between knowledge and wisdom is PAIN. As you get older, hopefully, you observe others going through pain, and you then try to take the lessons to heart without desiring to go through the pain yourself. This is called “maturity”.
I can’t recommend this enough. You really need to feel the pain in order to understand why things are the way they are.
As an ‘experienced’ programmer (ie no toes left) there are points at which mentorship can be best done by saying “good luck!” even when you know the problem. It can be hard to distinguish between groundless advice and grounded without experiencing the pain. Even if that pain is brutally obvious to the more experienced person, a bunch of “do as I say” will never equal one a-ha moment from a programmer.
Can be necessary*, it is however necessary to fully understand the reasoning behind a certain decision. As you become more experienced you can reason before shooting
That being said I often stray from “best practices” but its because I understand their limitations very well from applying them many times, and exercise a lot of caution when doing so.
Good judgement comes from bad judgement?
From experiences born of ignorance, I would say.
More generally hidden abstractions can be harmful if the need for the abstraction is too abstract.
I wouldn’t call this “shooting yourself in the foot”. It’s a preference for simple over complex which is usually the healthy approach. It’s much easier to go from simple to complex than the other way around so it’s better to stick with simple until you understand the trade-offs involved in more complex alternatives.