“Clean Code. It’s a bit older but a classic that shows how you easily write, read, understand, and change code. A lot of times people like to write complex code that only one person understands. Then other members of the team have to spend hours to understand it. In my opinion, it’s a mandatory book for any FE or BE developer.”
“I find “The Programmer’s Brain” very interesting. It’s basically about how our brain works and how we think about code.”
6 Reasons Why You Should Enjoy Reviewing Pull Requests
Raphael Marques •
May 2, 2023 •
This article was originally published by Raphael Marqueson Medium.
Reviewing Pull Requests (PRs) can be a tedious and dull task, especially when you have other tasks on your to-do list. However, it’s also one of the most efficient ways to maintain the quality of your codebase, improve your knowledge, and help your colleagues.
The key to making tedious tasks interesting is to have a good reason for doing them. That’s why I’ll give you six reasons why you should enjoy reviewing PRs:
1 — Help new joiners and junior members
Showing new team members how you maintain your codebase by reviewing their PRs can help them understand your practices and standards, the same happens for junior colleagues.
2 — There’s more than one way to solve a problem
Reviewing your colleagues’ PRs can provide you with new perspectives on how to solve problems. Even if their approach is not what you would have done, it can still be a valuable addition to your toolbox. Keep an open mind and be pragmatic.
3 — Avoid the “Looks good to me” (LGTM) mentality
Instead of just giving a quick LGTM comment, take the time to provide good feedback. Even if you think there’s nothing to improve, try to find something interesting to highlight about their code. If you find something wrong, be kind and straightforward, explaining why you think it’s wrong and offering potential solutions.
4 — Keep your Pull Requests small
Breaking down your code changes into smaller chunks will make it easier for your peers to review them. This approach will help you catch any potential bugs, code smells, or duplication. It’s collaborative work, so making it easier for everyone involved will benefit the team in the long run.
At first glance, it doesn’t make much sense, since “more code, more issues, right?” However, when we’re faced with a large amount of code to review, we tend to overlook important details, such as potential bugs, code smells, and duplication, which can make our PR reviews less effective.
5 — Review your own Pull Requests
Before asking for others to review your code, review it yourself. Take a break and come back to it with fresh eyes. Check for any unnecessary code, such as console.log or forgotten commented code. Highlight any decisions you’re unsure about, so the reviewer knows to pay extra attention.
6 — Take your time
Reviewing PRs requires careful attention to detail. Take it slow and read every line of code. Don’t hesitate to ask questions if you’re unsure about something. Remember, there are no stupid questions. The most important thing is to keep the codebase and the team sharp.
In conclusion, as mentioned before, reviewing PRs may seem like a tedious and dull task, but it is an essential part of maintaining the quality of your codebase and building a stronger team. By taking the time to review PRs thoroughly, you can help new team members, gain new perspectives, provide valuable feedback, and improve the overall code quality. This collaborative effort not only benefits the team but also contributes to personal growth by developing a deeper understanding of best practices and standards. Therefore, reviewing PRs should be an enjoyable and fulfilling task that is worth the investment of time and effort.
This article is written by Raphael Marques.
Share this Blog Article
Frontend Engineer @
Follow me on
ASKING FRONTEND DEVELOPERS
Thanh Hoang Nguyen •
April 13, 2023 •
What is your favorite tool / framework / language to work with as a Frontend Developer?
I have to give credit to Visual Studio Code as my buddy tool to code, it’s easy to set up, fast, and has a bunch of cool extensions to work with. But of course, if we want something more robust I’d go to WebStorm.
I’m going to go with Vue as my current favorite framework. I say “current” because in this fast-paced and always-evolving world, we never know what tomorrow brings, and I honestly believe we should always be open to change if we aspire to be good professionals.
Vue is a front-end framework that is not only easy to learn but also extremely versatile. With recent versions, it is also very optimized for performance and DX (developer experience). The community is booming, and the ecosystem around it is expanding at light speed with Vite as the default bundler for Vue3 in the center of attention right now – and for good reason! Even more exciting changes are coming this year to Vue and I can’t wait to try them out.
Share this Blog Article
Thanh Hoang Nguyen
Growth Manager @
Follow me on
Andreas Rau – How pilots communicate
Andreas Rau •
November 11, 2022 •
… and what we as Software Engineers/ Designers and Businessmen can learn from it
In this article you will learn about miscommunication pitfalls in aviation and that the same pitfalls occur in software development, design, and business. We will dive deeper into topics like the aviation decision-making (ADM) process. Have a glance at intercultural communication. How it dictates the way we speak and understand our world. Further an introduction to my own personal experiences and how you can sabotage the productivity of your organization effectively.
In the end, we will apply the ADM to foster and improve your communication.
How miscommunication can trigger disasters
On 25th January 1995, the Avianca flight from Bogota, Colombia, to JFK Airport in New York, was running out of fuel. Air traffic control (ATC) at JFK kept the airplane in a holding position until their plane’s fuel tank was running dangerously low. When revisiting the conversation between the airplane and the ATC at no point in time the word “emergency” or “mayday” was communicated by the pilots. The captain reportedly told the first officer to “tell them we are in an emergency”. instead of letting ATC know that the airplane is in a serious situation, the word “emergency” was not communicated. Instead, the first officer told ATC “We’re running out of fuel” “With air traffic control unaware of the gravity of the problem, the plane crashed just nine minutes later. Out of the 158 people on board, 73 died, including the pilot and the co-pilot.”
The complexity of reality
The Austrian philosopher, Ludwig Wittgenstein already shared with the world in 1921 in his famous book “Tractatus logico-philosophicus”.
From this, we can derive that even under calm conditions the human language fails. In the before shown example, it gets even worse under stressful conditions.
From Aviation to Software Development
First of all a disclaimer. I am a software developer and paragliding pilot. I am well aware that in airline aviation serious mistakes can endanger passenger lives and software development in most cases does not. What I am interested in, are the circumstances of mistakes and the diversity of people involved as well as their communication. When I was revealed how many aviation accidents happened because of miscommunication I started to question if the same situations occur in my day-to-day job and even in my private life. In both worlds, we face time-critical decisions. We both need to react to events that happen while we are executing tasks. I see only a few differences. One of them is that there are more decisions and events to consider in aviation. This means that there are more of them in a shorter amount of time. Both worlds make decisions. In software development, those decisions and their effects as well as their execution by 3rd parties take more time than in aviation. Think about this statement for a moment. Compare a 2h flight with all the decisions that you might need to take as a pilot to a software development sprint of two weeks.
I am a paragliding pilot, so nothing close to a real pilot, but in my experience, the amount of decisions I have to take in a 2h flight compared to a two-week sprint is about the same. In the next part, we will dive deeper into how the aviation industry takes decisions.
The aeronautical decision-making (ADM) process
The airline industry has identified a process that every aircraft pilot has to obey. Aeronautical decision-making (ADM) is a five-step process that a pilot needs to conduct when facing an unexpected or critical event. Adhering to this process helps the pilot to maximize his success chance.
Start to identify your situation, this is the most important step. Accurately detecting it enables you to make correct decisions and raise the probability of success.
Evaluate your options and in my experience, there are often more than I expected to be in the beginning.
Choose from your generated options while accessing the risks and viability.
Act according to your plan.
Evaluate if your action was successful and prepare for further decisions. You will always have further decision points where you need to start the process of ADM again.
This process is only one of many more in aviation.
Let’s apply this to a software bug.
Identify your situation
What is the real cause for the bug?
Is it reproducable, part of my product scope or not?
Did this bug occur because of our code changes or of dependency updates?
Is this bug on live systems?
Can I resolve the bug?
Do I need help?
Can I get more information?
Evaluate your options
Patch the bug with a new version.
Ask for help.
Decline because it’s a feature and the user is using it incorrectly.
Let’s assume the bug is on a live system and needs to be fixed asap -> Patch the bug with a new version.
Please enter your routine for fixing a bug here
Evaluate if your action was successful
Is the live system running as expected and was the bug resolved?
Should we establish a standardized process to fix bugs?
Did I resolve the bug in time? If not practice time management.
Is there anything we can do to mature the product?
Feedback to QA.
Share your insights.
Improve test procedures.
This is an easy example to illustrate how the ADM process can be applied to software development. A lesson I learned from paragliding and software development is to always finish your plan even if the circumstances change during your action. Trust in your abilities and execute your plan. If you followed the previous steps correctly your actions cannot be severely wrong. Given that the information you based your analysis on was correct.
Which language we use is an important part of correctly communicating with each other, let’s have a look at aviation English next.
Pilots and crew, regardless of their own native language or any other languages they speak, travel across the world. They have to be able to communicate with every airport and every ATC they face, on a daily basis. This was a challenge to solve, which occurred with the rise of civil aviation in the mid-20th century. There was already an unspoken agreement in place. The language of the sky at that time was Aviation English. Now Aviation English is, as misleading as it sounds not the English language that we know. In fact, it is a separate language compared to what is spoken on the ground. Even native English speakers have quite a long road to learn it ahead of them. It uses standardized phraseology in radio communications to ensure aviation safety. Since the manufacturing, as well as the operation of air crafts, was dominated by English-speaking countries. The International Civil Aviation Organization (ICAO) slowly but steadily understood one thing.
Good processes and procedures themselves will not solve the issue.
In 1951 they suggested that English should be the de facto international language of civil aviation. Let me emphasize that ICAO in 1951 only suggested, that English should be the language of the sky. It took them 50 more years, in 2001, to actually determine English as the standardized language of air transport. With said standardization, they published a directive. It stated that all aviation personnel, including pilots, flight attendants, and aircraft controllers must pass an English proficiency test and meet the requirements. Before that, language skills were not checked in any standard way.
Now let that sink in for a moment.
In Tech, Design and Business we do have our own set of languages. I am not talking about programming languages. Try to explain to your grandma/grandpa what exactly was decided in the last SAFE PI planning. You can substitute PI planning with almost every other meeting we have in our company. Now ask for honest feedback: “Can you summarize what I just told you?” Be prepared, it might be the case, that your elderly relatives are very kind to you and try to avoid the task you just gave them. But they will most likely not be able to summarize what you have explained to them. I already have issues trying to explain such things to my parents. I can already sense while speaking, that my parents won’t understand a word.
Although you and I were using English as a language. Our terminology, acronyms, processes, and neologism makes Tech/Design/Business English a very complex language.
I had the luck to work with many great people in my career so far and I am more than grateful for every one of them. Nevertheless, I discovered a couple of things for myself over the years. We are all working in the field of Information Technology, Design, and Business. We are all speaking the same language and share the same enthusiasm and skills. And still, we are different. We are all shaped and formed during our private and professional lives in ways one can only imagine. We all have a wide range of different religious, social, ethnic, and educational backgrounds. Living close to our families or far away from them. These differences became more and more visible to me with the amount of time I have spent with them. Differences in how colleagues perceive what you are trying to tell them. Differences in how people value their pursuits and sometimes sacrifice their benefits for the sake of the group. Differences in how authorities communicate with subordinates and vice versa. And these are only the people that I had the chance to work with. You have made your own experiences and shared time with so many more great souls.
What we are now tapping into is the field of intercultural communication. Gert (Gerard Hendrik) Hofstede (Dutchman, born on October 3, 1928, Haarlem, Netherlands) is a Dutch sociologist who proposed an indicators set that determines the various people’s cultural characteristics based on research conducted in the 1960-70s. The subject was part of my studies for one semester. At that time my brain did not understand the extent of the topic and how important it will be for my future life. Intercultural communication describes the discipline that studies communication across different cultures and social groups. In other words, how culture affects communication. There is an impressive amount of research done in the field of intercultural communication which investigates topics like:
Collectivist versus Individualistic
High Context versus Low Context
Feminity versus Masculinity
Long-term Orientation versus Short-term Orientation
Indulgence versus Restraint
All of them are worth investigating and I encourage you to do so. I have gathered further readings which should get you started.
On top of every culture, there is you, you how you perceive the world around you, and you, how you make sense of everything which is shaping you. Your personal touch might very well steer you into a counter course of what your culture tried to induce into you for the entirety of your childhood and more. I hereby am not suggesting that you are all rebels. I want to highlight that the personal level of communication can be far off from how the folks back in your hometown used to talk. If you haven’t already met a vast variety of people during your school time you will definitely do so in your professional life. In Software Development I have had the chance to work with many great people from all over the world. Although at some point already familiar with the concept of intercultural communication I often unknowingly said or did something I thought would be appropriate at this exact moment in time… it wasn’t. Having the basics of intercultural communication in mind is necessary but not sufficient. Get to know the person you are talking to and discover a new level of communication.
We have learned a couple of things about communication, let’s take a second look at the introductory example. The first officer, in disregard of what the pilot told him, made a severe mistake in not properly communicating the extent of the situation. Maybe, in her/his culture, it is common to understate issues and it can be rude to talk about severe issues or problems directly. Nevertheless, the situation required clear and fact-based information. Correct identification of the situation was therefore not possible. All further steps in the aeronautical decision-making process of the ATC were from then on based on false information and we all know the outcome. I often find myself in meetings where colleagues or superiors introduce me to a brand new process that will revolutionize how our company works, solve all the problems and issues at once and make us all happier. Thanks to good marketing everybody is excited and eager to implement the new processes with huge costs in time, money, and motivation only to find out that in the end, it didn’t work — again. I do not want to sound pessimistic, I want to tell you my perspective. Looking into software development and all the processes we have, I want to learn from aviation and invest more time and effort into educating our colleagues on how to properly and fruitfully communicate in a standardized and organized way.
Important factors for this, in my opinion, are honest, transparent, and truthful communication where hidden agendas or intercultural communication pitfalls are avoided. And to make one point clear, more communication is not equal to better communication. I think based on this foundation, processes can be fruitful.
Lost in translation
An enterprise company operating in multiple countries spread over multiple continents. What is the first thing that comes into your mind? For me, it is a rich and diverse project team over as many time zones as possible. During my early career, I was exposed to a trend in IT where teams could not be diverse enough. I know many companies which still steer 100% in this direction, but I also know many who are not. What I am trying to do here is to make you as a reader think. Think about your current circumstances, where are you working? Who are your colleagues? Do you work effectively together? Is communication easy for you or is it a burden? Do you have the feeling that meetings actually create useful artifacts or are they mostly a waste of time? Ask yourselves these questions and assess. I can only speak for myself and I have observed both. In my work, a rich and diverse team can accelerate me, but there have also been times when it slowed me down. When looking at the example I showed you earlier. Aviation English is a language that was an agreement on communication but it was not part of any training or checks. It is important to say, that this has nothing to do with the people per se. When I came to college, in Germany, I had the opportunity to choose if I wanted my studies and lectures in German or English. I was motivated and although my mother tongue is German, I wanted my studies to be in English. This was exciting to me and silly young me thought it would be good to already study in English since the language of IT was English. Now I really regret my decision. During all of my studies, I was confronted with a lot of bad English. Many interesting topics got lost in translation, simply because the lecturer was not proficient enough in her/his language skills. Please do not get me wrong here, my English at that time was not better either. I am just trying to make the point that the content of a message can be severely harmed when not communicated properly. During my career, I often did applicant interviews and had to clearly state my veto. The applicant might have had the best CV, and great experience, but bad English skills. In the IT industry, we have the great opportunity to have rich and diverse teams. This is a circumstance not exclusive to IT but it is still in my opinion a gift we should be thankful for. To make sure we respect and maintain said privilege I have a suggestion. I am suggesting that if we put so much emphasis on what technologies an applicant knows, for how many years she/he has worked with tech stack a, b or c. We should also check thoroughly if her/his English skills are proficient enough to communicate properly in a big and diverse company. We should offer and also expect and check from new hires to improve their language skills, if necessary. Language should never be a limiting factor. Coming from IT and especially web development, I have to deal with accessibility day in and day out. For me, it is easy to understand that digital tools and devices are about inclusion. In my opinion, it is the same with language.
Let’s take this a step further. A good colleague of mine introduced me to an amazing article on some second world war CIA practices.
How to effectively sabotage your organization’s productivity
The CIA created the “Simple Sabotage Field Manual” in 1944 on how everyday people could help the allies weaken their country by reducing production in factories, offices, and transportation lines. There is a wonderful article from the business insider which highlights that. Despite being written in 1944 these instructions are timeless. I am sharing with you the selected list of instructions from the business insider article, filtered for communication. See if any of those listed below remind you of our organization, your colleagues, or even yourself.
Organizations and Conferences
Insist on doing everything through “channels.” Never permit shortcuts to be taken in order to expedite decisions.
Make “speeches.” Talk as frequently as possible and at great length. Illustrate your “points” by long anecdotes and accounts of personal experiences.
When possible, refer all matters to committees, for “further study and consideration.” Attempt to make the committee as large as possible — never less than five.
Bring up irrelevant issues as frequently as possible.
Haggle over precise wordings of communications, minutes, and resolutions.
Refer back to matters decided upon at the last meeting and attempt to re-open the question of the advisability of that decision.
Hold conferences when there is more critical work to be done.
Multiply the procedures and clearances involved in issuing instructions, paychecks, and so on. See that three people have to approve everything where one would do.
Contrive as many interruptions to your work as you can.
Do your work poorly and blame it on bad tools, machinery, or equipment. Complain that these things are preventing you from doing your job right.
Never pass on your skill and experience to a new or less skillful worker.
Although being funny to read, the sad truth is that some of these instructions are common practice in our organization. I advise you to take this list into your notes, bookmark the article, read through it frequently, and ask yourself: Do my communication behaviors fall into the same categories? If yes, no worries! Everybody has to start from somewhere. Remember the ADM process:
Identify your situation and ask yourself: Am I sabotaging my company? It’s important, to be honest here! (Remember: Accurately detecting it enables you to make correct decisions and raise the probability of success)
Evaluate your options, there are plenty! Seek feedback from people you trust and ask them for honest feedback on your ways of communication, do an Udemy course. Heck, maybe even join a debating club!
Choose from your generated options while accessing the risks and viability.
Act according to your plan.
Evaluate if your action was successful and prepare for further decisions.
This is not easy – but it can be done. You can do it!
Now to bring this article to an end let’s look at the last dimension of communication.
Are you talking to me?
I often find myself in situations where I talk about colleagues and superiors rather than talking with them. Talking about colleagues is easy, but with most things in life, the outcome of easy is not great. It takes courage to work on yourself and even more to reach out for help. There is no effortless solution, be honest and ask yourself if you really want to change something about how you communicate and how you are perceived while communicating. This article is at most only a catalyst that will hopefully ignite your own journey.
We have learned how two, at first sight, completely different professions share many fundamental communication skills. We have had a look at the aeronautical decision-making process, what intercultural communication is, that processes are only as good as the material we put into them to be processed, how to effectively sabotage your company and what you can do to foster and improve your communication.
We touched on many topics today and I hope this article touched you personally in at least one of them. If you now think about what you have read in the last couple of minutes I feel already successful in my educational mission and if you remember only one thing then something along the lines of this:
‘Don’t worry the worst mistake you can make, is to not communicate at all.’
As promised here you have a small collection to further educate yourself about the topics in this article.
Hannes Probst •
February 17, 2022 •
WHY PAIR PROGRAMMING SHOULD BE IN EVERY TEAM’S TOOLBOX
Pair programming is old news for most developers. It’s quite possible that you “paired” with a colleague before and might have had some good and some bad experiences. In this blog post, you will get a quick overview of pair programming. You will learn that there are lots of benefits and potential downsides. Additionally, there are some hints on the process and pitfalls to keep in mind. Finally, you will find a quick overview of remote collaboration tools.
BENEFITS OF PAIR PROGRAMMING
According to a study conducted by a Microsoft Research team , participating developers reported “fewer bugs”, the “spread of code understanding”, and “higher quality of code” as the main benefits of pair programming.
In many work areas, the four-eyes principle allows teams to spot errors early on. Developers usually conduct code reviews before code goes out to production. Think of pair programming as giving a programmer a second pair of eyes. They might spot bugs right away, leading to reduced friction down the road. The earlier you spot a bug, the easier it is to fix.
@Saad Bin Akhlaq: After a pairing session, I have more confidence in pushing the code since 2 engineers have already gone over it.
Spread of Code Understanding
According to the Agile Alliance, a team that applies pair programming will gain “better diffusion of knowledge among the team, in particular when a developer unfamiliar with a component is pairing with one who knows it much better.” You will notice a “better transfer of skills, as junior developers pick up micro-techniques or broader skills from more experienced team members.” Furthermore, the Microsoft study highlights that “there is never only one person in the team who knows all the code”.
In the paper “The Costs and Benefits of Pair Programming”  by Alistair Cockburn and Laurie Williams, they claim that “if [a] pair can work together, then they learn ways to communicate more easily and they communicate more often. This raises the communication bandwidth and frequency within the project, increasing overall information flow within the team.”
@Jobrann Mous: I especially enjoy a pairing session when I am exposed to different topics, codebases, and coding practices.
Higher Quality Code
The authors of the Microsoft study state that pair programming helps to improve code quality “through more extensive review and collaboration.” Also, “‘Programming out loud’ leads to a clearer articulation of the complexities and hidden details in coding tasks, reducing the risk of error or going down blind alleys”, says the Agile Alliance.
In addition to that, a quantitative study at the University of Utah  showed that pairs not only completed their programs with superior quality, but they consistently implemented the same functionality as the individuals in fewer lines of code.
Critique of pair programming
In the same study from Microsoft, developers listed cost efficiency, scheduling, and personality clash as their biggest problems when applying pair programming.
Management most likely is in doubt about the efficiency of pair programming. In the Microsoft study “the number one problem reported with pair programming is cost. Two people are being paid to do the work of one.” On paper, you halve the allocatable time of two developers. But there are studies suggesting that pair programming actually increases time spent by only 15% (and not 100%), while at the same time reducing the error rate by 15%.  Occasional pairing programming will balance out the cost with the benefits.
Yet another meeting? Calendars are already full and scheduling meetings is a pain? Pair programming will not improve the situation. If scheduling a spontaneous pairing session is hard, your team should review the number of meetings in general.
What worked well for the cross-functional engineering teams of Bertha and Mercedes Me Service apps, is a fixed pairing slot every two weeks. The engineers begin the 2 hours slot with a short alignment, check who is available, and what topics they can pair on. Then the pairs (or sometimes groups of more than two) start their sessions.
During sprint planning for Bertha, we schedule pairing sessions to tackle tickets with high estimations together.
The backend team of Reach Me is doing it differently. Instead of scheduling anything, they start their day with a Teams-call which they keep running in the background for most of the day. It simulates a being-together-in-the-office feeling and allows for spontaneous conversations, some of which lead to pair programming sessions.
Pair programming is not the best work mode for every problem. While some of us are happy to collaborate on a task and align with a colleague, others need alone time. They want to play around with different possible solutions, sketch something, etc.
Most programmers tend to shy away from collaborative tasks. They want to be on their own while coding. Practice (and constant nudging) is your only chance to convince introverted people to pick up pairing more often.
There are also big differences in the way people articulate themselves. Pairing a person who thinks longer before answering with a fast speaker might end up in a one-sided conversation. It’s important to give everyone enough space. You don’t need to rush anything.
It is an acquired taste
You sometimes hear “I need to get this done, I don’t have time for a pairing session”. Or “it will take me half the time explaining the issue to my colleague before being productive”. Please reconsider. True, pair programming comes with a cost. You have to set it up, agree on a work mode, explain the context. It adds cognitive overhead. Practice can mitigate most of that. If you are getting used to pair-programming it becomes a standard way of working within your team. Doing so will feel normal, and you will consider it for more and more assignments. Jumping on a pairing session with someone lacking the context should be the outlier.
HOW TO DO PAIR PROGRAMMING
4 simple tips for pair programming. Just give it a try.
Agree on topic and scope
There should be a common understanding of what the problem is, and a general direction of how to tackle it. Keep reminding each other when you are deviating too far from your goal. It’s easy to get lost. Now you have someone helping you to focus!
Pick your role, switch them
Usually, when sitting next to each other at one desk, there is one keyboard to share. This puts the person on the keyboard in a different position than the person next to them. The person who types – the “driver” – is more concerned about the coding details, types, syntax, formatting. The person off the keyboard – the “navigator” – can think about the bigger picture, e.g. abstraction layers, dependencies, potential refactorings, etc.
That situation changes when you are leveraging remote collaboration tools. All participants can now write to the current codebase, they can be “drivers” and “navigators” at the same time.
Regardless of the setup, you should keep all participants engaged by flipping through the two roles. This allows everyone to contribute to the lower-level and big-picture problems.
Acknowledge different pairing situations
You should always be aware of the circumstances and the setting of each session.
@Svitlana Piddubna: “Not all tasks are equally good for pairing, so I think it works best when someone sees a ticket that could be a good one for pairing and offers to work on it together”
Are you and your pairing partner on the same page about the issue? Can you both focus on the issue at hand? Does the schedule suit both of you?
Plan enough breaks beforehand. This allows accommodating for individual daily routines, habits, speed of thought, etc. Especially during a pandemic, we need to pay special attention to a flexible schedule (eg: no daycare!). Some people need their time thinking through things alone. Take a break from the session when needed. Pair programming doesn’t mean you are bound to each other for the whole session.
Consider also the implicit or explicit power dynamic within a pair. An example: You are the most experienced developer in your team. Your pairing partner is a junior member with knowledge of the context, but lacking coding experience. As a senior, you have the responsibility to motivate, acknowledge, and drive the conversation positively. Don’t be condescending, don’t turn it into a lecturing lesson. You only get the inspiration of your counterpart flowing when it is a mutual experience.
Programming out loud
Reflection is an important step in learning. You are allowing your brain to streamline your thoughts on a topic. More often than not, only when attempting to write down or articulate, do you realize that you haven’t understood a problem. Now imagine you are articulating and reflecting on your current assignment. You gain an improved understanding of the topic and your pairing partner gains insights into your thought process.
The Agile Alliance advised, that “‘Programming out loud’ leads to a clearer articulation of the complexities and hidden details in coding tasks, reducing the risk of error or going down blind alleys.”
PRO TIP: Think of TV chefs and how they orate every detail of their process.
Remote pair programming
The obvious downside of remote pair programming is the fact that you can’t grab the keyboard and switch between navigator and driver. The “navigator” is not looking at the same monitor as the person who “drives”. To overcome these barriers, a variety of tools can help. The easiest and most intuitive solution is simple screen-sharing. If you need more elaborate features, look at tools like JetBrain’s Code With Me and Microsoft’s Live Share. They come with plenty of features to accommodate for a sophisticated pairing session.
At Mercedes-Benz.io the main tool for remote collaboration is Microsoft Teams. Its screen sharing feature already allows for a great remote pairing environment. You set up a call, share your screen, and go. There is even a function to take over the controls of the shared screen. This can be helpful when a topic is hard to articulate or to switch roles between “driver” and “navigator”.
JetBrains Code With Me
The Code With Me service  allows any JetBrains IDE user to share and open up their codebase for collaboration with remote colleagues. It works across almost all their IDEs (Android Studio coming soon). You can give your colleagues instant access to your current project. Up to 10 developers can join one session, and collaborate on one codebase. Especially for a mob-programming session, this is quite a valuable solution. Each participant can choose to either sync with (or follow) the “driver” and see what they are seeing, or work on their code area, all within one session.
Visual Studio Live Share
Visual Studio and Visual Studio Code offer a similar service, Live Share . You can start a collaboration session and share a link to it for others to join. You have fine-grained control over the permissions the session members get.
Pair programming is an important tool in the arsenal of software engineering teams. It’s a great way to share knowledge, reduce friction, and increase communication bandwidth. Most of us are currently working remotely. Introducing collaborative work methodologies like pair programming helps you to cope with that. Remote collaboration tools like screen sharing make it super easy to do. Now that you know more about pair programming, try it out more. You will be surprised about the positive outcome!
Senior Software Engineer - Technical Lead @
Follow me on
Sabine Geithner: “Bertha Benz is a developer.”
April 15, 2021 •
Sabine Geithner works as the Lead Link Mobile Engineering at Mercedes-Benz.io. She combines 13 years of experience, working in different leadership roles from Project Management, Online Marketing to Software Development.
Until recently, she worked as an iOS developer for the Bertha app. In her current position, she is in charge of hiring the right mobile developers to drive the mobile strategy of the company, fostering a culture of knowledge-sharing and providing an environment for professional growth for mobile developers.In her second role as People Promotershe helps MB.ioneers set meaningful professional development goals and supports them to achieve these goals.
Sabine’s career starts with her studies. She owns a university diploma in Biotechnology. The requirement for her first semester was an introduction to Java class. It may seem that Sabine has a bit of unusual career background, although it is not uncommon to find people with diverse backgrounds in software development.
In this interview, we want to find out what makes tech jobs interesting to women and how we can inspire young girls to strive towards such jobs. Hello, Sabine!
You’ve had quite the unconventional career journey—what did your start as a Developer look like?
My journey to software development kicked off when I turned 30 and looked back at my life where I was and where I wanted to be. At that time, I was working as Head of Online Marketing and Consumer Insights. My responsibilities included: writing HTML for our SEO landing pages, as well as analyzing consumer data to get valuable insights. So, I had already learned some web development and was using my rudimentary programming skills, for things like writingVBA scripts for my Excel Sheets and SQL statements for MS Access.
I realized I actually liked programming and wanted to learn more. I started to look for classes online and in Berlin, where I live. Coincidentally, an in-person program called Rails Girls Berlin (now called Code Curious) had just started. They offered free programming workshops for women. I had missed their first workshop, but I liked their idea so much that I offered to join the organizer team and support with marketing. This was the turning point!
What made you decide to completely pursue a career in tech?
By organizing the mentioned workshops for Code Curious I was able to witness women of all backgrounds quitting their jobs and pursuing successful careers as software developers. It was so inspiring that I decided to leave my own job, spend a few months learning with online courses, find myself an internship, and become a software developer. I was 31 years old when I took that step.
What are some of the challenges you have faced in your career?
When I started seriously considering software development as a career, I received some unwelcome comments from people. They said things like “You won’t be able to learn this so fast. You are learning the wrong programming language. You should learn [insert a preferred language] instead. I would never hire someone who hasn’t been writing code since they were little.” I could have easily been discouraged by their words. Luckily, I like to prove people wrong and understood it as a challenge to show them: it can be done and I will do it.
In the early years of my career, I sometimes wasn’t taken as seriously as my male counterparts and had to have several critical conversations confronting people with their behavior. Often they were completely shocked that they behaved this way and every-time things improved significantly afterwards. I wish I didn’t have to jump into these conversations, however, I can only encourage everyone (especially younger women) to confront such behavior. It helped me, and no one should ever feel intimidated and helpless.
What are some of the positive experiences you have gained throughout your career?
There were positive ones that encouraged and supported me to pursue my dream of becoming a Developer. For example, most of the coaches for Rails Girls Berlin were men and the whole Ruby community was actively working towards increasing the number of women in their field. Also, the people who gave me my very first iOS internship were super trusting in my abilities (I had only done online courses before that) and made me feel at home and welcome in the Developer scene.
There are also many men at Mercedes-Benz.io — who understand the value a diverse workforce adds to our team culture and performance and are actively working on hiring more diverse people.
What does a day-in-the-life at Mercedes-Benz.io look like for you?
There is little to no routine in software development. A “typical day” could look like this:
The day kicks off with a meeting that we call Stand-Up, where everyone gives an update on the progress of their current tasks. We also discuss blockers or topics that need more clarification and then talk about what we plan on doing today. Afterwards, everyone starts working on current tasks. If we work on a new feature, we will meet to talk about how to approach the problem.
These conversations can stretch over several teams, including backend and design. We talk through different approaches or give feedback to someone else’s result. At the end of the day, we publish the code we wrote to the whole codebase and have a coworker give us feedback on our solution. We also create a new internal version, that the team can use to test the new features we implemented during the day.
Let’s take a look at the bigger picture. According to a 2019 study by the UK Department of Education, parents and teachersare less likely to be encourage girls to study STEM subjects. Since only 3% of females say a career in technology is their first choice, a lower female participation in STEM fields equates to fewer female role models for girls.
Why could (or should) women be interested in becoming a Developer?
Let‘s stop putting people into boxes. The job is interesting for anyone who loves logic, no matter the gender. However, I’ve also observed that children’s interests are largely formed by their environment. If you offer girls only dolls and boys only cars, it’s no surprise they end up having a preference for one. I don’t have kids of my own, but I know that my interest in science was sparked at a very young age by getting microscopes and physics toys, so I give the same toys to my nieces.
Qualities of high-performing teams are made up of a wide breadth of holistic skills, such as empathy, sensitivity, creativity, and more! Regardless of gender, many roles benefit from having these qualities, e.g. the Plant, the Coordinator, and the Teamworker in Belbin’s model of Team Roles. Thus, I am certain that anyone can be interested in becoming a Developer but success does not depend on your gender.
What is the benefit of working in the tech industry?
Oh, there are many! From a lifestyle perspective, I think no other job allows for more freedom. Working remotely and asynchronously at weird hours has been common for software developers for a long time. This is absolutely perfect for those who want to have lots of freedom or need to juggle jobs and family. It’s also easy to find a job because software developers are always in demand—and always will be!
For me — the biggest benefit is actually the effect it has on your brain. When I started out, it really felt like my brain was growing. I mean it! You often need to keep a lot of thoughts and ideas in your head in order to figure out how to solve an issue. On top of that, it’s a job that requires life-long learning and keeps you mentally fit in the long-term.
Let’s talk about needed skills and interests.What do you think is the most important strength for software developers to ‘develop’? According to a study published in Nature, the most important strength for software developers is fluid reasoning and memory capacity (the ability to solve problems with logic and to keep several solutions/ideas in your head) followed by language ability. Funnily enough, numeracy (being good at Mathematics) has the lowest correlation with programming abilities.
However, being a successful software developer requires more than just being able to write good code. Developers need to be able to communicate their ideas to their client, their colleagues, and their boss. Communication skills are key. And of course, if you juggle several projects, you need to be organized, too. These skills become more and more important the more seniority you gain, the more you interact with stakeholders and the more projects you juggle at the same time.
How can I start getting into developing?
To figure out if coding is their interest, I recommend codecademy. It’s a gamified way to learn basic programming principles and highly addictive to people who like logical challenges.
For taking a step further, there are plenty of online platforms that offer pretty good courses, many of which are free. For example, most courses on coursera can be attended without paying. I started 7 years ago with team treehouse. I really liked their curriculum back then and it helped me stay motivated. You are learning software development by working on small projects that grow bit by bit and it is extremely rewarding to see the result so quickly.
What can I do as a parent to bring this professional field closer to my child and spark their interest?
For parents of young children, there are also plenty of opportunities. There is the code.org where kids can learn programming while building or playing a game.
Some toys help children practice logical thinking and learn the basics of computer instructions, e.g. Osmo.
There are hardware kits, like Kano, that allow kids to assemble their own computers and gives them an insight into how computers work.
And don’t forget free meetups and workshops (often called “Coder Dojo”) for kids in bigger cities where they can learn coding in a group.
One of the founders of Rails Girls Berlin also wrote a children’s book for girls called “Hello Ruby,” which also has a website to help parents with their kids quest to conquer the world with code.
What is your wish for the future of women in tech?
I hope that more women consider software development as a career and find more and more representation in their teams, at conferences and in technical leadership positions. My wish is that we can at one point drop the “female” in-front of the introduction and refer to people who happen to identify as female, just as “software developer” or “CTO” instead of “female software developer” or “female CTO”.
And lastly…why this headline?Why do you think Bertha Benz would be a Developer and active in mobile engineering today?
The headline is 100 percent correct. Bertha Benz would be a software engineer because she was a woman who valued freedom and independence and wasn’t afraid of entering a male-dominated area.
Want to support and inspire women for tech professions, want to change the game, and know talented women who need to become developers?
Way Forward: Digital House Product-Centric Organization
January 27, 2021 •
Mercedes-Benz AG and Mercedes-Benz.io strengthen their product teams within the “Digital House” initiative – realizing a product-centric organization.
Customers expect the best digital products and services worldwide. Hence, Mercedes-Benz aims at strengthening its operational e-commerce environments on an international level. Therefore, they will enhance the collaboration with Mercedes-Benz.io by scaling digital deliveries for e-commerce and online sales even further.
The goal of the “Digital House” (a joint initiative of Mercedes-Benz AG and Mercedes-Benz.io) is to optimize the business units behind the company’s digital sales and marketing platforms and channels by restructuring them to the upcoming and growing needs of markets and regions worldwide. Within this context of digital products for Sales & Marketing, Mercedes-Benz AG will continue focusing on business and market enabling, strategic portfolio management and respective phase measurements, while Mercedes-Benz.io will be responsible for the development and operation of digital products even more independently. Within the next two years, Mercedes-Benz.io will strengthen its digital product teams in Lisbon, Portugal. The Lisbon site will become the development core unit and a dedicated product organization that focuses on scalable product organization, vehicle leads, and sales-generating products. More than 100 additional digital product development positions will be established at Mercedes-Benz.io in Lisbon. The core of the alignment is a product-oriented organization with the aim of concentrating digital product responsibilities for online sales according to a clear business strategy.