"Toxic" was the correct word choice. Thanks.
Programming
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
One of the best tutorials on really "grokking" git
concepts, and it's online and interactive: https://learngitbranching.js.org
For programming, start with buildings things for yourself. Be practical, start small, and iterate, regardless if you consider the previous iteration was a success or failure. I've heard good things about https://automatetheboringstuff.com/ (in Python) in this regard.
Start with a git GUI application. I use git extensions on windows.
You'll be able to get a feel for how it all works and it actually shows you the commands it's running.
I also use bingai a lot when learning. The more specific your question the more likely you are to run into hallucinations and that. But for explaining basic concepts or query things that are well documented it's really good.
It also sources it's answers so you can follow the link for further reading if needed.
Just don't trust it to generate large amounts of code.
I'm trying to understand Git, but it's a giant conceptual leap.
To start with, start with just using git locally. Don't worry about GitHub or similar. Then git and SVN will work very similarly. The main difference is that you need to git add
files with changes inside before you commit them.
Once you're comfortable with using it by yourself, then I suggest running something like forgejo
locally to be your own code server. Then you can play and learn how the two parts work together.
Generally, you need to give yourself a little time. You need to do the work. Be efficient...sure, but don't try to force it to be quicker than the time you need to learn.
I guess, what I’d like to hear from you all is a way to jump back in as quickly as possible in such a way that it may be a career.
You might check job listings in your region/country to figure out what languages and technology stacks are in high demand, as where you are seems to matter a lot.
As for git, many basic concepts (e.g. staging area) clicked for me after reading some articles that Atlassian (people behind BitBucket) wrote. Other than that, I'd recommend adamj.eu 's book "Git DX" which is on gumroad. Haven't read it, tho. But I read his Django DX and like 90% of it was stuff I had to learn on my own, and thought: oh, how come I didn't find this book earlier...
Just remember: imposter syndrome is real. Everything you learn exposes you to ten things you don't yet know. Successful devs are comfortable with this reality - the job is one of constant learning. Best of luck!
You said it. I spent the first six months at a FAANG convinced that everyone could look at me and instantly tell that I didn't belong there. Glad I was able to flip my thinking on that one.
Just use a good GUI tool for git and Google how to do stuff with command line when needed, you'll eventually pick it up. Chatgpt and it's ilk can also be helpful with figuring out things when Google fails.
Get a book on Spring Boot and jump back inro Java web development.
With git, you don't need to master it, just find some subversion to git howto and start using it. It's half a page of text. Once you learn the basics you can learn more as you go. There are many otherwise competent programmers who don't know git too well, I know because I support them from time to time.
I’m trying to understand Git, but it’s a giant conceptual leap.
In that case, I suggest learning Mercurial first. Its underlying design is very similar to Git, but the interface is more consistent and does a much better job of presenting the concepts to humans (especially those already familiar with traditional version control). Then, once you're comfortable with the concepts and commands in Mercurial, learn Git, since it's everywhere nowadays.
Consider learning at least one new language, if not immediately (since you're in a hurry) then in your free time. Java is only one of many (and not even a particularly nice one IMHO). Try to find a language that you enjoy using; your programming life will be better for it. If you want something flexible and productive, consider Python. For more structure than that, maybe Go. If mobile apps interest you, there are Kotlin (Android), Swift (iOS), and Dart (both). If web development appeals to you, along with lots of job openings and lots of competition for those jobs, JavaScript. If you fancy the esoteric (and well-paying), Elixir and Erlang are worth a look. Lower level languages are in demand as well (e.g. C++, Rust) but they come with various kinds of pain that I wouldn't recommend to someone in your situation.
Above all, please make sure you're reserving time for things that make you happy, sleep, and (if still possible) some kind of exercise. Your own physical and mental health are important. If you endure a bad working environment or wear yourself thin for too long, you will burn out, which won't help you provide for yourself or anyone else.
Take care, OP.
It sounds like you already have a foundation to build on. If suggest using chatgpt or something similar to explore concepts you struggle with. "explain git to me as if I knew SVN 10 years ago but have forgotten a bit"
Best of luck to you!
I’m trying to understand Git, but it’s a giant conceptual leap.
Git is not that different from svn (I mean, the biggest hurdle is going from a shared folder to any version control system)... I'd say the main difference is that branches live in a different namespace than files (ie. you don't have trunk/src/whatever but just src/whatever in the main branch). On top of that there's that commit and push are two different things (and the same with fetch and checkout) and that merges are way easier than in svn (where you had to merge stuff manually).
If you create a repo locally and clone it twice in two different directories, you can easily simulate what would happen when you and a coworker collaborate via a centralized repo (say, github) - do a few experiments and you'll see it's not as complicated as it seems (I'd recommend using the CLI instead of some GUI client: it's way easier to figure things out without the overhead of learning to differentiate between git concepts and how the GUI tries to help).
To piggyback, the true main difference is svn stores commits as snapshots and git commits are deltas from previous. This is why git is depicted as a tree since it's inherently a node-based structure.
A git commit is a snapshot. The node-based tree structure is an artifact of recording pointers to other snapshots and labeling snapshots with a branch name.
You are correct. Technically a snapshot, but unmodified files are not duplicated from the previous. Imho that is one of the key things to understand about how git works ( and why rebasing and branch manipulation works so well)
If it's a motivation issue, you will need to figure it out on your own. I could give you some advice but motivation depends on a specific use case. If you want I can share what motivates me but there's no guarantee it will work for you.
As for getting back on a tech horse, there's a trick I've been using every time I was learning a new thing and it worked every single time. I start with a project idea. I write down the major goals I want to achieve and start working on it. At first I do the "quick start" adjusted to fit my project. It usually ends up with a working proof of concept and a list of things I don't know/understand. Next, I learn about the those unknowns and update the project with what I have learned. This raises more unknowns which leads to more things to learn about. After few iterations, when I'm happy about the project, I start a new, more complex project. And so on.
First of all, you can totally do it! The field is massive, but also full of very bad programmers, and seeing how you were able to write a coherent text of three paragraphs, that already puts you ahead of the curve. Determination and perseverance is key.
I would suggest to play to your strengths. Java is still Java. Most of the progress since the 1990s was in the libraries and tooling, which only recently have become passable. The language itself also evolved somewhat, but there's nothing that you won't pick up in a couple of days of working with it.
Start with [1], work through all the boxes that are unfamiliar to you, practice a little on a pet project, or an open source project, and you'll land a job in no time.
Also, if you remember enjoying hacking, maybe pick that up again? There's a massive shortage of security engineers at all times.
My personal recommendation:
-
Pick up Python, it's easy to learn and highly productive. If you also learn fastAPI, you can benefit from highly validated, declarative models to build REST APIs in the backend, well fast. It will yield quick results, you won't become demotivated and you can pick up a paid project soon.
-
Pick up Rust. It's "in" right now and I get requests from marketing people that know nothing about programming, asking if their project could be implemented in Rust
-
Go with memorizing the shell commands first, try to understand git later. Get productive, try to get where you were with e. g. svn or cvs. If you are comfortable, look at something in depth if you have a problem that you can't solve with the knowledge you have.
-
Fuck Java, seriously.
-
You have commercial interests, so it is probably wise to look into becoming a fullstack dev to maximize the kind of projects you can do. Look into React, vue.js, svelte. React is probably still the most widely used framework, you'll quickly do a project with vue.js and svelte is a super interesting look into things to come.
Fuck Java, seriously
Toxic...
You can find a lot of good work doing Java.
Side note: please don't abuse the word "toxic" until it becomes absolutely meaningless. Let's keep that to a more fitting context, having a
I was expressing an obviously personal opinion about the language itself, which is objectively a dull, barren wasteland that sucks out your soul while you walk it. That is precisely the reason why it's so widespread and loved by business entities and managers - there is no excitement, no surprises, just an everlasting monotony of keys clicking produced by a horde of clones wearing button-down shirts while sitting in absolute identical cubicles, creating yet another instance of FactoryProducer. It's very easy to plan and schedule for, while at the same time being unnecessarily verbose and mildly unproductive (compared to other languages).
Look, the JVM is fine, just pick another language. There is plenty of work doing Kotlin. But yes, if you're doing this only for the money, go ahead. I've always been unable to separate my job fromy personal life and my other interests, I couldn't imagine being cursed by Java again.
If you can sit somewhere for 8 to 10 hours each day, doing something that isn't fun and separate yourself from it, not going insane, all the power to you. I also get that not everyone has the luxury of picking their favorite toy and making it their job, but I firmly believe there are options that are not Java.
Now, if you're one of the rare types that actually enjoys Java, meet me in the closest Denny's parking lot, I need your cranial measurements.
Please note: this post contains hyperbole and humor. I don't hate any of you, I just hate Java
"Toxic" was the correct word choice, thanks.
Java have had very bad press lately (since the log4j fiasco I guess? maybe since before).
IDK why people blame Java for any issues with any library/project written in it... it's as dumb as blaming C/C++ for all the windows fuckups, and nobody blames php for the various cpanel vulnerabilities or python for all the shit people write in it.
I was going to say this. I hate Java as much as the next dev, but everything runs on Java. If it’s web -> Spring, DevOps -> Jenkins, Event Streams -> Kafka, Big Data -> Spark, Logging & SRE -> Flink. All of these are built on JVM based languages. I am fortunate enough to program Rust daily at my job, but my options for getting another Rust job are severely limited. Everybody always wants Java or Go. They always ask for C++ , but I’m convinced that day 1 they would have you switch to Java.
When I stopped, subversion was what we used. I’m trying to understand Git, but it’s a giant conceptual leap.
It's probably not 'that much of a leap' as you imagine. If you're looking at Git tutorials, they're usually covering all kinda complex scenarios of how to 'properly use Git'. But a lot of people barely care about 'properly using Git' and they just kinda use it as a substitute for SVN... You create branches, you merge them back and forth, and that's about it.
Like if you want to contribute to an open source project, all you have to do is create a fork (your own branch in SVN terms) - commit some stuff to it, and create a pull request (request to have your changes merged) back to the original branch. git pull
is just svn update
- getting someone elses commits
Not saying there aren't more complex features in git, just saying, I don't think you have to see it as a 'giant conceptual leap' that's preventing you from jumping back into programming. Easiest approach would probably just be to download a GUI like Sourcetree or Fork, and just kinda pretend you're still using SVN - approach wise
So the big important part of git is that it's a collection of commits. A branch is just a labeled commit and each commit is a list of what changed from the parent. Rebasing (the most confusing one for people) is when you fiddle with a commit from underneath yourself. Or in even more simple terms editing a parent commit. Rebasing is extremely powerful but most useful for when you notice a bug you wrote a couple commits ago. Fixing such issues via rebase (or !fixup
commits you auto squash at the end) keeps your history clean. It's as though you never wrote the bug. The other thing you do a lot with rebasing is moving your branch up in the history cause somebody updated the remote.
I mean, this could be useful, but I need a much higher level of understanding. When I was a dev, all we used was basically version control. There was no concept of commit, pulls, etc. I'm having to understand this from a standpoint of no understanding whatsoever. For most devs, they've done this for at least a decade with Git. Git is so much more complicated than a simple version control. I understand why it's necessary for large teams, but I still see it lke this:
You likely have a mental model of Subversion, so what I would suggest is to try to forget as much of it as possible first, as Git is very different.
Take a tutorial that is aimed at Git beginners, e.g. [1]. This will help you start building a new mental model as well as get first practical experience.
After that, read the official docs starting wtih the object model[2]. The reason why many people struggle to get into git, especially after using other VCS, is that it was built from the ground up, without much regard of the established conventions and terminology. Linus Torvalds once mentioned that he used his experience designing file systems when developing git.
So the object model of git is very simple, but also not intuitive. However, once you understand it, everything will start making sense, including the xkcd you've linked.
[1] https://gitimmersion.com/ [2] https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
You've linked into it, but I was just going to point at the Git book: https://git-scm.com/book/en/v2
It's an afternoon's reading; it does an excellent job of giving you the right mental model - and a crib aheet of commands to navigate it.
Someone will probably shoot me down for this but I actually find ChatGPT good for explaining concepts to me. Especially when I just want a high level understanding of a concept as I try to understand another one without getting too bogged down. A lot of Google results go into way too much detail.
A few months back I would have said the same. Lately, however, ChatGPT very often returned very incorrect information on very basic topics. Each wrong answer erodes my trust a little bit more. Lately to a point where I consider googling first instead of asking ChatGPT
It's great for explaining entry level information on a wide variety of topics. More advanced / obscure topics are more prone to hallucinations. I used it to learn React and it was a great introduction.
I’m doing this now as I learn Unity and come back to C# after a couple decades away. It’s great for helping with syntax and reminding you of libraries, also with debugging steps as you mention. I haven’t had it full on hallucinate, but it has given me suggestions that fail to do the thing I specifically asked it for. I also went down a couple rabbit holes following its suggestions to later realize there was a much simpler answer that it didn’t tell me about. All in all, I’d still highly recommend it for my situation and OPs. If you’re able to follow the logic and point out the flaws, it’s a hell of a lot faster than googling or following tutorials.
It’s also great for solving issues when you’re stuck. Not because of its superior reasoning skills but it can solve beginner issues and write you a list of things to try when it doesn’t know the answer right away. It’s like a rubber duck that will talk back.
Did you use Spring back then? It would be a useful thing to learn. Might as well see if you like to do frontend things such as React / Vue
Yeah Spring wasn’t 1.0 until 2004. We had XML files upon XML files just to describe one single Java “Bean”. I did java programming from 2001-2002 and the again from 2011-today. Things dramatically changed (framework-wise) in that short decade I was away from it.
I would agree, Spring Boot and Spring are very useful to learn. React, despite having its origins in Facebook and still with Meta’s hands on it, is a good web framework especially if you use it with Typescript.
No, we didn't use that. I did both front end and back end in a sense. I developed the web UI for the customers and managed the PHP and SQL back end since it was purely a web interface. Yeah, yeah, I know that's not true back end but that's where we were at that point.