John Carmack: Career Advice

I was nodding along until the last sentence of:

> In unkind learning environments like tennis, jazz, or marketing, the key is to learn as many things as you can as broadly as you can, to gain a reservoir of ideas to use.

I think this very much applies to kind (programming) too. Sometimes the biggest programming level ups requires broadly knowing about this, that and the other thing.

For example, you can practice writing file upload code until your eyes bleed but if you're unaware of the implications of what uploading to local disk brings in a containerized or Heroku-like platform then a lot of what you know suddenly falls apart. Your entire basis of what you've been doing might need to be rewritten or drastically altered (creating a "storage" abstraction, etc.).

With software development it's super valuable to get a broad understanding of many parts of the stack, not just individual features. I say "feature" here because in a golf analogy a feature would be putting within 6 feet, chipping under 20y, or using a driver. In golf you can individually learn these things in isolation and your overall game improves in the end. In programming this isn't as clear cut IMO.

  are you designing a database schema and writing queries against it = kind

I worked in a project using MongoDB. Initial implementation was easy and quick to iterate. After a few years when it was evident that it was not sustainable. Two years of painfull effort was required to squeeze out MongoDB.

  are you doing frontend development (or something similar where fast paced change means new technology, new best practices etc. all the time) = unkind

React already won, front-end tech is stable in last 4 years. It is an easier part of my job. Front-end development require high upfront learning, but it is boring at some point.

  are you doing text processing analysis of structured data following well understood schemas = kind

I know some pipelines on structured data that are hell. I worked with XML (FpML) and systems that produced/consume these, It would make most people cry. It is very easy to create massive technical debt where data is flowing. Any change needs to be done from both ends. It is not like front-end where I can refactor components as much I want.

Because programming is such diverse field, I would be careful with labeling anything kind/unkind.

less people are going to click a blog link, thats just facts.

Unfortunately they never reached out. But, wherever you are, I hope you're having a Merry Christmas, daodedickinson. Everyone should!

Don't worry too much about stuff. Things will get better. (Prozac also helped me.)

So for technical interviews, yes you should absolutely grind algorithms, and not just any algorithms, but exclusively the stuff that comes up in leetcode, and yes you should do weeks of daily practice at leetcode or hackerrank if you want to get hired at a FAANG (or many other places). Up to a certain level getting better at leetcode problems will even improve your actual programming skills (BTW: I would be extremely interested to hear about any data concerning this improvement).

Beyond bandwagon effects I suspect these tests originally became so popular because they are an unproblematic way to select for people who are highly intelligent but also do as they are told.

This also points to a potential shortcoming of the "grind leetcode" strategy: it is applicable to the extent you meet the above characteristics and even if you do well enough to commend yourself as a high-spec corporate cog, and get that FAANG job, it does little to differentiate yourself against other high-spec corporate cogs (unless you are one of the tiny top fraction of competitive coders, maybe).

So with the exception of mastering algorithms (as taught in uni beyond leetcode needs) or mastering C++ or Java[+], I wholeheartedly endorse your advice, but becoming really good at some suitable and economically useful X is, I think, a more widely applicable strategy with a higher ceiling.

Also, I find it interesting that although I explicitly mention that my idea of learning git deeply would involve the ability to implement it (rather than memorizing the man-pages, say, and presumably validated by actually taking a stab at it) a few people pointed out that git is essentially too pedestrian to be useful. This is not the case, in my experience: both in that understanding git well will go way beyond the antiquarian and also in that lacking git skills are in fact a productivity drain at many or most companies.

[+] Algorithm courses at uni seem to gravitate towards what's neither interesting nor useful. Of course, go a head and concentrate of C++ or Java if your interests require it (e.g. Games programming). Otherwise, I suspect the best languages to master early are either python or javascript. If you care about machine learning or science, master python, if you care about web and app development or graphics, master javascript; otherwise pick the one you like better. Either will deliver much better bang for the buck in terms of skilling up and being able to do interesting things in a short amount of time than Java (which risks pulling you towards enterprise antipatterns unless you have good guidance) or C++ (which requires mastering an enormous amount of antiquarian knowledge to get anything done). I would maybe complement this with learning enough C to be comfortable with heap, stack and pointers and enough Rust, Ocaml or Haskell to have a glimpse at what a language with a proper type system looks like.