> My job isn’t to use git, it’s to write specialist software. If I get the software written and the customer is happy, it doesn’t matter whether I use <ide> or not. Imagine having 100 complex things bouncing around your head and having to make that 101 when you forget the order of arguments to merge.
Imagine if you knew a cabinet builder who said:
"My job isn't to use a table saw, it's to build beautiful cabinets. If I get the cabinets built and the customer is happy, it doesn't matter whether I use a japanese handsaw or a CNC controlled laser. Imagine having 100 different pieces bouncing around around in your and having to then remember the assembly order."
Now, you might argue that this supports your point, by claiming that it actually doesn't matter whether the carpenter uses a japanese handsaw, table saw or CNC laser cutter. But I'd argue the opposite: it does matter whether the carpenter knows the tools they use as well as possible, because this will affect both the quality & speed of their work, but also the range of possibilities they can even consider. It doesn't matter much which tool they use, as long as they know it intimately and in depth.
I would argue that the same is true of the tools we use as software developers. Pretending that all of the skill lies only in the domain of creating actual lines of code is misleading. If you're using a revision control system, you owe it to yourself, your customers and your colleagues (if any) to be a master of that in the same way that you're a master of the specialist software you're creating.
> But I'd argue the opposite: it does matter whether the carpenter knows the tools they use as well as possible, because this will affect both the quality & speed of their work
You chose a strange analogy, because CNC woodworking is far and away the superior choice over hand tools for producing cabinets. CNC cut and drilled wood is going to be orders of magnitude cheaper, more accurate, and allow the cabinet professional to focus on what really matters (installing them properly) rather than wasting huge amounts of time trying to do everything the manual way.
Ironically, this might be a great analogy to support the OP's point: Someone who gets so caught up in the tools and methods and doing everything the manual way for the sake of flexing their knowledge is at risk of wasting a lot of time and energy.
Personally, I have a lot of fun doing things the hard, manual way when I'm working on a hobby project. But when it's time to get work done, I choose the efficient abstractions and tools that let me focus on the core work without wasting time.
If you have a CNC system, then I'd say you should absolutely be using that in preference to other things. But you should also come to as deep an understanding of the CNC system as possible, so as to be able to grasp what you can do with it, and how you could use it to carry out specific tasks that might arise in the course of your work.
What you should not do, IMO, is to say "Oh, I have a CNC system, but I never interact with it directly, I let CNC-Foo on my computer control it whenever I need to do anything".
> What you should not do, IMO, is to say "Oh, I have a CNC system, but I never interact with it directly, I let CNC-Foo on my computer control it whenever I need to do anything".
I have experience with CNC machines, and I would still not recommend that anyone try to control their CNC machine by typing in G-Code directly. Understanding G-code can be helpful, but you really need to learn to use the higher-level tools properly to get anything done.
HN is really strange on the topic of knowing the underlying details of complex systems:
- When the topic of CS interviews comes up, the comment section is irate that companies are testing for low-level knowledge that isn't used in day to day programming tasks. Asking someone to reverse a linked list is blasphemy because we have libraries for that.
- When the topic of Git comes up, the comment section is insistent that the only possible way to use tools is to have intimate working knowledge of the underlying low-level concepts. Insisting that people know the ins and outs of every git command instead of using a GUI is the only acceptable option.
I suspect there's a lot of overlap between the two positions, which boils down to: "I do things a certain way and I'm convinced my way is the correct and only way."
1) I don't think it ever makes much sense to have a concept such as "HN is really strange on ...". This place is a collection of thousands of individuals, and you're going to see a wide range of opinions, many of them contradictory. Since not everyone comments on every article, you'll see patterns that are not reflections of a single position held by any particular person. If you see contradictions in things that I've written, I'd love to have them pointed out, but saying that "one set of people on HN say X and another set of people on HN say !X or X'" just doesn't really convey anything that seems actionable or even that interesting. "People have different opinions! News at 11!!"
2) After I posted the comment you're replying to, I was absolutely certain that the question of which level of control was appropriate would come up (since that's really what we're discussing in the context of git). It doesn't seem obvious to try to carry the analogy too far, but for both systems there are obviously different levels that one can think about. I haven't used a CNC system, but I would imagine that there are very high level control systems that maybe start from some sort of design data and take it from there, some mid-level control systems that let you specify what you need and then program the machine to create it, and low-level control that would be rarely used unless the higher level tools just couldn't do what was needed.
If indeed this is an accurate description, then it seems to match the case with git quite well, and I'd still argue that even if you often/sometimes use the very high level control tool, you should understand and be aware of the possibilities of the lower level ones too.
> 1) I don't think it ever makes much sense to have a concept such as "HN is really strange on ...".
I enjoy HN, but I've also been here long enough to accept that HN is an echo chamber. Yes, we have downvotes and a variety of opinions, but the reality is that if you come into certain threads expressing certain unpopular opinions you're going to get hit with a wave of downvotes. Eventually you learn to just stop posting those opinions, which results in an echo chamber effect.
No social media site is free of echo chamber effects. HN is not an exception.
> I haven't used a CNC system, but...
Friendly suggestion: If you're not familiar with how something works, maybe it's not the best subject for an analogy?
"Haven't used" isn't the same as "have never been in a shop with a CNC system installed, never worked around people using them, and have no close friends who use them regularly".
As for the echo chamber, you won't be suprised that I disagree with you on this point.
It would be perfectly reasonable for someone to just say "no, I'm not going to imagine my job designing software as analogous to cabinetry," because argument from analogy shifts some of the burden of proof to the analogy itself, and the analogy must be defensible. In this case, you're drawing an equivalence between OP's 100 complex things and 100 cabinet components that must be assembled, yet also drawing an equivalence between the 101st thing and a central tool of the cabinet maker's trade. This is an internal inconsistency. You must either acknowledge the 100 things as 100 tools of cabinetry, each more important than the 101st, or you must regard the 101st thing as yet another fixture to be added to the cabinet. A domain expert is telling you that version control is a peripheral concern in their trade, the 101st tool, and you're responding with an idealism of mastery that stems from notions of integrity and identity and establishes no reasonable boundaries. You're welcome to this ethic and idealism, it's not a bad thing to have, but you're second guessing someone else's mastery based on arbitrary reference to your own mastery. I might as well be chiding you for looking up man pages without understanding the command-line capabilities of `troff`.
> A domain expert is telling you that version control is a peripheral concern in their trade
1) I have no way of knowing if they're a domain expert.
2) With 35 years of software development under my belt, and a half dozen version control systems too, I'd consider myself likely to be as much of a domain expert as the OP, and I'm saying the opposite.
3) I am not as master woodworker. I have built cabinets and many other things. Philosophically I consider the disjunction between our culture's attitude towards physical tools (where there's an assumption that one will have to take time to learn how to use the tool before actually being able to make anything good with them) and digital tools (where there's an assumption that apprenticeship should be kept to a minimum, preferably zero) extremely interesting.
4) When I'm working on a task (I also build very specialized, highly complex software) the distinction between the cognitive load caused by the task and the cognitive task caused by the tools I have available to work with is not very big. It doesn't make much different whether the "101st" thing concerns a tool or a component, it's just another part of the big picture that I have to struggle to keep in my head as I move forward.
This is an excellent reply, more interesting than my comment, and I certainly cannot gainsay you. However, '100' might as well be 'n'. Your reply suggests that there is a struggle to maintain contextual awareness of 'n'. In this model, for everyone, there will be an n+1, a necessary factor where the diminishing returns of mastery do not justify the cognitive load. I do not think the heart of your dispute truly lies so much his model of peripheral necessities as with his ranking of git as an n+1 tool.
Now I'm curious: why? Not that I don't believe you, but I'm wondering what is the reason? It's not intuitively clear why gloves would make it more dangerous, even knowing that it is.
If a glove comes into contact with a spinning blade, there is a good chance it will pull the rest of the glove, and the hand within it, right into the path of the blade.
Speaking as a person who lost half a thumb to a table saw ...
the difference in your analogy emerges when someone wants/needs you to carve out something more intricate, and you say "it's not my job to be able to do this without gloves".
To the op's point, using git is not the act of coding or in this example making cabinets. I think it would be more akin to a work flow used by a cabinet maker and I think people would be less likely to look down on one that has an idiosyncratic work flow. It may not be the most optimal work flow, but they can get the job done well following their methods.
I don't subscribe to that thinking and I try to optimize and improve wherever I can, but developers are an idiosyncratic bunch. You can lead them to water or show them how to fish but lots of good developers just like to do things their own way.
It's about tools. Git (and revision/version control more generally) is a tool available for you to use when developing software. The questions for me are: do you use the tool? do you understand the tool?
I think it's fine if someone says "I don't use that tool". I personally think that they are making their life harder and their software probably worse, but that seems like a valid choice. What I have a difficult time with is someone who says "I use that tool, but I limit my understanding of it to be as little as I can, because understanding my tools is not part of my job". That's what I felt the OP was doing.
Surely some tools have to be more important than others tho and not knowing some tools impacts some jobs less. Is git a saw for woodworking? Or is it a tool chest that has a drawer for a saw? If you need to use a thousand different tools, the tool chest becomes more important (the analogy doesn't map well there but it seems similar to working on a bunch of repos that have a bunch of branches or one repo with one branch). If you only need a handful, it seems like it would impact your job less.
There are more things that reasoning applies to than you can learn, so it’s not really helpful in deciding between all the things. Everything depends on your goals and there’s no one size fits all answer.
I know how to file documents in filing cabinets. I don't know how the bearing mechanism for sliding out the drawers work, or how to replace the user-serviceable locks – but I know that there's a mechanism, and that the locks are user-serviceable, and I could look up the relevant information if I ever needed to do anything with that.
You don't need much knowledge of your version-control system in your head to be an effective programmer.
Assuming a binary search over version history is a valid way of finding the bug. If you have a better idea of the probability distribution (e.g. it might've started being buggy any time in the past year, but I'm fairly sure it happened about nine months ago when the formatting of the report broke a bit) you can do a better job manually than `git bisect` – and if the bug is actually multiple bugs, or other things changed that affected the bug's presence or absence (making it appear or disappear in non-trivial patterns between versions), `git bisect` will mislead you.
`git bisect` is pretty cool, but “knowing your tools” isn't the same thing as “memorising the man pages”.
if you are confident that it happened about nine months ago, then just start the bisect bounded by age-appropriate commits. just a case of knowing your tools ;)
yes, if the bug is a complex interaction of several different code changes, and comes and goes, then a binary search will not find it. however, it may be the fastest way to realize that it is this sort of bug. recognizing patterns in what happens when you use git bisect is another aspect of knowing your tools, and in this case, will help you move more rapidly toward a more appropriate approach.
I interpreted what GP said as " the version control system is the place I store my files, so it's not just a tool, but it's an essential and necessary environment, the space where I organize my stuff"
That's more what I was going for. It's also part of the background, as opposed to something I deliberately interact with, so I don't use it like a tool in my day-to-day.
All things I know are possible. I understand Git's architecture, just like I know what an inode is. I could re-implement my own (bad) version control system, if I wanted to, just like I could make my own (bad) filesystem.
But that doesn't mean I need to have memorised the CLI invocations. There's a button in Git GUI for all the things I need to do (including the things you've listed), and in the rare case where I need to do something else (e.g. submodules), I can look it up, just as I do in the rare case where I need to make a symbolic link.
Imagine if you knew a cabinet builder who said:
"My job isn't to use a table saw, it's to build beautiful cabinets. If I get the cabinets built and the customer is happy, it doesn't matter whether I use a japanese handsaw or a CNC controlled laser. Imagine having 100 different pieces bouncing around around in your and having to then remember the assembly order."
Now, you might argue that this supports your point, by claiming that it actually doesn't matter whether the carpenter uses a japanese handsaw, table saw or CNC laser cutter. But I'd argue the opposite: it does matter whether the carpenter knows the tools they use as well as possible, because this will affect both the quality & speed of their work, but also the range of possibilities they can even consider. It doesn't matter much which tool they use, as long as they know it intimately and in depth.
I would argue that the same is true of the tools we use as software developers. Pretending that all of the skill lies only in the domain of creating actual lines of code is misleading. If you're using a revision control system, you owe it to yourself, your customers and your colleagues (if any) to be a master of that in the same way that you're a master of the specialist software you're creating.