What are they talking about? Technical vocabulary basics
Tech, localization, and global strategy - decoded.
Have you ever had a conversation with a "technical person" and felt like they were speaking a different language? Maybe you felt uncomfortable asking them every few sentences to explain what a phrase or word means (you shouldn't!). I've been there and over the years I've built up a basic understanding and vocabulary that allows me to decode what my more technical partners mean. I wanted to start a mini-series to help you get started on the same path. Each edition will feature a group of words, concepts, or phrases and give you a breakdown of each one. If you have suggestions for additional themes/words/phrases for this series, let me know and I will work them in!
Remember, drop the phrase “I’m not technical.” Instead say: “I’m building my technical skills.” Approach all of this with curiosity instead of intimidation and you will find that it makes a lot more sense!
For this edition, I wanted to talk about git, GitHub, code repositories, versioning, branches, PRs, production, etc. If you work in tech I'm sure you've heard these words and you may know what many of them mean. BUT I MADE YOU A PROMISE! I told you this series was for beginners and I mean it. I want anyone to be able to pick up this series, learn something new, and feel like they are growing their technical skills and understanding. So today we are starting with some basics:
Code Repository, Repository, Repo: This is just a fancy way of saying a place where code is stored. Think of it like a folder that keeps all the code files, but with extra features to help keep track of changes and versions.
→ Example: "I uploaded the new feature code to the repo, so you can check it out."
Git and GitHub (and what's the difference?): Git is a version control tool which means it's software that tracks changes (and/or “versions”) in your code. GitHub is a website (and a company) that lets you store Git-tracked code online and makes it easy to share with others. So GitHub is a centralized “hub” for Git.
→ Example: "I’m using Git to track my changes locally, but I pushed the project to GitHub so we can collaborate."
Versioning: This means keeping track of the different versions of a file or project. Like saving different drafts of a document but for code. With versioning, you can go back to a previous version if something goes wrong.
→Example: "Our app crashed, but thankfully we have versioning, so we can roll back to yesterday’s version."
Branches: These are separate lines of development for your code. Imagine you're writing a story, and you want to try a new plot without messing up the main story. You create a new branch, write your alternate plot, and decide later if you want to merge it into the main story.
→ Example: "We created a
spanish-translationbranch to update the Spanish text without affecting other languages."PRs (Pull Requests): A way to suggest changes in a code project. You make changes on a branch, then create a PR to ask others to review and approve those changes.
→ Example: "I just submitted a PR for the bug fix, can you review it before the end of the day?"
Side note: Watch a video of an engineer walking through some of these steps: How to Create Branches and Merge Changes by Swiftful Thinking (this is part of a series he did which is really great if you want to learn how to create you own Git projects)
Production/Prod: This means the live version of a website or app. So the version that real users see. This means if something is in "prod," it means it is live and available to users.
→ Example: "We found a bug, but it’s only on the test site, not in production."
Open Source: A type of software that anyone can view, use, modify, and share because its source code is publicly available.
→ Example: "We used an open-source translation memory tool, so we could add support for more languages."
Open Standard: A publicly available standard that anyone can use and implement, but it is maintained by a governing body.
→ Example: "The HTML specification is an open standard, so any browser can implement it." (note that Unicode is an open standard!)
That's just the start! Here are a few more vocabulary words and concepts that I think could be useful:
Commit: This means saving your changes in Git. Think of it like taking a snapshot of your progress.
→ Example: "Don’t forget to commit your changes before switching branches."
Merge: Combining two branches of code. If your experiment on a branch works out, you merge it into the main project.
→ Example: "I merged the feature branch into main after the PR was approved."
Clone: Making a copy of a code repository on your local computer.
→ Example: "I cloned the repo so I can work on it locally."
Fork: Making your own copy of someone else's project on GitHub, which you can modify without affecting the original.
→ Example: "I forked the open-source project to add my own features."
Fork vs. Clone: A fork is your own independent copy of a project on GitHub, which you can change without affecting the original. A clone is a direct copy of the project on your local computer, which stays connected to the original and can be updated.
Remote: This is the online version of your code repo, typically on GitHub.
→ Example: "Make sure your local code is synced with the remote repository."
How These Pieces Fit Together
Ok, now let’s say that you're working on a website project with a team:
You create a repository on GitHub to store your project files.
Each team member clones this repository to their own computer to work on it locally.
If you want to add a new feature, you could create a branch, so your changes don't disrupt the main code.
You would make your changes, commit them (saving them), and then open a Pull Request (PR) asking your team to review.
Once your changes are approved, they would be merged into the main branch.
When the project is ready for users, you would deploy it to production (prod), making it live (hooray!).
Woohoo, that's it for this first edition! I hope this gives you a clearer understanding of some of the most common terms you'll hear when talking with engineers/developers at your company. Do you have suggestions for other terms you'd like me to explain? Let me know!
Too basic? Ready for More?
If you felt this was too basic, that's a good thing because it means you're growing your skills and you’re ready to level up! Here are a few ways you can continue building your knowledge and challenging yourself:
If you want to do something more in depth and hands on, try out W3 school’s free Git Tutorial and learn how to create your own project, experiment with issues, pull requests and code reviews.
If you prefer a in-depth video guide/tutorial, I recommend The Net Ninja's Git & GitHub series
Practice using Git from the command line instead of a visual tool.
Contribute to open-source projects on GitHub to get real-world experience.
Explore Git advanced commands like rebase, cherry-pick, and stash.
→ Looking for more ways to grow your technical skills? Check out my free in depth guide on how to prepare for more technical roles which contains a ton of great learning resources all vetted by me!
What’s Next? And subscribe for Deep Dives + *even more* focused resources
Next week I’ll release May’s Deep Dive for paid subscribers teaching you how to build business cases for LARGER engineering initiatives so that you get the resources you need! I will walk you through how I’ve done this in my current and past roles, and include one of my personal templates that I’ve developed. Subscribing is the cost of grabbing me a coffee, and it helps justify me spending a few Saturday afternoons creating these structured lessons.
The first week of June I’ll be at LocWorld Malmo presenting a talk on How Localization Teams Can Use Unicode to Solve i18n Issues, if you are there please come and support my talk, say hello, and (hopefully) learn something new!
If you aren’t at LocWorld, don’t worry, I will still be publishing a new article that week on How to manage up (a game changer).
And the second week of June I will publish an interview with a Unicode Engineer, ahhhh!
If you are enjoying this series let me know in the comments and/or connect with me on LinkedIn!
Thanks a lot Hilary for this article. It took me a few years working alongside engineering and product teams to get a hang of these terms.
I would suggest you can add "Staging" in your workflow of explanation as that's the phase right before production, where most of the QA and other verification's take place before the code gets pushed to "Production".