Tech Terms to Know

Today's post will be dedicated to a few terms and phrases that are software, development, and tech specific. I was inspired by this tweet where Gergely Orosz, author of The Pragmatic Engineer newsletter (if you haven't checked it out, I highly recommend it), asks what terms many software engineers understand, but can confuse people outside of tech.

I related to many of the replies, as I was so confused by terms like production and staging on my first day as a junior developer.

Live footage of me on my first day:

Of all the terms mentioned, here are my favorites:

• Rubber Ducking
  Rubber Ducking is a term often used when talking about debugging. The term rubber duck debugging comes from a book by Andrew Hunt and David Thomas called The Pragmatic Programmer. In the book, the authors describe a programmer who carries a rubber duck around and debugs their code by explaining it, line-by-line, to the duck.
  
  While the practice of talking to a rubber duck may sound silly, its actually proven to be a helpful strategy for finding and solving problems with code.
  
  

• Daily Standup
  Daily Stand Ups are part of the Agile Software development process (and SCRUM). They are usually at the same time every day and can cover topics such as what you accomplished the day before, what you plan on accomplishing that day, and blockers.
  
  

• Blockers
  Something preventing (blocking) you from moving forward with a task, often code-related.
  
  

• Do a Git Blame
  A git-blame is used to show what revision and author last modified each line of a file. It's like checking the history of the development of a file. More formal definition from GitHub:
  
  The blame command is a Git feature, designed to help you determine who made changes to a file. Despite its negative-sounding name, git blame is actually pretty innocuous; its primary function is to point out who changed which lines in a file, and why. It can be a useful tool to identify changes in your code.
  
  

• Lead the Postmortem
  A post-mortem is when a team reflects on a project, how it was executed, what went right, what went wrong, how to prevent mistakes, and how to do better next time. I've heard this phrase used outside of tech many times.
  
  In my opinion, postmortems are really a helpful exercise regardless of industry. Oftentimes, someone is chosen to lead this, therefore leading the postmortem. I love this article from Free Code Camp on what postmortems can look like for software.
  
  

• Technical Debt
  Technical debt is the term used to describe the result of making decisions based on speed above all else. These quick, real-time decisions can make or break software updates. But there should be a balance between good decisions and fast ones. Technical debt can result in negative outcomes or be well worth itdepending on what you and your team decide.
  
  

• Spaghetti Code
  Spaghetti Code is a term used when describing unstructured and difficult-to-read code. Spaghetti Code can lead to problems over time, as it's often tricky to build on top of. If not resolved, it can lead to folks spending time and energy fixing and finding bugs due to the lack of structure in the code.
  
  

• Kill All
  killall is a tool for terminating running processes on your system based on name. You can run it like this:
  
  killall [process name]
  
  

• Development (aka Dev)
  Commonly referred to as dev, this is where developers build the code. For example, your company may have a 'dev' version of the site where you push up code for review.
  
  

• Staging (aka Stage)
  This environment is used to test the software using real data to validate it is ready for use. For example, your company may have a 'staging' version of the site where you push up code. In my experience, this step comes after testing code on dev.
  
  

• Production (aka Prod)
  Commonly referred to as prod, this is where the software is made available to users (aka friends, family, the general public, etc.)
  
  

• Ship to Production
  Shipping to production essentially means pushing code live to where it is available to all users. However, this can happen differently depending on your company. I love this article from Gergely Orosz on the different approaches to pushing code live.
  
  

• Cut a Release
  Cutting a release means taking the state of a code base, project, or repo, and locking it down so no further changes are made. This state is then given a release name and/or release version.
  
  An example would be how different versions of operating systems are released for your laptop or phone. Releases are helpful because when consistent versions of the software are given to users, it is easier for them to ask for help based on what version they are using.
  
  

• Change List
  New features and/or fixed bugs that are new from one version of software to the next.
  
  

Comment down below with any of your favorites!