4 ms·

> ...too many juniors will read this and think they need more abstraction. Yes. And that's a good thing. The way you become "an expert" is by making ALL the m

> ...too many juniors will read this and think they need more abstraction. Yes. And that's a good thing. The way you become "an expert" is by making ALL the mistakes yourself, seeing the results, and doing it over and over again in different contexts until you understand and can do it right (most of the time).

agentultra 7y ago
Mistakes are always a part of the process and are one way to learn. However I don't think we would have had Ramanujan if he were left to rediscover all of mathematics on his own. Having an expert validate your insights or point you in the right direction can speed up the learning process a lot.
tekkk 7y ago
A good thing is making those mistakes but never landing most of them into production. It will boost your progress immensely if you have somebody available to critique and guide you in the right direction. Making mistakes but learning only a month later when significant amount of time has been wasted in wrong things won't make you any smarter than figuring them out before-hand. Also you'll be a lot less confident afterwards doing anything by yourself after such a disaster. So no, don't make "ALL the mistakes". Learn by observing others around you, emulating it and then finally at some point understanding it clearly enough to make something completely novel.
- crispyambulance 7y ago
  > ...making those mistakes but never landing most of them into production. It will boost your progress immensely if you have somebody available to critique and guide... I mostly agree. But the consequences of what "landing a mistake in production" actually means depends on a lot on the environment and the project. Does it mean the deliverable has a hiccup and skids past the deadline a few days? Does it mean there's <gasp> a bug? Does it mean a hard-to-maintain big ball of mud that makes people miserable for years? Or does it mean a rocket blows up? All those things happen, of course, but to assign blame on any significant number of these to uppity juniors reading articles that are too advanced for them is a bit of a stretch. There are so many ways projects can fail. I think we all can agree that juniors need the agency to try things out (hopefully with a few guard-rails installed). Sadly having benevolent mentor watch-over juniors is, in many places, a luxury and they're forced to read "articles on the internet" for guidance. It's not optimal but it's OK.
  - tekkk 7y ago
    Sure, it's a vague line. And it's hard already for juniors to have the confidence to make their own decisions or code in general. To have them also fear failure is even worse with everybody fixated on not making any mistakes. But as a constant failurer myself, I don't view falling on your ass all the time as that great of a thing that you should be so careless to let it continuously happen. You have to try your best and be focused, otherwise you'll always half-ass things without learning the right mindset so to speak.
- username90 7y ago
  > Learn by observing others around you Or even better, learn by making mistakes and have great coworkers who can catch those in code reviews.
NohatCoder 7y ago
Learning abstractions is really hard, mainly because over or under abstracting doesn't break the code, it just wastes work, and if you keep on erring the same way you won't have a reference for how much work something should have taken.

agentultra 7y ago

Mistakes are always a part of the process and are one way to learn. However I don't think we would have had Ramanujan if he were left to rediscover all of mathematics on his own. Having an expert validate your insights or point you in the right direction can speed up the learning process a lot.

tekkk 7y ago

A good thing is making those mistakes but never landing most of them into production. It will boost your progress immensely if you have somebody available to critique and guide you in the right direction. Making mistakes but learning only a month later when significant amount of time has been wasted in wrong things won't make you any smarter than figuring them out before-hand. Also you'll be a lot less confident afterwards doing anything by yourself after such a disaster. So no, don't make "ALL the mistakes". Learn by observing others around you, emulating it and then finally at some point understanding it clearly enough to make something completely novel.

crispyambulance 7y ago
> ...making those mistakes but never landing most of them into production. It will boost your progress immensely if you have somebody available to critique and guide... I mostly agree. But the consequences of what "landing a mistake in production" actually means depends on a lot on the environment and the project. Does it mean the deliverable has a hiccup and skids past the deadline a few days? Does it mean there's <gasp> a bug? Does it mean a hard-to-maintain big ball of mud that makes people miserable for years? Or does it mean a rocket blows up? All those things happen, of course, but to assign blame on any significant number of these to uppity juniors reading articles that are too advanced for them is a bit of a stretch. There are so many ways projects can fail. I think we all can agree that juniors need the agency to try things out (hopefully with a few guard-rails installed). Sadly having benevolent mentor watch-over juniors is, in many places, a luxury and they're forced to read "articles on the internet" for guidance. It's not optimal but it's OK.
- tekkk 7y ago
  Sure, it's a vague line. And it's hard already for juniors to have the confidence to make their own decisions or code in general. To have them also fear failure is even worse with everybody fixated on not making any mistakes. But as a constant failurer myself, I don't view falling on your ass all the time as that great of a thing that you should be so careless to let it continuously happen. You have to try your best and be focused, otherwise you'll always half-ass things without learning the right mindset so to speak.
username90 7y ago
> Learn by observing others around you Or even better, learn by making mistakes and have great coworkers who can catch those in code reviews.

NohatCoder 7y ago

Learning abstractions is really hard, mainly because over or under abstracting doesn't break the code, it just wastes work, and if you keep on erring the same way you won't have a reference for how much work something should have taken.