Forem: MyOnlineStore

Adapting to an ever-changing environment

Carlo Palinckx — Tue, 21 Jul 2020 06:32:21 +0000

600 million years ago, the planet was inhabited by simple organisms. There was no predatory behavior and life was peaceful. Then over time, our nervous systems got more and more complex and interactions increased exponentially. All of a sudden, we needed to be able to sense our environment and the beings around us in order to stay alive. We started to evolve, along the way we developed tools like eyes and ears that helped us get a better understanding of what was happening around us.

We learned to interact with each other and our environment.

This metaphor holds up very well when held against the current state of web development. Users are coming at us from more directions than they ever have and (either through user-expectations and technological advances) the environment is ever-changing. There is an opportunity here for us to evolve.

Evolving our nervous systems

The environment around us is changing. Perhaps we should too, but how should we be changing? In evolution theory, a species branches off from its current form because of a change in the environment around it and in turn forms a new "subspecies". This new species is better at solving a small set of specific problems that endanger its survival. They become "specialists". Perhaps we can apply something similar to web development. Let's look at how we as developers can work towards becoming a group of "specialists".

For reference: We currently house 2 product teams with each: 2 frontenders, 2-3 backenders, 1 designer and 1 product-owner.

The goal here is to develop a framework that helps you communicate and improves expertise. The boundaries you set as a group of specialists indicate the points of contact you have with the outside world, be it other teams, or be it your users.

Gaining eyes and ears

After defining what kind of specialism we could benefit from, we should start working towards a better understanding of our environment. A big part of this is knowing where you need to go and what is happening around us. We need eyes and ears.

A pair of eyes

We are trying to change our behavior in order to become better adapted to our environment. With evolution by natural selection, there is a clear indicator of whether or not we are heading in the right way, survival. However, it is probably for the better to look at a less radical approach when applying this metaphor.

As a group of specialists, it is very useful to know if our change is having the desired effect. We should try to measure our progress.

You have probably come up with a few themes or goals that you want to achieve while defining your specialism. It is important that you really tailor these to your team. There is no set of themes that will work for every team. For instance, a few of the themes that worked for us when we started moving towards a more separated existence:

Developer experience

Most of the code at MyOnlineStore (although this is decreasing at a pretty fast rate) lives in a monolithic application, which is a giant Symfony application. Symfony isn't really built for having a wide array of frontend tooling that can help us build features faster. We wanted to have independent tooling that would not interfere with Symfony. You could keep track of your developer satisfaction as well as to measure how fast your javascript builds are compared to before.

Deliver faster

Getting things done was hard at the time and often required one or more handoffs with backenders. This often clogged up the delivery of a feature. Backenders wrote controllers in PHP (in a traditional MVC architecture) that would directly affect user interaction. We would be a lot faster if we could deliver the entirety of a feature with just the UX designers and frontenders. Backend would still supply us with the data, but we would be able to freely interpret this. To keep an eye on how much faster you can deliver, you could start looking at the number of handoffs you are skipping. Or how your estimations for user-stories change (or the amount you deliver within the same estimations).

Deliver better

The complexity of our client applications would suddenly increase. We wanted to at least try to make this as sound as possible by writing tests and documentation. Our frontend stack at the time didn't lend itself for this, however. We decided that we should start migrating to a javascript framework in favor of a template language like Twig. The progress here could be measured by the amount of test coverage you can gather or a percentual decrease in bugs.

Themes like this can help you stay on track of the change you are trying to apply to your teams. Once you are starting to become more comfortable with your newfound specialism, you could start turning these into metrics to track your performance. "Delivering better" could be redefined as % of bugs that occur compared to before. "Developer experience" could be tracked by taking internal surveys or by measuring the time spent waiting for code to build or tests to run. Note that these themes or metrics are never set in stone and you might be required to change directions once your environment changes again (which it certainly will).

A set of ears

Now that we know what we need to look for when starting this process, we need to talk about the things that we cannot visually perceive. Instead of only looking at our progress we should also start listening to our environment.

Implicit knowledge

Like I mentioned earlier, handoffs are horrible (for us). The team alignment required to get things done is a pretty hard topic to get right. However, one thing that is great about handoffs is the fact that you are required to share knowledge formally. Almost every application and every feature of that application has undocumented knowledge that could turn out to be important somewhere along the road. Something that works great for us is refining user-stories together with other specialisms and working our way towards the implementation from a user perspective. This makes sure that you can still rely on all specialisms involved when solving a problem that a user faces, instead of letting team members like UX designers or frontend developers be the only ones responsible for user experience.

Traceability of bugs

Another thing that you could lose track of is the traceability of bugs. A lot of teams that migrate towards a more headless approach may come from an application that renders server-sided documents and fetches data synchronously with something like PHP or Ruby on Rails. This is a pretty big contrast compared to modern javascript frameworks that tend to heavily focus on asynchronous data-fetching. Because of this, bugs can have several surface points. It is important that you can follow errors all the way down to the origin, wherever it may be. There are several tools (we use Rollbar for this) that let you log errors across multiple applications or services by providing some form of a shared identifier everywhere in your stack. That way you can easily follow the bug on its path of wreckage and plug the hole it came through.

Walking on land

I hope our story has prepared you a bit for what will come when changing your team or organization. This story is by far a conclusive approach but it helped us get where we are today. At the time of writing, we are in a happy symbiotic relationship with our environment and our investments are starting to pay their dividends. Our developer experience has drastically improved, we are delivering a lot faster and are delivering more robust client applications than we ever have. We are at a point where we want to turn the themes we set into metrics that we can actively measure and work towards improving.

Like actual evolution, this is not a fast process, not 600 million years long, but still pretty slow. Getting proficient in these topics is something that takes time and practice because it fundamentally changes the way you interact with each other. Give it some time and keep your eyes and ears on what you are trying to achieve together.

Time for you to venture out there and explore everything your environment has to offer!

This article was heavily inspired by one of my favorite blogposts/talks: https://emptysqua.re/blog/api-evolution-the-right-way/ by A. Jesse Jiryu Davis
The beautiful imagery comes from a collection of old atlases bundled here: https://www.flickr.com/photos/biodivlibrary/albums/page1
Another inspiration for this article was the book "Other Minds - The Octopus and the Evolution of Intelligent Life" by Peter Godfrey-Smith

Best practice setup for Infrastructure as Code with Terraform, Kubernetes and Helm (part 1)

Steven Hermans — Wed, 06 May 2020 15:05:48 +0000

In these series I’m going to explain how to set up your workspace to accomplish Infrastructure as Code with Terraform, Kubernetes and Helm. This setup is based on my real world experience as a DevOps Engineer working with these techniques for over 3 years.

Concepts that these series will cover:

Disaster Recovery and Infrastructure as Code
Setting up a remote workspace
File structure
Storing secrets
Setting up a Terraform project
Deploying applications with Helm
Backup and restore process

Disaster Recovery (DR) and Infrastructure as Code (IaC)

In this episode I’ll tell you some things you need to know about Disaster Recovery Plan and Infrastructure as Code. Disaster Recovery is the process of bringing your application back online and (partly) functional in any way possible, when a major outage has happened. So it is good to have a plan for that. Infrastructure as Code on the other hand ensures that the current state of the infrastructure is written in Code. Which helps a lot during a DR event.

Mean time to repair (MTTR)

There is one thing that a DR Plan and IaC have in common, which is reducing the mean time to repair during an outage. All outages are avoidable, but it still happens even to the best of us. Therefore you should not only focus on how to prevent an outage, but also on how to reduce the time it takes to repair it or go back to the previous working state.

Change management

In order to reduce the mean time to repair, it is important to have a clear overview of the changes that are made to the infrastructure and also the applications running on it. Next to server overloads, “changes” are the most leading causes of outages. Therefore this phrase: “Version everything!”.

Git is a useful and easy tool to track changes. In order to use Git, you’ll first need to manage your Infrastructure as Code. There are several tools that are really helpful in accomplishing IaC, like Terraform and Helm. I’ll dig deeper into these tools in one of the next episodes.

Deploy and rollback changes

I’ve read that some Ops teams use Continuous Deployment (CD) for deploying Infrastructure changes. As this sounds like a good idea, there are some drawbacks to it.

The first one is that you don’t have hands on when things are starting to break and the changes that are being deployed are not always at the top of your mind anymore. This eventually will increase the mean time to repair the disruption. Next to that, how are you going to do complex maintenance, like a database migration through CD?

My personal preference is to always be at the buttons when deploying something, so in case it goes wrong you’ll have all the possibilities open to resolve it quickly.

Consistency

Another thing that IaC will solve, is inconsistency throughout the infrastructure. Throughout my experiences I’ve seen a lot of times when there are two servers that should be identical, they eventually become inconsistent over time.

Backup and restore process

An important part a DR Plan solves is to have a clear process of how to restore backups. The process of making backups is something that is done a lot of times automatically. So you gain experience over time with it when it breaks and you’ll have to fix it. But the restore process you’ll hopefully never use. Nevertheless should it be clear how it is done. Because when you’ll have to use it, you don’t have much time to figure it out.

In the end there is one thing that is really important when doing Ops. In modern infrastructures, there are a lot of changes happening everyday, so a mistake that causes a disruption is not a rare thing. Mistakes don't matter and are inevitable, it matters how you respond to them. Therefore focus on the Mean time to repair.

In the next episode I'll talk about how to setup up your workspace to get started with IaC. Stay tuned!

I am an imposter. You too?

Johan van Tongeren — Fri, 13 Mar 2020 08:40:33 +0000

Do you recognize this situation?

I have completed a coding task. I am a senior developer and I've been doing this for the past 15 years. I've written ~~millions~~ hundreds of thousands of lines of code.

So, these lines of code perfectly meet requirements as described by the product owner. I functionally tested the code. The new page works flawlessly. I doublecheck it by doing some monkey testing and I try to break stuff. Nothing bad happens.

The code is written to spec, there are no linting errors. Pre-commit hooks with some code quality checks succeed.

I've written some unit tests and an E2E test and wondrously these new tests and the existing tests don't fail. Every checkbox on my todo-before-pull-request-list is checked.

I open GitHub and create a new pull request and ask my co-worker Charles for a review and wait for Charles to review my new addition to the codebase.

"Hopefully Charles doesn't think I am a bad developer...", my brain thinks.

Not that Charles is a dick or anything. Actually he's a great guy. Really considerate. He never yells at anybody or calls out co-workers. But still, this thought crossed my mind.

After a while I get a notification:

@Charles approved this pull request

And 2 seconds later:

Merged #1337 into master.

And then it happens: some weird feeling takes over. Your brain explodes of the sudden stream of thoughts like "Did Charles actually look at the code? Is something wrong with Charles? Is he having an off-day? Why did he not see this code is crap? Help! I can only write crap code!"

And one question always returns:

"When will they find out I'm a fraud? I've been fooling them for years now..."

Another example

Last year I was curious about my position in the job market. So I decided to go look around for new job opportunities. And I got a lot of messages on LinkedIn from people that were impressed by my history and skillset. The only thing I could think is:

"Wait until you hire me... you'll find out I really suck!"

I event went on a few job interviews and the companies were really enthusiastic about me. So much that they kept stalking me after I already declined their offers. Instead of thinking "wow, I am good" I thought:

"Shit, I must accidentally be saying the right words to make them so enthusiastic... It can't be my actual skills, because I suck... Why didn't they see that??"

What is happening?

It might sound like low self-esteem, but actually I have been struck by something that's known as The Imposter Syndrome. And if you recognize this, you're probably familiar or even suffering too.

Impostor syndrome is a psychological pattern in which one doubts one's accomplishments and has a persistent internalized fear of being exposed as a "fraud". Despite external evidence of their competence, those experiencing this phenomenon remain convinced that they are frauds, and do not deserve all they have achieved. Individuals with impostorism incorrectly attribute their success to luck or interpret it as a result of deceiving others into thinking they are more intelligent than they perceive themselves to be.

If you've recognized yourself in the previous examples, you're probably thinking "I actually am an imposter!"

But what if I told you that a lot of very smart and/or successful people also have had thoughts like this? Like Serena Williams, David Bowie, Michelle Obama, and Albert Einstein?

You can even take an online test to see how high you score on the Clance Imposter Syndrome Scale.

Where does this come from?

It is called a "syndrome", but it's not a mental illness and not per definition related to things like depression or other mental conditions.

I think the most important cause of these thoughts is a combination of these factors:

You don't know what other people think. Others might seem very confident. But they probably have similar doubts.
It's hard to compare your own skills and abilities to others. Even more, if you master rare skills. It feels like others are always more skilled than you are. This is often not true.
Social media makes it look like the world is full of skilled people. But you probably only follow that hand full of people in the world that are actually as skilled or sometimes better than you are. There are still about 8 billion more people that are less skilled...
You stop listening to positive feedback. You might physically hear them, but you don't actually hear them. Either your mind immediately refutes them or is so numb that you actually filter them out. Like you don't see ads on websites anymore.

In my case, the last one was the worst. I had a lot of therapy since my burnout a few years ago, and one of the things I figured out was that I didn't accept and process positive feedback. This happened so automatically that I didn't even realize it.

Even worse, my mind immediately comes with a lot of "proof" to refute the positive feedback I get. For example, this happened when I was fueling up my extensively modified Volvo at a gas station and a car enthusiast came up to me:

"Omg, did you build that yourself? 😲 It's so awesome!! 😊"

Then this happens in my mind:

setTimeout(() => {    
    console.error("Ahhw thanks...");
    console.error("Wait what?");
    console.error("Is he blind?");
    console.error("He doesn't see that one crappy weld I effed up!");
    console.error("Look at that corner of the wrap that's peeling!");
    console.error("Everything I build is shit!");    
    console.error("I am not worthy!");
}, 100);

So after 100ms, my mind bent the compliment to a confrontation with my shortcomings (which only exist in my mind).

What can you do?

In my particular case, the Imposter Syndrome really went hand-in-hand with lowered self-esteem. These two are like twins, they look alike, but they are really different on the inside.

I am still struggling with these negative thoughts from day to day, but it greatly improved. Hopefully one of these following experiences can help you too if you recognized yourself in one of the previous examples.

1. Realize you're not alone.
Read about it. Google for "imposter syndrome". Or what you're feeling. Literally type in "I don't know what I'm doing at work" and you'll get numerous articles that relate and refute your feelings.

2. You're not wrong.
When somebody has commented on something you did does not mean you're wrong. It only means they do not agree with your view on something. They are entitled to their opinions, but so are you. A healthy discussion will result in a choice on what solution will be used, but even if the solution is not yours it does not mean it was a bad idea.

3. Talk about it.
This is one of the best advice I could give about anything that goes on inside your head, and it's certainly true in this situation. If you are insecure, validate if your thoughts are just. You will find that often, if not always, your thoughts are unfounded.

4. Never belittle yourself.
When talking (and even better: when thinking) do not belittle yourself. Never ever. Phrases like "If I can do it, everybody can do it!" are killing for your self-esteem and fuel for the Imposter devil on your shoulders. I've read about this a while ago and since then I try to practice it and I feel much better about myself since.

5. Actually listen to what people say.
This might be the hardest one. When somebody gives you some positive feedback on something, try to accept it. If you struggle with this, this will be the hardest to do. But remember, Rome wasn't built in one day. Big changes like this come in small steps. Realization is the first one. So if you notice you discard positive feedback don't think "See, I can't do this!" but remind yourself that you've noticed it. That's the first step. Knowing what happens. Next time you can try to stop the negative thoughts that follow. Even if they only get a little milder is a big step forward. Keep it up and keep practicing!

Conclusion

So, these fraudulent feelings are more common than you might have thought and I hope that if you have them too you've found some comfort in reading this and knowing you're not alone. I also hope I gave you some tools on how to start minimizing these feelings.

If you have any tips or just recognize yourself in the examples, please comment below and tell me about your experience!

Video

Before writing this blog I did some research and found this awesome video which explains the effect very well:

Being the first to start remote working

Johan van Tongeren — Fri, 28 Feb 2020 13:28:36 +0000

My girlfriend and I want to move to another city. Not a few miles to the next big city, not to the other side of Holland, but a country on the other side of Europe: Sweden. That's about 1600 kilometers (1000 miles). And it is also not fancy Stockholm we chose as our destination, but a region which is quite remote and desolate. Where there are more trees than bytes in the air.

My employer knows about our immigration plans. I don't want to leave them, and they don't want me to leave. I like my job and love my co-workers. And I like the Friday hamburgers, daily ping-pong matches, good coffee, banter, and drinks after work hours.

So why not keep working for MyOnlineStore and move to another country? That is the solution we came up with.

It is 2020. I am a web developer. Fully online focussed. There are few things that stand in the way of working remotely.

But will I not miss the hamburgers? And my co-workers and friends? Is a daily standup possible with one member of the team not in the same room? Will I fall asleep at my desk? Will I eat all the snacks in my house?

The first remote worker? 🤔

I hear you thinking: "The first remote worker? Me and my thousand co-workers have been doing this for years now!"

I am by far not the first to start working remotely, but I am the first one at MyOnlineStore. The company made a shift from being an oldskool 9-to-5 company to a more modern and true agile approach since a few new managers were hired last year.

So this story is about being the first person in a company who starts working remotely.

Before making the big move to Sweden and finding out it doesn’t work I wanted to try this cool new thing. A period of experiments started and I was the first to work from home (a few miles from the office) for more than an incidental day or the afternoon after a visit to the dentist.

Up until now, nobody worked from home for more than one or two days. Yes, I am the First Real Remote Worker.

Two major factors 🥓

So there are two issues we anticipated beforehand:

technical difficulties: can we find proper soft- and hardware?
the social aspect: when will I go mad?

I think the subject of hard- and software for conference calls has been covered enough, so this will not be a "best conference call software of 2020" kind of story. I do want to tell you about the little struggles we had and how we dealt with them.

The second issue was a lot more impactful for me, but we will get back to that later.

Software and hardware 🎥

We quickly found that the software we already use for communication in our team (Slack) has a big advantage: it offers the ability to click on a phone icon and call a single person or start a conference call.

The only downside of using slack’s video calling I noticed is that slack does not offer the possibility to see my teammates during a call when somebody is sharing his or her screen. We often do this, for example when discussing the backlog. The PO opens the backlog, shares the screen so I can see what they see and they also put that view up on the big screen in the conference room. This works fine, but I found that it's hard to discuss something when you can't see the people you're talking too. Also doing a demonstration of new functionality for the entire company sucks when you can't see your audience.

We are still working on these issues. Maybe we are going to use other software, maybe we'll hang a few webcams at strategic spots in the office and start streaming this, I don't know yet. It feels like we're 99% there and just need to improve on these small issues and make it feel 100% natural and seamless.

The ease of video/audio calls online surprised me a bit, being an oldtimer that had been scared by the crappiness of online conferencing years ago when the web wasn't as evolved as it is today.

Conclusion: hard- and software can't be a problem. As long as you have a decent internet connection you're set.

Loneliness 🥱

We found out that being remote in a close working team is not really that different from being in the office, but what happens if you live in isolation for weeks in a row?

I was kinda worried about this one, to be honest. I am not that kind of developer that thrives when locked up in a windowless basement with a red stapler.

I need people around me. I need to chat. I need to vent frustration from time to time. I need to show my newest lego kit. I like to have fun with my co-workers. I love staying late for Friday drinks.

So I am a socially dependent man. What will happen to me when not being surrounded by people? Will I start talking to myself? drooling?

I've been working remotely for 1,5 months now and it turns out that it's not that bad! I haven't gone mad and killed somebody. Yet.

I think this has to do with the close contact I have with my team. We run sprints of one week, where Fridays are used for a retrospective, refinement, etc. and these days are full of conference calls and consulting coworkers.

A co-worker and I have even developed a paper-rock-scissor-like sign language to play planning poker.

Also, I call him a lot. Mostly just to discuss some coding issues, but also sometimes just to have a chat about everyday stuff. We get along great and it is always fun to hang out, even if it is through a webcam.

Conclusion on this topic: It's not as hard as expected. I miss my precious Cheeshouse hamburgers, but that might be a good thing for my body.

Self-reliance and question quality 💪🏻

Working remotely also greatly enhance self-reliance. It doesn't matter how good the soft- and hardware are there will always be a small threshold to call a colleague to ask him or her something.

I experienced this a few days ago. Normally, to start the development environment of our component library, I have to enter yarn dev in my command line. But after pulling the master and getting the latest version, this resulted in an error.

Normally I'd ask my fellow frontender who's sitting 2 meters away from me in the office building "What happened to the start command for Bricks?" and he'll say "Ah yes, I changed that command. Forgot to tell you that, sorry!"

Now I opened the package.json file, looked up the appropriate command which has changed to yarn start:components. Problem solved. Didn't disturb my co-worker. Everybody's happy.

This is just a small example, mostly born from laziness, but I've noticed that I try to figure stuff out by myself more than I did before I started remote working. So this raises self-reliance and the quality of the questions that remain also increases.

Concentration 😳

I found that working alone greatly increased my ability to concentrate on my work. Not being interrupted by co-workers or other things that happen in a busy office building made a big change for me.

Our office building is in the city center of a small city, close to the police station and the fire department. Loud cars, blaring sirens, obnoxious motorcycles, we get them all. This distracts me always, despite the noise-canceling headphones and other measures I took.

My home office is at the back of our house and nothing visual happens there. I also live in a very small town, where it always is very quiet.

Apart from the increased output, I notice this when I miss my (lunch)break times. Only a notification for a new e-mail or a Slack message breaks this concentration.

When needed I also shut myself off for all these concentration-breakers, it was enough to quit the mail app and Slack. Doing this in an office building is hard without physically moving to another (empty) room.

One thing I think is very important is that I have the luxury of a separate room in my house, designated as a home office. The room has a big desk, a comfy office chair, a good view outside, a proper audio system and everything I need to make my work pleasant.

One concentration killer is other people in your house. We don't have kids, but sometimes we have kids/family over. So when I am working and my 4-year old niece wants to show me the drawing she made for me, it is very sour and saddening to tell her to not disturb me and leave me to work.

Luckily days with such distractions are quite rare. I guestimate that 95% of the workdays are without any distractions other than the mailman.

Slackshaming 👮🏻‍♂️

The big brother in my laptop. I think this is something very personal to me, but probably also something that some people can relate to. Maybe it is something caused by Dutch work ethics (which are very relentless), I don't know, but it's something that I struggle with.

There is a stigma around working alone or from home. People tend to think that Remotees work less hard than people in the office that are constantly watched by others. Take extra long walks with the dog, watch youtube all day or even take naps.

So what happens in my mind is "They must never think I am not working on my computer!"

So I keep one eye constantly focussed on Slack and its notifications. As soon as one of my teammates sends me a message or calls me, I must respond immediately. Otherwise, they will say "See! Proof! He's not doing anything! He's probably in his workshop welding stuff or working on his car! Booo!"

This is a downside of being remote for me. Despite knowing that these thoughts are unfounded. I know people trust that I do my work and deliver. I've proven that by completing sprints every time. There are no unexplained blanks in my weeks at home.

So this is something I need to work on personally. I have to get more confident that people trust me to do my work. I'll have to tell my colleagues that this is a struggle for me and ask them to tell me if there are any doubts about my commitment.

Conclusion 🏁

Remote working is great! As a conclusion a list of pros and cons:

Pros 😊

Working in a pleasant environment that is optimized for me
Increased productivity
Increased concentration
Listening to my music on speakers
No more 8-hour headphone days
A higher quality of questions and more self-reliance

Cons 😢

Glitches or bugs in software make for awkward situations sometimes
Lack of body language and other subtle stuff when you don't see the other person(s)
Tempted to eat more candy/snacks since they're at hand
I miss all the birthday celebrations with cake and other treats
No more delicious hamburgers at that one joint close to the office

How to not be a dinosaur.

Johan van Tongeren — Wed, 13 Nov 2019 13:24:34 +0000

This is the story of how I became an experienced senior frontend developer and how I had to start all over again. How it felt like I had to start all over. How to learn.

This story is mostly about learning React, but might apply to other frameworks as well. Heck, it might even apply to completely different areas of expertise.

What happened?

It is 2019 now and I am 37 years old. I have been working for 15+ years professionally as a web developer and web designer. After high school I went to design school and learned to be a designer. But I have also always been interested in coding. In the early 90's I was already writing code in GW-Basic. I can recall writing my first lines of code in the last grade of primary school. Later I learned HTML and even a little PHP 3. In design school I also learned Flash and OOP in Lingo. When my class got the task to code a simple dice-rolling program, I wrote the complete Monopoly game. Just because writing code was a never-ending path of discovery, wonder and dopamine.

This is not me. But it could have been if I had such an awesome mustache at the age of ten

In the years working as a developer I have seen the landscape around me change drastically. When I started designing and coding in the early 2000s, CSS, some javascript and later jQuery was all I needed to master being a frontender. I also added some backend code (PHP and even Coldfusion in a dark era) to be able to integrate the frontend code with the backend. So for years I could design a project, code it and integrate it. At one point I was named a full stack developer. Life was simple. Even simpler when post-processors like SCSS came to life. I was like "I got this, bro!"

Also not me.

So what changed?

So I was happily writing SCSS, JS and some PHP, but then around 2012 the world started to change around me. I saw more and more articles about fancy frameworks like AngularJS on Twitter. At some point it seemed like new frameworks were being released every day. I was naturally drawn to this, but couldn't keep up and got a little overwhelmed by the seeming complexity of some of these frameworks. And I also suffered a bit of metathesiophobia.

Still not me.

Then one day I attended a meetup where some guy enthusiastically demonstrated AngularJS. He made a list of hospital employees which could be clicked to unfold a list of their certifications and skills. A very simple page. And the amount of code that was shipped to make this simple page work was over 1mb.

So that was it for me. This new stuff was overly complex, scary and most of all: I could write this accordion list in less than 1kb of vanilla JS. Or maybe even without JS in CSS and HTML only… My common sense said: "Why the **** would you use something so complex for something so simple?!"

At that time I was the only frontend developer at MyOnlineStore. And I have always been the only frontend developer for all my previous employers. So there was nobody to convince me that it would be wise to embrace these new techniques.

Why I stood still for so long

In late 2015, when I was already late to the party I got sick. A severe burnout followed by a big relapse one year later while I was still recovering. When I felt a bit better after a while and came back to the MyOnlineStore offices everything had changed. There were two new frontend developers. With new repos, new code, new words, new everything!

It was 2017 already. I did not know where to start. I didn't dare to ask for help, because of my misplaced pride. I was writing code before some of my new colleagues were even born… and now I should go to these guys and admit I had no clue what I was doing?

But I tried… I tried to keep up with it for a few months and then I was like: "I don't get it! fuck this shit!"

"I have been doing design and development 50/50 for all of my career, so now it's time to say goodbye to one of these and focus on the other." And since I got so scared of The New Frontend World, I fled to the design department of MyOnlineStore. This was in early 2018.

Yes, this is me doing design

Unfortunately, after a year of doing (UX) design, I found out this was the wrong choice. After years of intensive therapy and running straight into a black hole that was another potential burnout, I came to the conclusion that design was not for me. I am able to design, but I can't handle the stress that goes with it. I felt like I had to answer and fight for all the design choices I made. And since my UX designing was mostly driven by instinct, this was really hard for me. On top of that, it all felt very personal. Maybe I can handle it today or in the near future, with all the things I have learned since, but not then. It fueled my insecurity enormously.

And then in late 2018, I decided to go back to frontend development. There I was, a frontend dinosaur in a modern world.

Yes this is me.

How to get up to speed?

Now I faced a big challenge. I didn't want to go extinct like a real dinosaur and stick to my old habits, so how do you get up to speed after being paused for a few years in a world that changed (and is still changing) so rapidly? The first thing to overcome was my aversion for The New Frontend World™️. I tried to look at React and all other new tools with a fresh and unbiased view.

While I was away in design world a lot has changed within our codebase, but also in The New Frontend World™️. The tools we used improved or were replaced with better alternatives. The tools and codebase became more solid and mature.

Then there was news: React Hooks was about to be released in React 16.8. This made code so much more readable that I started thinking "Hmm, maybe I can do this".

I don't want to go all geeky on the differences between hooks and classes and why hooks are so awesome, especially since there are many excellent articles written on this subject. If you would like to learn more about this, you should check them out.

For me personally the biggest thing was the improved simplicity of using hooks in function components compared to using class components. Where it felt like class components made me jump through hoops to keep track of state, hooks just let me use useState().

For example, in oldskool classes, I used to write this to increment a counter:

this.setState({ count: this.state.count + 1 })

Where hooks let me do this:

setCount(count + 1)

I bet that if you are reading this you'll feel that the second version is simpler even if you have little (react) programming experience.

After this "challenge accepted!" point the hardest obstacle had to be overcame: how to handle the "I have to start all over again" feeling. I felt like I knew nothing. I was Jon Snow.

Dealin' with dem feelins...

Who had I been kidding all these years calling myself a senior developer? How embarrassing was it that I had to ask my 12 years younger colleague for help over and over again...

Some people will think "what's the big deal?", and I am happy for you if you do, but you have to understand that asking for help was a big issue for me. And a major cause for my burn out and the personality disorder that came with it.

So I did two things: I decided to start learning all these new tools and frameworks and more importantly I started to ask for help. But the most important thing I did: I told my colleagues how I was feeling and how insecure I was about everything. They were very supportive and this gave me the confidence to go for it.

One of the most supportive things they did is showing me that I did make progress. A lot, actually. They also showed me that not knowing everything is not the end of the world. As long as you keep trying and learning, things will work out in the end.

Soon, I also realized I did not have to start all over again at all. It might have felt like it, but I still had a big headstart with my years of experience in programming overall. It was just a new framework and new tools that I needed to learn, not learning how to speak and not the first tool I ever used.

It will take some time to learn all these new things. And that's okay. Good things take time. I should have realized this earlier since it's literally written on my body, but sadly it's not that obvious sometimes.

Yes, this is also me.

Okay great, challenge accepted! Where to begin?

First I made a list of all the tools we use. There were quite a few things for me to learn: Typescript, Babel, Webpack, React, Apollo, Redux, GraphQL, Yarn and many more. This list was somewhat overwhelming until I started to put them into two groups: things I needed to learn right from the start and things I could figure out later. It turned out the first list is not that big and a lot more do-able.

For example, I now know how to set up a project using Babel, although I have no idea about the inner workings. And that's okay, I will learn it someday. Until then it's perfectly fine to ask a colleague who does get it.

Bottom line is that it is okay to not know things. It's not the number of things you know that makes you a senior developer, it's the way you handle things that make you a senior. In my opinion.

I have always tried to take some time for personal growth once in a while, but this was only a few spare hours every now and then. However, for a few months our company MyOnlineStore is doing so-called Ship-it days where we developers can do whatever we want as long as it's somehow work-related. This is a great way for me to learn stuff I might not naturally learn during everyday work. When I work in our normal codebase I just run yarn dev, storybook starts and that's it. But on these ship-it days I create new repo's, install packages and configure everything myself. That is a great way to learn new things.

Conclusion

Take your time: good things take time.

Be yourself.

Be awesome.

If you liked this blog, please let us know by giving us some claps, retweets or likes.

If you think working at MyOnlineStore would be something for you, here are our job openings (NL).

If you have questions about this blog check out what I do in my spare time or just want to get in touch, you can find me at Bad Decision Works Instagram

You can find more of our blogs on Medium

Cheers 👋

How to automate your GitHub workflow and go home early

Carlo Palinckx — Thu, 31 Oct 2019 07:35:55 +0000

If you have more than zero co-workers you are probably using some kind of platform to help you with pull requests and reviews. If your platform of choice is GitHub, you're in luck. We compiled a list of tools and tricks that can help you get your commits merged in that sweet master branch as fast as possible.

Set up a pull request template

Writing a good pull request template can help you and teammates find a common ground on how to summarize what's in a PR. You can also add a checklist if there are some requirements that have to be met before it can be merged.

Auto label your pull requests

With the new GitHub actions you can automatically label your pull requests based on what files you touched in your pull request. This can help a lot with the discoverability of your pull request overview.

To set this up, go to your GitHub repo with actions enabled, click on "New workflow" and once in the marketplace scroll down to "Automate every step in your process" where you'll find the "labeler" action:

Automatically request reviews with "Code owners"

We can take the automatic labeling of your pull request one step further. There is a feature in GitHub called "code owners" which lets you assign co-workers to certain parts of your application(s). GitHub will use code owners to automatically assign reviews.

Setting up code owners is easy, check this guide to get started with code owners.

Let a panda spam your co-workers into submission for reviews.

One thing that has been very helpful to our team is the addition of Pull panda. It is a Slack integration that automatically sends a message to your co-workers when someone requests their review.

When you request a review, the reviewer gets a message like:

If someone approves your pull request, you'll be notified as well:

Even if someone comments on your pull request, panda will show you the comments right away in Slack:

Automatically merge the pull request

After applying all these steps, Our pull request get's labeled automatically, the correct reviewers get assigned automatically and they receive a Slack message reminding them that there is work to be done. Now there is one final thing for us the robots to do, merge the pull request into the master branch! If your team uses any form of automated checks on pull requests, you have probably already wasted some time blindly staring at your screen until the merge button turns green.

With another GitHub action called automerge, this is a thing of the past. This action automatically merges your pull request based the preferences of your team.

For instance: We set up automerge to merge a pull request once:

An "automerge" label is added to the pull request
All required checks are complete and successful
All the required reviews are approved

And of course after your pull request is automatically merged, you get a message from pull panda:

Conclusion

I hope this list gives you some inspiration on how to automate the little things in your workflow. Even though these steps are probably not the worst bottlenecks for the speed of your team, saving a few minutes per pull request can quickly add up to something worthwhile.

If you liked this blog, please let us know by giving us some claps, retweets or likes.

If you think working at MyOnlineStore would be something for you, here are our job openings (NL).

If you have questions about this blog or just want to get in touch, you can tweet to me at https://twitter.com/CarloPalinckx

You can find more of our blogs on Medium

Cheers 👋