Developer Speak
Expanding your conversation through vocabulary no one ever taught you.
Below is a list of terms, phrases, and concepts I have found useful but nothing that would have come up in my coding boot camp; I hope you find them helpful.
Legacy Code
Source code that is no longer updated or supported. This can include old code maintained as part of a more extensive system and, therefore, kept running because "we don't know what will break if we turn it off."
It seems funny to put this one at the top, but it is important to me because I spend much of my time with legacy code.
Action Item/s
A task/s that is created from a meeting or conversation that helps you move toward your goal.
I've often found it helpful to ask at the end of a conversation, "So what are our action items then?"
STAR
Situation — goal or context of work
Task — what needs to be done to reach that goal?
Action — how do we go about meeting that goal?
Result — what is our expected outcome?
This is a great way to assess work that needs to be done.
Code Churn
The rewriting or deleting of code shortly after being written.
This is often poorly written, poorly planned, or instant legacy code.
Undifferentiated Heavy Lifting
Undertaking a complex or time-consuming task to create functionality that may exist within a previously established tool, ultimately providing little to no constructive or competitive advantage.
When we take on such takes, they often result in code churn.
Example: Writing a function that provides the same results as a Higher-Order Function provided within the coding language you currently use.
Promotable Tasks
A skill or work directly related to the unique skill set you were hired for.
Context Switching
Rapidly shifting between various and unrelated tasks.
Cognitive Load
The amount of information a person can process to complete a task.
When the cognitive load is too high, people are unable to retain and process all the information needed to complete their tasks.
Our cognitive load is often reached rapidly if these are not promotable tasks or if we are required to context switch regularly.
Personal Velocity
Velocity is an agile term determined by adding up the estimated time and effort required to complete stories during an iteration.
When we refer to personal velocity, we mean what we can contribute within a set period. A number of factors can impact this, but it should also account for the cognitive load required for that individual and any personal life impacts.
Radical Collaboration
This is a principle that people with different backgrounds bring their distinctive perspectives, technical knowledge, and human experiences to the team. Bring about empathic and unique solutions, Ultimately creating a more versatile product.
Competencies Matrix
A rubric that provides guidance on the specific skills, knowledge, and abilities expected of a position. This can help inform where you currently are on your career path within your organization or provide an understanding of your job requirements and duties.
A good competitor matrix will also provide a roadmap for growth. Requesting a copy at the start of your job will make your life much easier. I've even known organizations use this tool to build out an MVP instead of a person's job.
Knowledge Silo
This phenomenon occurs when individuals or teams possess valuable knowledge, insights, or competencies that are not shared or accessible to others. This leads to a lack of cross-functional collaboration, hindered communication, and inhibited learning.
Documentation and peer reviews are a great way to fight against knowledge silos.
Information Bubble, aka "filter bubble."
Being isolated by your own information/knowledge prevents others from providing meaningful input.
Sometimes this is related to your position, or the information you have access to.
I've seen this create difficulties for developers since they are looking at everything through their specific filter and not seeing the larger context of the problem. An information bubble is different from a knowledge silo, but one can exacerbate the other.
5 Whys
This is a problem-solving technique in which you ask "why" five times to explore the root cause of the issue.
A better phrase for this can be "5 Questions"; they don't have to be specific why questions, but they should drill down into the specifics of your issue to determine where the problem is coming from.
Gravity Problems
A problem that you have little to no control over, and this is inactionable.
If you are dealing with a gravity problem that fundamentally cannot be changed, you are more than likely trying to address the wrong problem, and you may need to dig a little deeper to find your root issue, maybe by using the 5 Whys.
I came across this phrase in Bill Burnett and Dave Evans' Designing Your Life. I highly recommend it.
Goodhart's Law
When a measure becomes a target, it ceases to be a good unit of measurement.
In other words, you need a clearer understanding of the problem you are trying to solve. Without a good concept of the actual goal, you will create a poor measurement of your success. In other words, if you don't know what you are trying to achieve, you only measure for failure.
Proximity Bias
When people in positions of authority show favoritism or give preferential treatment to employees who are closest to them physically.
In the wake of remote working, this has become a serious issue and something we should all consider.
Interoperability
The ability to use one thing with something else.
Example: Using a USBC on multiple pieces of hardware.
There are rules that go along with creating something that is interoperable:
- They have to be administrable and cannot constitute a capital barrier.
- Rules cannot be cheated on.
- The right to exit.
Feel free to read more on this from Corey Doctorow.
The Internet of Things (IoT)
The collective network of connected devices and technology facilitates communication between them and the cloud, as well as between them.
Example: Your computer talking to your printers.
Ideally, your IoT will incorporate the principles of interoperability.
Ubiquitous Language
When discussing a domain and using a term, you use exactly the same term; we mean precisely the same thing.
This one trips people up a lot, especially when dealing with highly technical people with very different backgrounds. Every job I've ever had required me to learn a new vocabulary. Using the same word can have a different meaning. This is the difference between having an explicit understanding versus an implicit understanding. Ensuring everyone is using the language to mean the same thing saves time, money, and effort everywhere.
This goes beyond the programming language you are currently working in. This is the product, application, or functionality you are trying to create.
Well, that's all I have for right now. I hope you find these terms useful in your future conversations.
