Teaching is not easy, especially in the technical space. There are so many acronyms, standards, and conventions that it’s easy to get lost in the jargon. “When sampling a signal from the continuous domain an ADC is used to convert the signal into the discrete domain. The higher the bit rate of the ADC the less quantization error occurs.” Ummm… What? Unless you have some exposure in electronics, chances are you don’t know what on earth is being said here. Your career may not expose you to such details. So, to you, it’s another language being spoken. Have you ever considered how you translate the details of your labor to your non-technical peers at work? I remember the days of sitting at college in a computer science lesson, glancing at the teacher with a look of discontent. It wasn’t because I didn’t want to be there. I did. The problem was that the teacher was trying to explain a programming language. It was the first time I was exposed to what seemed like reading hieroglyphics in the tomb of Seth-Peribsen. You see, the problem was that this lecturer was trying out teaching for the first time. This teacher had a solid twenty years in the industry and knew how to get the job done. The problem? The transfer of knowledge between the teacher and us students was like trying to pass water through a blocked pipe. You’d think with all that experience it would be a breeze. We were tasked to create a simple game using Java. We had no idea what was going on because it was assumed we just ‘got it’. It’s easy to climb the technical knowledge ladder and forget to lend out a helping hand to the people below you. For a teacher, they need to be prepared to jump down to the ground and start from the very basics. Okay… maybe not jump as that goes against health and safety. Metaphors are a great way to explain certain concepts if someone actually wants to understand something. “So, what is the difference between HTML, CSS and JavaScript? I never understood the difference.” “Let’s say you were building a new shed in your back garden. Think of HTML as the foundations, the panels, the door and the roof. When you want to decorate it, add finishing touches and give it a fresh lick of paint, this is where CSS would come in. But what if you wanted to add some interaction to the shed. Whenever you clap, the door opens or closes. This is where JavaScript would step in.” Teaching is not easy, especially in the technical space. There are so many acronyms, standards, and conventions that it’s easy to get lost in the jargon. It’s also very easy to ‘assume’ that the non-technical people you are speaking with understand what you are talking about. Chances are — unless spoken in layman’s terms — they don’t. It is always good to speak in a common language so that communication doesn’t get interpreted the wrong way. Misinformation can lead to problems later on down the line. Think about the times you are in a meeting with your team. Teams these days are usually broken up into different areas. You may have a product owner, a business analyst, quality assurance testers, some backend engineers and frontend engineers too. Each of the roles — minus yours — have their own expertise that they understand more than you. Well… I would hope so. When you communicate what you have been doing to the other professions, you want to speak in the same language. Create that meaningful bridge so no-one is left politely nodding. Consider this conversation between a front-end engineer (Steve) and a non-technical product owner (Fred). “Well first, I will need to make an AJAX request to the customer service endpoint, then retrieve the JSON payload back. I will need to iterate the results to find the index of that customer, and then render it using the Customer Details React component,” said Steve. “Right… thanks, Steve,” said Fred. Yes, Fred is secretly a pug. That exchange was too verbose and brings little value to the conversation. Try and come down to their level and keep it short and sweet. “Well, first Fred, I need to fetch some information from the customer service and then display it on the customer details page.” The example is contrived but demonstrates an important point. They explained what is needed in one sentence. Going into the details about making an AJAX request or creating a component doesn’t add any value. These details should be left for the technical discussions between the engineers. A daily stand-up is a very meeting with your team to explain: what you did yesterday, what you are doing today, and is there anything stopping you from doing your job? (blocking). See the emphasis on brief… this means you should not go into a great detail on the work you did yesterday or doing today. If this happens, usually someone will step in and tell you to ‘take it offline’, meaning you should have this discussion outside of the stand-up ceremony. brief “I was having this problem unit testing the sagas for the payment component yesterday. I didn’t understand how the generators worked at first, then realized I had to trigger the next function to get the next value. I will refactor it a bit as I’m not happy with it in its current state. The configuration from the other team is implemented in a way that…” You get the idea. Instead, consider simplifying your update like so. “Yesterday I made good progress on the payments screen. I plan to finish it today but cannot deploy it until the configuration is done from the other team. I will then move on to the dashboard. That’s my update.” This update is short and sweet, signifies to the team that we need to resolve a problem that is blocking us from another team. This can be chased up in parallel with the work you are doing. Woohoo! Spend less time in meetings, and more time actually getting things moved to ‘done’. Thanks for reading, drop a few claps and follow me for new posts! Shaun Michael Stone.Follow and reach out to me on . Twitter
