Forem: Jessica Veit

Testing IaC Scripts 🧪

Jessica Veit — Tue, 06 Jun 2023 07:18:52 +0000

Lack of testing can introduce defects in IaC scripts, which in turn can have serious conse-quences. A synthesis of IaC testing practices can be helpful for practitioners to mitigate defects in IaC scripts. (Hasan et al., 2020)

Although IaC is more and more adopted by various companies in their operation process and integrated in many cloud providers using APIs, the quality assurance and maintenance of the scripts created still has to undergo further research and development to achieve a certain level of quality in form of system security and resilience. Because of the undeniable importance of this topic, IaC providers like Terraform and Pulumi, external companies like Snyk and Gruntwork as well as cloud providers like Azure and AWS are currently working on improving the development conditions with IaC.

Testing Guidelines Provided by IaC Providers

Starting with the most well-known IaC provider HashiCorp, Terraform provides documentations and guidelines describing how to implemented unit and snapshot testing capabilities in their developer documentation. Other than that, there is an experimental feature related to module testing and community content for integration tests such as shown by the Github User Ansgarm. As for Pulumi, documentations for unit, property and integration tests are available.

Testing in Terraform 🌱

Testing in Terraform heavily depends on the language that was used to write the Terraform code itself. When using HCL for example the testing framework to favour is Jest by Facebook, which provides testing capabilities to JavaScript and TypeScript, yet is still compatible with Terraform. It was included in version 0.6 for snapshot tests and assertions.

An important factor is the existence of the so-called cdktf (Cloud Development Kit for Terraform) package for the testing framework at use. This package provides an interface for interacting with the Terraform framework itself. When writing common unit test assertion statements in TypeScript a so-called synthScope is used to test part of the application. It returns a JSON string representing the synthesized HCL-JSON on which assertions can then by applied. This way important assertions such as toHa-veResource (whether a resource of a certain type exists) and toHaveResourceWithProperties can applied.

Testing in Pulumi 🧊

To get a broader view on common or experimental testing techniques for IaC tools in general, Pulumi will also be considered in this series. It provides the same base functionality as Terraform, however in addition to unit and integration tests, Pulumi provides the concept of so-called Property Test, which are used to assert properties on a resource-level while infrastructure is being deployed. The key difference between the three testing techniques documented are illustrated below.

Key differences of testing styles documented by Pulumi

With each of the techniques a specific point in time of the infrastructure can be tested. The unit tests are mostly mock-based implemented, meaning the engine normally used for the deployment of Pulumi is replaced by a mock, thus removing the need for out-of-process calls and increasing isolation. Property testing can be seen as a form of policy-as-code to ensure that the deployed infrastructure complies with desired policies. Finally, the integration tests are labelled as deploy-check-destroy tests by Pulumi as they deploy cloud resources and validate their actual behavior.

Next Steps 🪜

After discussing the testing approaches suggested by the two IaC providers Terraform and Pulumi, in the next post we will take a look at the dedicated IaC testing providers takes on this topic. Here we will have a look at Gruntwork and Snyk. So, stay tuned if you are interessted!

Cover Image by Martin Lopez! 🥳

What do you Like most about dev.to?

Jessica Veit — Thu, 01 Jun 2023 06:15:12 +0000

To be honest, I came here by pure luck - an English assignment in my bachelor program - but I stayed because of the community! 😇

I feel like it is a safe space were nerds can be nerds, developers can be developers and anyone can be anyone they want to be. It is just a nice corner of the internet where all sorts of techincal and non-technical matters are discussed in a professional way.

So, what do you like most about dev.to? How did you stumble upon it and what was your reason to stay? 🤗

Image by Kevin Ku! 🥳

Terraform Basics 🌱

Jessica Veit — Tue, 30 May 2023 06:30:07 +0000

Terraform by HashiCorp is the current industry standard tool regarding automated infrastructure provisioning. With Terraform provisioning of resources via machine-readable files is made possible in a cloud-agnostic fashion as well as on-premise. It does this using the so-called Terraform Providers, which are pieces of software, often implemented by the community, as illustrated in the figure below. Which cloud providers are specifically supported can be seen in the Terraform Registry.

Terraform to cloud provider connection (HashiCorp)

Language Support 💻

Terraform supports multiple languages for provisioning infrastructure. First and foremost is the HCL, the HashiCorp Configuration Language, which was specifically designed to be used for Terraform. Second, configuration via Json or CRDS (Custom Resource Definition used for Kubernetes) are possible too. Yet while those are all languages rather common in the operations sector (apart from Json), Terraform also supports Typescript, Python, Java, C# and Go via its CDK (Cloud Development Kit), which are more common in software engineering.

Support languages of Terraform (HashiCorp)

The greatest difference in using a GPL for Terraform files is that options like the HCL are declarative approaches, meaning the goal of the code is described within it, whereas languages such as Java or C# require an imperative defining of what should be done to achieve the desired state (Howard, 2022).

The choice of what language to use heavily depends on multiple factors, such as readability of the code as a declarative style generally is associated with being more human-readable, the performance and ease of deployment as code must go through additional steps before being executed, and the general experience and knowledge of the personnel in charge of the implementation.

The relevance of this section for our on going quest of understanding QA for IaC is the possible usage of GPLs when working with Terraform. This implies that there are plenty well-known and well-incorporated testing tools available. Yet the possible level of quality assurance not just depends on the language used.

The Terraform Workflow 🌊

“Terraform's purpose is to provide one workflow to provision any infrastructure” (HashiCorp) and it does this by executing a three step workflow:

Write – Author infrastructure code
Plan – Preview changes that will be done before applying
Apply – Provision reproducible infrastructure

Especially the plan phase is relevant from an QA point of view. With this, a feedback loop for the developer is created with which syntax errors can be found and fixed at the earliest point of development possible. Again, just like a Docker image, the plan created in this phase is only a template of changes applicable to the target system. This may also give a possible angle of attack to perform tests on the implemented changes.

Important to add here is that plan does not necessary correspond to the artifacts generated in apply by default. They are separated operations meaning that in apply changes may be made that were not shown in the result of plan as the generated plan is only speculative. However, according to the Terraform documentation:

“You can use the optional -out=FILE option to save the generated plan to a file on disk, which you can later execute by passing the file to terraform apply as an extra argument. This two-step workflow is primarily intended for when running Terraform in automation”
(HashiCorp)

This way additional steps such as testing and general quality assurance are done at the actually used artifact.

Next Steps 🪜

In the previous posws we already looked at how IaC came to be and why we need it in our modern world. Now, being familiar with the tool Terraform and its history, in the next post we will dive into testing Terraform!

Cover image by RDNE Stock project! 🥳

Navigating a Code Basis as a Newbie (and beyond)

Jessica Veit — Thu, 25 May 2023 09:57:14 +0000

A new pupil of mine does a great job. Their current task is to get to know the code basis and implement some smaller features into it in order to do so. What I like about them - They asked me whenever something is unclear. And they asked very good questions so far! However, most of them are questions for which they could find the answers themselves would they only invest 10 more minutes, and here is how ...

The Curse of Impatience ❤️‍🔥

The pupil is full of drive and energy, and thus wants to feel this sense of reward whenever one completes a task. Because of this, they grow impatience pretty fast. And this is nothing new to me, in fact I was just like them when I first started working as a developer.

I remember how my mentor grew progressively tired of me asking questions that I could have easily answered by myself, not because they weren't a good mentor, yet they also had their fair share of work to do. Back then I didn't really see the big deal and now that I am in his shoes, there isn't a big deal. The problem is the context switching my mentor and now I have to go through that sucks a lot of energy from you.

Breaking the Habit ⛏️

So, investing 10 more minutes sounds reasonable and managable for someone eager to deploy their next feature tomorrow. Yet how should these 10 minutes be spend? As I told you before I have been just like them and nowadays are these the things I do in order before going forth and asking a collogue about it:

Zero. Take a Step Back: Get up from your desk, look out of the window for a minute, get a coffee - do something to break that tense feeling in your mind.

1. Planning Before Coding: This is something I always do by now. When I have to implement a more complex feature requiring changes in multiple classes a add comments in each of them outlining what has to be done here and there. Then I start creating a bunch of automated tests before a start the acutal implementation.

This procedure helps me to get an overview of what I have to implement and where the code has to go. A big benefit I see with this is that I can estimate wheter what I had in my mind would theoretically work or not. Therefore, giving me a good head start for the actual implemetation.

2. Git Blame: And no, I don't want someone to screenshot some piece of code, sending it to someone with a message reading: "What did you think when writing this?". In the teams I worked in so far it was a custom to add the ticket number at the beginning of each commit message. With this valuable info one can just open up their ticketing system and search for this specific ticket. If you know what the requirements back then where you will probaly understand why the code is the way it is.

3. Look at the Tests Implemeted: Another way to understand what a piece of code was meant to be doing is to take a look at the implemented tests. Given there are any, they usually give a good overview of what real-life cases the code was intented to be used in. Looking at how the code is used and with which data the calls are supposed to be working should give you a good graps of the domain logic abstracted.

Tip: In some intances, as I looked at the ticket related to this code beforehand, I even add some tests myself when I see them as fitting. This way I can check wheter I understood the requirements correctly and we even get more tests for the code which is always a good thing.

When I do it, I mention it in our daily meeting and create a separte merge request for it. In my team such work is gladly seen, yet check in with your colluges before doing so.

4. Use Break Points: Using the tools provided to us by your IDEs of choice is another option you should consider when stuck in a new code basis. With them you can see which snippets are executed at which point in time and what parameters are thrown all about. In this sense, any kind of debugging you are using in your daily life might also be used in a discovering sense.

5. Break it: Moving a little further away from this conservative approaches - I would claim that we all work with some kind of source control. If I don't seem to unravel the mysteries surrounding the code I need to work with, I simply start removing some of it. That way you can see what test may fail now, which things behave differently and which things simply stopped existing.

I hope these tips may help one or the other developer, pupil or mentor. On my part doing all of them in order until I found what I have been looking for takes about 10 to 20 minutes, yet having years and years of routine with it, this is not suprising. So, don't worry if it takes you a little longer than that!

What are your tips in this regard? I would love to hear them from you and improve my one routine!

Cover image by Yan Krukau! 🥳

Note: When looking into this topic a bit more on our beloved dev.to I also found this well-written post by Nicolas Frankel. Go checkout that post as well if you want even more tips on this topic!

📝The Origins of IaC

Jessica Veit — Tue, 23 May 2023 07:04:32 +0000

Infrastructure as Code is a key element of most top performing engineering setups. It’s a big leap forward in the way Ops and Devs interact with their own infrastructure. (Galante, 2021)

After the introduction of the QA and IaC topic in the first blog post of this series, we now dive head first into the origins of IaC - Why do we even need to in the first place?

The Need for Automation 🤖

The massive adoption of cloud over the past years has forced the need for automation in the infrastructure sector. As shown in the hype cycle depicted below, topics like industry cloud platforms or cloud sustainability are an innovation trigger ready to define new industry standards soon. Previously a change in infrastructure was limited by the hardware purchasing cycle often spanning weeks before a new piece of hardware arrived. Due to this circumstance, there was no need to rush its proper setup (Morris, 2016).

Hype Cycle for Emerging Tech (Perri, 2022)

With cloud deployment of virtual anything needed in infrastructure can be configured, deployed, and destroyed in a matter of minutes. This of course leads to fast provisioned yet poorly maintained systems, an ever-growing portfolio of servers, sometimes even spanning multiple cloud providers, and configuration drift as well as snowflake servers.

Early on it was clear that the full potential of cloud could only be utilized using novel tools, which for one, help to automate deployment, and additionally, enable those responsible to maintain the system with reasonable effort. As Morris put it...

The essence of Infrastructure as Code is to treat the configuration of systems the same way that software source code is treated.

... only the reorientation of infrastructure development and management towards software development can ensure the most efficient handling of this new and unique technology.

Four Levels of Operational Maturity 🌡️

The full automation of processes and making them auditable, scalable, and their results reproducible nowadays is the overall goal of the ongoing digitalization. In this context the question of maturity of a system or procedure, as in this case, the operation processes, always needs to be answered before progress can be made. For practices of provisioning in operations there are four levels of maturity define by HashiCorp:

Manual
Semi-Automation
Infrastructure as Code
Collaborative Infrastructure as Code

Each of those stages is characterized by how the infrastructure is provisioned and how traceable changes made are as well as the ability to rollback and collaboration, respectively reuse, possibilities. The model provided also corresponds very well with the common maturity model seen over the whole operation department. There is a general agreement on a model similar to the hereafter graphic representation by Accenture:

Operational maturity model (Henneborn & Mody, 2021)

It also describes a stable, yet labour-intensive workflow at the start of operations, it then gets more and more efficient by automation until the processes are orientated towards only judgment-based manual tasks, automating the others. With this it can be seen that the clear definition of what level of maturity in the provisioning regard a company currently has, is crucial for the introduction of IaC workflows and tools in operations. It defines the starting point of this operational evolution leaning more and more towards DevOps.

Next Steps 🪜

In the next blog post Terraform comes into the picture. We are going to discuss how this tool works and see what we can do with it. So, stay tuned if you are interested!

Cover Image by Skitterphoto! 🥳

📝Why QA for IaC is important

Jessica Veit — Tue, 16 May 2023 07:44:14 +0000

The world of Clouds ☁️ A seemingly magical place, scalable to the prim and the epitome of automation. Yet I wouldn’t be the code quality advocate that I am, if my first question here wouldn’t be: How do I test it?

The past months I immersed myself in Terraform, an Infrastructure as Code tool, and embarked on the quest to find out how different or maybe similar testing IaC is to test our well-known general-purpose code. Yet, let us not get ahead of yourself. In this post we are looking at what Infrastructure as Code acutally means and how quality assurance comes into play in this field.

Infrastructure as Code and QA 📋

Infrastructure as Code (IaC) is currently fundamentally changing the processes in IT operation departments. It is the practice of provisioning infrastructure with an (often) declarative approach promoting scalability and automatization in this sector. Although it is not a new technology with the first impactful launches of IaC tools by HashiCorp and Azure in 2014 its usage picked up significantly in the past years as the cloud computing sector started to grow incessantly. Not at least because of the pace infrastructure is to be provisioned in the cloud nowadays, IaC is the future of operations.

Yet, even though this practice is seen as the new industry standard, testing and general quality assurance as well as maintenance of the implemented code is still a blank spot in research. For this reason, this blog series aims to give an overview of the state-of-the-art IaC technologies and their potential pitfalls, defects and misconfigurations that can impact the final infrastructure deployed as well as point out its similarities to the development and testing of general-purpose languages (GPLs). The information presented are a combination of literature research and practical implementation in form of proof-of-concepts with Terraform.

Why QA is important 🛎️

We evidence that the field of development and maintenance IaC is in its infancy and deserves further attention. (Kumara et al., 2021)

In software development, code testing, agile workflows, the practice of continues integration and delivery (CI/CD) and versioning of source code were heavily adopted over recent years not least thanks to pioneers like Robert C. Martin and Martin Fowler. It was a clear response to the rapid pace of change in demands and expectations of end users as well as the progressing digitalization in virtually every sector imaginable – the assurance of code quality. In parallel to these developments in the software sector, also information technology (IT) infrastructure has undergone many innovations, with one being Infrastructure as Code (IaC).

Infrastructure-as-code (IaC) is the DevOps tactic of managing and provisioning infrastructure through machinereadable definition files, rather than physical hardware configuration or interactive configuration tools (Guerriero et al., 2019)

... and it thus paves the way to unite development and operations (short DevOps) in a way it has not been possible before. With IaC network engineers can utilize the aforementioned software development practices that, until now, were exclusively applicable in the domain of software development. Like with general purpose code, IaC scripts form a living, comprehensible documentation more accurate than any configuration management database (CMDB) could ever do and enable a new chapter in the QA of infrastructure as a whole.

This is important due not least to the very high risks of deploying new software, be it a software service or an IaC script, without rigorous QA, have greater implications now than ever before. As the IBM Cost of Data Breaches Report 2022 showed, depending on the effected cloud environment the breaches average cost for companies are enormous (Ermetic Team, 2022). With these cloud-based breaches, which account for 45% of all data breaches included in the report, the seriousness of this issue, especially in the prospect of the ever-increasing adoption of cloud computing, cannot be ignored. For this reason, it is not just important to lay the focus on generally making infrastructure deployment simpler at its core with IaC, but simultaneously define and improve its testing options. Because in software engineering untested code is one of the most effective ways to generated legacy code fast as...

Tests document the intended behaviour of code which is a tremen-dous help for future developers to understand it. (Schweighofer, n.d.).

Next Steps 🪜

After understanding the issue the next logical step is to understand how IaC came to be and what it means in the boarder context of IT operations. So, get ready for the origin story of IaC in the next post!

Photo by Pixabay! 🥳

Organization as Motivation

Jessica Veit — Wed, 03 May 2023 12:48:23 +0000

I am just gonna throw this in here: Is anyone familiar with The Magic of tidying up?

Marie Kondo is a japanese organizing consultant teaching people how to organize and declutter mostly their physical spaces, which in turn also has a huge emotional effect on them. Words that often are heard in her TV series or read in the aforementioned book are joy and gratitude. Basically, only hold on to the items that spark joy for you and be grateful for the service items you no longer need served you.

So, what has that to do with coding? When I took a closer look at this magic of the sympathetic mother of two living on the other side of the planet, I saw a valuable lesson in her teaching - especially for my pupil and co-worker. I do not know who else needs to hear this, but just read the following lines carefully:

Change whatever you like in your local copy of the code, we have Git.
Of course, be sure which changes you check into the repository, but be assured, if they are still enjoying some leisure on a nice and comfy feature branch of yours nothing bad can happen (except the occasionally failing pipeline yet show me one developer who did not accept the responsibility for that little red icon). Again - Git.
And even if your changes land in a trunk, main or production branch - it is all cool. As long as we know about it no one has to stay and badge up the damage in the course of an extra night shift.

All nice and well, but what has all of these reassurances to do with the magic that introduced this post and why would anyone post these self-evident statements about Git?

Git (as well as other source control tools to also get this out of the way) gives us as developers a unique opportunity other professions can only dream of. We have to power to make changes disappear, to change to way of history and are the masters of the now and the a little bit later! And... Okay, but let us be real here, we can try out ideas basically for free. Of course, every action consumes at least some time, but we trade this time for findings we would have never known about otherwise.

So do as you please with your code, especially if you are an beginner. Do not be afraid of getting rid or let us say letting go of one or the other line of code (and please, stop leaving code comments in there). Ask yourself does this line of code spark joy aka do something good for the system seen in its entirety? and feel how freeing and motivating this minimalist approach to coding can be.

Photo by RODNAE Productions!

What is Some Random Tech-Fact you Know?

Jessica Veit — Mon, 13 Jun 2022 06:18:33 +0000

We all have something living rent-free in our heads 🐛. Be it a meme, gif, song or something completely different. Yet most of them are basically a File on some server, something only existing digitally (next to our minds). These are the true wonders of our technology as they make us happy.

Our Everyday Heroes! 🦸🦸‍♀️

And just like those - which can also be found on every meme Monday here on dev.to - every engineer has some random tech fact someone with another profession would probably not know 🧠.

So, here goes my rent-free Tech Fact concerning hardware limits:

The Bekenstein bound limits the amount of information that can be stored within a spherical volume to the entropy of a black hole with the same surface area.
Read More About it on Wikipedia

And something more coding related - Atwood's Law:

Any application that can be written in JavaScript, will eventually be written in JavaScript.

Photo by Binti Malu on Pexels 🎉

Why you Should get Into Coding Patterns Right Away 🏁

Jessica Veit — Tue, 07 Jun 2022 06:36:13 +0000

First and for most - I would love to hear your thoughts on

When in ones developer journey should one look into the topic of patterns?

As of my opinion is as early as possible and here is why! 😊

Software development can be simply descripted as solving problems and occasionally drinking coffee ☕. Although this is what we as developers do and also what we hopefully enjoy doing, there is not always a need for that. You might ask why? Well, firstly that in your hand is properly not your first one of the day, and secondly lots of people, especially four very dedicated man, already did a lot of thinking for you 🧠.

Disclaimer
Do not get me wrong, finding your own way of problem solving and kind of developing a 64-bit sense for it is a crucial skill you need as a developer, yet I think especially for beginners it is not any less interesting as it is educational to see how other people approach all sorts of problems.

Where to Start

When talking about design patterns in software engineering the Gang of Four Design Patterns are what most people think of. Those are your goto for any sort of somehow generic problems like...

Factory Method: To create instances of different implementations of an interface.

Composite: To compose objects into tree structures and work with these structures like with individual objects.

Iterator: To iterate all elements of a collection without exposing their underlying representation.

Just to give a quick overview on those patterns, there 23 of them, categorized into:

Creational Patterns
Structural Patterns
Behavioural Patterns

In the book Design Patterns: Elements of Reusable Object-Oriented Software each pattern is descripted and exemplify with UML diagrams, template source code and a real-world example. It is very well-written and gets you right into the different topics and use cases.

How I Practiced Them

Back in school, my professor always did the following three-step-approach of showing us the purpose of a new pattern:

Explain a problem
Give time to the students to come up with their own solution
Discuss the approaches and present the pattern-solution

I loved this technique of him teaching us as we were given the chance to think about a problem and understanding it as a whole. Additionally, since then I always had a distinct example for every pattern in my mind!

What to do Next

So, now that you got all your sources of information ready, maybe even a collection of code snippets and explanations, what next? Think through them, maybe find real-life examples based on your own experience and code, code, code as one of my professors always used to say:

I didn’t really understand it - until I tried it!

In the End

Design patterns are a great thing to know. They make the life of a developer much easier and are optimal against headaches and bad code design, yet bear in mind that these patterns should support you and you should not just blindly follow along.

Understand what code can do and what you can do with code!

Photo by Jonas Svidras on Pexels 🎉

Ps.: Also an amazing tip in terms of improving your coding skill and the overall quality of your code is the Clean Code Initiative providing the theoretical input and also a roadmap on how to go about it.

What Games can Make you a Better Developer? 🎮

Jessica Veit — Mon, 30 May 2022 07:54:20 +0000

I believe in the power of YES... concerning, if you want to take away something from everything, you can! Recently, I treated myself with the indie game Papers, please!, which in its core is about being in a boarder checkpoint, checking papers of travelers and potentially finding forgeries.

So, what does this have to do with my professional career as a software developer? Easy, doing code reviews, comparing files and finding mistakes in them 😄📝!

What games do you feel let you practice some handy skill, not only speaking of professional situations and not only thinking of video games? 💭

Photo by Francesco Ungaro on Pexels 🎉

Accepting Your Lows and how to get out of Them

Jessica Veit — Tue, 24 May 2022 12:09:27 +0000

You wake up with a headache hammering like crazy, feeling like your mind is trying to grind the coffee beans by itself today, or your car breaks down in the middle of nowhere just like the service you deployed last week? Everyone knows these days, everyone is trying to survive these days, and everyone knows these days will always creep up on you at some point. There are days or even weeks where you seem not to make your compiler happy, your threads won't act like they are supposed to act and eat each other up in endless dead-locks, and on top of all this - the coffee machine broken.

It is easy to slip of into a numb state on difficult days where you are just trying to survive the eight hours in office only to go home and worry even more about every single line you may or may not wrote today. Everyone is going through a phase like this from time to time, it is completely normal, it is human. Sure, the thing is that, if you are really stuck, like really stuck, sleeping till eleven on a Saturday and enjoying the well-deserved weekend may not be enough. And just going on holiday in the middle of an important project is also not on the table for you. So, what to do about all of this?

Well, what gets me out of situation like these is:

💪 Reminding myself of accomplishments
📖 Refreshing my knowledge by going over best practices or patterns as well as expending my horizon with new stuff (it does not have to be about coding all the time 😉)
🙇‍♀️ Not forcing myself to anything and always staying clear of the purpose of why I am doing something

And on top of all
Reminding myself why I used to love what I do and how I got where I am today.

As I said, I believe everybody has their lows from time to time, which begs the question of What are your to-goes when it comes to overcoming these times and maybe coming out of them stronger, smarter or even happier than before? 👼

Cover picture by Engin Akyurt on Pexels 🎉

Where There is Code There Should be a Review (but Why?)

Jessica Veit — Thu, 19 May 2022 09:41:40 +0000

Lately, I was asked by one of my trainees why I am so persistent when it comes to code reviews. An interesting question if you ask me, so I decided to take a closer look as to what my big Whys were, and also wanted to ask you what you think about the (sometimes feared) Code Review 👻💻!

No matter if your dev-team is looking on a Scrum or Kanban board on a daily basis (🥁) there most probably is this one column with a header like To Verify, Testing or Q’n’A written prominently above it. Why? Well, in my mind there are a lot of good reasons for cultivating code reviews within, especially small, dev-teams:

👌 Quality Assurance: Four eyes always see more than two and so potential bugs or pitfalls can be fixed on the spot. The argument of quality of course needs to be the first point on this kind of agenda as it is the most practical reason for their existence.

🏝️ A Break from your own Tickets and Code: Personally I love nothing more than spending Monday mornings with some delicious coffee reviewing new merge requests to again find into the right mindset for the week and stay up-to-day with current developments.

🌱 Everyone Learns Something new: Of course, always depending on your levels within the coding domain, both – the coder and the reviewer – will always learn something new in the process. Be it how to do something or how not to do something.

💬 More Communication: Especially with home office and remote work, working together changed a lot over the scope of the past few months (and actually years!). The biggest pain-point for most people probably was the lack of interaction with their peers and colleagues, and personally within the scope of reviews I communicated the most with my co-workers also on a personal level.

What are your opinion on Code Reviews? What other Whys do you see (so I can hype my protégé up even more when it comes to them)?

Looking forward to hearing your thoughts 😉.

Cover picture by Markus Winkler on Pexels 🎉