DEV Community: Studio M - Song

Building a “Follow Light” with Arduino: Part 2

Stefan Stöhr — Fri, 10 Jun 2022 14:13:24 +0000

It's been a while since we started our Follow Light Arduino Project (and it's still not installed in our corridor 😳), but I recently stumbled over this awesome online simulator called Wokwi!

So I decided to tidy up our codebase a bit and put it into action there.

Wokwi doesn't support the TFmini Plus LiDAR sensor, but it does have the HC-SR04 Ultrasonic distance sensor.

And there is a (hidden) Wokwi Neo Pixel Canvas component, which acts like a LED lightstrip. You can only add it by editing the diagram.json.

You can find our Follow Light simulation here: https://wokwi.com/projects/334003558896632403

Just run the simulator and click the HC-SR04 component to change the detected distance.

Things I’ve learned being a Junior Dev

Josefine Schfr — Tue, 21 Dec 2021 09:52:37 +0000

Picture by Gelgas Airlangga

So often we only realize how far we’ve come only when things come to an end - it took being shifted to our next career level for me to realize how much had happened in the last years.

In two years of being a Junior Developer, I feel safe to say I’ve learned a lot - of course in terms of technical skills, but also as a person. Some things certainly did not come easy to me, I won’t lie - there was definitely some sweat and tears on the journey. But I made it. And I want to share with you lessons I have learned being a Junior Dev - I’d love to hear what your take away was from your time as a Junior (or whatever the ‘bottom of the food chain’ is called at our workplace) - please let us know in the comments!

You don’t have to know it all.

Despite the perceived pressure you might feel to have all the answers, to solve every problem alone and to stay on top of the latest technology trend - nobody expects you to know it all. Simply because it’s not possible - nobody does. There is way too much information out there and our time is far too precious to care about everything at once. Everybody googles all the time and that is perfectly fine. Stay curious and continue to dare asking questions even though you might feel like the answer is obvious (more often than not, people will be relieved you asked cause they didn’t dare themselves). Learn what you are passionate or curious about, but by no means feel pressured to continue studying because you feel like you have too.

Because…

…You will keep learning (probably forever).

Let’s face it: you will never be done learning. For some time I was sure I would be more comfortable calling myself a developer if I just understood that one concept or fixed that one bug confidently. No no, my friend, the journey is the reward - You will most certainly get quicker and tackle more complex problems with confidence, but there will always be something you will just see for the first time. So brace yourself for the long run, it’s a marathon - not a sprint. And it’s likely a good idea to stay humble despite your progress.

You will find your people. Or they will find you.

Especially in the beginning I felt like there was no way I would fit into this community. I felt like other developers must surely smell that I was too different from them. Many of the people I met had been in the industry for ages or had been interested in computers and technology from a young age, loved video games and had a bunch of side projects and were overall very intimidating to me. I don’t mean to play on stereotypes at all, I just felt like I couldn’t join in many conversations and was scared I would have to force myself to be something I’m not to fit in.

If this sounds anything like you, be sure: you don’t. You are great, just the way you are and you will be accepted as such. Maybe not by anybody, but by your crowd. And they will find you - or vice versa. Just stay true to yourself and be open-minded when meeting new people - this community is very accepting.

Human connections over - well - everything.

For some, their job is just a job and they aren’t out to make friends. That’s perfectly fine, it’s just not me. I found that what (to me) mattered most as a Junior Dev was not the technological progress I made but the people I met along the way. Mentors, colleagues, managers, people from other disciplines, who shaped the way I worked, what I learned and how I grew as a person. Especially in odd times working remotely with what felt like little connection to the outside world. It’s great to be focused and productive - but make sure you take time to have a (virtual) coffee with your fellows, check in and talk about something else than code for a couple of minutes.

Your voice matters.

You might feel from time to time that your idea doesn’t matter as a Junior - that your solution might be less worthy than somebody else's or that your question is redundant. It’s not. Your input matters and is highly valuable. And whoever makes you feel otherwise likely didn’t get the memo yet. Often, less experienced people bring in a new perspective, fresh ideas and dare to challenge the status quo. Sure, if decisions need to be made and someone has to take responsibility, it’s great to have very experienced people on the team to take charge for a team - but that doesn’t make your contribution less valuable. Mentors can learn from Mentees, bosses from their employees - knowledge isn’t a one way street. It’s good to listen and learn, but don’t let anyone convince you to stop asking questions and make your voice heard.

Share your Coding Playlist 🎷

Annika_H — Wed, 15 Dec 2021 10:36:01 +0000

On twitter, we've asked about everyone's favorite music to listen to while coding/working. Did you have a particular highlight in 2021?

We would love to hear it! Share in the comments or reply to our tweet (hopefully you can also find some inspiration there).

We are hiring - SinnerSchrader Engineers

@s2engineers

The year is coming to an end and we're looking forward to a well-deserved break and a new exciting 2022 ⏸️ Music has made a lot of our days better in 2021 🎇 Do you have a playlist or artists you enjoy listening to in particular while working? Sharing is caring! #codeiscolorful

10:28 AM - 15 Dec 2021

We hope y'all have a relaxing and peaceful end of the year and some time off!❤️

Underrepresented Groups in Tech depicted in Popular Culture - a Personal Review of "Good Trouble"

Annika_H — Wed, 08 Dec 2021 11:24:00 +0000

I don’t know about you but I am always on the hunt for new TV shows to binge in my free time. When one of my friends told me about a series she’s recently watched and approved I was intrigued and had to find out myself if this one was really that binge worthy.

In my country of residence, which is Germany, the first two seasons of “Good Trouble” are available on Disney+ (not sponsored). Luckily I already subscribed so I could start right away.

If you’re wondering why I want to talk about this show on dev.to, let me explain. “Good Trouble” is actually a spin-off series of “The Fosters” (I didn’t know it before) and is about two characters Callie and Mariana who are about to start the next chapter of their lives after university. And guess what? Mariana went to MIT and started her job as a software engineer in a fancy Tech company in Los Angeles.

During the first minutes, I thought that it was another “coming of age-twenty-something-life in L.A.” kind of series and I was actually surprised to see how it quickly developed and critically depicts various societal issues. One of them being how women, or underrepresented groups in general, are treated in tech.

Mariana is hyped and confident that she will rock her new role after she’s been able to prove herself at MIT. Naturally, she wants to make a good first impression and dresses up accordingly. When she meets her team, her dream bursts with a bang. Just like the entire company, the team is male dominated (including the CEO) and instead of appreciating diversity and welcoming a woman on their team, they treat her disrespectfully from day one.

As mentioned earlier, the show depicts various topics, however, I was particularly intrigued by the fact that it deals with the issues of the tech industry. While Mariana reaches her limits in this toxic environment, she also decides to fight the occurring inequalities and starts an initiative to raise awareness and improve things.

I’m not a developer myself but I’ve worked in this field for the last two years and I quickly learned about the grievances, particularly when it comes to inclusion and diversity. In my opinion, the series portrays these quite accurately.

Mariana is a great developer and has to fight so hard to even prove her talent. She is bold and brings the power to address the issues she is facing at her company but before she was there nobody dared to do it. There are other colleagues of underrepresented groups who live in fear of losing their jobs if they speak up and the worst part of it all is that it’s not even .

Just like in real life, the people who suffer from injustice are also the ones who become activists and strive to create a better environment for themselves. Mariana and her colleagues do find allies eventually but the fight is still not over. When she gets a promotion or the chance to lead a project (which was her own idea) she is accused of getting her way only because she is a woman and not because she is good at what she does.

There are so many examples I could name from the show I could relate to as a woman and as an ally to underrepresented people in tech, I could probably even write several books about this topic. In the end, what I want to achieve by talking about the show is to point out that 1. The issue is real (and even has arrived in pop culture) and 2. I really really want people to watch it.

It made me feel empowered because I felt with the characters and it also made me feel hopeful to see that topics like inclusion and diversity (in the workplace but also in everyday life) are incorporated into mainstream TV shows. I know that most of the people who watch shows like that are already educated but I also genuinely wish for people to check it out who are living in their privileged bubble. It’s important to read, talk, share knowledge and listen to each other but it’s also SO GREAT that series like these exist and we need more of this!

This brings me to my last point. I wouldn’t have discovered the series (or the fact that it deals with the tech industry issue) without my friend. But I want to watch more of this stuff and I’m sure that there is more of it out there. So please feel free to share TV shows, movies etc. you know of that critically deal with inclusion and diversity in the tech industry (or the workfield in general). I would love to watch and share them.

Just 'blah, blah, blah' when it is about finding and developing the right employees?

Christoph Pöhlsen — Wed, 24 Nov 2021 07:37:51 +0000

How to overcome the 'blah, blah, blah' when searching for and developing the right employees for your software development company?

It's quite straightforward - although it isn't:

I assume that there is widespread agreement that we need to bring, or develop a lot more skills as software developers than just creating (individually, ourselves) great software pieces.

When we act as part of a group or a company, it's not just about making software. It's also about making our people great, creating great teams, who see themselves as successful and thrive.

So what is this 'blah, blah, blah'?

You just read something of it: "teams [...] see themselves as successful and thrive".

Other examples are "No alpha leaders, no beta teams", "see success as the result of teamwork", "giving constructive feedback", "lead juniors and intermediates", "creating a safe space for all employees", and furthermore.

Don't get me wrong: I totally agree with this 'blah, blah, blah', because it doesn’t come from nowhere - there are good intentions behind it.

But can we overcome this 'blah, blah, blah' to really practice what we preach - not just talking about it?

From my perspective it is all about focus.

If you want to really change or do something, you have to have it in your focus. This means to have it on your day-to-day agenda. And if you want to do or change something in a group or company, all those people have to bring attention to it.

But how to put it there?

I guess there are two big levers:

1st: Take care of the critical points where the switches are made.

These points can be:
/ What are your true, applied(!) criteria for evaluating your employees' performance?
/ To whom do you delegate responsibility?
/ Who do you promote & who do you hire?
Be honest!

2nd: Bring it regularly to (everyones) attention in everyday life

Beside these critical points, you need to keep the topics in the mind of the people. And for this you have to drive the conversation in the direction of these topics. There are different ways for this.

One might be to create some measurements: you can put up a kind of performance dashboard with a KPI value - like you probably already do with your margin, turnover or other financial parameters, or with a burndown chart or something similar to measure your sprint performance (i.e. story point output or something). You need to find an indicator to represent the fulfilment of your topics.

Another way might be to ask other people regularly about the important topics. In your Dailys, your status updates, or some steering meetings, ask the important questions - e.g. for your team health, not just whether everyone is on time and working.

To condense these few sentences:
It is all about focus - and the focus needs to be set by people who lead (in whatever position)!

It's that easy - isn't it?

What does a Developer Relations Engineer do?

Josefine Schfr — Wed, 17 Nov 2021 12:41:21 +0000

FAQ with our favorite Feli - Executive Principal Engineer at SinnerSchrader

Before I met Feli, I had no idea the position of Developer Relations Engineer even existed (which, I guess - embarrassingly shows my ignorance of the many different roles in the tech industry). Even now, I am not entirely sure what the role exactly entails - and whether there are common pillars among the many different variations of this position in different companies.

Assuming some of you might still have some blank spots regarding this topic just like me, I raised all my questions to shed some light. If any of your questions remain unanswered in the following FAQ, feel free to drop them in the comment section below.

So Feli, what does your role as DevRel entail?

Every company defines DevRel differently, and nearly every company who has people working in DevRel are product companies with products for developers. But at most companies they are building relationships and acting as the liaison between the company and existing developer communities. And if you bring it down to that, then also non product companies can do so, like SinnerSchrader. My Job was to be the liaison between SinnerSchrader and existing developer communities. SinnerSchrader strongly believes in the developer communities and wanted to give back. At the same time it’s a good opportunity to strengthen your employer branding for developers but also doing recruiting actions.
To break it down to real tasks, part of my job was to do community work, getting meetups into our offices, organise meetups and conferences, knowing what is going on in the community, contributing to open source, help our recruiting department to decide which conferences are we sponsoring and what are we doing at the conference booth, as well as connecting people of SinnerSchrader with the community and the other way around.

Have you always worked in this field or how did you end up there?
No, I think at the beginning of my career it didn't even exist. I started to work in this field 2017 at a time where I actually wanted to leave the company. Our Head of Recruitment at that time (Aileen Neu) asked me to help her to find someone like me for a new position. She hit a nerve and I asked her one day afterwards if we could talk about the possibility that I want to do. She was really visionary in thinking about implementing something like a “Tech Evangelist” to strengthen our recruitment of Engineers. The only thing we changed was the name of the role. I’m so thankful she had the idea and always believed in the position but also me! Without her I wouldn’t be where I am today.

What is your favorite part of your job?
Giving back to the community and using the task of the role to support inclusion and diversity. For example I implemented clear rules of which conferences we are going to sponsor . For example they need to have a code of conduct in place with real action commitment and not just a copy & paste of JSConf. The lineup needs to be diverse, a white male only line up is a clear no go. But also the internal task, coming up with new events and ways to connect our engineers, to help them grow and show them that a lot of struggles that early career joiners are facing are normal to everyone, you are just getting more used to it. E.g googling a lot of stuff, getting more comfortable with searching solutions or help on the internet or at colleagues.

What (if anything) changed throughout the last two years?
There are no in person events anymore. A few are starting again but I personally don’t feel safe enough yet for a conference. A lot of people jumped on remote events, but we decided to concentrate on content at dev.to. To ensure we still have something where we can show who we are. I had the idea, but since 1 year my lovely colleagues Annika & you Josi are rocking the content part. Making myself unnecessary and seeing others grow into that and even making a better job in creating content as I did, was one of the most enjoyable achievements.
On top of it I got promoted which also means I didn’t have enough time for all the community stuff anymore.

How should people go about it if they want to become Developer Relations Engineers?
First of all you should know why you are doing it, knowing your own personal motivation is very important. Then you should know if it is the right decision for you. If you are working in Developer Relations you will be part of the community, that also means a lot of people are watching what you are doing. This can create big pressure from the outside and / or people will have their opinion about what you are doing and they will share it, if you like it or not.
After that, reach out to Developer Relation people or to companies that are searching. Of course a lot of them would like to see that you worked in Open Source, that you already write articles and or have been a speaker. Personally, I think it is a job that you learn by simply doing it and that doesn't necessarily require a specific degree but rather empathy, organisational skills and motivation. If the industry (also the DevRel companies) doesn’t accept that, we will never get diverse and inclusive and only privileged people will get the chance to work in developer relations. It’s a job where you should learn it while you are doing it and should be able to start as a junior developer relations without a lot of experience. To be clear, you should have a talent in writing, speaking etc. and the motivation to learn, but you don’t need to have plenty of years of experience.
Nowadays more and more companies are searching for Junior Developer Relation Engineers which is a very good sign. A few years ago you rarely found a Junior level Job in Developer Relations.

Which skills or traits does a person need who aspires to work in DevRel, in your opinion?
They should be very good in human (aka soft) skills. I think empathy is something that will help you a lot to connect with people. But it’s not a must. You definitely should enjoy sharing your knowledge and experience. Don’t think you can’t do it if you are shy or introverted. A lot of people who are working in Developer Relations would say they are introverts or shy. There are a lot of methods to outsmart your own shyness or introvert being.
Something where I would also say is a must, is being open. Being open to other people, to other thoughts. Same goes for being an organized personality, you need to have a lot of things in mind, you will organise events, content or other things. And trust me there will be things that will go wrong - my most beloved topic with other DevRels “what was your funniest mistake”. But to avoid as much as possible you must be very organised.

Things a female dev who has been in the industry for 16 years has to say

Annika_H — Wed, 10 Nov 2021 13:49:24 +0000

“What being a developer really means” - that’s the name of an internal series initiated by my colleague Feli. When I spoke to her after the first session, she told me that she was so surprised to see how many people joined. I think she hit a nerve.

The tables have turned! In the last two sessions, Feli was the one asking the questions but now it was time for her to share her thoughts with the other participants.

The ultimate question

At the beginning of their career everybody asks themselves (and probably also their managers) this one question: “How do I get rid of the Junior title?” I guess it’s entirely natural to strive for development and promotions. For Feli, however, there are no proper definitions for hard or soft (or as she likes to call them “human”) skills you are required to be promoted. As a Junior you learn a lot, probably more than you’ll ever learn later in your career. She also says that in her opinion, as an Intermediate developer you have to be able to help Juniors whereas as a Senior you should have the capability to mentor them. Creating a plan with your manager and defining which steps are necessary to advance definitely helps and in the end YOU have to be given the chance to prove yourself, in her point of view.

Career and Life Choices

Feli has been working in the tech industry for more than 16 years and started her apprenticeship 19 years ago. From time to time she wonders if it’s the right place for her. 1,5 years after she started her career she had a teacher who told her that “women don’t belong in tech”. Hearing words like these naturally do something to you. No matter how hard it was and no matter how many obstacles got in her way -so far she never quit because she just loves coding too much. Nowadays, and currently more than ever, she considers turning her back on the tech industry for good. At these confessions, the mood in this usually quite cheerful format shifted a bit - it is always hard to hear the struggles underrepresented folks are facing, regardless of how important it is to address them openly. It’s a privileged choice not everyone can make and she’s aware of that. Changing careers can be risky and most definitely scary. Still, she is not the only woman who struggles to feel accepted in tech.

Women in Tech, or out

Just as many women and members of underrepresented groups, Feli has had negative experiences and struggled in the industry because she is a woman. Besides the universally known grievances, there are reasons why women decide not to pursue a career in tech in the first place. Raffaele asked Feli what’s keeping women from considering an engineering job and Feli says that this issue is probably already rooted in our childhoods. This does seem surprising at first, but stereotyping can cause children to develop in certain ways and in Feli’s case that means, she was used to playing with her brother and doing “boy’s stuff”, as it would be considered by society, from a young age. She thinks that this often is the case and once more it becomes clear that we still have a lot of work to do and prove it to the doubters that everyone has a place in the tech community.

After many years, Feli will leave s2engineers 💔 Everyone, especially the dev.to content team, will miss her so much. Her persistent motivation to make the (tech) world a better place inspired us and we wish her all the best!

Learning Resources for Developers

Josefine Schfr — Wed, 03 Nov 2021 09:02:29 +0000

Photo by Abby Chung from Pexels

You would like to continue your journey as a developer by intentionally taking some time to learn something new? Or maybe deepen your existing knowledge in a specific subject but are not sure where to find appropriate resources? Trust me, I’ve been there. In the past, I sometimes got so overwhelmed by the sheer amount of options that I simply spent most of my time browsing around, hopping from one great course to the next until there was no more time to study. But fear no more - I put together a list of reliable options for you to dig in. If you are missing something, please feel free to add it in a comment, I’d love to check it out!

Tiny Teachers
This morning I read in Stefan Judis' newsletter (literally my favourite web development newsletter out there, hands down) that he put together the platform ‘Tiny Teachers’ - where you can browse resources by category (currently things like CSS, Vim & Typescript are on there to name a few) and add your own. Will be great to see how this one develops once more people contribute!

Frontend Masters
A classic - I was lucky enough to get free access for a year through my education program, maybe your school or employer offers the same? Here you can find a wide range of topics from Developer Productivity to specific frameworks, Grid & Flexbox or an Intro to Computer Science - all at a high quality and with the benefit of the name - Frontend Masters is popular enough to ring a bell when you put it on your CV.

CodeJourneys
Code Journeys is a friendly, inclusive developer community - welcoming everyone regardless of level, experience or interest in a specific language or framework. The community meets on Slack or calls for coding challenges and workshops - a great way to get in touch with like minded people, ask questions and learn beyond the scope of one's own horizon. And founder Raffaele makes sure everyone gets the support they need.

Egghead
Another classic I stumbled upon during my bootcamp - an epic number of courses on what seems to me like all the topics one could ever want to learn, some free (like the beginners guide to react) some part of their pro membership (like docker fundamentals). Besides that, a great library of articles and podcast episodes - in case you want to switch learning methods around a little bit.

Just JavaScript
I signed up for Just JavaScript on recommendation of my mentor, back when it was still in beta testing and free. Yet I would pay every cent of the 42$ it costs now, cause it simply wowed me. The 10 episode program is created by Dan Abramov himself in cooperation with illustrator Maggie Appleton and teaches you mental models behind JavaScript - giving participants a deeper understanding of the concepts they might be working with already. To quote their website “a way of thinking about JS that will completely shift your understanding of the language.”

These are some of my favourite resources to learn more about web development. When browsing around dev.to, I found this great article that put together exclusively free resources - which is absolutely amazing and a lot more accessible of course than some of the paid programs. Which one is your favourite resource for learning something new in web development? And why? I’d love to learn about it, please leave a comment below to let me know :)

Getting hired after finishing a coding bootcamp

SinnerSchrader Engineers — Wed, 27 Oct 2021 09:51:59 +0000

This article was written by Sandra Gläsner (Director Product Engineering).

If you've decided to reshape your career and successfully completed a coding bootcamp, you're probably now facing the challenge of finding your first job in a completely new field.

I'd like to briefly share my experience as a team lead who has had an increased number of applications from bootcamp graduates on her screen over the past few months. Maybe you can take something from this for your future applications and interviews.

1. Tell your career story

In his resume, an applicant (now colleague) once added a short statement to each of his previous job stations about what his motivation was. This created a coherent picture of what drives him and made it easy for me to understand why he developed his career the way he did.

Your decision to take a new career path in (web) development will definitely not have been made on a whim. Find the common thread that underlies your decision and tell your very personal story.

2. Reflect your personal strengths and interests

Most of you have learned the same content in the same short amount of time. I have seen many practical final projects that were very similar in terms of implementation. This is because of the nature of bootcamps, which usually teach a specific, narrow curriculum.

But that makes it very difficult for me to distinguish between the different applicants and their strengths. And this is where your personal experiences come into play: tell me why you chose this masterpiece, what you had difficulties with, or what you found particularly easy and had fun with. Maybe you liked the setup of build and deployment pipelines more than everything else? Cool! Or did you fall in love with the styling part? Wonderful! Or did you spend much time on finding out what best practices are used in terms of web accessibility? Nice, tell me more!

Reflect your learning path and where your strengths and interests lie.
And finally…

3. Decide what you want (to learn next)

A bootcamp can always be just a start. Think about what you have been missing in the bootcamp or what you would like to learn more about. Please don't be afraid of the vast amounts of knowledge you think you still lack. Be patient with yourself and take one step at a time.

How to refactor without overtime and missed deadlines

Nikita Milyanik — Wed, 20 Oct 2021 09:03:34 +0000

A lot of software engineers, including myself, are passionate about code quality. This striving for a well-shaped codebase, while getting things done could cost one quite a few hours and nerves, though. I'm constantly looking for ways to achieve these two goals without significant trade-offs. Stand by for the current state.

Don't dedicate time
Use the proper technique
Remember the scope
When it's better not to refactor

Refactoring is "a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior" according to Martin Fowler. In other words, the goal pursued by this alteration is a well-structured, readable code doing the same thing, but taking new changes more naturally.

The unchanged observable behaviour he mentioned covers both directions, by the way. Clearly everything should work the same way afterwards. Simultaneously we are liberated from putting any bug fixes or performance improvements on the top of it. It could be a pleasant side effect, but not the destination of refactoring. Better not to feed two birds with one scone to decrease the probability of new bugs. At the end of the day it'll save some debugging time.

It applies, even if optimization is the objective of your current mission. Cold-bloodedly improve structure without any performance, but readability in mind. And then, with much better understanding, start with the optimization. It will often be done in less time, than jumping into a badly structured code right away.

Don't dedicate time

Sounds counterproductive, I know.

However, the point is, a dedicated time for some code restructuring will often sound like a joke. Unless it's a side project on your own, good luck in convincing your manager. They'd have a concrete solid argument – numbers. Totally reasonable, who wants to pay for a prettier code, while software remains literally the same? As I said in the beginning, refactoring won't necessarily bring any billable value to a product. Performance wouldn't jump higher, bugs wouldn't disappear.

Good news is, you don't have to convince anyone, if refactoring is just a part of your daily routine. Like using terminal, commiting in git, reading emails, etc. Such activities are probably seamlessly integrated into your workflow as only a fraction, thus no one really worried about time spent on them. Similar to an artist preparing a canvas before painting, refactoring is about a software engineer preparing a code before editing – a natural part of the job.

However, none of your initially small refactorings should suddenly swell into a fortnight marathon with a broken codebase.

Continually functional software is essential, 'cause it gives full control over the process. You could stop refactoring basically at any moment and ~~leave the building~~ switch to an actual task.

Use the proper technique

I've learned that basically two components shape the controlled refactoring: small transformations and fast testing, performed after each of those changes.

Small step-by-step transformations help a lot with preventing a broken state. A mistake may occur reasonably rarely by changing only a few lines of code.

The steps should ideally be as small as renaming a variable or extracting a block of code into a function. Consider automated tools, like the "Rename Symbol" command in VS Code, as they're often less error prone than manual editing.

Such changes could have a little meaning on their own. But since every of them is a move towards a better code structure, you'll eventually end up with satisfying results. Think of it as a chess game – a coherent strategy leads to a win. Even though a single move could seem quite passive or even odd, they're powerful together.

And even if something goes wrong, it's easy to go a step back and try again. Hence be generous in committing those steps into a version control system (e. g. git). Those are checkpoints. Go with meaningful commit messages like "extract the validation logic into a function" instead of generic ones like "refactor". If something goes wrong, you can easily navigate between those commits. Something broke at the very beginning, but you've noticed it only after a dozen commits? Don't worry and try git bisect. Don't worry about messy git history either, squash it before merging into a main branch.

In spite of how precise changes are, you can't be completely sure based only on a static code analysis whether everything still works the same way. We're still humans, right? Ideally, assure the health of a codebase after each piece of change. That's why fast and easy-to-run testing is required. In the best case, there're automated tests executed against the part of a system you're currently working on. Lack of automated tests? Probably it's a good moment to add some. Otherwise try to find the path of least resistance to test your system manually.

That was a brief overview of the controlled refactoring technique. I just wanted to share essential concepts within my piece of advice without aiming at being a definition guide. If you'd like a deep dive, I recommend starting with Martin Fowler's "Refactoring: Improving the Design of Existing Code" book. I drew quite a bit of thoughts from it, applied to my daily work, which inspired me to write the text you're reading now.

Remember the scope

It's pretty common yet understandable to go too far with a refactoring. Using the technique we just talked about, it might be quite tempting to just follow the rhythm and forget about an actual goal.

In my workflow I usually try to evaluate by asking the following question. Did my code become good enough to start with the actual implementation?

There will always be room for transformations towards perfection. Doubtful, that it could be achieved in the end. Moreover no matter how close you were, software is usually constantly being changed within its lifecycle. Over time and through follow-up fixes there's a good chance for a shift from the perfect match to the "why would one choose that way!?" reaction. So, why would you waste too much of your precious time on it? You might want to consider the Pareto principle for good measure.

Don't get me wrong. I don't encourage you to rush into things without consideration for quality. Refactoring definitely worth itself and increases both quality and speed of development. Better aim for the good than for the best, though. Restructure your code with the future in mind, but mainly focus on the present. Consider edge cases, but don't try to cover unrealistic ones. Follow paradigms, but prefer readability. Keep your own coding style, but don't let it lead you.

When it's better not to refactor

At last, what could be better from the time-saving perspective, than just skipping the whole thing?

But as a decent engineer, you'd probably like a good reason to pass.

I consider the rule of thumb, that refactoring of a working code without aiming to utilize it is probably a waste of time.

Every so often for one or another reason you might stumble across a random smelly code. Although the code is unrelated to your current work, it could be easily very tempting to improve it. Especially when flaws are on the surface.

In that case it's better to get going. But, I must say, I'm usually having a bad feeling leaving such a codebase untouched. Sometimes the bad feeling wins. I jump in with the hope to introduce quick low-effort improvements here and there. Then I start to notice how far it goes away from actual work and regretfully revert my changes. Be smarter than me and avoid such traps. It'll probably save you quite a bit of time, drained by possible follow-up hot-fixing.

How to refactor without overtime and missed deadlines? Seamless integration into the daily working routine, healthy amount of discipline, pragmatic level of quality were the answers on my way so far.

Hopefully they'll help you to improve your development experience. At the end of the day it's what matters when building things. Remember, these workflows constantly evolve – it’s an ongoing process, don't struggle to perfect it overnight.

I'm always looking for better approaches, please don't hesitate to share yours in the comments. And to challenge mine, of course.

The credit for the cover photo goes to Naja Bertolt Jensen on Unsplash.

And the special credit goes to @josefine for making this text real in the first place.

The Importance of Representation

Josefine Schfr — Tue, 12 Oct 2021 12:59:38 +0000

Today, on Ada Lovelace Day, we are celebrating women in STEM - and while we have come a ~~far~~ well ... a way since Ada wrote the first ever computer program in 1843, there is still a lot to do.

Lately, I have been reminded of the importance of representation quite a lot. We keep discussing why less women sign up to study computer science, why we have fewer applicants from non-male developers and why it’s apparently “so difficult to diversify staff” (imagine me rolling my eyes here). Yet we fail to accommodate the few folks that were brave enough to join this industry.

I’m tired of explaining why we need equal pay, equal recognition, equal opportunities & challenges - and I can only imagine how those who have been part of this battle much, much longer are feeling. Or why are not willing to continue the fight.

I love the support among women and other underrepresented groups in the tech community. It’s one of the reasons I got in and am still here. But it can’t be all we got - we need representation. We need people who look and think like us at the top. In the middle. In all the damn places. And we need allies.

Take today as a reminder to value all the great women in tech - to celebrate Ada Lovelace and all that came after her and are yet to come. Make sure they know.

Artwork by the Amazing Women of History

If you are not sure how, here is a list of seven ways to celebrate Ada Lovelace Day, including a list of videos to binge, tips on where you can donate to support women in STEM and a little guidance on how to diversify / audit your Twitter feed.

What great achievements by women in this industry are you celebrating today? Happy Ada Lovelace Day, let’s make it count!💜

More things you might want to hear from an experienced developer

Annika_H — Wed, 06 Oct 2021 13:46:53 +0000

“What being a developer really means” - that’s the name of a new internal series initiated by my colleague Feli. When I spoke to her after the first session, she told me that she was so surprised to see how many people joined. I think she hit a nerve.

This assumption was confirmed in the second session. This time she asked our colleague Lasse (Senior Product Engineer) questions and it was interesting and reassuring to hear that everybody struggles from time to time.

It’s okay not to know everything

To kick off the session, Lasse answered Feli’s question about what he’d like to share with Junior developers with “It’s ok to not know everything”. It’s not bad at all to ask questions and nobody will think any less of you. Basically everybody has questions. Maybe they already know the answer to yours but they are still learning and asking questions. When Lasse first did pair programming, he struggled with imposter syndrome because he was he was afraid of being judged if he made a mistake. Nowadays this is how he prefers to work.

The never ending need to Google

Does anybody actually claim to never use Google (or any other search engine) at all? I think they wouldn’t tell the truth. It’s 2021 and Google saves our lives on a regular basis. Of course, Lasse makes use of Google and Stack Overflow as well. We already learned in the previous session with Raffaele that googling or researching is a skill of its own. It’s not just about looking random things up, it takes more to find solutions and potential inspirations. It’s super important to know which questions to ask and how to break down a problem.

Communication is key

It’s okay and completely natural to get frustrated from time to time. Lasse tries not to get angry with code, though. Still, something that really annoys him is when someone doesn’t communicate properly and consequently disrespects his and his colleague's time. Writing code without documentation, for instance or unclear commit messages put Lasse’s patience to the test. If this happens, he tries to talk to that person and sets out to find the source of the problem. Maybe the person doesn’t know how to do it the right way or always did it like this in a previous job. Even if it’s hard, being patient and talking it out helps in most cases.

Thanks Feli and Lasse for this session and the insights and tipps. They certainly help many!