[phist_mcgee]

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.

[Kinrany]

I don't think going top down like this works.

You can use top-down knowledge to inform yourself on what concepts you need to learn, and you can ignore the parts of the domain you need right now. But you still have to learn them bottom up. Getting confused by the concepts you're using is a gigantic waste of time.

And the harder the concepts, the easier it is to get confused, so there's no trade-off.

[thecupisblue]

> 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]

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

[tester756]

I use GUI because it's infinitely times easier for me to check what changes I've done and to rethink them e.g trying to spot a stupid bug

>With that mentality, what do you ever learn?

>Where is the joy in that? Where is the growth?

>Are you always in a rush to deliver software without a moment to think?

There's nothing sexy about learning git commands for me

I'd rather spend that time on actual computer science fundamentals or even reading stuff like HTTP RFC than learning git quirks