4 ms·

> but I'm seriously falling behind due to jetbrains integration This IntelliJ integration is the source of quite a lot of git problems in teams I worked with.

> but I'm seriously falling behind due to jetbrains integration This IntelliJ integration is the source of quite a lot of git problems in teams I worked with. I'm quite flabbergasted by this - devs claim to know git on their CV, come in and know what "commit" is and how to use the IntelliJ UI, but don't even understand what its doing. And everyone is acting like it's OK and learning git is a "hard thing ill never need" and we should all use sourcetree or jetbrains. Or people just get so used to it and never understand what exists below it. They lose all sense of what they're doing and just think "the machine knows what I want". Then a vaguely questioned dialog appears - or something similar - and they cause clusterfuck upon their branch - or sometimes even other people's remote branches. How do we allow our culture to be so lazy that people resist using one of the basic tools because "oh its hard I gotta remember 5 commands" and we find it OK? No wonder the plane is burning. It's good that you still know that reflog exists, because a lot of "inteliij is my git client" users don't even know about it. Tho I'm still wondering, isn't it faster/easier to open intelliJ terminal and type a command or two than having to ope a whole new window and click around it? (also sorry if this sounds like an attack on you, it isn't! just really wondering!) Also, re: OP: So basically 2 new commands were added that do what other commands already do, but people dont read the docs so we should add new commands so maybe people will read the docs for them?

phist_mcgee 5y ago
I think you're approaching git and software dev from a bottom up perspective. You learn the tools, understand why they exist, and then use the tools to solve higher level problems. Unfortunately due to time constraints, interest levels, and simply ease people go top down. They need to switch branch, so they will follow the least effort principle and use a UI. Barely understanding many fundamental tools is common these days for devs, and I honestly think that it's a sign that our field has grown massively in terms of the tools we need to use, the processes we use to deploy, and the products we use to develop. I have to deliver products and deliverables, when and what do I focus on wrt gaps in my knowledge? Git? Unix commands? OWASP Security principles? Cache busting? global state management? ORM integrations with popular DBs? Kubernetes configs? It's hard to see the gaps someone else has, and wonder why they can't know what you know, but they may have some deep knowledge in a domain you are only superficially knowledgable in. I agree we need to nail the basics, but this isn't 2002 anymore, and we don't ship Gold CDs to customers by running a build command on a single PC in the office. Our jobs are so much more complex and multi-faceted, and the oldbeard assumption that things are 'bare essentials' is eroded by the pragmatic realisation that we only have so many hours in the day.
- thecupisblue 5y ago
  > I think you're approaching git and software dev from a bottom up perspective. You learn the tools, understand why they exist, and then use the tools to solve higher level problems Actually, I'm trying to look at it more from a "shallow sea" perspective - you have a problem and are given a tool to solve it. But do you not dive in just a bit to see "hey what is this tool" after you solve the problem? Or after using it for a while? UI is also something you have to learn how to use. Sourcetree UI is as complicated as terminal for someone who never used it. >I have to deliver products and deliverables, when and what do I focus on wrt gaps in my knowledge? Git? Unix commands? OWASP Security principles? Cache busting? global state management? ORM integrations with popular DBs? Kubernetes configs? With that mentality, what do you ever learn? Do you just keep on chugging year after year with "duct-tape the tools"? Where is the joy in that? Where is the growth? Are you always in a rush to deliver software without a moment to think? You learn about the level you're using - like, are you using git daily? Just reading a tutorial or two and spending 5 mins a day with it in the terminal is going to do wonders for understanding it long-term. >Barely understanding many fundamental tools is common these days for devs It's common for someone starting to develop or starting to use a tool - hell, 8 years ago I have been as confused as "wtf is this git" as anyone. Gradle was magic to me. Terminal was a dark and scary place. That doesn't mean that it is okay to stay at that level. If we accept "not trying to understand" as the new common, then we accept failure and ignorance as the new common. We accept the world of broken software because people don't understand what they're doing - and we're telling them "you don't need to understand so don't even bother". And hell, maybe that's gatekeeping, but fuck it, I'll rather be St. Peter at the gates than accept a world where learning and understanding is something "we don't have time for".
  - fn-mote 5y ago
    >>I have to deliver products and deliverables, when and what do I focus on wrt gaps in my knowledge? Git? Unix commands? OWASP Security principles? Cache busting? global state management? ORM integrations with popular DBs? Kubernetes configs? > With that mentality, what do you ever learn? The way I understand it, this comment is saying you have to prioritize and work on the highest-impact areas. Of course you grow, but until a certain point you don't benefit much from knowing the guts of git more than Framework X. I have never experienced any joy of creativity from using git, so it's not something I'm putting high on my list. Heck, learning Rust was 10x as good for my development as git, so I don't regret prioritizing that way. I expect (hope?) that most people understand the git they use in their daily workflow... but that doesn't mean they have to have mastered every dark corner. Find a specialist (Stack Overflow :) when an unusual situation arises. If it's happening consistently, then I agree some more learning should occur.
papaf 5y ago
How do we allow our culture to be so lazy that people resist using one of the basic tools because "oh its hard I gotta remember 5 commands" and we find it OK? No wonder the plane is burning. Its probably a rhetorical question but I think its worth answering anyway. Experienced developers had the luxury of learning git, say, over a 10 year period. I certainly know a lot more git than 10 years ago. If you are a new developer thrown into your first real project and Intellij handles git for you so that you can concentrate on being productive then learning command line git takes a back seat. I see this in many aspects of programming. One thing I am struggling with currently, is that JHipster generates applications in a user friendly way. JHipster is highly productive and seems like the future of programming BUT it means that there will be a generation of programmers that do not understand the MB of Spring Java code that is casually puked out by the code generator. Its depressing to say it, but I think not understanding the tools is only natural and is probably the new normal in this age of complexity.
- thecupisblue 5y ago
  >Experienced developers had the luxury of learning git, say, over a 10 year period. I certainly know a lot more git than 10 years ago. The depressing thing is I'm not talking just about off-the-shelf newbies, I'm also talking about experienced devs. >Its depressing to say it, but I think not understanding the tools is only natural and is probably the new normal in this age of complexity. Yes, unfortunately, this is becoming the new normal. But what is the next "new normal" after this? More complexity and obscurity? How long can we keep building that house of cards before it collapses upon us?
  - joseluis 5y ago
    the solution I believe would be to focus on creating simpler tools, and by that I mean tools with at least the same usefulness/as powerful as the ones we have now, but with much less cognitive burden, with better interoperability and composability by using simple standard data interchange formats.
    - PaulDavisThe1st 5y ago
yunohn 5y ago
This is an unnecessarily antagonistic rant, which boils down to “I know git from scratch, I’m so smart, why isn’t everyone else doing this”. Git is a very complicated, bloated command line. Frankly, most of the day-to-day can easily be done with a high level understanding and a GUI. There is no shame in not knowing the minutiae of git. The goal of being a programmer is to produce cool things, not to duel with your tooling.
- thecupisblue 5y ago
  I don't know git from scratch, never written it or dived into source code itself. Yes, you can write C without understanding poinnters, you can paint without understanding colors and how they mix, draw without knowing difference between 3H and 2B, use a drill without knowing which type of head is for what. But try doing it long term and you either gotta learn those things or your output will be limited and clear expression of your vision will be harder. I'm not advocating for people to learn git from scratch. I'm advocating for understanding - not low level, at least high level. And is it better to go through a "how to use X tool in Y GUI" tutorial or how to use "X tool" and then gain immediate understanding of what Y does? What if you switch GUI's? Which knowledge will be sticking?
  - yunohn 5y ago
    > I'm advocating for understanding - not low level, at least high level. It sounds a lot like you mean low-level, not high-level, though? There’s more than enough to be achieved by just knowing the tree concept of git, and using a GUI to visualize it while running the basics - checkout, commit, branch, rebase, etc.
    - thecupisblue 5y ago
      >There’s more than enough to be achieved by just knowing the tree concept of git, and using a GUI to visualize it while running the basics - checkout, commit, branch, rebase, etc. Oh, that's exactly what I meant. At least basic, high level understanding of the git model and basic operations on it. But most people never even get to rebasing or try do understand what lies behind magical buttons in the GUI.
wpietri 5y ago
This attitude mystifies me. The whole point of computers is to solve problems well enough that most people don't have to understand the machinery. It is literally impossible for us to understand how everything we use works. We expect a compiler to just compile things and work; nobody is ranting about how modern developers are lazy because they can't hand-verify the compiler is outputting the right opcodes. Nobody is ranting about how web developers are lazy because they can't debug a browser runtime and its interface to the OS's rendering primitives. Can some people do those things? Sure. Do we imply character flaws for the 98% of developers who have focused on other things? No. If this old-man-yells-at-clouds, good-enough-for-grandpa-so-its-good-enough-for-me style were the dominant approach in our industry, we'd still be working with punch cards and fanfold printer output. Thank goodness it isn't. Instead of having a million developers adapt to git, git should adapt to the million developers and free up their time for doing something that actually matters to a user.
- thecupisblue 5y ago
  >Instead of having a million developers adapt to git, git should adapt to the million developers and free up their time for doing something that actually matters to a user. How should git adapt? Can you get a simpler model than this? Is really a basic structure like a tree so complicated millions of developers are having a hard time with it? Nobody is advocating for "dont use new stuff, old is betteer". Nobody is advocating for people to hand-check compiler outputs (unless your analogy pertains to people who work in a GUI tool that shows them pretty pictures for opcodes and they check if the pictures match). You've missed the point. The point is "try to understand the basics of the tool you are using". If me wanting people to learn and understand more makes me an asshole, so be it. I'd rather be an asshole and help people learn more and understand more than coddle them in the safety of the pretty buttons and say "it's ok, you don't have to understand". If we don't understand our tools and the problems they solve, how will we make progress? How will we make better tools? How will we make better software? How do you learn and grow if not by understanding what you don't?
  - wpietri 5y ago
    One way it could adapt is by doing exactly what this article is talking about: Giving commands for common operations where name and behavior matches user intent. That you can't tell the difference between "let's make software more usable" and "nobody should learn anything ever again and just soften into blobs of undifferentiated protoplasm" seems like a you problem.
AnthonBerg 5y ago
Might I ask what those git problems are? Thanks!

phist_mcgee 5y ago

I think you're approaching git and software dev from a bottom up perspective. You learn the tools, understand why they exist, and then use the tools to solve higher level problems. Unfortunately due to time constraints, interest levels, and simply ease people go top down. They need to switch branch, so they will follow the least effort principle and use a UI. Barely understanding many fundamental tools is common these days for devs, and I honestly think that it's a sign that our field has grown massively in terms of the tools we need to use, the processes we use to deploy, and the products we use to develop. I have to deliver products and deliverables, when and what do I focus on wrt gaps in my knowledge? Git? Unix commands? OWASP Security principles? Cache busting? global state management? ORM integrations with popular DBs? Kubernetes configs? It's hard to see the gaps someone else has, and wonder why they can't know what you know, but they may have some deep knowledge in a domain you are only superficially knowledgable in. I agree we need to nail the basics, but this isn't 2002 anymore, and we don't ship Gold CDs to customers by running a build command on a single PC in the office. Our jobs are so much more complex and multi-faceted, and the oldbeard assumption that things are 'bare essentials' is eroded by the pragmatic realisation that we only have so many hours in the day.

thecupisblue 5y ago
> I think you're approaching git and software dev from a bottom up perspective. You learn the tools, understand why they exist, and then use the tools to solve higher level problems Actually, I'm trying to look at it more from a "shallow sea" perspective - you have a problem and are given a tool to solve it. But do you not dive in just a bit to see "hey what is this tool" after you solve the problem? Or after using it for a while? UI is also something you have to learn how to use. Sourcetree UI is as complicated as terminal for someone who never used it. >I have to deliver products and deliverables, when and what do I focus on wrt gaps in my knowledge? Git? Unix commands? OWASP Security principles? Cache busting? global state management? ORM integrations with popular DBs? Kubernetes configs? With that mentality, what do you ever learn? Do you just keep on chugging year after year with "duct-tape the tools"? Where is the joy in that? Where is the growth? Are you always in a rush to deliver software without a moment to think? You learn about the level you're using - like, are you using git daily? Just reading a tutorial or two and spending 5 mins a day with it in the terminal is going to do wonders for understanding it long-term. >Barely understanding many fundamental tools is common these days for devs It's common for someone starting to develop or starting to use a tool - hell, 8 years ago I have been as confused as "wtf is this git" as anyone. Gradle was magic to me. Terminal was a dark and scary place. That doesn't mean that it is okay to stay at that level. If we accept "not trying to understand" as the new common, then we accept failure and ignorance as the new common. We accept the world of broken software because people don't understand what they're doing - and we're telling them "you don't need to understand so don't even bother". And hell, maybe that's gatekeeping, but fuck it, I'll rather be St. Peter at the gates than accept a world where learning and understanding is something "we don't have time for".
- fn-mote 5y ago
  >>I have to deliver products and deliverables, when and what do I focus on wrt gaps in my knowledge? Git? Unix commands? OWASP Security principles? Cache busting? global state management? ORM integrations with popular DBs? Kubernetes configs? > With that mentality, what do you ever learn? The way I understand it, this comment is saying you have to prioritize and work on the highest-impact areas. Of course you grow, but until a certain point you don't benefit much from knowing the guts of git more than Framework X. I have never experienced any joy of creativity from using git, so it's not something I'm putting high on my list. Heck, learning Rust was 10x as good for my development as git, so I don't regret prioritizing that way. I expect (hope?) that most people understand the git they use in their daily workflow... but that doesn't mean they have to have mastered every dark corner. Find a specialist (Stack Overflow :) when an unusual situation arises. If it's happening consistently, then I agree some more learning should occur.

papaf 5y ago

How do we allow our culture to be so lazy that people resist using one of the basic tools because "oh its hard I gotta remember 5 commands" and we find it OK? No wonder the plane is burning. Its probably a rhetorical question but I think its worth answering anyway. Experienced developers had the luxury of learning git, say, over a 10 year period. I certainly know a lot more git than 10 years ago. If you are a new developer thrown into your first real project and Intellij handles git for you so that you can concentrate on being productive then learning command line git takes a back seat. I see this in many aspects of programming. One thing I am struggling with currently, is that JHipster generates applications in a user friendly way. JHipster is highly productive and seems like the future of programming BUT it means that there will be a generation of programmers that do not understand the MB of Spring Java code that is casually puked out by the code generator. Its depressing to say it, but I think not understanding the tools is only natural and is probably the new normal in this age of complexity.

thecupisblue 5y ago
>Experienced developers had the luxury of learning git, say, over a 10 year period. I certainly know a lot more git than 10 years ago. The depressing thing is I'm not talking just about off-the-shelf newbies, I'm also talking about experienced devs. >Its depressing to say it, but I think not understanding the tools is only natural and is probably the new normal in this age of complexity. Yes, unfortunately, this is becoming the new normal. But what is the next "new normal" after this? More complexity and obscurity? How long can we keep building that house of cards before it collapses upon us?
- joseluis 5y ago
  the solution I believe would be to focus on creating simpler tools, and by that I mean tools with at least the same usefulness/as powerful as the ones we have now, but with much less cognitive burden, with better interoperability and composability by using simple standard data interchange formats.
  - PaulDavisThe1st 5y ago

yunohn 5y ago

This is an unnecessarily antagonistic rant, which boils down to “I know git from scratch, I’m so smart, why isn’t everyone else doing this”. Git is a very complicated, bloated command line. Frankly, most of the day-to-day can easily be done with a high level understanding and a GUI. There is no shame in not knowing the minutiae of git. The goal of being a programmer is to produce cool things, not to duel with your tooling.

thecupisblue 5y ago
I don't know git from scratch, never written it or dived into source code itself. Yes, you can write C without understanding poinnters, you can paint without understanding colors and how they mix, draw without knowing difference between 3H and 2B, use a drill without knowing which type of head is for what. But try doing it long term and you either gotta learn those things or your output will be limited and clear expression of your vision will be harder. I'm not advocating for people to learn git from scratch. I'm advocating for understanding - not low level, at least high level. And is it better to go through a "how to use X tool in Y GUI" tutorial or how to use "X tool" and then gain immediate understanding of what Y does? What if you switch GUI's? Which knowledge will be sticking?
- yunohn 5y ago
  > I'm advocating for understanding - not low level, at least high level. It sounds a lot like you mean low-level, not high-level, though? There’s more than enough to be achieved by just knowing the tree concept of git, and using a GUI to visualize it while running the basics - checkout, commit, branch, rebase, etc.
  - thecupisblue 5y ago
    >There’s more than enough to be achieved by just knowing the tree concept of git, and using a GUI to visualize it while running the basics - checkout, commit, branch, rebase, etc. Oh, that's exactly what I meant. At least basic, high level understanding of the git model and basic operations on it. But most people never even get to rebasing or try do understand what lies behind magical buttons in the GUI.

wpietri 5y ago

This attitude mystifies me. The whole point of computers is to solve problems well enough that most people don't have to understand the machinery. It is literally impossible for us to understand how everything we use works. We expect a compiler to just compile things and work; nobody is ranting about how modern developers are lazy because they can't hand-verify the compiler is outputting the right opcodes. Nobody is ranting about how web developers are lazy because they can't debug a browser runtime and its interface to the OS's rendering primitives. Can some people do those things? Sure. Do we imply character flaws for the 98% of developers who have focused on other things? No. If this old-man-yells-at-clouds, good-enough-for-grandpa-so-its-good-enough-for-me style were the dominant approach in our industry, we'd still be working with punch cards and fanfold printer output. Thank goodness it isn't. Instead of having a million developers adapt to git, git should adapt to the million developers and free up their time for doing something that actually matters to a user.

thecupisblue 5y ago
>Instead of having a million developers adapt to git, git should adapt to the million developers and free up their time for doing something that actually matters to a user. How should git adapt? Can you get a simpler model than this? Is really a basic structure like a tree so complicated millions of developers are having a hard time with it? Nobody is advocating for "dont use new stuff, old is betteer". Nobody is advocating for people to hand-check compiler outputs (unless your analogy pertains to people who work in a GUI tool that shows them pretty pictures for opcodes and they check if the pictures match). You've missed the point. The point is "try to understand the basics of the tool you are using". If me wanting people to learn and understand more makes me an asshole, so be it. I'd rather be an asshole and help people learn more and understand more than coddle them in the safety of the pretty buttons and say "it's ok, you don't have to understand". If we don't understand our tools and the problems they solve, how will we make progress? How will we make better tools? How will we make better software? How do you learn and grow if not by understanding what you don't?
- wpietri 5y ago
  One way it could adapt is by doing exactly what this article is talking about: Giving commands for common operations where name and behavior matches user intent. That you can't tell the difference between "let's make software more usable" and "nobody should learn anything ever again and just soften into blobs of undifferentiated protoplasm" seems like a you problem.

AnthonBerg 5y ago

Might I ask what those git problems are? Thanks!