30 ms·

Two things jump out to me: > Only learn something new when forced I think there is a balance between always doing things in a new way, versus always doing thi

by robbya 7y ago

Two things jump out to me: > Only learn something new when forced I think there is a balance between always doing things in a new way, versus always doing things as you've done before. When engineers are pushed too hard on deadlines, some will avoid learning new things as a short term approach for quick delivery. If your in that environment, you aren't going to grow. > Avoid linking to other software unless forced. It empirically rarely goes well. Source? The rapid growth of npm, rubygems, and other ecosystems suggests otherwise. I was hoping this would talk about how to support your co-workers (code review, culture, cohesion) or how to succeed at non-engineering tasks other 'good' programers may overlook

deleted 7y ago
[deleted]
mysterydip 7y ago
> Source? The rapid growth of npm, rubygems, and other ecosystems suggests otherwise. Probably referring to the dependency hell that can occur. Things work great when you first choose your libraries, but then months or years later while maintaining code you find x feature is deprecated or lib y no longer plays nicely with lib z or lib a is dependent on lib b version 2 and lib c needs lib b to be version 3, etc.
zitterbewegung 7y ago
I think I interpret "Only learn something new when forced" is more like you should prioritize what to learn to do a task. Learning new things to learn new things is different than having a concrete project that emphasizes that you should learn one new thing. Learning the newest system of the week isn't really going to help you as much as a tried and true system that is well maintained and proven to work. The second part about linking to other software is valid. What if the thing you are linking to is not going to be maintained? What if the thing you are linking to has a security issue? Now you are probably going to have to either link to something else or replicate the functionality. By only linking to things that are essentially hard to replicate instead of blindly linking to anything else. In the above examples it is more of striking a balance instead of mere absolutes.
k__ 7y ago
I used PHP where everyone would reinvent the wheel and JS where everyone would install hundreds of packages. This gave me the feeling that the truth is somewhere in-between. Maybe NPM packages are overall low quality and it would be okay to use more of them if they were better, but I'm now just installing a package when I don't have the time or skills to code it myself. This saved me from dependency hell, but it also helped me to move faster than doing all on my own.
- baroffoos 7y ago
  I feel like rails is the good in between. It contains loads of helpful functions and tools to get 90% of the stuff you need done but its all part of one package so its all tested together and comes from one trusted org rather than 1000 random js devs.
BigJono 7y ago
Learning is pretty simple, the golden rule is "Don't learn new tech, learn how to solve new problems". Learning how to use something like Vue when you already know how to use React (or vice versa) is stupid because they both solve the exact same problem in a reasonably similar way with a reasonably different API. A better example might be something like Postgres and DynamoDB, since it can go either way. If your problem is 'I need a database for a CRUD app' then learning the second one is stupid because they both solve that problem just fine. But if your problem is 'I have a complex use case, my data is in a bad format for the one I'm using and I'm taking a huge hit in performance' then learning the other one is a reasonable choice and probably not a waste of time. Basically whenever you take the time to learn something, make sure you're getting something out of it in terms of end results. It feels good to just learn more of the same tech, and if the API is different enough it'll feel like you're making progress, but you're probably not.
- soulofmischief 7y ago
  > Learning how to use something like Vue when you already know how to use React (or vice versa) is stupid because they both solve the exact same problem in a reasonably similar way with a reasonably different API. Settling on Mithril as my front-end library was a long journey from framework to framework. If I had stopped at Vue or React, I'd be much worse off for it. Really, if I had stopped at the first front-end library/framework I used in web dev, I'd still be using PHP. Sometimes you need to move on, and if later asked about your technical choices in a professional environment, you need to have a professional answer that comes from wide experience.
  - BigJono 7y ago
    > Really, if I had stopped at the first front-end library/framework I used in web dev, I'd still be using PHP. Well, I did specifically give an example of two techs that do similar things that might be worth learning if they're different enough that one solves a problem the other doesn't. I don't know anything about Mithril, but if you're right that you'd be 'much worse off' then that would be a similar case, no?

by robbya 7y ago

deleted 7y ago

[deleted]

mysterydip 7y ago

> Source? The rapid growth of npm, rubygems, and other ecosystems suggests otherwise. Probably referring to the dependency hell that can occur. Things work great when you first choose your libraries, but then months or years later while maintaining code you find x feature is deprecated or lib y no longer plays nicely with lib z or lib a is dependent on lib b version 2 and lib c needs lib b to be version 3, etc.

zitterbewegung 7y ago

I think I interpret "Only learn something new when forced" is more like you should prioritize what to learn to do a task. Learning new things to learn new things is different than having a concrete project that emphasizes that you should learn one new thing. Learning the newest system of the week isn't really going to help you as much as a tried and true system that is well maintained and proven to work. The second part about linking to other software is valid. What if the thing you are linking to is not going to be maintained? What if the thing you are linking to has a security issue? Now you are probably going to have to either link to something else or replicate the functionality. By only linking to things that are essentially hard to replicate instead of blindly linking to anything else. In the above examples it is more of striking a balance instead of mere absolutes.

k__ 7y ago

I used PHP where everyone would reinvent the wheel and JS where everyone would install hundreds of packages. This gave me the feeling that the truth is somewhere in-between. Maybe NPM packages are overall low quality and it would be okay to use more of them if they were better, but I'm now just installing a package when I don't have the time or skills to code it myself. This saved me from dependency hell, but it also helped me to move faster than doing all on my own.

baroffoos 7y ago
I feel like rails is the good in between. It contains loads of helpful functions and tools to get 90% of the stuff you need done but its all part of one package so its all tested together and comes from one trusted org rather than 1000 random js devs.

BigJono 7y ago

Learning is pretty simple, the golden rule is "Don't learn new tech, learn how to solve new problems". Learning how to use something like Vue when you already know how to use React (or vice versa) is stupid because they both solve the exact same problem in a reasonably similar way with a reasonably different API. A better example might be something like Postgres and DynamoDB, since it can go either way. If your problem is 'I need a database for a CRUD app' then learning the second one is stupid because they both solve that problem just fine. But if your problem is 'I have a complex use case, my data is in a bad format for the one I'm using and I'm taking a huge hit in performance' then learning the other one is a reasonable choice and probably not a waste of time. Basically whenever you take the time to learn something, make sure you're getting something out of it in terms of end results. It feels good to just learn more of the same tech, and if the API is different enough it'll feel like you're making progress, but you're probably not.

soulofmischief 7y ago
> Learning how to use something like Vue when you already know how to use React (or vice versa) is stupid because they both solve the exact same problem in a reasonably similar way with a reasonably different API. Settling on Mithril as my front-end library was a long journey from framework to framework. If I had stopped at Vue or React, I'd be much worse off for it. Really, if I had stopped at the first front-end library/framework I used in web dev, I'd still be using PHP. Sometimes you need to move on, and if later asked about your technical choices in a professional environment, you need to have a professional answer that comes from wide experience.
- BigJono 7y ago
  > Really, if I had stopped at the first front-end library/framework I used in web dev, I'd still be using PHP. Well, I did specifically give an example of two techs that do similar things that might be worth learning if they're different enough that one solves a problem the other doesn't. I don't know anything about Mithril, but if you're right that you'd be 'much worse off' then that would be a similar case, no?