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

John Carmack: Career Advice

twitter.com

Post reply on HN
Print view View original

111–120 of 178 posts

Re: John Carmack: Career Advice

#111

Post by redisman »

tmotwu wrote: post #74
kranner wrote: post #17

Earlier quoted context omitted.

The problem is that far fewer people get hired to work on the fundamentals than to operate the current industry-standard tools. Also many of the jobs that require fundamental skills seem to require steep academic credentials (e.g. a PhD from a big name university) that are sometimes more difficult to acquire than knowledge of the fundamentals itself.

I think people misunderstand about the advantages of understanding fundamentals. Yes, very few are inventing new tools, protocols or reimplementing known data structures or hash functions. But the point of mastering the fundamentals is to transform the way your brain thinks when it approaches all sorts of computing problems. It's a framework that allows you to deeply think about the correctness and speed of what you…

Unfortunately the most optimal thing to get your career started is not deep study of fundamentals but "grinding leetcode".

Re: John Carmack: Career Advice

#112

Post by Frost1x »

st1x7 wrote: post #64
Frost1x wrote: post #55

Earlier quoted context omitted.

I'd be a bit weary of gaps in some environments. As you suggest, those gaps often exist for a reason. From my experience a lot of those gaps are essentially integration efforts between two systems where one person builds something independent of the other that were supposed to be integrated or are now desired to be integrated yet were never planned or designed appropriately to integrate. In the end, you end up needin…

> My suggestion is to find gaps that aren't integration efforts, if possible, that are instead extension efforts. Yes! This can go even further and the technical integration work can easily slip into soft/people/team/project/management integration. Here is a talk which warns against doing this kind of glue work too early in your career: Video: https://www.youtube.com/watch?v=KClAPipnKqw Summary article: https://noide…

Excellent video and summary, thank you for the links.

I explain this same concept to people at less software savvy businesses frequently, so it's nice to have an external reference to point to. Going to borrow her nomenclature.

Re: John Carmack: Career Advice

#113

Post by enumjorge »

_urga wrote: post #106

Here are some ways to learn deeply and be relevant: 1. Pick a data structure (such as a hash table or LSM-Tree) then read all the literature there is to read, every single paper that's great, following the best conferences year after year, and implement a 10x faster or more scalable version for the std lib of your favorite language. 2. Pick a fault model (such as storage faults, network faults, cryptography faults) t…

Let’s say I’ve picked a data structure. How would you suggest identifying the great papers and best conferences related to it?

Re: John Carmack: Career Advice

#114

Post by _urga »

enumjorge wrote: post #113
_urga wrote: post #106

Here are some ways to learn deeply and be relevant: 1. Pick a data structure (such as a hash table or LSM-Tree) then read all the literature there is to read, every single paper that's great, following the best conferences year after year, and implement a 10x faster or more scalable version for the std lib of your favorite language. 2. Pick a fault model (such as storage faults, network faults, cryptography faults) t…

Let’s say I’ve picked a data structure. How would you suggest identifying the great papers and best conferences related to it?

A few ideas:

1. Add "abstract" to your search query to surface papers.

2. Search for "... reading list". For example, Heidi Howard maintains https://github.com/heidihoward/distributed-consensus-reading...

3. Read blogs like "The Morning Paper" (https://blog.acolyer.org) but skip fields that are outside your scope. You don't have time to follow more than one or two (or three) major fields.

4. Use Google Scholar to find the most cited papers, or to find papers that build on papers you think are good.

5. Keep an eye out for the conferences where these papers were presented. Then read the other papers that were also presented.

6. When you come across an amazing paper, read other papers by the same authors or supervisors.

7. If you're lucky you might also find good "survey" papers that cover and reference the state of the art.

8. Lecture notes from Stanford or MIT or another university can also be a great way to get a big picture of the evolution of techniques for a given data structure or problem. For example, these lecture notes are just brilliant for getting started with stuff around memory hierarchies: https://www.eidos.ic.i.u-tokyo.ac.jp/~tau/lecture/parallel_d...

These are a few tricks that I find useful. What else?

Re: John Carmack: Career Advice

#115

Post by kenferry »

st1x7 wrote: post #8

Can anyone elaborate on what Carmack is suggesting here? To specialise in some tool early in your career? Or something else? I don't quite get it. (Or at least I don't get why it would be such a good idea.) Carmack is usually great to listen to, by the way; check out some of his interviews or talks if you haven't before.

It's pretty interesting that there's so much variation in how we're understanding the advice.

I read this as John suggesting a stair step path to "learn deeply". If you can section off one defined area, a tool, it's possible to learn _that_ inside and out in a reasonable amount of time. Then you're useful and people want you around. From there you can expand outward or down or whatever.

This would be as an alternative to dabbling, learning the most commonly known things across a wide area.

Re: John Carmack: Career Advice

#116

Post by swiftcoder »

redisman wrote: post #109
almost_usual wrote: post #103

Earlier quoted context omitted.

To me it makes more sense to learn widely early on as a junior. You’ll get a sense of what you enjoy and what you’re good at over the years. Then you can focus on what you like as you become senior and have a foundation.

Depends on the needs of the team too. In most of my roles, having good breadth has been more important to keep an eye on the big picture and to be able to contribute in various areas and tell when the Jr's are doing something unwise.

Indeed. The most senior engineer on a team typically needs to have sufficient broad knowledge to understand (in detail) what everyone else on the team is (or should be) doing.

That said, Carmack clearly has wide-ranging enough knowledge to run rings around entire engineering teams - despite his preference for learning in depth.

Re: John Carmack: Career Advice

#117

Post by swiftcoder »

ido wrote: post #75
patrec wrote: post #20

Earlier quoted context omitted.

I think his argument is fairly simple: 1. Learning (fundamental) stuff deeply is the way to become great. 2. But knowing how stuff works fundamentally at an abstract level (e.g. being able to write your own toy OS) is not directly economically useful (and/or very time consuming to get to that stage). So it won't get you a job. 3. So for starters learn just one thing that people actually use (say git) deeply at a conc…

The above explanation is great but I think the example you selected (git) is rarely the right thing to choose as for most companies git isn't where the money comes from (notable exceptions are companies like GitHub or GitLab). Sorta like the difference between working in the IT department vs Development (for a software company). Maybe a better choice is something like CSS: there's actually a lot to know about it and…

Managing distributed version control at scale is one of the core challenges facing nearly every growing software company. Performance issues, the increasing incidence of merge conflicts, preemptive CI, build system integration... this is definitely a topic you can go deeply into, and make an impact at many companies.

On the flip side, you are now a source control/build system engineer, and it's pretty easy to get typecast as such (given the outsize impact your specialist skillset will have).

Re: John Carmack: Career Advice

#118

Post by mason55 »

almost_usual wrote: post #101
Balgair wrote: post #95

David Epstein's Range has a lot to say about this topic. Carmack's idea of 'deep' work [0] is environmentally dependent. It works for him and for the places he has been at. But it is not a universal rule for learning in all environments. Epstein uses Tiger Woods and Roger Federer as his headline case, but goes into many other forms of learning. Woods' golf is a kind learning environment ; the rules are clear, the fee…

This is an interesting perspective, from a technical view it seems like the difference between writing library and debugging a system. Programming a library referencing an RFC seems kind, the rules are already there. Debugging a performance issue in a large distributed system is unkind, you need a lot of existing knowledge and ideas to know where to start.

I don't know, I think debugging a perf issue in a large distributed system still falls under kind work to me, assuming you actually have a way to tell when it's fixed. Yes, you need a lot of knowledge, but the rules and outcomes are still clear. Compared to writing a novel or painting, it's very clear when you've reached success and it's hard to argue that you've been successful.

IMO the "unkind" work that a typical engineer does is things like writing specs. The work itself does not give you any feedback about if you're making progress or doing a good job.

Of course it's all on a sliding scale, and if your perf issue takes four weeks to surface after each deploy then that's a much less kind environment. But, in general, anything that you can put clear metrics around is much closer to the "kind" bucket to me because those metrics give you a clear path for improvement and iteration (the major risk is getting stuck in some local maximum).

Re: John Carmack: Career Advice

#119

Post by deltron3030 »

Imo the best way is the painters approach, starting with the broadest strokes. For software this means tool and platform independent knowledge that can translate to any tool first. Being a specialist without getting the the big picture seems very fordist and dystopian, gulag shit imo.

Re: John Carmack: Career Advice

#120

Post by snarfy »

patrec wrote: post #20
st1x7 wrote: post #8

Can anyone elaborate on what Carmack is suggesting here? To specialise in some tool early in your career? Or something else? I don't quite get it. (Or at least I don't get why it would be such a good idea.) Carmack is usually great to listen to, by the way; check out some of his interviews or talks if you haven't before.

I think his argument is fairly simple: 1. Learning (fundamental) stuff deeply is the way to become great. 2. But knowing how stuff works fundamentally at an abstract level (e.g. being able to write your own toy OS) is not directly economically useful (and/or very time consuming to get to that stage). So it won't get you a job. 3. So for starters learn just one thing that people actually use (say git) deeply at a conc…

It's paramount to keep #1 firmly in place. The fundamentals don't change but the implementations do constantly. If you focus only on the implementations you can very well end up a programmer with 20 years of 1 year experience.
Post reply on HN