John Carmack: Career Advice
twitter.com
twitter.com
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 feedback is quick, the skills are straightforward. Federer's tennis is an unkind learning environment; the rules aren't as clear, the feedback isn't as quick, and the skills are more murky. A lot of tennis is the mind-game aspect and in elite tennis, you don't get the same person very often.
With programming and development, the environment Carmack talks about is a kind learning environment (rules are stated, feedback is a compile away, skills are practicable). Contrast this to the business/marketing people whose environment is unkind (unclear rules, long feedback cycles, skill overload).
Epstein relates the method to be great at a thingy is to know what environment you are in. This gives the keys to success. In kind learning environments like programming, golf, or chess, the key is practice and drilling, to do it until you can't be bad anymore. 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.
[0] not Cal Newport's idea of 'deep work', to be clear.
I'd agree this is the case up to a point with programming, but some of the most important aspects of the job are in the things that are unkind, like how well your design will hold up under future maintenance. Often times there are no feedback mechanisms whatsoever for whether you've done a good job. Or they're slow and coarse and can be ignored or justified away. It's easy to just hop onto the next project and leave the mess you've made behind.
The more subjective stuff like how to approach problems as well as what to write and not to write in the first place -- these are what separate people who can technically do the job from those at higher levels. And often even a successful application here ends up getting overlooked by the very fact that it Just Works and doesn't make a lot of noise.
This is just one aspect of the unkindness. There's also how effective you are, how reliable your systems are, how productive you are, whether you pick the right things to invest in learning about, how well you solve problems, how well you debug, how well you coordinate with peers, how well you are able to understand and navigate existing systems, and how well you communicate technical ideas. Many of these things compound in positive or negative directions over time. I've yet to see any good materials teaching most of this stuff, and I suspect plenty of people will go their entire careers without ever really figuring out or being aware of a large chunk of it.
are you building things that all sorts of different systems need to integrate with that you don't necessarily know what the technical specifications of these systems are = unkind
are you designing a database schema and writing queries against it = kind
are you doing frontend development (or something similar where fast paced change means new technology, new best practices etc. all the time) = unkind
are you doing text processing analysis of structured data following well understood schemas = kind
I mean really, they gave two examples of sports one which was kind one unkind - but for programming it is just kind?
are you designing a database schema and writing queries against it = kind
are you doing frontend development (or something similar where fast paced change means new technology, new best practices etc. all the time) = unkind
are you doing text processing analysis of structured data following well understood schemas = kind
Because programming is such diverse field, I would be careful with labeling anything kind/unkind.
If the change needs to be done on both ends it is probably an integration problem, which I labelled unkind.
The use of the words kind/unkind is probably not well-thought out, because kind implies easy, but there is nothing in the description of the term that means it is an easy thing to do.
I would argue that programming is fundamentally unkind. You can only learn a small fraction of stack and operate on assumptions. It is very hard to learn from other people's experiences as it is hard to quantify complexity. If someone is preaching for microservices you can only understand tradeoffs by having a specific knowledge/experience. That why we have people still using PHP for new projects because they are so entrenched in their local maximum.
https://www.amazon.com/Range-Generalists-Triumph-Specialized...
The Inner Game of Tennis [0] for folks interested in learning more about this.
[0] https://www.amazon.com/Inner-Game-Tennis-Classic-Performance...
PS Novak's probably more clutch than Rog.
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.
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).
The same goes for poker, you know when you won a hand. However winning a hand doesn't mean you learned something, similarly successfully debugging a large performance issue doesn't mean you learned something either. The learning we actually care about in software engineers isn't kind at all.
Depends.
Is there a reference implementation? A format/protocol validator? An interoperability matrix? What's the ratio of SHOULDs and MAYs to REQUIREDs, SHALLs, and MUSTs? Does the RFC reference other RFCs? What are the answers to these questions regarding those?
I mean, I wouldn't ever describe the task of implementing a SOAP[0] or WebDAV[1] library as 'kind'.
Oh, and if you're working at a sufficiently large org, be prepared to battle it out with a competing internal implementation for the coveted position of 'company standard'.
Note that you (or your boss) may not actually want to win that battle, as internal customers will make all sorts of unreasonable demands[2], and implementing them all will cut into your real work and negatively affect your evaluations and career advancement. Also, refusing to implement those requests will get you labelled as "not a team player" and negatively affect your evaluations and career advancement.
Fun times!
[0] https://www.shlomifish.org/humour/by-others/s-stands-for-sim...
[1] https://www.slideshare.net/mobile/tobyS/webdav-the-good-the-...
Being a mechanic on your own car is one thing, but working in a shop with new cars and problems coming in all the time is another.
> 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.
I'm not sure where you work but I'd love this kind of environment.
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) then read all the literature there is to read, every single paper that's great, following the best conferences year after year, and write a fault injection or fuzzing harness to break some of the most respected storage/network/cryptography systems (for examples, see the work done by Remzi and Andrea Arpaci-Dusseau on storage faults, Kyle Kingsbury on Jepsen, and Guido Vranken on Cryptofuzz: https://github.com/guidovranken/cryptofuzz).
3. Pick a software field (such as web applications, mobile applications, native applications, file formats such as Office Open XML, or protocols such as SMTP, MIME, HTTP, QUIC) then read as many CVE reports and bug bounty reports as you can find, and then start participating in bug bounty programs within this field. Pick a target and give yourself a goal, e.g. DoS, RCE or read/write access, and do the work to make it happen. Chain as many steps as you can. Automate and enumerate. You'll find a way in if you keep at it. There's nothing like crafting an exploit to change the way you think about programming.
As you gain experience in data structures, storage/networking/cryptography, and security, you'll find this translates well to most software engineering work. You'll gain a speed/safety/security way of thinking, you'll have fun being curious and learning along the way (and hopefully you'll earn a bounty or two and get some CVEs under your name).
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?
Also pay attention to authors. If someone has done an influential paper on a topic, it's likely there will be additional work or tech reports in that area on their homepage or with their research group.
To find conferences/venues just note where the more recent papers are published.
There are conferences for hash tables?
https://www.youtube.com/watch?v=aXj_DsIx1xs
https://www.youtube.com/watch?v=ncHmEUmJZf4
Carmack is usually great to listen to, by the way; check out some of his interviews or talks if you haven't before.
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 concrete level. That is economically useful, because most devs will only have fairly superficial git skills, so you becoming the go-to person for git will provide economic value to the company.
4. At the same time, this is an effective way to bootstrap a more abstract deep understanding. E.g. if you really master git, you will also learn a fair amount of abstract concepts that go beyond the concrete tool (deep understanding of git implies the ability to implement at least a toy version yourself, which will teach you useful stuff; in particular if you can implement your own version of git you are probably already better than 90% of programmers).
5. Be mindful that you will be blinkered at this stage (because you only know a single thing and thus lack a basis for comparison), so don't become opinionated yet.
I think this a great early career strategy as long as you pick the right thing to deep-dive into. E.g. if you picked AspectJ or Agent Learning or CASE tools or the semantic web around 15-20 years ago (at the peak of their hype-cycle), this possibly wouldn't have worked out so hot. In particular, learning some things like Spring or Freudian Psychology will probably harm rather than help your intellectual development.
Making a good pick is hard if you lack experience; I'd say if in doubt pick something really everyone in your line of work uses but most people have not mastered and where there is value in mastery (and you can see how mastery might tie into things you want to learn more about at a fundamental level). Also, preferably pick something that has been around for at least 5 years (unless you are quite confident in your nose for trends).
The only down side is there are often reasons those gaps are there, but it's just time to roll up your sleeves and get to work. It's an approach I've taken every time I've joined a team and it worked well for me.
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 needing to become a master of the disjoint pieces that formed that gap to connect them and have to deal with two 'masters' as opposed to one.
My suggestion is to find gaps that aren't integration efforts, if possible, that are instead extension efforts. This allows you freedom of creativity for some greenfield development while avoiding a bunch of legacy code and technical debt that will swallow you whole. It also gives you a starting leap from something developed by a master to work from.
I can't count how many times I've joined different teams to assist and found a pile of integration efforts (my sample may be biased, YMMV). This seems to be a more common modern phenomenon where people need to pump out something to look good/productive and then coast away before the challenging effort of making things work together occurs. I would say this issue is exacerbated by the mass adoption of "agile" where integration is always an afterthought since business leaders are often the dictators.
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://noidea.dog/glue
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.
For me it is the latter over the former. I would love to do a 3 point business feature every sprint and spend the rest of the time cleaning up code. Between the POs pushing work onto my plate, as well as everything else I have to do (releases, code reviews, fixing regressions etc.), cleaning up old code is a luxury at the moment.
Maybe a better choice is something like CSS: there's actually a lot to know about it and a lot of companies need people who are good at it for their core product (even though it's not as deep a topic as say being very knowledgeable/skilled in functional programming).
Her and one of her colleagues are the de facto git gurus in her entire department of over 100 people. She's ended up owning tooling in their build pipelines that is quite complex, using libgit, etc... That tooling was eventually exported around to the rest of the engineering teams (~1,000 total engineers). Now she gets random, challenging git (and perforce, to a lesser degree, and she stepped in to help with some SVN issues at one point in time, though those projects have moved over to perforce, I believe) questions from the entire engineering organization.
I do agree with you, though, that git is probably the wrong thing to focus on and that she and her colleague are outliers. But, it's interesting to see nonetheless.
Granted in any sane company this should just be done by the devs themselves. But as the OP said, in most teams knowledge about versioning, branching and version control is very very limited. Even if all you know is how to do a rebase of a longer lived feature branch easily in git (skipping the commits from the other branch) you will be the wizard that everyone goes to. Many many devs will not even attempt a regular rebase. It's black magic for them.
If all you desire is a cozy job in a large company with braindead processes and policies this sort of thing is probably enough to be tipping the scales towards: well we shouldn't lay off that guy coz he's the only one that can work the version control magic AND he codes like mad.
If you wanna stick out in a company filled with John Carmacks you will have to do better, sure.
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).
It's clearly just an example, but whether it's a bad one or not is debatable. Git is used by most shops, and most people have challenges with it at one time or another. Further, it is IMO an excellent example of how choosing the right data structure for a problem can have a profound impact on the resulting application. You could do worse for broadening your knowledge of ComSci than by a deep study of Git.
I also find it quite interesting that you mentioned git specifically, because I’ve been going back and forth for the last few days with myself about whether I should spend the rest of Winter Break and next semester (I’m an undergrad with one semester left) learning git internals deeply. So, this felt somewhat validating of the perspective that I should learn about git more deeply so I can have enhanced practical knowledge, which could translate into more economic value for the company I’m working with after graduation.
Once a decision is made in this regard, I then have to figure out the best way to actually learn it. I’ve considered trying to follow the mailing list[0] and contribute code to the git project, thinking that would force me to learn it very deeply. But at the same time, I feel like trying to go that deep might have diminishing returns and might stress me out. I like the idea of being an open source contributor to such a huge project and gaining more experience that way, but I also worry about the potentially high time cost.
I imagine I could alternatively read the Pro Git Book[1], the git documentation[2], and/or some other specific git internals resource someone has curated, but I haven’t decided what would be best yet.
[0]: https://git.wiki.kernel.org/index.php/GitCommunity
For less of a time commitment, Git from the inside out [2] is a really nice explanation of the internals, from initializing a repo and the files that creates in the .git directory, all the way to pulling from and pushing to remotes.
[0]: https://wyag.thb.lt/
[1]: https://news.ycombinator.com/item?id=19386141
[2]: https://maryrosecook.com/blog/post/git-from-the-inside-out
I know from (my albeit limited development) experience that I definitely retain concepts I’ve encountered via a hands-on approach better, but I hadn’t made the leap to _this_ sort of hands-on approach! I’d just resigned myself to the long slog of trying to get a commit merged into the master branch haha.
Once again, thank you! I’m going to check out both of those resources!
There is no harm in reading through Pro Git (which is a fine git book) either, but generally, and I wish I had been more acutely aware of this myself when I was at school, if you really want to learn something you have to either implement it yourself or use it in anger in a realistic setting. It is useful to read about stuff to get more of a feel for what's out there, but you won't get a good understanding of anything you will need to actively engage with it, and it a setting that practically matters to you. From personal experience: it's easy to trick oneself into a superficial sense of knowing something and coming up short when called upon to either implement it or use it to solve a real problem. So my number one advice would be don't fall into this trap; do (hard for you) things in a way you can't cheat yourself (and get them working first before you make them pretty).
So give it a try, the winter break should be long enough to get it done, and if you find it's beyond you at the moment, you can always scale back your ambitions and tackle it once you've grown in ability.
This is so true! Only towards the end of my formal education have I begun to learn the same thing. In many ways, I’m still biased towards just reading things —- partly because implementing something and running into issues I feel I’m not knowledgeable enough to solve/failing really bugs me —- but I’m gradually learning that failure is just part of the learning process, and doesn’t imply I’m incapable of doing something.
I’m definitely going to try it out over the break! :)
If you want to spend a whole winter break + semester (which is a very valuable amount of time), is there anything else you're interested in that would also line up with your career interests? That might be a win-win for the academic exercise and practical benefit
The main issue for me is that my interests are a bit too broad. Should I learn web dev from my job by day, then try to implement an OS in my free time by night? I know I can't learn everything, but yet it feels like there's so much I really _do_ need to know to be a competent developer.
There really isn't anyone on the planet who is truly a "full stack developer" and competent from the front-end all the way down to the OS and bare metal. No one.
Most developers stick to a particular layer, and are only familiar with adjacent layers to the extent of being able to have arguments with those developers. A 5x-ish developer is competent in those adjacent layers as well. A 10x developer either has mastery of their chosen layer, adds additional competency layers, adds competencies on the connecting tech between chosen layers (ie. not just front-end + backend, but networking too), has relevant domain competencies, or some combination.
So, just pick an entry point, learn as much of it as you want, check out whatever is adjacent, follow your interests, and periodically evaluate whether you need/want to change course or dig deeper into technologies, tools, domains, etc. wherever you happen to be. Even if you end up wandering quite far from where you started, the experience and knowledge you gain on the way isn't likely to be "wasted", unless it is mastery of some in-house tech or tool that literally no other organization uses.
Separately, "the stack" is inherently polyglot, and even aggressively pruning the selection wherever possible and eliding many formats, tools, and protocols still gives you an absolutely minimal set like JavaScript, HTML, CSS, HTTPS, TCP/IP, SQL, C/C++, Assembly, & VHDL.
You value practicality as well as personal interest/fulfillment. Either pick one and start there or pick both and consider the options there. If you want to be practical, learn the most marketable skill that you're at least somewhat interested in: Java, AWS, Docker, Javascript are all incredibly marketable. If you want to go for interest, just pick the thing you're most interested in. You could also try and juggle two deep dives, at the cost of more time and less depth, but maybe that works for you.
Don't worry about becoming a senior dev in a semester. Pick something and focus on it. That could be an AWS certification, building something in Java, etc. Once you get through that, then decide your next step.
Without getting sidetracked about the merits of the technical interview, it is current a fact of life. In my experience most undergrads struggle solving even the most basic problems and even if they come up with a solution, they are unable to code it in any language of their choice. If you are coming out of university as a "git expert" and can't code up a basic solution, you will get passed over every time.
Most teams (at least in my experience) are not struggling to solve git problems (although they certainly pop up). So while you could add some "value" there, overall you aren't adding a whole lot of value. On the other hand, if you know your language and are a moderately competent coder, you can add a lot more value.
The level of understanding of git you need to stand out is very very limited in my experience. Most devs in "regular" companies struggle to understand even the basic rebase. Even on a logical, abstracted level. Never mind how and why it actually works as well as it does.
The types predicaments I see people get themselves into even with git vs say subversion is mind boggling. I have never gotten myself into a situation that wasn't resolvable by simply making sure that everything I try is done after committing my changes. You can just always go back and retry. And just slapping a label (branch in git speak, sure) on a commit before force pushing after that rebase with lots of conflicts so that I have a backup. And even that is not strictly necessary. I've fucked up conflict resolution only to notice when the build server tells me and I had to go find a commit hash in my terminal output somewhere to resurrect it (I guess I was lucky I didn't hit an auto cleanup of dangling commits in between ;))
I am really surprised by your comments about git at "regular" companies. If all we are talking about in this chain is understanding workflow and how to rebase, cherry pick, etc. then I completely misunderstood the discussion.
I have certainly gotten myself into some hairy situations. Since I avoid making massive commits, if things get too bad I have always been able to quickly resolve the issue by just doing a clean clone somewhere else and moving my changes over. As a last ditch effort it works quite well and does not take too much time (or stress :) ).
Btw. in case it helps you. No fresh clone in a different place needed. I think I know what kind of situation you mean and all you need is to cherry pick your commit on top of the branch you want instead of doing that merge/rebase that isn't working out. Takes even less time than cloning somewhere else and moving your changes over.
And in some cases what this sort of situation really just needed was an interactive rebase that just skips the appropriate commits that already happened on the main branch. Suddenly a litany of seemingly unresolvavle conflicts doesn't even exist in the first place. Many ways leading to Rome there.
I would encourage you to always work from just within exactly one repo with git. The whole "having another copy of the repo somewhere else" is something I have seen so much with svn but it just really isn't required with git at all. And even if you have to "do a fresh clone" you really don't have to. Just get rid of all files (rm -rf) except the .git directory (or copy it where you need it) and checkout again. I've used that a few times when I was having build issues and I wanted to make absolutely sure there were no generated files from either my IDE or the local build left anywhere that could screw things up.
Ive managed to not have to do a technical interview for all of my internships and jobs so far, largely due to my efforts networking and focusing on learning popular technologies (especially React). Ive done the theoretical coursework and enjoy the problems, but the hour-a-day leetcode would not have been nearly as useful as learning a popular library and building connections.
And that said, I'd say git problems are the norm especially with newer devs. Having that one person on the team who is a git-master is invaluable when you've made a mess.
It sounds from your post like you may do front-end work. I work primarily on distributed systems for machine learning, so I can't speak to front-end work, but in my experience understanding basic data structures and algorithms is quite useful in day-to-day work. It is great you have gotten to where you are without doing technical interviews. On the other hand, every job interview I have had has had multiple rounds of technical interviews.
And I should also make clear that I am not saying become a competitive programmer or a Leetcode expert. For example, there isn't much value in looking at dynamic programming style problems unless you are interviewing at a top company. But spending 30min to an hour a day on easy to medium level questions will definitely sharpen your reasoning about algorithms and data structures. And like I said, in my experience those are used very often in day to day work (at least on the backend side of things). Also, to clarify, I am not saying you should do this forever.
As an anecdotal example, I recently reviewed a PR that had a lot of complex if-else statements that was dramatically simplified through the use of a set. The updated code was easier to read as well as understand. When I pointed this out, the engineer agreed and understood what was going on. But their initial instinct was to use the one tool they knew: arrays and chains of if-else statements. This is the kind of skill I am getting at - knowing enough about your language, data structures, and algorithms to know when to use the tools in your toolbox.
I don't think it is unreasonable to expect a software engineer to understand the difference between tree-based and hash-based data structures, when you should use arrays, and pros/cons of linked lists, etc. Practicing this kind of stuff, which is very easy to do in Leetcode, is the fastest way to build this intuition (at least in my experience with distributed systems).
Edit: just wanted to add that understanding these things makes it extremely easy to reason about systems like Redis, memcached, Cassandra, Kafka, etc. If you understanding the basic, then you start having these moments of clairty thinking "oh this is just a big hash table!" etc.
Also, meant to add that thee repetition of Leetcode style questions is super valuable in learning the APIs of your language. Things like "how do I create a hash table? how do I populate it? How do I check if it contains a key?" This is all simple stuff but a lot of new grads aren't as familiar with the APIs. It's not a big deal, sure, but it is also an _incredibly_ easy way to stand out.
In fact, I had a similar "simplification" moment during the summer after practicing Leetcode for a few weeks. There was a longer than needed function that returned a list of unique items, and realizing the intent of the code, I simplified it to a one-liner using built-in data structures. Small moments of recognition like that feel great!
Your point about becoming more familiar with your language's APIs is also a great one. After the aforementioned Leetcode practice, I didn't have to look up things half as much as I did previously about Python. It was a good feeling :)
Unrelated to the above anecdote, I recently started following the Backend Engineering Show with Hussein Nasser [0], and he makes a lot of these kinds of connections to popular technologies like you described.
EDIT: forgot to add the link!
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.
I just started some client/contract work with Spring as API/middle, I'm curious about your opinion on Spring especially on this context of Careers. A niche to be avoided?
"I'm usually advocating for undestanding deeply the problem and being an expert in the matter, not in the tools that solve it that come and go quickly. But in reality it's ok to be learn the tool, as it also brings you knowledge on the same matter, eventually. It may not be as comprehensive, but it's still desired. And people who understand tools that solve the problem are also needed and it may fill some real world needs."
I find it very relatable, as I'm kinda doing that at my work. I'm no expert in anything but solve problems very skillfull coders embarrass themselves at. Not that they are dumb. They are smarter than me, more expierienced as well. But they often lack a wider view of the issue, don't take account so many things. The OS in their code, neglect the existance of network, delays, assume weird things about how other software work and so on. The almost always neglect that people just lie sometimes or will fight to death to prove they tested corectly while I know they made trivial mistakes while testing. All people do. I just verify that once more. Sometimes coders ask me (after I help them with an issue) what apps do I code at our company, while I don't code at all. It would take me a year to Hello World using company internal standards. I just troubleshoot a lot. I know options. I read what you guys write here and try to understand what problems you have or don't have when using different aproaches. So I can suggest new ways of debugging, solving issues, simplifying things.
I like my job. Except for the part when developers lie to me, but in general it's a cool job ;)
For any fan of Carmack, Doom (the game), or just video games in general, I recommend reading "Masters of Doom". Carmack's story honestly reads like a programming/general nerd rockstar in the book, and it's a lot of fun. Also helps me understand what kind of personality it takes to be considered one of the best ever at something: for much of his early life, Carmack was essentially awake just to program. His home was basically a mattress and a computer at one point, IIRC.
Dungeons and Dreamers was a side by side story and contrast between Carmack and Id's path vs Richard Garriot and Origin Systems.
The History of the Future features a much older John Carmack at the top of the industry, joining Palmer Lucky and a team of young entrepreneurs to build Oculus and VR. The entrepreneurial and technical ride is at least as wild as the one in Masters of Doom.
Carmack is saying learning something deeply, for example learning all features of a tool, helps in the long run, but in this approach it takes a while to provide value.
An alternate approach is to learn a subset that provides immediate values. In the case learning only the subset of features of the tool that are being used at that time. That's more tractable and allows you to provided immediate value.
He is leaning towards the 2nd approach because first groups of people are opinionated without broad experience.
Elon Musk said something very similar. He said, lets say you need to use a wrench, but if you start from the very basic it would be extraordinarily difficult to start working. Instead you can just starting learn about the wrench and go backward from there. This was you are providing immediate values to the work at hand.
I think he is overall suggesting that you should find your business value - your value as an employee to the business you work for. He seems to be specifically talking about "career advice", as advice for employment, so slightly outside of his own experience.
He is suggesting a shortcut to this business value is to know one tool deeply enough that you become the go-to person for that tool in your company (whether or not that is in your job description).
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.
TBH I also believe in knowing fairly deeply a few areas (you have to have _some_ depth too, not just breadth); but I suspect Carmack is not exactly a narrow-field specialist, with him founding Armadillo Aerospace and all... his knowledge might very well be both wider & deeper than mine :)
This whole kind of advice is not very useful in practise. Copying a recipe for success from a person that is wildly different in personality than you will not lead to the same outcomes.
If you've read Masters of Doom, it is evident that Carmack is not neuro-typical. Few people have the ability to concentrate like him. There is no point trying to become like him, this will only make you miserable. Don't fall for post-hoc rationalisation: he naturally gravitated towards it and became successful. 200 years ago he might have been a scholarly monk, or a watchmaker tinkering.
You have to choose your own path. Doesn't mean you cannot learn from the mistakes of others, but this will probably be about how and less about what.
If you know the fundamentals and the theory of programming/CS well enough, you can contribute to almost all kinds of programming projects (given some time to acclimate). Some examples of what I mean by fundamentals:
- data structures;
- computer architecture (no need to design your own hardware, but you should know how all the components interact);
- basics of complexity theory;
- at least one scripting language.
- knowing how to write low-level programs in at least two operating systems. For example, write a simple HTTP proxy in C by using just the C standard library and BSD sockets. If you don't want to use C, use another compiled language but avoid any fancy libraries for this kind of exercise.
If you're good at all of the above you'll never run out of companies that want to hire you. You won't know everything, but you'll be able to learn most things quickly enough.
> If you're good at all of the above you'll never run out of companies that want to hire you.
If you're good at all the above, you'll be hit with whiteboard monkeydance and the interviewer will walk away convinced you don't know how to write an if statement.
There's a specific term for this, it's called "being T-shaped". You have breadth at the top and then depth in one subject area.
I think the ideal balance probably varies from person to person. Some people really enjoy going deep on a subject (these are the kinds of people who get PhD's). I personally can't keep my interest on one thing for too long so I end up with a lot of breadth, but I make sure there are a few subjects I revisit a lot so that I manage to build some depth.
That said, Carmack clearly has wide-ranging enough knowledge to run rings around entire engineering teams - despite his preference for learning in depth.
On the other hand, null-terminated strings are avoided by most modern programming languages, which tend to explicitly store the string's length.
the 1/n scheme indicates the length of the sequence upfront, whereas the backslash scheme doesn't.
I've seen a variation of the 1/n scheme that literally uses "1/n", "2/n", etc. to avoid specifying the length up front. Usually the end of the sequence isn't indicated in that case.
There's something to be said for writing where your audience is. Carmack isn't a blogger and doesn't often write longer posts.
For me, I have no problem reading threads on Twitter. I look forward to the daily one from Foone. But if you put someone who hasn't used Twitter much before in front of this interface it becomes apparent very quickly how poor the UX is for threads.
Right now, we're discussing the various symbols people put in their posts (which are severely space-limited!) to indicate that there is a thread. Why is this necessary?
For sharing purposes, you might try using one of the "thread unroll" services to get around this issue.
There should be a word for people like that...
It's neat how fast a good convention spreads.
He's actually giving decent advice which is make yourself a source of knowledge on something within your chosen field.
Most people who are just starting out are not going to create the next amazing thing, but it's within reach for them to become a subject-matter-expert (or at least start that journey) so that they can use that knowledge to help them make things (and in the process support their peers and benefit from knowledge sharing).
I've wasted so much time in my life trying to learn things top down... that is, learn bits and pieces of something to complete a task without fundamental knowledge of the thing I'm working on. I've noticed "geniuses" never work this way. They insist on knowing their fundamentals first and work up from there.
A genius' mental framework for problem solving is so well developed that it just seems like they won DNA lottery. Carmack is incredible at what he does, but there are likely many intellectual things that he is terrible at because he has no mental framework for solving those types of problems. It ultimately would take him thousands of hours to be great at those things like the rest of us plebs.
To a large extent, career success is the result of a combination of hard work and luck. The more you have of one, the less you have to rely on the other.
1. Make sure you do what you love to do.
2. Make sure you constantly improve and try to do as good job as is possible.
3. Don't get distracted.
In almost any field, there is always need for people who have deep expertise and can do excellent job. It doesn't matter if you are developer or lawyer or a salesperson or actor. If you do world class job, your prospects are good.
It is hard enough to do something for entire lifetime. It is harder to do something you don't love.
It is hard to find strength to constantly improve in a field you just don't feel particularly interested in.
I have non-techie friends who have toyed with learning to code, but they usually get discouraged after a few weeks. I try to encourage and mentor, but it rarely pans out. There's a huge disconnect between what people are taught and how career progression works in the modern world. It's enough of a gap that I struggle to connect "Eloquent JavaScript" or a similar 101 guide with actually getting someone a job.
I'm certain there's a framework out there that could help learn and make a living in an emerging industry (outside of "work your ass off and don't get exploited"), but there's also so much garbage and bad guidance muddying these waters.
Also, most of the things I genuinely love (like reading whatever strikes my fancy at the moment for pleasure) aren't things anyone will pay me to do.
this is why I focus on generalized principles in my writing. all personal success is anecdotal but we should not let that stop us from trying to discover generalizable truths by induction and deduction.
When you actually understand and question everything, you understand why things are how they are and then you are able to just fix the critical things because you acutally understand the system.
After a while the technical deep dive will not matter that much anymore as they become systems, you become a system expert and you only need to look at technical details here and there.
Edit: Since we are talking about Carmack here you probably know he is among other things famous for designing custom algorithms for the games he made. So when he talks about deep understanding it includes deep understanding of algorithms, how they work and how to make new ones. If you got that down well then leetcode isn't hard at all.
So you're right, he's talking about "this makes you desirable in my eyes", not "practical employability through the lens of HR".
* If you've mastered git commands, you haven't followed Carmack's advice.
* If you've used git as a domain to understand key-value stores, Merkle trees, hash functions, and network theory, you have followed Carmack's advice.
Or another example:
* If you've mastered using a gaming library to move characters around and memorized APIs, you haven't followed Carmack's advice
* If you've mastered a game library to understand 3d transformation matrices, GPGU, and simulations of physics, you have.
A tool can point you to an aligned, coherent set of fundamentals which also work together to make a package useful for employment.
https://www.youtube.com/watch?v=e3msMuwqp-o&list=PLctkxgWNSR...
“I have given a talk with this title many times, and it turns out from discussions after the talk I could have just as well have called it "You and Your Engineering Career," or even "You and Your Career." But I left the word "Research" in the title because that is what I have most studied.”
It is good advice. I’m doing pretty well in my career at 43 as an individual contributor. Next year I’ll be earning $500k easily (and I don’t live in NY or SF). I started as a coop student out of university which helped me focus on individual specialties. One of my very first jobs was as a database design analyst. I wanted to be a developer, but, i hit it off with this hiring manager in the interview.
When I started I had no idea about entity relation design, normalization, the great relational vs networked vs hierarchical database wars, data warehousing vs operational datastores, star schemas, reporting vs OLAP cubes, ETL tools, etc. I got very good at understanding a few of these tools [edit: specifically datamirror, informatica, Cognos, and Oracle RDBMS] very deeply, and became something of a technical expert on the topic of data warehousing, eventually meeting the pioneers of the field (Inman, Kimball) and eventually working for one of them (Terdeman). This was over the course of 5 years, with a sidestep into coding a large scientific test and measurement system on a Gemstone object database platform (a new area that benefited from my prior specialty). It was all a mix of serendipity and ability to focus.
My career moved away from data/analytics after that into middleware and REST architecture, and now cloud computing, and Kubernetes.
Tl;dr:
Knowing a few tools or subject areas super deeply comes across as having super powers. It really is about focus and curiosity.
If you don't mind sharing more, is that working for a single US company or is it contracting / your own company?
I'm at 1/3 of your income but I find it increasingly hard to grow from here. To be honest I wouldn't mind being an individual contributor in the future but I don't see my income raise much more than that (I'm in Europe and I literally don't know anyone making close to half a million as an individual contributor).
I guess FAANGs (and stock options) would be an option but my friends at Google / Apple / FB are not very happy. Mostly dull jobs unless you're in some lucky team, less flexibility (at least pre covid, now everyone is remote anyway), more politics, similar cash compensation but very valuable stocks (which is how you make money). Plus throwing away two months of my life to prepare for a dumb interview.
Instead I'm looking into kissing my IC's career goodbye, start a small tech business and try to grow that one.
During this period for about 2 years I was an independent contractor and was at around $250k annually (could be higher, but you don’t get paid for vacation, conferences or marketing/sales efforts).
Building a small lifestyle business is another pathway to making a lot of money, though it too tends to take a few years. I have friends that have built niche industry software apps that gives them about $1m-2m a year. Enough to hire staff to keep things running.
You start with a tool and then build experience in the area so you can eventually make evaluative judgements.
I think this has its merits (and actually I think, it suits me), but without any guidance your measurable and marketable progress is slow. For example, I build my scientific softwarestacks with spack, debugging build failures. Net result is, that I got into a random project of a colleague, fixed his C++-Makefile without having more than basic C-knowledge.
For example the majority of webdevs probably couldn't write V8 but they can make JS sing.
From there, it's a totally new story/path.
It helps a little bit if you like what you do, but you don't need to 'love' it - if you do, you may get taken advantage of, i.e.'gaming'.
Once on the inside, it should become clear the folks that are valued and some of them will be in accessible positions with a degree of focus.
Tech is a pretty good industry for talent exposition, almost like no other. Usually when people are good or where knowledge shines ... it stands out. At least more than in almost every other industry.
The best solution is not to reproduce till you can help your children with connection.
It's also as far as these things go pretty mediocre and obvious advice. The majority of the games industry today is focused on using and customizing a reasonably small set of tools rather than writing their own.
Further engines like Unity and Unreal actually have pretty big penetration outside of games making them even more valuable skills to have.