10 ms·

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 a

by patrec 6y ago

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 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).

pmart123 6y ago
Nice explanation.
amitranade 6y ago
Nice explanation. MIT’s “The Missing Semester of Your CS Education” attempts to address some of your points https://missing.csail.mit.edu/ https://missing.csail.mit.edu/
- st1x7 6y ago
  The course is decent but I really don't get how it's relevant here.
simonh 6y ago
This closely matches advice I've been giving to new hires and team members for years. When you join a new team look for the gaps, what isn't getting done or what will benefit the team most and fill that gap. You're not going to compete with the current guru of this or that, so learn from them for sure but that's not going to mark you out. 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.
- Frost1x 6y ago
  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 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.
  - st1x7 6y ago
    > 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 https://www.youtube.com/watch?v=KClAPipnKqw Summary article: https://noidea.dog/glue https://noidea.dog/glue
didizaja 6y ago
Thanks for the comprehensive explanation! 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 https://git.wiki.kernel.org/index.php/GitCommunity [1]: https://git-scm.com/book/en/v2 https://git-scm.com/book/en/v2 [2]: https://github.com/git/git/tree/master/Documentation https://github.com/git/git/tree/master/Documentation
- leobakerhytch 6y ago
  You might like to try Write yourself a Git [0] (discussed here previously [1]). YMMV, but I find the best way to learn something deeply is to get hands on. Less of a chance of convincing yourself you understand something that you really don’t. 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/ https://wyag.thb.lt/ [1]: https://news.ycombinator.com/item?id=19386141 https://news.ycombinator.com/item?id=19386141 [2]: https://maryrosecook.com/blog/post/git-from-the-inside-out https://maryrosecook.com/blog/post/git-from-the-inside-out
  - didizaja 6y ago
ido 6y ago
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 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).
- tharkun__ 6y ago
  At least in pre git days many large companies had people whose entire job it was to merge and resolve merge conflicts. They were not part of the project teams. They were part of the build and deployment team. 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.
- scruple 6y ago
  It's been surprising to me to see my wifes deep knowledge of git, SVN, and perforce be so cherished in her organization. Surprising because she works for a place that is routinely featured on the frontpage of HN, where very nearly every single person on HN has used their software sometime in the last ~30 years. It was my view, originally, that these people ought to already have the answers to the questions they're asking. I was wrong. 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.
m12k 6y ago
Regarding specific picks, I would say things like git or SQL (if you want something "ageless") or docker, aws, react (if you want something trendy, but still proven) would be good choices.
snarfy 6y ago
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.
BlueTemplar 6y ago
Heh, I was the "git guy" for a project, and it mostly made me want to try the alternatives like fossil and pijul...
yamoriyamori 6y ago
> "Spring ... will probably harm ... your intellectual development." 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?

by patrec 6y ago

pmart123 6y ago

Nice explanation.

amitranade 6y ago

Nice explanation. MIT’s “The Missing Semester of Your CS Education” attempts to address some of your points https://missing.csail.mit.edu/ https://missing.csail.mit.edu/

st1x7 6y ago
The course is decent but I really don't get how it's relevant here.

simonh 6y ago

This closely matches advice I've been giving to new hires and team members for years. When you join a new team look for the gaps, what isn't getting done or what will benefit the team most and fill that gap. You're not going to compete with the current guru of this or that, so learn from them for sure but that's not going to mark you out. 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.

Frost1x 6y ago
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 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.
- st1x7 6y ago
  > 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 https://www.youtube.com/watch?v=KClAPipnKqw Summary article: https://noidea.dog/glue https://noidea.dog/glue

didizaja 6y ago

Thanks for the comprehensive explanation! 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 https://git.wiki.kernel.org/index.php/GitCommunity [1]: https://git-scm.com/book/en/v2 https://git-scm.com/book/en/v2 [2]: https://github.com/git/git/tree/master/Documentation https://github.com/git/git/tree/master/Documentation

leobakerhytch 6y ago
You might like to try Write yourself a Git [0] (discussed here previously [1]). YMMV, but I find the best way to learn something deeply is to get hands on. Less of a chance of convincing yourself you understand something that you really don’t. 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/ https://wyag.thb.lt/ [1]: https://news.ycombinator.com/item?id=19386141 https://news.ycombinator.com/item?id=19386141 [2]: https://maryrosecook.com/blog/post/git-from-the-inside-out https://maryrosecook.com/blog/post/git-from-the-inside-out
- didizaja 6y ago

ido 6y ago

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 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).

tharkun__ 6y ago
At least in pre git days many large companies had people whose entire job it was to merge and resolve merge conflicts. They were not part of the project teams. They were part of the build and deployment team. 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.
scruple 6y ago
It's been surprising to me to see my wifes deep knowledge of git, SVN, and perforce be so cherished in her organization. Surprising because she works for a place that is routinely featured on the frontpage of HN, where very nearly every single person on HN has used their software sometime in the last ~30 years. It was my view, originally, that these people ought to already have the answers to the questions they're asking. I was wrong. 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.

m12k 6y ago

Regarding specific picks, I would say things like git or SQL (if you want something "ageless") or docker, aws, react (if you want something trendy, but still proven) would be good choices.

snarfy 6y ago

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.

BlueTemplar 6y ago

Heh, I was the "git guy" for a project, and it mostly made me want to try the alternatives like fossil and pijul...

yamoriyamori 6y ago

> "Spring ... will probably harm ... your intellectual development." 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?