5 ms·

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

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
  Wow, thank you so much for pointing this 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!
smiths1999 6y ago
I'm sure many will come down hard on my comment and disagree. But speaking as someone who teaches at a university and also works in industry and is involved in hiring, I don't think becoming an expert in git is worth your time. At this stage in your career you should spend your time mastering algorithms, data structures, and a compiled language like Java or C++. I would put emphasis on learning how to use your language of choice idiomatically (e.g., iterators, streams, the standard library and its core data structures, etc.). In my experience, the best way to do this is practice Leetcode every day. Doing one question a day (a 30-60min commitment) will put you leagues ahead of your peers. Combine this with reading a major book on your language (e.g., Effective Java or Modern C++ Design, etc.) 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.
- jlos 6y ago
  Pretty sure your getting downvoted because this sounds like the advice of a professor who hasn't spent much time in an industry setting: grind algorithmic problems to succeed, only to find out past the interview that knowledge rarely gets used. 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.
  - smiths1999 6y ago
    Hmm - that is surprising since I specifically mention I work in industry (and have for quite some time). 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.
patrec 6y ago
I agree with the sibling comment that trying to implement a limited version of git (but that can work on a real git repo) would almost certainly a great way to learn git (there are multiple "implement git yourself in X" projects for different languages X that you can find online). 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.
- didizaja 6y ago
  > 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. 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! :)
silicon2401 6y ago
Since you mentioned diminishing returns, stress, and time cost, it sounds like you want to balance practicality with interest. Being frank, don't do it. I'm a software engineer and I have had incredibly talented coworkers, some of whom are the type that everyone goes to for help, who barely know how to use git without a GUI, if at all. 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
- didizaja 6y ago
  This is a very good question and I'm going to think about it more. During this past semester, I started keeping a Trello list of potential projects/readings I could work on to consolidate things, but it's still hard to pick from. The Git internals thing I mentioned was one thing in that list. Since I'm interested in open source software and the communities that form around projects, another idea I had is developing a "book club" where people meet and read the code and discuss the architecture of popular open source projects. I created a basic site for this a few weeks back, but haven't advertised it since it's not acceptable for public viewing yet. 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.
  - silicon2401 6y ago
    This is what I would do. Treat it like an engineering problem: break it down into smaller, simpler parts, and start with small steps. 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.

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
Wow, thank you so much for pointing this 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!

smiths1999 6y ago

I'm sure many will come down hard on my comment and disagree. But speaking as someone who teaches at a university and also works in industry and is involved in hiring, I don't think becoming an expert in git is worth your time. At this stage in your career you should spend your time mastering algorithms, data structures, and a compiled language like Java or C++. I would put emphasis on learning how to use your language of choice idiomatically (e.g., iterators, streams, the standard library and its core data structures, etc.). In my experience, the best way to do this is practice Leetcode every day. Doing one question a day (a 30-60min commitment) will put you leagues ahead of your peers. Combine this with reading a major book on your language (e.g., Effective Java or Modern C++ Design, etc.) 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.

jlos 6y ago
Pretty sure your getting downvoted because this sounds like the advice of a professor who hasn't spent much time in an industry setting: grind algorithmic problems to succeed, only to find out past the interview that knowledge rarely gets used. 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.
- smiths1999 6y ago
  Hmm - that is surprising since I specifically mention I work in industry (and have for quite some time). 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.

patrec 6y ago

I agree with the sibling comment that trying to implement a limited version of git (but that can work on a real git repo) would almost certainly a great way to learn git (there are multiple "implement git yourself in X" projects for different languages X that you can find online). 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.

didizaja 6y ago
> 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. 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! :)

silicon2401 6y ago

Since you mentioned diminishing returns, stress, and time cost, it sounds like you want to balance practicality with interest. Being frank, don't do it. I'm a software engineer and I have had incredibly talented coworkers, some of whom are the type that everyone goes to for help, who barely know how to use git without a GUI, if at all. 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

didizaja 6y ago
This is a very good question and I'm going to think about it more. During this past semester, I started keeping a Trello list of potential projects/readings I could work on to consolidate things, but it's still hard to pick from. The Git internals thing I mentioned was one thing in that list. Since I'm interested in open source software and the communities that form around projects, another idea I had is developing a "book club" where people meet and read the code and discuss the architecture of popular open source projects. I created a basic site for this a few weeks back, but haven't advertised it since it's not acceptable for public viewing yet. 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.
- silicon2401 6y ago
  This is what I would do. Treat it like an engineering problem: break it down into smaller, simpler parts, and start with small steps. 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.