DEV Community: Svenja Schäfer

3 Question Framework – How to Respond Without Reacting

Svenja Schäfer — Sun, 02 Feb 2025 22:10:43 +0000

First published on thoughtbot

Last year, in 2023, I applied internally for a Development Team Lead position – and got the job 🎉. Basically that means that I manage wonderful folks on top of continuing to work as a developer and consultant. My add-on focus, so to say, is that I work with my teammates to identify areas for growth, ways to maintain and raise their level of fulfillment, and to give and receive feedback. We also catch up about what’s going on in our lives and how we feel, in general.

The idea behind the 3 question framework is a result of one such meeting I had with a teammate I support. We were discussing experiences we both had where we felt we didn’t work efficiently because we were constantly answering questions and reacting to comments on Slack. We do this because we really care about one another and we find fulfillment in helping others. But in doing so, we didn’t give others the chance to contribute or to find answers on their own. On top of that, it was frustrating as we were slower in finishing our own tasks.

After that meeting, I thought about a way to prevent this from happening. It wasn’t as easy as just saying “stop reacting to posts, focus on your own tasks” because as I mentioned it fulfills us to help and we definitely don’t want to stop doing it. A balance was needed. That balance called “3 Question Framework”.

THE FRAMEWORK

As the name implies, the framework consists of three questions to ask when you find yourself reading comments or inquiries that give you the urge to react to them. These are the questions:

Is the comment or question directly related to my work?
Can the author answer the question themself?
Is there someone around who can answer?
Although we have three questions, you might be done with the framework after answering the first. If you answer with “no, this is not directly related to my work”, then you have to force yourself to bring your focus to your own task. Do not react to the question.

If the comment is related to your task, move to the second question from the framework: can the writer answer the question themself? Maybe they are looking for a document or similar and are asking if someone knows where to find it off the top of their head. If this is the case and you would need to search for it as well, you do not react to it.

If they can’t answer it by themselves and given that it is related directly to your work, you go to the third and last question: are there other folks in the team who can react to the post. If there are, give them the chance to answer – and I use “chance” intentionally. You keep yourself in the background and focus on your task.

Finally, if there is a post that is directly linked to your work where the author can’t proceed without input from you alone, that is the only time when you will answer.

THE IDEAL

Ideally, you don’t want to use this framework forever. You should use it as a method to trick your brain into not reacting the known way: immediately reacting to every message. I can say that it helped my teammate and myself. If you are worried you might come across as rude, you can inform your colleagues that you are trying out this framework. And if you did use it, let me know what you think and if it helped you or your mates.

Understanding Regular Expressions once and for all [PART 4]

Svenja Schäfer — Mon, 17 Aug 2020 07:17:56 +0000

Originally published at: Codegram's blog

Here comes part 4 of the "Understanding Regular Expressions once and for all" series. Until now, you should be able to match literal characters, numbers, spaces at the end and beginning of a line. Also, you are aware of the optional character - the question mark. And you can check if a character appears minimum once or zero times thanks to + and *. So far, so good. Today, it's time to meet brackets.

DINNER WITH [FRIENDS]

Imagine some friends will come over for dinner. And you have to prepare the evening, including - of course - the dinner itself. You look through all the recipes but this time it's not super important what you cook (ingredients), but for how many people it is. Our task: only matching recipes for the number of friends coming over. Let's say, 5 friends will sit at the table tonight. We could write something like this: servings: 5. But while this is a totally accepted expression, we want to make it a bit more "regex-like". Also, there's always this type of friend who brings someone with and another might cancel, so a range would be better suited. Ranges can look like this: [0-3]. So, our expression could be: servings:\s[4-6]. With this, we would match the recipes for 4, 5 and 6 people.

But what if we run a nice vegan BBQ party? We expect to see about 12 - 16 people. How can we match that? Remember, that we match a single character. Always. If we want to match more, we specifically have to say it. We could end up with something like this: servings:\s[0-9]+ but with that, we would actually match any amount. Useless. We could, however, write this: servings:\s[1][2-6]. Nice, isn't it?

The square brackets also work with any other character. For example, if we want to match all recipes starting with a capital B (like the B in BBQ), we could use this expression: ^B, right? But what, if the recipes we are looking for are ordered under G (like in Grilling)? Easy-peasy with our square brackets: ^[BG]. You see, it doesn't have to be a range we are looking for. Any character inside the square brackets can be a match. Can, not must!

EXCEPTIONS, EXCEPTIONS

Did you see in the previous expression, that the caret character is outside the square brackets? That's not an error but has a good reason. If it were inside like this: [^BG], we would match any recipe that doesn't have a B or G. The ^ inside square brackets means not. Sure, we can use this as well. For example, like this: ^[^AC-FH-Z]. With that, we wouldn't match any starting uppercase letter besides B and G. To exclude any lowercase characters as well, we could change the expression into: ^[^a-zAC-FH-Z].

Yes, square brackets are pretty useful and like the rest of regular expressions powerful. But there are more. More brackets. Curly ones for example.

Remember, when we covered matching multiple digits in Part 3 of this blog series? We used * or + for it. But what if we don't want to end up with endless repetitions of a character but matching a specific amount? Say hello to {}. Whichever character length you want to define, this is the expression for it. So maybe we want to find all digits with the length of 4 in our recipe, like 1000 ml. Just because we want to change it into 1 litre. We could write \d{4}. Even ranges are possible with these neat brackets. To match minimum four and maximum six characters, the regular expression would look like this: \d{4,6}.

See, with only two types of brackets, you can be so much more precise. Imagine what you can do with three types. That's exactly what we will learn in the next part. But until then:
^Ke{2}p\s[n-p]+\slearning$.

Photos by Jessica Ruscello on Unsplash

Rails Engines - Independent Heroes

Svenja Schäfer — Thu, 28 May 2020 18:36:12 +0000

Originally published at: Codegram's blog

If you have built a Rails application in the past, chances are that you used Rails engines already – maybe unknowingly. The well-known devise gem, for example, is based on Rails engines. But what is it exactly? Well, simply put a Rails engine is the miniature edition of a Rails application. It comes with an app folder, including controllers, models, views, routes, migrations... The difference though is, that an engine won't work on its own. To show what it's capable of, it needs to become part of something bigger - a part of a main Rails application.

THE POWER OF INDEPENDENCE

I can hear your question: if we still need a main application and an engine is just a small edition of it, why do we need it in the first place?

Well, let me tell you of a van I bought a few years ago. A 1984 Volkswagen LT. Huge, kind of old, lots of adjustments made by more or less experienced former owners with a lack of documentation. Sounds familiar? This could be true for some larger applications as well.

Like this one, only in red. Photo by Tobias Tullius on Unsplash

When an app starts to grow, when it becomes huge, one can get confused. You are scared to touch file "A" because it is somehow related to file "S" and file "P". Maybe that's not even the case any longer! Maybe you don't need the file "S" any more. Fact is, bigger applications can drive you nuts easily. Wouldn't it be better, if you could separate some components? Wouldn't it be better if I could fix, test and improve the wires of my van without the need of the actual van? Or the motor? Sure, it would. And that's exactly why you might want to think about using Rails engines.

You have a nice, clear structure where tasks are separated into different components
You can and will test them on their own
You can add and remove engines at will from/to your main application

But, same with everything in life, big decisions (outsourcing parts of a larger application into engines is one of these decisions) come with a good portion of responsibility.

YOU'RE ALLOWED TO EAT ANYTHING BUT NOT TO KNOW EVERYTHING

With engines it's the same as with that German phrase: they can include anything (controllers, models, gems, routes, migrations, ...) but they must not know about any behaviour of the main application.

What does that mean? Well, I told you about my van. Like any other car or van, it has a fuel system. This system should work. No matter if it's part of my van, your car or my Dads' bus. It should function totally independent and it should not care about the global picture – in this case, the car, van, bus. If it cared about it, yes, if it even would rely on the outer shell, what's the idea of having it separated in the first place? Why not creating a fuel system individually made for each car? Sure, that wouldn't make sense at all. And that's why it doesn't make sense for our engines either. Use them as independent heroes for your main application, and don't mix up responsibilities.

Once you are aware of that, the next thing you want to take care of, is the testing part. Actually, it's kind of the same: you have an independent miniature application that should function on its own, 100% apart from any main application. S*o, the most obvious solution is testing it separately, right? Right. As the engine shouldn't know about anything of the main *application, stick to tests that are important to that engine. That doesn't mean you shouldn't have tests that cover the integration of the engine but these tests should sit inside the main application, not inside the engine.

Photo by Ashutosh Dave on Unsplash

The first step is always the hardest. But let me give you some resources that will make it easier. For a good technical overview, I'd suggest following the official Rails engines tutorial. This shouldn't take too long as you already know what engines are. You also can read about "component-based rails applications" as they use rails engines quite often. Once you feel more confident and aren't afraid of a challenge, head over to decidim - The participatory democracy framework. It's an open-source application that is fully based on engines. Fully means fully so it might feel a bit overwhelming at the beginning. But as it's open-source, you can see and use the whole code. There's also a detailed documentation included, so don't be afraid and give it a try!

And finally, if you want to know why decidim looks the way it looks like and why it's based on engines, read the case study on: codegram - Bringing institutions and people closer together.

In case you have questions and/or suggestions, I'm happy to hear from you!

Photo by Kumiko SHIMIZU on Unsplash

Understanding Regular Expressions once and for all [PART 3]

Svenja Schäfer — Fri, 08 May 2020 16:40:26 +0000

Originally published at: Codegram's blog

Welcome back to the third edition of Understanding Regular Expressions once and for all. By now, you shouldn't freak out any longer when seeing something like this: /^\d$/. In case you are really scared, you might want to read the first parts of this series (again): Understanding Regular Expressions once and for all [PART 1] and Understanding Regular Expressions once and for all [PART 2]. If you are just a little bit unsure, let me recap what we've learned:

HEATING UP

These are the characters we know about (and don't forget the literal characters):

^ - the hat/caret character matches characters at the start of a line/string

$ - the dollar sign matches characters at the end of a line/string

\w - matches word (alphanumeric) characters (including underscores)

\d - matches digits

\s - matches whitespaces and line breaks

\b - the word boundary pattern

. - matches any character except line breaks

And here's the most important sentence from part 1:

Do not read the word itself but each character separated.

With that in mind, let's have a look at the expression from the beginning: /^\d$/. We have the opening slash which indicates that a regular expression starts. After that, we see the caret character. So the character we are looking for is located at the very beginning of a line. The following backslash should make you aware that the next character is somehow important. As it's a d, we know, it's an expression to match digits. The last regular expression is the dollar sign which means, the digit must sit at the end of a line. Confused? Great. /^\d$/ doesn't mean anything else than matching these options:

There is no character before the digit, nor after. Just the numbers 0 to 9.
Truth be told, most of the time, we want more. A single character is a bit lame.

GOOD THINGS COME IN THREES

Spoon, knife, fork. Yellow, red, blue. Regular expression quantifiers. Well, honestly, there are a lot more than three, but the three quantifiers I'll show you here today are a fabulous start. Just believe me.

As we said, /^\d$/ will match a single character only. But, and see how easily I get the transition to my second favourite topic: food (right after regular expressions), what if we are looking for all digits at the beginning of an ingredients list? It makes a huge difference, if you have to use 1 tablespoon of soy sauce or 10, right? Right. So how do we do that? We know it must be at the beginning of a line, so the caret should definitely be part of it. And the expression to match digits. So far, our regular expression would look like this: /^\d/.

And here's the recipe we'll work with today:

Vegan Mayonnaise

120 g Cashew nuts

60 ml Olive oil

125 ml Oat milk

2 tsp Apple vinegar

1 tsp Maple syrup (or another sweetener of your choice)

Salt

We would match 1, 6, 1, 2 and 1. That's bad. I don't wanna know what mayonnaise tastes like with 1 cashew nut, 6 ml olive oil and 1 ml oat milk. So, we want to match all digits. Say hello to the + character. The plus sign indicates that the preceding character will be there minimum once but maximum endlessly. Important is the minimum once part. So if we end up with a regular expression like this: /^\d+/ we would match all the digits at the beginning of each line: 120. 60, 125, 2 and 1. The + can be used for every other regular expression as well. For example /Mayon+aise/ would match Mayonnaise, Mayonaise and even Mayonnnnnnnaise. But not Mayoaise. And let's be honest, who doesn't have trouble with this word and prefer sticking to the short version Mayo instead?!

Okay, with the + sign, we finally caught all our ingredients. Kinda. We're missing the salt. Personally, I like salt, so I don't want to miss this part of the recipe either. But, instead of + where the digit must exist minimum once, I can use * . When using the asterisk, or (little) star, the preceding character gets matched minimum zero but maximum endlessly times. So with /^\d*/, we would get the ingredients that use a number and the ones without. And with the * character, we covered two of three exciting quantifiers.

NOT SURE?

The third quantifier is fairly similar to the asterisk (*) sign. You use it when you're not sure if the character before it is there or not. The difference is, that if the character exists, it will exist once, not two, three or endless times. And it looks like this: ?. A question mark. The word Mayonnaise is a nice example for this one again. Two or one "n"s? I said, that we match the anterior character, so what would the regular expression look like?
If you have something like this /Mayon?aise/ I must ask you to give it another try. At least if we want to match the correct spelling. Remember, the ? matches characters that exist minimum zero times but maximum one time. The correct regular expression would be this: /Mayonn?aise/: maybe the second "n" exists, maybe not.

I hope there aren't any more question marks over your head for the moment. But if so, don't hesitate to reach out to us! And get excited for the next part of Understanding Regular Expressions once and for all.

Photo by Mitchell Luo on Unsplash

Understanding Regular Expressions once and for all [PART 2]

Svenja Schäfer — Tue, 28 Apr 2020 16:19:21 +0000

Originally published at: Codegram's blog

Welcome back to Understanding Regular Expressions once and for all [PART 2]. The first post covered some basic regular expressions, like literal characters, the caret (^) and the dollar sign ($). If you have missed it, check it here: Understanding Regular Expressions once and for all [PART 1]. If you are ready, let's grab our food bowl and start with some delicious regular expressions.

IT'S ALL ABOUT THE CHARACTER

Well, firstly I think we'll need a new example. And as I want to stay in the food section, I think a whole recipe might do the trick. Remember, you can copy and paste it to your editor of choice and follow along.

Scrambled Tofu (15 minutes)

Easy to prepare and super delicious. A vegan scrambled eggs alternative. 
Give it a try!

WHAT YOU NEED:

2 tbsp oil
1 small red onion (chopped)
2 garlic cloves (minced)
400 g silken tofu
1 1/2 tbsp tamari/any other soy sauce
1 tbsp nutritional yeast
1/4 tsp curcuma
salt 

OPTIONAL:
tomatoes
mushrooms
spinach

INSTRUCTIONS:

1. Heat a (non-stick) pan.
2. Add oil and onion and stir until onions turn translucent. 
3. Add garlic and stir another minute.
4. Add silken tofu - you don't need to worry about the liquid.
5. Add tamari, nutritional yeast, curcuma and salt.
6. Stir until everything is combined.
7. Cook with medium heat until some liquid vaporized.
8. Serve with bread and vegan butter.

Write a comment on www.write_your_opinion.com

So, by now we should have a fair understanding of literal characters inside regular expressions. Means, all of you should know that /oil/ would match all characters in our recipe that contains o, i, and l (in exactly that order). But sometimes, we don't want to be so explicit but maybe we are looking for numbers, or words. Guess what, there's a special regular expression for it. Let's start with numbers. But as we've learned before, regular expressions check each character on its own. Well, 400 for example, is a number but it consists of three digits: 4, 0 and 0. That's why the first regular expression pattern we are looking for today, isn't called \n but \d – for digit.

I mentioned the backslash in the first part already but as a reminder: if the regular expression would look like this: /d/ , we would match all d's in our recipe. But we are looking for digits, so we need the backslash to tell that we gonna use kinda predefined pattern to match all digits.

A bit less strict is the word character, that looks like this: \w. Using this pattern, we'd match all alphanumeric characters. So basically all letters, no matter if capital or lowercase and all digits. Also, underscores (_) will get matched, for example, the URL in our recipe. But no ', (), / or spaces. Actually, spaces are a common task to look out for. They don't belong to digits and although you could write the pattern to match spaces like this: / /, it's not very easy to read. Luckily, there's a special character for it: the whitespace character: \s. Not too difficult, right? For digits, we use \d, for words \w and for spaces \s.

And just when it starts making sense, I'll create a bit of chaos. But don't worry, not for long.

Sometimes, we just want to go nuts and match everything. Literally everything. We are hungry. For that, we need a very, very important special character: .. Yep, it's a dot that will bring us the power to match the whole alphabet soup – and even the spaces in-between. Crazy, isn't it? But what's the chaos I mentioned? Well, there's no backslash. So if you want to literally want to match a dot - and only a dot, you have to escape it with a backslash. So while . matches everything, \. will match dots only.

BRAIN FOOD

I know, it was a lot to take in. So, let's review all the things we've learned. If you are in the unfortunate situation of not being able to open your editor, have a look at this short video where I apply the patterns we just learned. At first, we catch all digits. After that all words, all spaces and at the end, we use the fantastic but sometimes scary . character to match everything:

As you have seen, when we use \d to match all digits, we literally match all digits. Same with \w – we match all word characters. While that is logical and correct, it also might be a bit confusing as it seems the \w expression matches whole words. That's not the case: it matches each character on its own. One way to make it easier to understand is when we use the hat/caret character: ^. In combination with our digit expression, we'll get the following result:

Have a look at the number 400. We will only match the 4, as that's the digit at the beginning and exactly what we are looking for – for a single digit at the start of a line. You can try the other new expressions in combination with the hat as well: /^\w/, /^\s/ and even /^./. See, our expressions start to look cryptic but you are able to read them! That's amazing! We can do more. Guess what the following regular expression might match before you enter it to your editor: /\b\w\b/. The \b character was the one for word boundary and we covered it in the first part.

And, did you figure the correct answer?

Header photo by Simon Matzinger on Unsplash

Understanding Regular Expressions once and for all [PART 1]

Svenja Schäfer — Tue, 25 Feb 2020 09:45:22 +0000

Originally published at: Codegram's blog

Did you ever try to learn Regular Expressions and felt a bit overwhelmed when getting confronted with a bunch of characters? Characters that – in correct order – are able to create any kind of search pattern you were looking for? If so, believe me, you are not alone. And good news: After this series, all the question marks in your head will be gone and you might start using regular expressions asking your friends for their dinner plans. (-> send them a link, so they can answer)

WHAT’S THE FUSS ABOUT

To get an idea of how regular expressions are structured, let’s have a look at a very simple example: Let’s imagine we have the following sentence:

Hummus is a dip made from chickpeas, tahini (optional), lemon, garlic and some more spices.

We want to check, if chickpeas are an ingredient of Hummus, so let’s write our very first regular expression: /chickpea/. That’s it. That’s a fully working and acceptable regular expression. The important part is, how you’ll read it: Do not read the word itself but each character separated. Start at the very beginning:
/ implies we’ll write a regular expression. Followed by c, by h, an i, c, k, p, e, a and finally another /, that shows the end of our pattern. Et voilà, we’ll get a match because 'chickpea' consists literally of the regular expression we just wrote. And with that, you know one very important set of regular expressions: literal characters. So whenever you see a character without any other symbol (/, ^, $, … ), it’s a literal character. The fun starts with the next group though: the special character group.

WHEN YOU ENTER A RESTAURANT, TAKE YOUR HAT OFF

Let’s imagine, our text not only shows the explanation what Hummus is, but maybe has a whole food list. But we are only interested in Hummus, because it’s so damn yummy. So, we are looking for the very first character(s) of each line. To do so, we’ll use a special character: the hat: ^. Instead of writing /Hummus/, we’ll add the tiny hat in front of our literal characters: /^Hummus/. Like this, it doesn’t matter if one of the other foods maybe are made of Hummus, our pattern will only filter the word Hummus at the beginning of a line:

Hummus is a dip made from chickpeas, tahini (optional), lemon, garlic and some more spices. | Origin: Middle East

Falafel is a deep-fried ball (or patty), made from ground chickpeas, herbs, spices and onions and gets served with Hummus. | Origin: Egypt

Miso soup consists of a stock called “dashi” mixed with miso paste. | Origin: Japan

Tofu is made by coagulating soy milk and then pressing the resulting curds into blocks of varying softness. | Origin: China

Pay attention that the Hummus inside the Falafel description doesn’t get matched!

BEFORE YOU LEAVE, PAY!

Now that we’ve seen how to catch the beginning of a line, what about the end of one? What, if we want to get all the food from Japan only? We just could write our literal character expression (/Japan/) but maybe 'Japan' is included in the description part of the list as well. That’s not what we want. Also, if you use the literal character expression, you would get a match for “Japanese” as well. Again, that’s not what we want. We want to find “Japan” at the end of a line.
Coming back to our restaurant situation: we enjoyed a fancy dinner and what do we have to do before leaving? Right, paying the bill. And here comes our next special regular expression character: $ - the dollar sign. While the hat character gets added at the beginning of the expression, the dollar sign gets attached to the end of it like so: /Japan$/. And with that, you would be able to match Japan in the third row of our example.

Now that we know how to catch something at the beginning of a line (^) and at the end of a line ($), let’s have a look how we can match some pattern in the whole text. I mentioned that with this regular expression /Japan/, we would find each “Japan” inside our given list. But we would also match 'Japanese' because 'Japan' is part of it. If we just want to search for 'Japan', we need the word boundary character that looks like this: \b. This special character is different to the previous ones as it consists of two characters: \ and b. You’ll see the backslash in the next parts more often. It is a special character on its own and in this case it indicates that the following literal character 'b' is a special character, too. Another difference to the hat and dollar character is, that it not only appears once but twice: before and after the word you are trying to find. In our case, if we want to match “Japan” only, our expression could look like this: /\bJapan\b/. I said it’s gonna be fun, right?

COOKING TIME

Reading about regular expressions is one thing, writing a totally different one. So let’s jump to our kitchen and prepare some nice regular expressions. Although there are different tools out there to test regular expressions, we’ll keep it simple and use our favourite editor for now (mine is Visual Studio Code). Create a new file 'hungry-regex.md' and copy the food list from above. Open the search bar (⌘+F) and click this magical sign: .*. That sign enables searching with regular expressions (Note: you don’t need to add / at the start and end of your regular expression!). Now, let’s try out some scenarios:

Write a regular expression to find the characters 'is' inside the whole list.
Write a regular expression to find the characters 'Miso' at the beginning of a line.
Write a regular expression to find the characters 'Yemen' at the end of a line.
Write a regular expression to find the word 'is' inside the whole list.

Well done! Stay tuned for the next part where we'll check out some more special characters like \w, \s, \d,.

Photo by George Pagan III on Unsplash