6 ms·

Much thanks to Dan for taking the time to write this up. UI dev is a deep and highly technical field, but we’re often inundated with juniorish programmers becau

Much thanks to Dan for taking the time to write this up. UI dev is a deep and highly technical field, but we’re often inundated with juniorish programmers because it’s often the entry point for folks coming out of school or boot camps. We need folks writing more about these kinds of principles and less about a new way to reinvent the wheel

austincheney 8y ago
Absolutely. https://en.wikipedia.org/wiki/Invented_here https://en.wikipedia.org/wiki/Invented_here The name of the game is failure aversion. Frameworks and NPM packages for everything. When I interview JavaScript or UI developers this is my first discriminator. Why write original code or reinvent the wheel when somebody else has your simple solution behind 50mb of external code that you didn't write? If you are that fearful coward who believes in not writing original code I don't want to work with you. Have a nice life and go work somewhere else. I would rather work with somebody willing to take a chance on problem solving. If you are going to down vote please mention why. Don't be a troll. Hacker News tries very hard to not be an echo chamber.
- 0xCMP 8y ago
  You're being toxic by calling people "cowards" for simply using a package instead of writing it themselves which reduces the amount of code they need to directly maintain. Displays a complete misunderstanding of the tradeoffs involved as well as being rude. And what's funny is that if you hadn't been a jerk the original point of Frameworks and NPM Packages for everything is a good point and probably would have been well received. Because, the fact is that, sometimes it IS better to do it yourself instead of using the package and most wouldn't. Sometimes.
  - austincheney 8y ago
    Thank you for having the balls to respond. I could have tap danced around that by using a bunch of words like: demonstrating a proportional degree of insecurity to the depth of requirements presented across the breadth of considerations required by this responsibility. I found the word coward to be more honest and fitting, though. Ultimately, the rampant insecurity isn't a technology problem. It is a personality consideration. > And what's funny is that if you hadn't been a jerk the original point... People on the internet tend to have big tears and thin skin. I don't like lying to people because they have sensitivity issues. I would rather take the down votes. All these few down votes from a few shattered JavaScript developer hearts are instantly wiped clean when I get 80 up votes for posting a single comment about analysis or interviewing. Being honest and transparent has always helped me in the offline real world.
    - HedgeSparrow 8y ago
      Why is it people think being "honest and transparent" means being rude and mean? Tact is also a useful skill.
      - austincheney 8y ago
        Because sensitive people are too selfish to tell the difference. The world isn’t always smiles, hearts, and rainbows there to please you. Directness isn’t condescension unless you are a child. Sometimes honesty really does mean telling people what they don’t want to hear. Tact isn’t a form of antidepressant. Tact is the means to account for the intention of offense without regard for actual offense. Overly sensitive people may never see that distinction. People who figure these things out early tend to live happier and more fulfilled lives.
        pritambaral 8y ago
        > The world isn’t always smiles, hearts, and rainbows there to please you. Of course it isn't, but that does not grant one an implicit licence to be uncouth. > Directness isn’t condescension unless you are a child. Directness isn't condescension, period. That, however, does not mean you can mix condescension with directness and call it plain directness. > Sometimes honesty really does mean telling people what they don’t want to hear. Then please, by all means, do just that, without resorting to improper name-calling. ---- You know what, I'm going to stop countering your points one-by-one, and try to talk to your central idea. I agree with you, at a central level. I wouldn't hire people who cannot write their own code either. I, too, would rather work with people who can and want to solve problems than merely put pegs in holes with assistance from the likes of npm and SO. But I wouldn't call them cowards. Because that would be mis-characterization, at best; and hyper-generalization, at worst. Even if you meant to call someone risk-averse, or fearful, using the word 'coward' is more than being direct. 'fearful' is direct and sufficient, as is 'risk-averse', but if you couldn't settle there and had to reach as far as 'coward', that suggests you wanted to use the extra force that comes with that word. Thus, condescensional offence. And then you continue in this path, characterizing those who wouldn't respond to you as lacking "balls", everyone who disagrees with your choice of words as "insecure", and everyone who downvoted you as "JavaScript developers" with "shattered hearts", those suggesting your "honest and rude" words lack tact as "overly sensitive" people. Lastly, I'll leave you with the suggestion that people in this world lead happier and even more fulfilled lives without resorting to even the slight force you're employing here.
- Daynil 8y ago
  It's important to understand the root of the arguments for and against both "not invented here" and "invented here". Both can be considered a poor mindset because it's thinking in absolutes. Certainly, everyone can agree there is no need to "write original code" for every problem you encounter. If there are libraries behind which there are teams of strong engineers (React, Angular), who work specifically on that problem and exhaustively test and iterate on it, why would you take time and productivity away from the development of your product in order to create your own solutions? On the other hand, if the existing libraries/solutions don't fit your use cases and you spend more time customizing them to work than you do developing your product, or the existing solutions are out of date, unsupported, or appear slapped together, it would certainly be worth working on your own solution to see if you can find a better way. Likewise, experimenting with custom reimplementation is a great way to understand the problems libraries solve in an in-depth way, as Dan suggests, and you may even end up with something better. You just need to be realistic about whether it makes sense to make it yourself or utilize what exists.
  - austincheney 8y ago
    I suppose the common problem is of when to apply abstraction. There are times when abstraction is necessary to prevent duplication of effort and other times when it is convenience layer. These qualities are not the same and I find people generally cannot differentiate them, even outside of programming. The crux of that problem is confusion is confusion of a person’s own level of effort versus actual effort auctioned by an artifact.
- deleted 8y ago
  [deleted]

austincheney 8y ago

Absolutely. https://en.wikipedia.org/wiki/Invented_here https://en.wikipedia.org/wiki/Invented_here The name of the game is failure aversion. Frameworks and NPM packages for everything. When I interview JavaScript or UI developers this is my first discriminator. Why write original code or reinvent the wheel when somebody else has your simple solution behind 50mb of external code that you didn't write? If you are that fearful coward who believes in not writing original code I don't want to work with you. Have a nice life and go work somewhere else. I would rather work with somebody willing to take a chance on problem solving. If you are going to down vote please mention why. Don't be a troll. Hacker News tries very hard to not be an echo chamber.

0xCMP 8y ago
You're being toxic by calling people "cowards" for simply using a package instead of writing it themselves which reduces the amount of code they need to directly maintain. Displays a complete misunderstanding of the tradeoffs involved as well as being rude. And what's funny is that if you hadn't been a jerk the original point of Frameworks and NPM Packages for everything is a good point and probably would have been well received. Because, the fact is that, sometimes it IS better to do it yourself instead of using the package and most wouldn't. Sometimes.
- austincheney 8y ago
  Thank you for having the balls to respond. I could have tap danced around that by using a bunch of words like: demonstrating a proportional degree of insecurity to the depth of requirements presented across the breadth of considerations required by this responsibility. I found the word coward to be more honest and fitting, though. Ultimately, the rampant insecurity isn't a technology problem. It is a personality consideration. > And what's funny is that if you hadn't been a jerk the original point... People on the internet tend to have big tears and thin skin. I don't like lying to people because they have sensitivity issues. I would rather take the down votes. All these few down votes from a few shattered JavaScript developer hearts are instantly wiped clean when I get 80 up votes for posting a single comment about analysis or interviewing. Being honest and transparent has always helped me in the offline real world.
  - HedgeSparrow 8y ago
    Why is it people think being "honest and transparent" means being rude and mean? Tact is also a useful skill.
    - austincheney 8y ago
      Because sensitive people are too selfish to tell the difference. The world isn’t always smiles, hearts, and rainbows there to please you. Directness isn’t condescension unless you are a child. Sometimes honesty really does mean telling people what they don’t want to hear. Tact isn’t a form of antidepressant. Tact is the means to account for the intention of offense without regard for actual offense. Overly sensitive people may never see that distinction. People who figure these things out early tend to live happier and more fulfilled lives.
      - pritambaral 8y ago
        > The world isn’t always smiles, hearts, and rainbows there to please you. Of course it isn't, but that does not grant one an implicit licence to be uncouth. > Directness isn’t condescension unless you are a child. Directness isn't condescension, period. That, however, does not mean you can mix condescension with directness and call it plain directness. > Sometimes honesty really does mean telling people what they don’t want to hear. Then please, by all means, do just that, without resorting to improper name-calling. ---- You know what, I'm going to stop countering your points one-by-one, and try to talk to your central idea. I agree with you, at a central level. I wouldn't hire people who cannot write their own code either. I, too, would rather work with people who can and want to solve problems than merely put pegs in holes with assistance from the likes of npm and SO. But I wouldn't call them cowards. Because that would be mis-characterization, at best; and hyper-generalization, at worst. Even if you meant to call someone risk-averse, or fearful, using the word 'coward' is more than being direct. 'fearful' is direct and sufficient, as is 'risk-averse', but if you couldn't settle there and had to reach as far as 'coward', that suggests you wanted to use the extra force that comes with that word. Thus, condescensional offence. And then you continue in this path, characterizing those who wouldn't respond to you as lacking "balls", everyone who disagrees with your choice of words as "insecure", and everyone who downvoted you as "JavaScript developers" with "shattered hearts", those suggesting your "honest and rude" words lack tact as "overly sensitive" people. Lastly, I'll leave you with the suggestion that people in this world lead happier and even more fulfilled lives without resorting to even the slight force you're employing here.
Daynil 8y ago
It's important to understand the root of the arguments for and against both "not invented here" and "invented here". Both can be considered a poor mindset because it's thinking in absolutes. Certainly, everyone can agree there is no need to "write original code" for every problem you encounter. If there are libraries behind which there are teams of strong engineers (React, Angular), who work specifically on that problem and exhaustively test and iterate on it, why would you take time and productivity away from the development of your product in order to create your own solutions? On the other hand, if the existing libraries/solutions don't fit your use cases and you spend more time customizing them to work than you do developing your product, or the existing solutions are out of date, unsupported, or appear slapped together, it would certainly be worth working on your own solution to see if you can find a better way. Likewise, experimenting with custom reimplementation is a great way to understand the problems libraries solve in an in-depth way, as Dan suggests, and you may even end up with something better. You just need to be realistic about whether it makes sense to make it yourself or utilize what exists.
- austincheney 8y ago
  I suppose the common problem is of when to apply abstraction. There are times when abstraction is necessary to prevent duplication of effort and other times when it is convenience layer. These qualities are not the same and I find people generally cannot differentiate them, even outside of programming. The crux of that problem is confusion is confusion of a person’s own level of effort versus actual effort auctioned by an artifact.
deleted 8y ago
[deleted]