The hardest part of my first 3 months as a web developer
Intro
Finally landing my first real web developer job was an amazing accomplishment. After 1 year of self directed learning and a decade of wishing I was a developer, I had finally done it. The only problem now was that I had to start this new job as a professional coder and be able to keep up.
Before my start date I studied extra hard in an effort to try and fill
any gaps in my knowledge. I finally got around to using those weird
React hooks that I was too afraid to use before like useRef and
useContext
I read blog posts by Dan Abramov
from the React team. I tried really hard to try to cover all my basis
before day 1 on the job. In reality I had no idea what I needed to
spend my time learning. Once actually starting the new job i was hit
with very different things. I wasn't so caught up in writing really
cool React code, although there was some of that.
The #1 thing that I've spent my time doing is working out how to use Git in a large project.
Git is one of those things that you cannot really do on your own. Coding is a team sport and you need everyone else to contribute to really understand git.
Before starting this job I used Github with all of my personal projects and had what I thought was a pretty good idea of how to use it. Sadly, I could not have been more wrong. When using Git in a large project there are several things you have to consider, all of which I'd never put much thought into.
#1 CI Issues
There was the CI (continuous integration) issues (check out this video if you want to learn more about CI/CD or just learn what it is). In my work Github project there are several steps and checks you must pass before a Pull Request is able to be merged. Things like tests, CircleCI, Storybook the list goes on. If any one of these fail you need to go into the logs within CircleCI and start trouble shooting. This was super time consuming for me. Each of these CI checks is it's own rabbit hole that can a while to learn.
#2 All the commands
Merging, Rebasing, Cherry-picking, oh my. I'm just going to lump all these and some other that I did not mention into one category. I only really knew what a commit was. I never really understood what a merge was, and I don't think I ever even heard of rebasing before starting the job. cherry-pick became my best friend after someone helped bail me out after I borked up my branch.
#3 Pull Requests
Pull Requests or PRs. Some things I think experienced people take for granted is how to behave or communicate within a PR. It was pretty stressful having to learn what to do when people commented on my PRs.
Pretty early on I received some pretty harsh feedback about my changeset on a pull request. It was super defailting! But I used that energy to learn what the heck a changeset was and the best way to write one.
#4 git checkout -b 'cool-feature'
This could be it's own blog post, and maybe it will be someday. Using the command line with Git. It's really hard, especially if you don't know much about the command line (like me). This is still something I'm working on.
Git-ing over my weaknesses
Tips for anyone wanting to sure up their git skills.
You're reading the wrong docs
After finding myself on the official Git docs. I found myself more confused and frustrated then when I started. For example check out this page on rebasing. I know the information in there is good info, but something about that page makes it hard for me to learn from. That said, I'd recommend checking out the Atlassian documentation here. I found that these articles not only read better, but the UI feels better. Let's just say, one has pictures, and the other one does not š .
GitKracken
GitKracken is a application that provide a GUI for your Git repos branches. It also allows you to do all the things you'd normally do using the command line but in the GUI.
This was super helpful for me to see the changes I was making before pushing them. This gave me confidence to know the rebase or merge was doing what I think it was doing. I must say that this too has it's own learning curve but I think a GUI for git is a really useful tool to look into.
As I've gotten used to GitKracken I'm wayyy more comfortable doing interactive rebases (I did not even know what that was a few months ago), creating PRs, and doing everyday Git stuff right in GitKracken.
One downside of using a tool like this is that it may become a crutch. As in it may prevent you from learning how to use git via the command line. Personally, I've found that GitKracken has only improved my knowledge of Git and helps me use the git commands on the command line better.
I can't recommend using GitKracken enough.
Learn Git Branching
Learn Git Branching is another git visualization learning tool. It's like a little course that goes through all of git's features. I found this to be a great primer for all things git. It introduces you to all of the different features. I found myself coming back to this a few times to test some cherry picks and rebases before doing it in my real repo.
Another honorable mention is Git School. I find the UI to be cleaner than learngitbranching, but they're pretty similar.
Keep a changelog
If you're interested in learning more about changelogs check out this page.
Conclusion
If I could go back to the time before I as working as a developer, I'd spend some more time learning git. It was something that I did not know that I did not know.