The right path to knowledge transfer in software development
Often, development companies will face multiple changes inside the organization, whether it’s about new projects, shifting developers from one project to another, or employees leaving or coming, one thing is for certain. A proper knowledge transfer management system has to be implemented to turn these changes into a positive experience led by progress and not regressing. Knowledge, observed from multiple perspectives, is one of a software development company’s greatest assets. But, how you manage it and utilize it, is how you create cohesive and successful teams. Prioritizing knowledge transfer should be on your to-do list to allow for smooth transitioning and to minimize knowledge gaps when changes occur inside your company. What actually is knowledge transfer? Knowledge transfer is the process of relaying or transferring information, advice, procedures, and know-how between members of your team. It’s the act of ensuring each team member has the targeted knowledge to understand their work better and perform tasks. This process is done in service of breaking knowledge silos and towers of knowledge. These towers occur when one person holds all the knowledge and insight on the project or the code itself. The point is to minimize the power and influence that kind of person has, in case they decide to leave the project or the company. Yes, knowledge transfer can be observed as a risk mitigation tool. If we observe software development teams, they can be best described as a unique collective. Each team has its specificities, strengths, and weaknesses. It’s a different set of relationships inside one team, so knowledge transfer should be adapted to that. But when we talk about knowledge in general we can identify two main types: explicit and tacit. Explicit knowledge This is documented information, procedures, best practices, coding patterns, and techniques one might need to perform their job. It is mostly shared through documentation, written rules, presentations, or even golden paths. They are not individual-specific, but rather a collection of, a sort of common, knowledge everyone can access. Tacit knowledge This type of knowledge is individual-specific and it represents personal knowledge one gained through experience, learned competencies, intuition, and skills. It is not as easy to transfer this type of knowledge as the explicit one since it’s linked solely to one person, their characteristics, and understanding. Methods of effective knowledge transfer The most effective way to transfer knowledge is by using multiple methods. It will be different for each company, team, or project. You must find what works best for you and use a mix of techniques or methods to achieve the best results and break those knowledge silos. Mentorships One-on-one mentorships are a great way to convey tacit knowledge. It’s usually done by assigning a senior developer to mentor a junior developer. Here the mentor can transfer his know-how from years of experience to his mentee. They can share tips and tricks, and best practices when it comes to specific types of projects or technologies. Pair programming This is an agile software development technique where two developers work at the same station, meaning on the same computer with one keyboard and mouse. They work together on designing, coding, and testing while solving a specific problem. It’s one of the best ways to transfer knowledge, but it has its drawbacks we explored in our previous blog post. Brown bag lunches As the term says, this is where everyone brings their lunch and has it together while discussing topics regarding their work. It’s an informal setting where everyone is encouraged to participate in a relaxed manner and share some valuable insights or updates on their projects or work. This has proven to be a great tactic to connect senior or high-level executives with juniors and others in the company. Documentation One of the ways to transfer explicit knowledge is through documentation. Great documentation is integral to providing insights into the code and project as a whole. If you ask any developer what’s important to them when coming onto the project, they will all say it’s properly written documentation. The only thing you must be careful about is that it doesn’t become obsolete. Documentation has to be regularly checked and updated. Otherwise, developers will have no use of it. Code reviews If you get everyone involved in code reviews, they’ll get acquainted with the whole code and how it was written. Not only will they get insight into how something works and what the project is about, but they’ll also share their knowledge and guidance on how to improve the existing code or approach. This allows senior developers to guide less experienced ones, which in turn fosters collaboration and improves code quality. Golden Paths Golden Paths are defined as an opinionated and supported way to build something. They are an explicit type of knowledge of written instructions, knowledge, and insights on how to develop applications and software. If a developer or anybody else doesn’t know how to do something, they can always consult the Golden Path for help. They are a great way to transfer knowledge since they contain anything a developer might need to know and are updated frequently. One-on-one sessions Team leaders can organize one-on-one sessions to convey expectations, and team culture and set the tone for the project. This is an opportunity for them to share knowledge, but also assess other team members in their skills. Leaders can use this to answer any questions or doubts others may have by providing their tacit knowledge. They can also gather information and updates from team members on how to raise the quality of performance and the code itself. Hackathons Hackathons have been around for a long time. A lot of teams organize them to set a fast-paced environment to produce fresh and new ideas under challenging time constraints. These events bring together team members of various backgrounds, developers, sales, marketing, and others to bring in new perspectives. It’s a quick exchange of knowledge through a competitive environment. But first… Talk to your team. An efficient knowledge transfer
Igloo small talk – Luka
Making a career switch is not easy, but this is what Luka did when he decided to switch from an economy field to web development. As a Frontend developer, he found his calling, so jump into small bits and pieces about himself, his work, and his usual work day. Tell us who you are and what you do in Deegloo. I am Luka, formerly an economist but decided to change career direction and became a self-taught web developer. This is what I do here in Deegloo and I enjoy it. What does your typical day look like? I do mostly frontend development stuff, but I don’t mind taking some backend stuff, CI/CD small changes, or maybe making some simpler SQL queries. Besides that, there are some meetings 2-3 times a week, sometimes there are other colleagues that need help so I help them and of course, there are some calls or messages with clients to explain what they actually want me to do in some specific ticket. What made you decide to develop your career in this field? The opportunity to use your mind to accomplish something. I like intellectual jobs where you have to think and solve problems. What drives you in your work? Being able to program and make functional whatever I imagine in my head. What’s the best part about your position? Always learning something new, never getting bored, and always becoming aware of how much I still have to learn but also seeing how much I have learned. What don’t you like about your work? Unorganized sprints, poorly/wrongly described tasks. What’s the biggest mistake you’ve made in your career or what ups moment you had? The biggest mistake is not being serious about starting to do what I like the most – programming. I spent several years just to discover that programming really is my passion and really is what I want to do my entire life. What drives you crazy about your job or your daily activities? Not having clearly defined tasks when the client thinks that the developer should read their mind. Which technology/tech stack do you like the most? React is my number one. Besides that, I like good old SCSS. Currently, I work in Angular and it is also good although a bit different than React. I usually interact with Java/Spring on backend and I like it as well but Javascript world is what I like the most. What advice would you give to someone entering this field? Practice, practice, practice, and then projects, projects, projects. And then, guess what? Projects again. And then projects. Then try to find a good project and work on that project. And then again projects 😀 Do you have any funny or interesting stories that happened here in the company? While on teambuilding, we were playing some games and by accident renamed Mariah Carey to Marie Curie (obviously we were drunk 😂). Your favorite person to work with? Gabriela and Tomislav. Both of them are smart, sharp, easygoing, and have a broad range of knowledge. If you could compare your job/work to one movie or show, what would it be? Sherlock Holmes 😂 If you could choose one song to go along with your job or which would make you be really in the zone while working, what would it be? Welshly Arms – Legendary
Pair programming – to do or not to do
A term so well-known among the software development community. Some swear by it, some hate it. Nonetheless, most of the developers tried it at some point. Pair programming brings benefits to some, but also trepidations to others. It is something software development companies try to do when they encounter a complex task or want more experienced developers to transfer knowledge and guidance. It may seem like a pretty straightforward process, but if not executed properly, it’s counterproductive. A quick reminder on what pair programming is Pair programming is an agile software development technique where two developers work at the same station, meaning on the same computer with one keyboard and mouse. They work together on designing, coding, and testing while solving a specific problem. It’s a joint effort between two developers who rely on each other and have great communication skills. Pair programming requires them to work in close collaboration, to write the code, and also discuss it and test it. Although it may seem like a straightforward approach, it is not for everybody. It requires both hard and soft skills for developers to be on the same page throughout the whole process. In pair programming, the two roles developers fill are the driver and the navigator. These roles have to be switched at every time interval those developers have decided on. The driver is responsible for writing the code. She or he is the person behind the keyboard. The navigator is responsible for the direction of the development. The navigator reviews the code, gives directions, and reviews the code. How does it exactly work? It seems a bit redundant to have two developers working on the same station. Many argue that you only fully utilize one of them, and you don’t need two to achieve the same results. Well, that’s why these roles need to be clearly defined and their work scope should be complimentary, rather than one person doing most of the work. Cohesion is key. Great organization among these developers is important. The roles are either assigned or they work it out themselves, as well as how will they approach the problem or task at hand. They start with receiving the task and deciding on small goals to tackle, one at a time. The process requires them to collectively agree on the best approach and technique. Switching roles means that the code will be of higher quality and done with more consideration. This is done in turn until the task is solved. Pair programming is based on the four-eyes principle, meaning more people see the problem from all sides, and must be reviewed by at least two people to make final decisions. One important thing to remember is that pair programming is meant to be knowledge and experience-sharing occurrences to combat knowledge silos and towers of knowledge. Also, pair programming is highly oriented toward creating focused time slots where the driver and navigator remove distractions so they can effectively maximize their efforts and have a smooth workflow. Let’s talk about pair programming styles Pair programming can be done in more than one way. It depends on the experience and knowledge of these developers, as well as on their previous familiarity with pair programming. Driver-navigator style As described above, this style is one where there is a driver-navigator relationship – one developer writes the code and the other directs and reviews the direction where it’s going. This style is based on active participation and both developers regularly switch roles to emphasize code quality and knowledge sharing. This style is good for partnering up a more experienced developer with one that is less experienced. But note that in this case, you should not always pair someone who differs so much in experience and knowledge. This is not a mentorship program. Why? Because it beats the purpose of pair programming and it will take more time and effort to resolve a task. Also, the more experienced developer will most likely have to take on more responsibilities than the less experienced. If you do this pairing as an onboarding tool, do it, but don’t overuse it since it defies the role-switching aspect. Unstructured style The unstructured style is just that, unstructured. There are no clear guidelines on how should one behave in this setup. Everything is organized and discussed as work happens, not before. The role-switching happens when needed and how developers agree on the go. This style could work with developers who have already worked together, have a great natural flow, and are similar in terms of their knowledge and experience. Ping-pong style This style is related to and matched with test-driven development. In this case, one person writes the test and the other writes the code to make the test pass. The pair should switch roles in writing tests and making them pass. This approach is great for moving the workflow and the complete development cycle. Common pitfalls of pair programming Even a popular technique, that derives from first programming works and cooperation, has some downsides. When you have people working together, you can always encounter some problems or even tension. Even the best relationships can suffer from some minor disagreements. But it’s not only that. Some outline issues with the business and profitability side. Efficiency and cost Some may argue that when you put two developers on the same task, you are losing potential gains if one of them could be working on another project. Also, pair programming takes more time to accomplish results. With continuous role switching it will take developers more time to get their head in and focus on their current role. Productivity is not as high as it can be if two developers work separately. Issues with equal contribution If you pair up two developers that differ so much in their skill sets, one might do more work than the other. More experienced developers will take on more and overtake the development process just to finish the task. This leads to no knowledge
How to avoid the FOMO effect in software development
With a new year approaching, we will see more and more articles on new trends in the industry and all the new shiny bling that should bring software development to another level. Often, all the new trends do bring some sort of prosperity and advances. But, this happens only when they are utilized properly. FOMO or Fear of missing out is a regular occurrence in software development. Because, if we don’t do it first, everyone else will take the market and expertise. Why does this happen? Simple. Because of clients or companies who hear a new buzz floating around and decide they must also have it. So, many companies fall into the trap of prioritizing following new changes and trends rather than focusing on what brings the most value. Hype or advancement? How many times did a new technology emerge or something new appeared in your tech stack? Probably far too many times. You probably spent a lot of time learning about it and trying to grasp the core functionality and possibilities of it. Sometimes, it pays off. And other times it leads to technical debt. For something to make your development process or your product better, it must bring true additional value. It all sounds pretty familiar to you, doesn’t it? Right now you might be thinking of something quite like it. So when does something go from hype to advancement?Often FOMO shapes the technological landscape and environment. People get anxious if they feel they are missing out or staying behind on new exciting things. We love to be kept in the loop and discuss with others on hot topics or in this case all things novel and trailblazing. Let’s be honest, IT and software development are highly defined and influenced by trends. So, it’s a thin line between revolutionary and something hyped up. And when the line is crossed we can encounter scope creep or we need to tap into change management processes to fix things. FOMO could be good but also bad – depending on how you look at it FOMO in tech could easily lead us down the rabbit hole of trying to keep up with everything new. It could make us go too much into learning new things, rather than becoming experts in something that is already proven. But, there is this aspect of it that drives us to learn and progress. It could define what type of a developer will you be, T-shaped, X, or E-shaped, and so on. Fear of missing out is a balancing act between advancing and losing sight of the end goal, or rather becoming a generalist over a specialist but not in a good way. But, even when something new is not that revolutionary, it could stimulate innovations and make people dig more into why something is making such a buzz. This leads to the creation of better solutions. And if you persist in this new technology, it might become the best thing you’ve ever done. FOMO could be a motivator to find solutions and to push ourselves into new and exciting opportunities. It’s just a case of weighing the risks against possible gains. On the other hand, FOMO could force someone to push new tech into solutions just to fill a gap or to say that they know how to work with it, without actually providing true value. Sometimes, people abandon projects because the new tech doesn’t fit the project scope. Often a good solution turns out to create more problems and issues than not using it. It’s not even about finishing the project in the designated time frame but delivering a solution that is not sustainable in the long run. Developers have it bad Developers often fall victim to the FOMO effect. Whenever they encounter a new technology, they spend much time learning it from tutorials and enter the endless tutorial loop. Doesn’t matter if they need to learn it for a new project, are shifting their areas of expertise, or are simply reacting to a hype, they tend to spiral down into the rabbit hole. They ask themselves the all-present question “If I’m not learning it, am I falling behind?”. Instead of focusing on what brings value to them and the project, they become oriented towards not becoming obsolete. All of this could lead to them feeling like they’re falling behind, to burnout, harder context switching, and maybe imposter syndrome. Uncontrolled FOMO brings some downsides to it all. But you have to consider external influences, as well. Developers could feel pressured by the community and market demands to start grabbing onto each new piece of knowledge or technology. So, FOMO can be initiated internally and externally. How to fight it or manage it? We could definitely mention JOMO (joy of missing out) where you focus on things that bring you joy and help you focus elsewhere besides work and things that minimize anxiousness. But, as we said, the drivers behind FOMO are not always so bad if, in the end, you do prosper. Control it so it doesn’t rule you. Because sometimes we go overboard with our ambitions and with proving ourselves to others. We all want more, more knowledge, more expertise, we want to be the best, so we end up in a never-ending cycle where we want to try everything. That’s why we unconsciously put limitations on ourselves. We forget to stop and think if something is necessarily beneficial to us at that moment. Is the new tech a solution to my problems? This is a great question to pose. Is the new technology, language, or framework a direct solution to the issue or project at hand? If you do start learning and using it, will it help you bring value or not? Here is where you’ll need to balance cost vs. benefit. Meaning, how much time and effort you have to put into this versus how more efficiently or effectively will you solve the task or purpose you have. Does the new
How to handle change requests and establish a change management system
Software development is a dynamic process, as we all know. It is far from static as it can be. Not one software will be the same, and as such, the process of developing one will differ. Even though we can establish SDLCs and follow some structured approaches, changes are bound to happen. Change requests are a common occurrence and that’s why software development companies need to have a change management system in place. Especially, if they work on complex and big projects that are sensitive to errors. We can sometimes call software developers rebels, but when something derails the plan, it’s good to return to some rules. Scope creep and gold plating are situations where changes can significantly influence the SDLC and the whole development process. So, controlling response to changes is quite integral in keeping the process on track. Setting the scene Change requests are not an unfamiliar term, quite the opposite. You can perform perfect requirements elicitation, set up the SDLC to cover each point, and define features that align with every single requirement, and yet, at some point and new change could come up internally or externally, from the client. Changes come naturally, and they are nothing to be especially afraid of. Often, most of them are expected. But, even when changes happen, anticipated or not, software development teams and companies should have change management systems in place. Yes, it may seem like an extra task and something not many want to be burdened with, but it can help them get back control over the process if they know how to react. A change management system is a set of guided, controlled, and effectively communicated processes that help teams understand and implement changes in the software development process. It follows the transition from the current to the new state of the software. Change management systems help plan, track, and implement changes while reducing the offchance of mistakes and setbacks. It should always be accompanied by a change management policy. Change management policy Even though this sounds like an administrative thing, change management policy is a set of steps one needs to take when tackling change requests. The wrong thing would be to just take a change request, do it, and that’s it. No, there are some vital processes to follow, so that in the future, you can react more swiftly and efficiently. A change management policy in software development is a set of rules, guidelines, and procedures on how to effectively manage changes. They are there to provide stable and guided recommendations on how to approach changes, and their implementation, and push them to production and deployment. As said above, changes don’t happen just like that, or they shouldn’t be approached without enough consideration. Doing them without proper planning and structure can considerably influence the whole software development process. That’s why change management policy should cover some aspects or elements. The policy should cover change management processes, who on the team is responsible for them, how you review and approve processes, testing, how you keep records about change, and compliance with rules and laws. They can also be translated into common change management steps: Planning This is where you need to plan how will you address changes and what are some consequential steps. “Why, how, and who”, are the answers you are in the end looking for. You also have to plan how will you design and implement changes in the system or solution. Evaluation Risk evaluation refers to the evaluation of what will the changes do to the software and development process. Will the outcome bring more value or only costs? It’s about assessing whether the changes are worth it and if they won’t obstruct further development. One important thing is to determine if changes align with the goals and objectives of the software and user expectations. Approval This stage is where changes either get accepted or discarded. It’s an important step because if you approve the wrong change, you’ll find yourself right back here. All the parties involved (team members, stakeholders) have to approve the change since they will initiate and perform it. Communication Approved changes have to be communicated across each individual involved in the software development process. What has to be communicated is the scope of changes, what they implicate, the time frame, and expectations from it. Implementation This is where the approved changes have to be performed according to the plan and in a set time frame. Documentation Don’t forget about documentation and change records! Each change has to be written down and documented to comply with security standards. But it also serves as a guide for future similar changes to show how they were executed. Post-change review Each change has to be monitored to see if it was executed correctly and if further adjustments are required. Reviews are there to see if the process was successful or not. Why are change management systems a necessity Well, change management systems are basically sort of risk assessment and management tools. They exist so change requests are done correctly and when they are absolutely necessary for the software to reach its full functionality to provide a great user experience. Rules have to exist somewhere just to guide people involved in the process. Standardization of processes is not a limitation but rather a helping guide on how to approach unexpected situations. Making everyone familiar with the change management system and its policy is quite integral. Hence, each individual knows exactly what is expected of him and how he will approach the issue. It’s also about defining responsibilities and roles for each stakeholder in the process. Easy in theory, but what in practice? It’s easy to define how change management systems should look, but what about practical implementation? It’s one thing to have a system defined, but it’s another to comply with it. How do you stick to guidance and make your team live and breathe it? Communicate the system clearly Each stakeholder should be
Golden Path – for software development and anything else
It almost doesn’t matter what we are talking about, but often standardizations and guidelines make our life easier. You don’t need to search for answers on your own and spend a lot of time on it. A lot of time, we are happy if there is an outlined path with clear signage and instructions, a Golden Path. Wherever you are going, having a map will make the journey easier. It’s the definition of “work smarter, not harder” – meaning that you want to use all the best practices to achieve the best results. We are not implying you shouldn’t work hard, quite the opposite. But, grabbing that hand outstretched in the offering, should be a no-brainer. Golden Paths or paved roads have been around for quite some time. And you definitely should sing “Follow the yellow brick road”, because just like in the Wizard of Oz, that’s the road you should walk on. So, about Golden Paths? When most think about the Golden Paths they often refer to the Spotify case. They are among some of the most famous examples where Golden Paths have been incorporated. Their Golden Path was created for engineering purposes – to guide developers in onboarding and performing tasks based on best practices. But what exactly is a Golden Path? Golden Path is often defined as an opinionated and supported way to build something. Mainly it is used in software development as a guidebook of well-defined, structured, and task-specific paths to develop applications and software, faster, with better quality and control. But it is not limited only to development processes. It can be applied to various business procedures as well, from onboarding to sales, and so on. A Golden Path is a cluster of best practices, knowledge, insights, and tools that are supposed to minimize complexity and dependencies on others in development or business processes. It is supposed to make life easier for anyone coming on board and catching up with how something is done according to the company culture, rules, and learnings. These pathways are basically templates and frameworks on how to do something more easily and without issues or bugs. It’s a self-service tool or guide that shows the way to efficiently perform common tasks. It’s not always about development Even though when we talk about Golden Paths we mostly think about software development, they can also be utilized in other business procedures. Onboarding materials are a great showcase of what a Golden Path is. It’s a roadmap for anyone new entering the company with instructions and how-to’s when setting up for work and a new working environment. It’s not only that, but it’s about which equipment and technology will you use and how. Even how to do simple tasks like setting up your work accounts and the process behind everything you might need. In sales or marketing a Golden Path could be oriented on how to do their job more efficiently following a brand’s name and image. Other Golden Path could be observed from the user’s or consumer’s point of view. For example, defining each scenario of their behavior and what is the company’s answer to each action they might take – from user intention to user outcome. Each situation that can be described with appropriate steps and actions can be introduced in the Golden Path. The point is to reduce complexity, anticipate possible struggles, and speed up the delivery of tasks with desired results. Can over-standardization or Golden Paths kill creativity? It’s an interesting debate if Golden Paths kill creativity and free thinking. Some might argue that limiting someone to specific procedures could do so, while others think that guidance is just that, something to help you move along. What if a developer comes up with an idea to introduce a new tech stack? Maybe, yes, it could solve a problem faster in the short term, but more experienced developers could see possible pitfalls in the long run if they do this. Yes, it’s a thin line between best practices and hard rules. But, let’s emphasize that Golden Paths are not there to put limitations on your work. They are there to introduce everyone to the company’s culture, technology, and procedures. Such paths are not set in stone. Oh, no. It’s the flexibility and adaptation that are the main characteristics. As time progresses, the company will change, technologies will evolve, and new guidances will need to be set. Golden Paths can actually stimulate creativity. If standard tasks can be performed more efficiently and faster, there is more time for developers or people in other roles to develop new ideas, see room for improvement, potentiate change, and contribute to the Golden Path itself. Let’s not look at a Golden Path as a hard unyielding rule, but rather as a side helper (but not like the widely hated Clippy). We can imagine such paths as bricklaying and building something. You need to have a strong foundation. You need to know how to properly stack those bricks or your whole structure will fall apart. But that doesn’t mean that you can’t boost your creativity on other tasks. No one is forced to adopt a Golden Path if it doesn’t fulfill their need or help them in any way. The uphills and downhills of Golden Paths Okay, as with anything in life, there are benefits and drawbacks of Golden Paths. Not everything that shines is gold (yes, we’re kicking it up with puns). So the best way to do this is to see what they bring to the table, and what potential downsides or traps are there. Minimized knowledge silos With Golden Paths, knowledge sharing is not only encouraged, it’s almost mandatory. By creating step-by-step guidebooks, other developers or team members (depending on the Golden Path purpose) share their knowledge and insights on how to do something most efficiently. Documentation, guides, technology, advice, and how-to’s all serve to minimize time to search for answers and to basically promote, let’s call it, knowledge democratization. This way
Igloo small talk – Patrik
As a team lead and a full-stack developer, Patrik has his hands full. But he still dedicated some time to showing you his world and what his day looks like in our company. So, deep dive into what makes him tick and how he decided to jump into this career. Tell us who you are and what you do in Deegloo. My name is Patrik and I am a team lead at Deegloo. Some of my daily to-do tasks are organizing projects, and making sure that each of my team members is good and has stuff to do, and if some of them are stuck somewhere, I am always here to help. Also, I am a full-stack developer on the project. What does your typical day look like? I usually start my work part of the day at 8 or 9 a.m. I have scheduled todos that guide me every day through that morning part of it. I have some sort of checklist for each day so I don’t miss something. The afternoon is more dynamic, there is lunch, maybe some talk with teammates, some time for focus work, and a bunch of meetings with the client. And that’s it. At the end of the day, I tend to prepare everything for tomorrow so that I don’t need to think about what to do when I come in the next morning. What made you decide to develop your career in this field? Mostly my passion for math and the influence of my CS teachers in high school. They were awesome and the way they approached the students and the way they taught us programming is something that influenced me the most. That’s something where I can see myself in the future. Part-time developer, part-time CS teacher somewhere. What drives you in your work? Mostly client satisfaction when a successful project is delivered. Also, constant learning about new stuff, not technology-wise. More like domain-specific stuff. I like to learn new things about different industries, people, ways of doing things… What’s the best part about your position? If I have to single out one thing from the last answer, that would be learning new stuff every day. What don’t you like about your job? Meetings without agenda. There needs to be some sort of penalty if you create a meeting without an agenda. What’s the biggest mistake you’ve made in your career or what ups moment you had? Nothing that huge. Once I worked on the feature for a long time, and I thought I pushed changes to the remote branch so I wanted to reset the current state to remote, I did `git reset –hard` and that unpleasant tingling went through my entire body. Stress level arose. Sweat started to break out on the surface of my skin… Ultimately, it was not as dramatic as it felt at that moment. It took me a day or two more to implement that feature and that’s all. What drives you crazy about your job or your daily activities? I’ll repeat myself. Meetings without agenda. And meeting with 7+ people invited. Those types of meetings are mostly unproductive, unnecessary, and often indicative of a flawed process. Which technology/tech stack do you like the most? I have a preference for React paired with Java Spring Boot on the backend. However, I’m not as enthusiastic about Next.js, but given the direction of the React community, I find myself using it despite my hesitations. What advice would you give to someone entering this field? Do you have any funny or interesting stories that happened here in the company? There is one office event that is stored deeply in my heart (I don’t know why, it just is) and that is an event when Dario, Renato, and I transplanted flowers into a larger pot. Your favorite person to work with? I enjoy working with all of my colleagues, but there’s something particularly enjoyable about working with Jakov. He does things with remarkable simplicity as if the most complex challenges were effortlessly within his grasp. If you can compare your job to one movie or show, what would it be? Ufff, this is a tough one for me. I am not really a movie guy but if I had to pick one, I’d pick “Peaceful Warrior.”. If you haven’t already watched it, it’s definitely worth checking out. If you can choose one song to go along with your job or which would make you be really in the zone while working, what would it be? I am not listening to songs while I work. Music with lyrics distracts me from the thinking. I am mostly listening to some lo-fi or some other instrumental alternatives (soundtracks from movies like Interstellar).
How to kill knowledge silos in your dev teams
If you followed our Digital Poirots, you have most definitely heard of data silos. An occurrence where all data is centralized in one place without allowing others access to it. Almost the same characteristics apply to knowledge silos. The principles are the same and you might imagine where this is going. But, we’ll get onto that in a second. Software development has never been a one-man-team project. After all, the quote “No man is an island.” has never rung more true than in software development, especially in big projects. The core of every software development company’s culture is collaboration and teamwork. IT companies thrive on that and center the whole environment on it. So, when knowledge silos appear, it becomes harder and harder to foster such a culture. And breaking knowledge silos becomes a priority. What exactly are knowledge silos? Knowledge silos happen when an individual or a group of people know something, have some information or skills, and don’t share it with others inside the organization. They happen when individuals or teams don’t want to exchange information, communicate, or collaborate, whether we’re talking about with other teams or departments. In software development, knowledge silos appear when one person or a group hold skills, expertise, or historical knowledge on projects or programming and doesn’t share it with other team members. Why is that such an issue? Because of a term called the “bus factor”. The bus factor is a measure of risk when someone holds skills, information, or knowledge only privy to them. So when this person goes on vacation or leaves the company, others can’t pick up their work. The term is derived from the statement “What if they get hit by a bus?”. The question is who will in that scenario be able to continue this person’s work? A bit ominous and selfish statement, but it’s unfortunately necessary for work organization and dispersing knowledge silos. Why are knowledge silos a no-no? Well, sharing is caring. The same applies to knowledge. It’s not about forcing someone to share all their hard-earned expertise, but it’s about company and project information. Sharing technical skills and mentoring others is a perk in creating cohesive teams that are oriented towards learning. Knowledge silos are especially bad when you have teams with different skill sets. Meaning, that not exchanging information between, for example, product development, project managers, developers, and similar, could lead to a bad product, or software in this case, delays, and issues. Poor communication leads to way too many bumps in the road. Here teams work almost in isolation and don’t know what others are doing. This ultimately causes work duplications, miscommunication, incompatibility in goals, slower time to finish projects, intolerance towards unintentional mistakes or others, and discrepancies in work progress. Knowledge silos basically alienate teams and remove all cohesiveness. Yes, you can argue that one team leads one project and everyone doesn’t need to be informed. That’s true, but still, unexpected issues might arise and others will need to be onboarded onto the project. This then takes time and creates additional costs. And you want to avoid that completely. You can compare silos to high school cliques. Each group does its own thing and it’s hard to become a part of one. And, unfortunately, they will work against each other. Break it or don’t make it The best thing for you and your company is to try and break knowledge silos. Your software engineering teams are dependent on collaboration, especially if we talk about big and complex projects. You don’t know whether the scope will change in the future or new complex requirements will come in. In this case, you’ll need to bring more people onto the project team and it could be rather difficult for them to catch on. More issues arise if they need to catch up on new technologies or other changes. Create documentation on projects and identify critical knowledge Creating documentation should be a standardized procedure, meaning that each team member should consciously and continuously write it parallelly with their work. It is especially beneficial if one person leaves the project and another has to be onboarded. This is also great for avoiding creating complex legacy code with poor documentation. Identifying critical knowledge each team member has to possess is also vital. Certain things can be standardized if they are a part of everyday operations and procedures. Pair programming Pair programming is where two developers work on the same computer to design, code, test, and review. This is great for knowledge sharing and collaboration since developers provide each other with insights and new thinking. With pair programming, there is a way to ensure that more than one developer knows everything about the code and project. Share activities and communicate What’s important in most companies is to regularly do hands-on meetings to share information on current projects and activities. It’s not always about knowledge sharing, but about informing other team members on cultural and organizational activities. In such situations, someone might share issues and problems they encounter in their tasks, and others can help solve them. Create initiatives and time for knowledge sharing What software development companies can do is offer tech sessions where the more experienced or more knowledgeable developers can share their knowledge on certain technologies or best practices. This fosters a culture of improvement, and also, developers feel more validated as valuable team members or mentors. Involve developers in each stage of development We know that most developers would love nothing more than just to code. But, to avoid knowledge silos, it’s beneficial to involve them in the development process from start to finish, from learning about domain knowledge to product delivery. This way they will understand better what they are working on and can provide input when needed. By knowing what others are doing, they can learn more and perhaps provide some guidance or advice. Code reviews Code reviews are software quality assurance activities where more people asses the code, get themselves familiar
The good and the bad of 10x, rockstar, superstar, or 100x developers
When employing developers, as a company you will always strive to get the best. There has never been a more significant trend to employ senior developers with great experience who could lead projects and teams like they’re a piece of cake. Finding that unicorn of a developer is like finding the pot of gold at the end of a rainbow. Terms like 10x developer, rockstar, superstar, and 100x developers are used to describe them. It sounds wonderful, doesn’t it? Having one of those on your team can be extremely rewarding and beneficial. Imagine having someone who can code ten times more efficiently than others and can deliver spectacular results. But, is it really all that great to build up a team of just 10x or superstar developers? Or could some of them become downfalls of projects and teams? What is a 10x, rockstar, superstar, or 100x developer? A 10x developer is a developer who can deliver results and perform tasks 10 times more quickly and efficiently than the rest of the developers with the same level of expertise. Or their work is 10 times more impactful and beneficial to businesses. There has been a rise of the term 100x developer where such developers can perform tasks more efficiently, but they also bring a new depth to understanding the business domain and concepts. They are not focused solely on creating the code faster, but they try to bring in the value of understanding business requirements as well. They turn towards solving problems and realizing which features can they executed better. Essentially, these types of developers are the top performers in teams and are extremely valuable to have. It’s no wonder other terms for them are rockstar or superstar. The level of their productivity surpasses the one of their peers. What exactly do 10x or superstar developers bring to the table? Besides developing the software faster, these developers can offer guidance in making less expert developers become better at what they do. It’s not only about coding more quickly, it’s about teaching other developers how to think beyond the code and with users in mind. These types of developers are often self-reliant. That means that they don’t necessarily ask for help or guidance on projects. They know their tasks and execute them efficiently and often faster. Also, as mentioned before, they are business-oriented not only by trying to understand the business domain of the project but the company they work for as well. They want to be included in business workings, like organization and fostering excellent team culture. This in turn drives them towards innovation and they always seek better and more optimal approaches to solving problems or doing something more efficiently. They will have a different outlook on the issues at hand and a different mindset. All of this can lead to them being skilled in working with clients in terms of negotiating the project scope and which features are necessary, which ones are just nice-to-haves, and which ones are completely unnecessary. This means that the project will be better handled and more under control. When are those types of developers less wanted? Like with everything in business, not everything shines bright and gold all the time. Even these types of developers, have their faults and can cause trouble. A lot of the time, being treated as a rockstar or superstar, can give developers certain freedom to act out. Getting a bit self-conceited can be extremely bad for team morale. There are countless stories where 10x developers considered other developers lacking in skills and knowledge and they outright verbalized it. Next, they would take on bigger chunks of the project or even the whole project and fully take over the development. You might think that’s not that bad, but they often get lost in their own code, which usually leads to delays in development and bad code. If such developer takes on too much responsibility, they could omit to do other things besides coding. They could forget to document things, make notes, code reviews, and other things, because they will exclude other team members from the project. Someone taking over a big project and not letting anyone else influence the development process is counterproductive and will lead to delivering a not-so-quality solution, if so. If other developers are not included in code writing, it could be hard for anyone else to come on board and make sense of the code. This in turn creates legacy code, which we all know is not such a fun thing to have. All sorts of dependencies will arise from these dealings. How to turn these types of developers into your asset? Yes, there are two outcomes of having 10x developers. On the one hand, you have terrific and productive team members, and on the other, you have so-called “divas”. So how do you make sure that 10x or even 100x are nurtured and a great asset for your company, rather than someone thinking they are superior to everyone else? Because even when such developer performs well and is not hard to handle, how do you keep them in your company? Foster a culture of knowledge sharing Before employing 10x or other developers, make sure to introduce them to the team culture and emphasize knowledge sharing. It should be encouraged across all teams that teamwork and collaboration are essential in delivering exceptional products. When you have help and insights from others, that’s when developers will grow and you can ensure the continuous growth of their quality. Don’t overlook soft skills Soft skills are as much as important as technical skills, maybe even more. Having a developer who does not play well with others is not a good tactic. If someone is a great developer and has exceptional skills, you’d want him to share the knowledge with others. Listening, empathy, and great communication skills are harder to learn or obtain than technical skills. Let’s face it, if you have a team that gets on well, then you
Igloo small talk – Mateo
Dive into our latest employee interview and meet Mateo, our Frontend Developer. From how he started this career, what he loves about it, to some advice for younger generations, explore what his work life is like. Tell us who you are and what you do in Deegloo. I’m Mateo, a Frontend Developer at Deegloo. In short, my role involves working on the development of the frontend for the Mobile Manifest app. This encompasses tasks such as implementing new features, addressing potential issues, conducting testing, and managing app builds and deployments. What does your typical day look like? I begin my day around 8 AM by making myself a cup of coffee. Following that, I gather with my colleagues during the coffee break to hang out. After our coffee break, I start to work on my work obligations. This involves reviewing my Jira tickets, Slack messages, and emails. Next, I tackle the tasks assigned to me until we have our team’s daily standup meeting. During this meeting, we discuss our progress and address any potential issues or blockers. Following the standup, I continue my work until the lunch break. After lunch, I hang out a bit more with my colleagues before resuming my tasks until around 4 PM, when we hold our standup meeting with our colleagues in the US. Once the meeting with our American colleagues concludes, I wrap up my work for the day and sign off. What made you decide to develop your career in this field? Since I was very young I loved everything related to computers, I always fiddled around so I learned a lot by myself. Once I got into college and started learning software development and getting to know different programming languages, my love for coding really took off. And you know what? That passion is still going strong. 🙂 What drives you in your work? I love to work on myself and gain new knowledge. Also, technologies evolve constantly so keeping up is sometimes challenging. That’s part of what pushes me to keep improving myself. What’s the best part about your position? Being a frontend developer is something I love because I love to see what I am working on and I really love visually appealing applications. It’s rewarding to receive recognition for my work on the visual front, and it’s nice to share what I do with my family and friends. Also, the chance to work remotely is a real blessing, as it allows me to visit my hometown more frequently. What don’t you like about your job? Work might get a bit dull when you’re dealing with big chunks of repetitive tasks, but I think that’s something normal in every company in one way or another. What’s the biggest mistake you’ve made in your career or what ups moment you had? I didn’t have any crucial mistakes which could destroy the company I worked in :D, but I had one time-consuming mistake while I was working on one WordPress project. I knew the basics of WordPress from my own side projects, but nobody else at the company had any knowledge about it. So, when my team lead asked if I could handle it, I said yes, and suddenly I was the only one carrying the whole project on my shoulders. The project was a webshop WP project which additionally required integrating React code in WordPress. While this was a bit tricky, I managed to implement that code into the project, but the biggest time-consuming issue was translating the text which was imported into the project. I spent a few days translating the whole site manually because there was no free appropriate plugin that would translate integrated React code in WordPress and the company was too cheap to pay for that plugin, so there I was the unpaid human translation plugin 😀. What drives you crazy about your job or your daily activities? There is a time when unexpected issues arise and you need to find a way to solve those issues. For example, some time ago, on the project we needed to update all npm packages, and “untangling” those dependencies can be tricky and drive you crazy. Which technology/tech stack do you like the most? I have had the opportunity to work with different frontend frameworks throughout my career, all built on JavaScript. This experience has allowed me to develop proficiency in Javascript and various frontend technologies, especially React. What advice would you give to someone entering this field? Never stop learning and always push hard because in challenging fast evolving areas you have to keep up and you can develop yourself quickly. Do you have any funny or interesting stories that happened here in the company? I enjoyed bowling team building last year. This was a fun get-together and a great opportunity to get to know colleagues better and in a new light. It would be a great experience to repeat. Your favorite person to work with? I can say that I like working with all my colleagues, but if I had to pick someone, Franjo is definitely the person I’ve clicked with the most. If you can compare your job/work to one movie or show, what would it be? Maybe a mashup between The Office and Silicon Valley would compare the best. 😂 If you can choose one song to go along with your job or which would make you be really in the zone while working, what would it be? Since I like to listen to various artists and I am open to different genres, the song I usually pick depends on the day and my current playlist. But if I had to choose one it would be “Three Little Birds” by Bob Marley, because it is a great song representing positivity and it is one of my favorites.