Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What to Learn

danluu.com

Post reply on HN
Print view View original

71–80 of 113 posts

Re: What to Learn

#71

Post by bluGill »

stonecharioteer wrote: post #42
xyzelement wrote: post #19

I believe the thing we often need to learn is the thing we're afraid of learning. We often (always?) have weaknesses that can/do jeopardize our strength and closing those weaknesses is crucial. The famous Scott Galloway (whom I had as a b-school professor) made this point like this: if you are a great guy, great father, great boss, etc, but once in a while you get violently drunk and hurt people in your life - THAT t…

So I wonder about this a lot. If I have a developer on my team who needs to learn X, or get better at Y, I can always offer that feedback and it is construed as constructive feedback. But if I tell a developer who can't speak well or communicate lucidly that they need to work on their communication skills, that comes across as offensive. There was a horrible architect at my previous organization who was universally l…

I know a Korean Engineer with terrible English. He is well aware how bad it is, but has no idea how to fix it. I'm a terrible speller (seems to be related to disgraphia - but the diagnosis didn't exist when I was a kid) with no idea how to fix it.

It is one thing to say fix your greatest weakness, if it is easy you should. However for many there is more gain from improving on a strength and avoiding situations where the weakness matters; than improving the weakness, even though a small improvement in the weakness is worth more than an improvement in the strength..

Re: What to Learn

#72

Post by ianmcgowan »

itsmemattchung wrote: post #30
nojs wrote: post #14

Earlier quoted context omitted.

For a solo entrepreneur I would argue it’s more important to be fairly good at everything than e.g. really good at programming and having no understanding of other things like sales and marketing. Instead of perfecting your Haskell skills, you’re far better off learning the basics of how to construct a good sales funnel, even if it’s not a natural fit for you. Some knowledge is a lot better than none.

100%. One of the conversations I've repeatedly had with my friend, a technical co-founder of his own company, is how difficult and challenging Sales really is. We don't really see eye to eye on this topic. As a engineer and computer scientist, I appreciate all the work we do to build software that's robust, etc but to be honest, the more challenging parts (and equally rewarding, for me as a solo entrepreneur) is the…

"Selling is easy", until you try to do it, then it's brutally hard. You should ask your friend to do a cold-call with you.

Re: What to Learn

#73

Post by ipnon »

A corollary: Companies are want to hire people who are good at interviewing, not people who are good at their job. The proof of this is that we find a disconnect between the interview process and the day to day job of working at as a software engineer. If you are primarily interested in making money, the best advice would be to become exceedingly proficient at the interview rodeo. Charm your way through the intro call, knock out the algorithmic quiz, and know the best approach for the problem in the technical screen right from the start. Improve your skill at these and your financial gains will be bountiful.

Re: What to Learn

#74

Post by yibg »

cratermoon wrote: post #53
xyzelement wrote: post #34

Earlier quoted context omitted.

So basically your approach to life is to "not teach a man to fish" ?

> either go figure out how to help and help or shut the fuck up and keep walking. No, he's saying that you don't tell someone who is hungry "if you would learn to fish, you wouldn't be hungry" and leave it at that. Especially don't do this if you don't know how to fish yourself. But do, if you know that "learning to fish" is good, team up with the other person and learn to fish together. At the very least, you can he…

That doesn't sound very good in real life scenarios either. I can provide feedback without necessarily knowing how to fix it. For example, if someone I work with consistently have a hard time communicating their ideas, I can and should provide that feedback, even without knowing how they can fix it. At the very least if they realize the issue, they can attempt to go fix it themselves. Providing feedback in general is a gift.

Re: What to Learn

#75

Post by ozim »

I am big fan of "circle of competence" as Warren Buffet with Charlie Munger describe it. But I stole it to drive my learning approach.

Learning is investment so I would say learn mostly in your area of competence to get better. Of course you want to broaden your area with time so you might spend 80-90% of your learning time on things that are directly in your area of competence. Then 10% or 20% to broaden that, when you start using those new things they will become your circle of competence and then you can go deeper with learning about those. If you won't use those - ditch those and go find another 20%.

Downside to this approach is that you need a starting point like "should I be a Python dev or Ruby dev" which mostly is asked by new fresh starters - and my answer is pick one, if it sticks and is your 80% (even if it is not really) continue if not go for another one.

I had link to article by Kent Beck who advises something similar so I also copied a lot of that approach from his article. Unfortunately I don't have a link now.

Re: What to Learn

#76

Post by chrislloyd »

ozim wrote: post #75

I am big fan of "circle of competence" as Warren Buffet with Charlie Munger describe it. But I stole it to drive my learning approach. Learning is investment so I would say learn mostly in your area of competence to get better. Of course you want to broaden your area with time so you might spend 80-90% of your learning time on things that are directly in your area of competence. Then 10% or 20% to broaden that, when…

I hadn't thought of personal learning as a multi-armed bandit problem before! Thank you.

Re: What to Learn

#77

Post by wenc »

I can relate to the “looking at data” as a skill bit, especially the part where he mentions that it’s not a skill most data scientists necessarily have. I have observed that too. (I’m one myself)

Many data scientists like to jump into feature extraction and modeling the data with ML/DS tools because for us that’s the fun part. (we might look at some plots and summary statistics but we don’t dwell there for too long.) Few have the patience to just sit with the data for a week just to look at it, checking it against our intuition about the real world and the domain and basically just trying to put 2 and 2 together without models (except a mental model of the world) and just turning the data over in Tableau (or Excel). It’s actually not an easy skill to learn because it requires other meta skills. For one it requires an ability to match numbers to the real world — and for that you need experience and a good intuition of how the world works.

My first manager was exceptionally good at doing this. I’ve noticed too that folks in senior management — at least competent ones — tended to be good at looking at data and picking out things too. I suspect this is actually a make or break ability to get to senior management at most companies.

Data scientists, not so much. (Unless they worked in the field or came from the business side of things.)

Re: What to Learn

#78

Post by jjtheblunt »

karmakaze wrote: post #58
willchang wrote: post #52

This wouldn't be Hacker News if someone didn't comment that ACTUALLY a random walk of n steps will get you sqrt(n) in some direction, which is much better than log(n). I guess my special skill is being pedantic.

I've come to realize that 'exponential' is so often used to describe anything nonlinear. This would be the exact corollary. Good to pick up on it. I'll look out for this too now.

corollary : i've come to learn to ignore writers who use "exponential" incorrectly, to your point.

i realize this makes me picky, but it seems to be reasonable, as that incorrect usage often is a signal of sloppy thought.

Re: What to Learn

#79

Post by Zababa »

ozim wrote: post #75

I am big fan of "circle of competence" as Warren Buffet with Charlie Munger describe it. But I stole it to drive my learning approach. Learning is investment so I would say learn mostly in your area of competence to get better. Of course you want to broaden your area with time so you might spend 80-90% of your learning time on things that are directly in your area of competence. Then 10% or 20% to broaden that, when…

> Downside to this approach is that you need a starting point like "should I be a Python dev or Ruby dev" which mostly is asked by new fresh starters - and my answer is pick one, if it sticks and is your 80% (even if it is not really) continue if not go for another one.

I remembering hearing in a podcast something like "If there's a fork in the road, pick it and stick with it. You'll end up in a better place two years later than if you just spend two years weighing the options. And if you stick with something for a period of time, it's usually easier to switch to something else than if you didn't do anything."

Re: What to Learn

#80

Post by fouric »

lukego wrote: post #21

Forth is an interesting case. It's really unproductive to build complex systems with. If you try, you will probably be frustrated. Instead it forces you to try really hard to find a cheating short-cut to solve the problem as few moving parts as possible. Just one simple example. The 'struct' language feature is 1500 LOC in Lisp but only 10 LOC in FORTH (see below.) Are they equivalent? No, the Lisp one has lots of be…

I think you've identified one of the essential parts of the design of Forth: it makes it very easy to implement simple systems, and very difficult to implement complex systems. In other words, polynomial O(n^a) complexity, where "a" is large, but the hidden constant k is small.

Making good use of Forth seems to be contingent on identifying situations where you want to implement a very small and simple system (embedded systems, firmware, OS bootloaders, tiny IoT devices?), and using Forth there - and avoiding it like the plague in all other cases.

I very much doubt that implementing a VLSI CAD program, where you want as many features to help your design as possible (features which necessarily incur a complexity cost), is a good use of Forth, for example.

Post reply on HN