6 ms·

> Read at least HackerNews and possibly some other tech news site regularly. And then make sure to not get too caught up in the hype for new stuff. Interesting

by Boulth 8y ago

> Read at least HackerNews and possibly some other tech news site regularly. And then make sure to not get too caught up in the hype for new stuff. Interesting because I advise the exact opposite: do not waste time reading HN, just find one thing that is interesting and master it. Then repeat. As much as I like HN there is a lot of noise here. Novice mind can easily fall into a trap looking for signal here.

rkangel 8y ago
The advice elsewhere in this thread about focusing on one stack and getting good at it is definitely true. Broadening your knowledge to be aware of other stuff is also useful though. The most useful people are those who understand how multiple things work and fit together.
donkeyd 8y ago
> there is a lot of noise here This is true. However, much of what I know about how software development can work, I've learned from reading HN. I've learned loads about cloud, containers, micro services, project problems, etc. This helps me understand all the discussions around me while I was a junior and allowed me to successfully lead development of a SaaS product. If I just focused on learning a single thing, I wouldn't have been able to grasp all the other stuff that is necessary to actually build a product from scratch.
sevensor 8y ago
I've gotten a lot of value from reading HN. I've also wasted a lot of time. It helps to develop a personal filter. Mine is * Avoid headlines that make me angry, unless the news is really important. The discussion is never worthwhile, don't even bother. * WSJ, Bloomberg, and WaPo won't let me read articles with w3m, so I skip the article. If the topic is tremendously interesting, I'll check the comments. * TED and nautil.us are the information verison of empty calories. I've never gained any long term benefit from reading them. * Javascript framework churn is intense. It's not worth trying to keep up with the details unless you do web development. If, like me, you don't, it's still worth reading the headlines to keep abreast of what frameworks are popular, what paradigms they embody, and who's pushing them. This changes every six months or so. * It's always worth scanning the comments in threads about programming languages. There are some really interesting people who sometimes jump into those threads and blow your mind. * Know your prejudices and look for information that challenges them. My prejudices are that I think Windows is lame, that MacOS is infuriating, that Javascript is terrible, that vim is better than emacs, and emacs is better than IDEs, and object orientation is a failed paradigm. So I look out for articles that have a different point of view. I've learned that Microsoft has some really interesting technology, that Apple is infuriating even to its own users but it doesn't matter because they're sitting on the world's biggest pile of dollar bills, that Javascript is usually unnecessary but occasionally useful, that kakoune is even better than vim, and that nobody agrees about what object orientation even is.
- Eire_Banshee 8y ago
  "object orientation is a failed paradigm" uh... wtf?
  - sevensor 8y ago
    I know my prejudices. I recognize that a lot of people think OO is just dandy, and I'm on the lookout for a good argument in its favor. I'm open to the possibility that the reason I think OO doesn't work is that I don't understand it well enough. Maybe somebody out there will explain encapsulation in a way that doesn't make hidden mutable state seem like a nightmare. Maybe somebody's got a blog post that explains why inheritance only looks like it makes spaghetti code, but actually I can safely ignore the dragons lurking three levels up the hierarchy. Maybe there's some piece of OO code out there that embodies a beautiful solution to a problem I've been struggling with. If those things are out there, they're going to get posted to HN eventually.
  - Reedx 8y ago
    Here's an explanation from Casey Muratori: https://youtu.be/GKYCA3UsmrU?t=4m50s https://youtu.be/GKYCA3UsmrU?t=4m50s See also Mike Acton (Engine Director @ Insomniac Games): https://www.youtube.com/watch?v=rX0ItVEVjHc https://www.youtube.com/watch?v=rX0ItVEVjHc
    - Zimahl 8y ago
      You aren't going to get a lot of support for OO in places where it isn't really necessary like games, and especially games with single developers. At that point the management of data is on the developer. Essentially one is saying that if they fuck up the data, that's on them. OO is handy in enterprise software where there are lots of developers who may not understand why things are the way they are, they just need to do something. In big, complex systems where a lot of things are going on, if you give someone a noose, they will hang themselves. OO can protect data from some (of course not all) unintended consequences.
- mingeek 8y ago
  > Avoid headlines that make me angry, unless the news is really important. The discussion is never worthwhile, don't even bother. > Know your prejudices and look for information that challenges them. How do you prevent the two of these from coming into conflict?
sitkack 8y ago
> and master it Mastering something is expensive, one should have multiple good justifications for doing so. Deep familiarity is what people usually need, beyond exposure, but below mastery/trial by fire.

by Boulth 8y ago

rkangel 8y ago

The advice elsewhere in this thread about focusing on one stack and getting good at it is definitely true. Broadening your knowledge to be aware of other stuff is also useful though. The most useful people are those who understand how multiple things work and fit together.

donkeyd 8y ago

> there is a lot of noise here This is true. However, much of what I know about how software development can work, I've learned from reading HN. I've learned loads about cloud, containers, micro services, project problems, etc. This helps me understand all the discussions around me while I was a junior and allowed me to successfully lead development of a SaaS product. If I just focused on learning a single thing, I wouldn't have been able to grasp all the other stuff that is necessary to actually build a product from scratch.

sevensor 8y ago

I've gotten a lot of value from reading HN. I've also wasted a lot of time. It helps to develop a personal filter. Mine is * Avoid headlines that make me angry, unless the news is really important. The discussion is never worthwhile, don't even bother. * WSJ, Bloomberg, and WaPo won't let me read articles with w3m, so I skip the article. If the topic is tremendously interesting, I'll check the comments. * TED and nautil.us are the information verison of empty calories. I've never gained any long term benefit from reading them. * Javascript framework churn is intense. It's not worth trying to keep up with the details unless you do web development. If, like me, you don't, it's still worth reading the headlines to keep abreast of what frameworks are popular, what paradigms they embody, and who's pushing them. This changes every six months or so. * It's always worth scanning the comments in threads about programming languages. There are some really interesting people who sometimes jump into those threads and blow your mind. * Know your prejudices and look for information that challenges them. My prejudices are that I think Windows is lame, that MacOS is infuriating, that Javascript is terrible, that vim is better than emacs, and emacs is better than IDEs, and object orientation is a failed paradigm. So I look out for articles that have a different point of view. I've learned that Microsoft has some really interesting technology, that Apple is infuriating even to its own users but it doesn't matter because they're sitting on the world's biggest pile of dollar bills, that Javascript is usually unnecessary but occasionally useful, that kakoune is even better than vim, and that nobody agrees about what object orientation even is.

Eire_Banshee 8y ago
"object orientation is a failed paradigm" uh... wtf?
- sevensor 8y ago
  I know my prejudices. I recognize that a lot of people think OO is just dandy, and I'm on the lookout for a good argument in its favor. I'm open to the possibility that the reason I think OO doesn't work is that I don't understand it well enough. Maybe somebody out there will explain encapsulation in a way that doesn't make hidden mutable state seem like a nightmare. Maybe somebody's got a blog post that explains why inheritance only looks like it makes spaghetti code, but actually I can safely ignore the dragons lurking three levels up the hierarchy. Maybe there's some piece of OO code out there that embodies a beautiful solution to a problem I've been struggling with. If those things are out there, they're going to get posted to HN eventually.
- Reedx 8y ago
  Here's an explanation from Casey Muratori: https://youtu.be/GKYCA3UsmrU?t=4m50s https://youtu.be/GKYCA3UsmrU?t=4m50s See also Mike Acton (Engine Director @ Insomniac Games): https://www.youtube.com/watch?v=rX0ItVEVjHc https://www.youtube.com/watch?v=rX0ItVEVjHc
  - Zimahl 8y ago
    You aren't going to get a lot of support for OO in places where it isn't really necessary like games, and especially games with single developers. At that point the management of data is on the developer. Essentially one is saying that if they fuck up the data, that's on them. OO is handy in enterprise software where there are lots of developers who may not understand why things are the way they are, they just need to do something. In big, complex systems where a lot of things are going on, if you give someone a noose, they will hang themselves. OO can protect data from some (of course not all) unintended consequences.
mingeek 8y ago
> Avoid headlines that make me angry, unless the news is really important. The discussion is never worthwhile, don't even bother. > Know your prejudices and look for information that challenges them. How do you prevent the two of these from coming into conflict?

sitkack 8y ago

> and master it Mastering something is expensive, one should have multiple good justifications for doing so. Deep familiarity is what people usually need, beyond exposure, but below mastery/trial by fire.