Author: Emmanuel Goossaert

Building a Payment System for the Ethereum Blockchain

Building a Payment System for the Ethereum Blockchain

Published by Emmanuel Goossaert on June 1, 2022

Over the past few years, I’ve oriented the content of this blog towards engineering management and tech leadership, and consequently, I haven’t written anything purely technical for a while. Some of my most technical article series ended up finding a large audience, namely Implementing a Key-Value Store, and Coding for SSDs, and it now feels like it’s been an eternity since I wrote them.

Crypto protocols have made a serious dent in the tech space, and even more so over the past couple of years, often referred to as a whole as crypto or web3 technologies. With my personal commitment to keep upskilling myself, I have decided to make it a top priority for me to understand how blockchain technology was built and operated, and what kinds of businesses and product experiences this technology could enable in the long term.

I decided to build something basic yet complex enough that it would force me to interact with blockchain data in interesting ways. Because token transactions and crypto payments are simplest interactions on the blockchain, I settled on building a payment system.

Therefore in this series of articles, I will be sharing how I implemented a fully-functional payment system on top of the Ethereum blockchain, with the following features:

Managing a list of products and time-bound subscriptions. Allowing for coupons and whitelistings.
Displaying the current and past purchased products for a user.
Guiding users through payment transactions on the Ethereum blockchain, by connecting their Ethereum wallets.
Handling complex situations of network and service disruptions, to prevent double payments, avoid hanged transactions, and cover all other edge cases. This is mostly done by making all operations idempotent and idempotency keys.
Monitoring the Ethereum blockchain to verify that payments for a particular product has been received.
Once payment has been received, allowing paid users to access the private parts of a website by signing on with their Ethereum wallet to authenticate.

Learn Street Epistemology To Deal With Difficult People at Work

Learn Street Epistemology To Deal With Difficult People at Work

Published by Emmanuel Goossaert on December 20, 2021

Dealing with a stubborn coworker is something most of us dread. “Oh man, I have to talk to that guy again, ugh…” you tell yourself, especially in cases where you don’t have much leverage on the situation or the person.

And sometimes, the person you deal with seems somewhat reasonable, but the two of you see things so differently that you can’t seem to reach any agreement or even start to understand why your respective conclusions are so far apart.

Imagine you’re at work and you’re facing some of the following conversations:

An engineer tells you he strongly believes that project X doesn’t make any sense, because technology W is not good enough for it.
A product manager tells you he is absolutely convinced that using a certain approach to roll out a new feature is doomed to failure.
An engineering manager who reports to you is saying that without any doubts, person P on her team is really not good enough and is underperforming.

Ever been in a situation like that? I bet you have.

And what do these situations have in common? They’re all opinions and beliefs that people are dumping on you without context or facts.

When faced by such a situation, it’s tempting to shove it into someone’s face that they’re wrong, and press it to the point that it’s painful for them. There’s a certain satisfaction that we all get from “being right.” I know it, because I’ve done this myself in the past, and I’m not proud of it.

That’s also what most people do: they just reply with whatever opinions they have in their own minds at that moment. And the hope is that after some time of throwing opinions at each other’s face, the argument is going to sort itself out and help the two parties come to an agreement, or at least, to an understanding.

But reality is often very different from that, and without a more structured and pragmatic approach to such conversations, you’ll end up making decisions based on social status, feelings, beliefs, and personal preferences, which is the total opposite of what you want to do if you wish to make rational decisions.

My intent with this article is to introduce you to a conversation technique called street epistemology.

Many introductions to street epistemology have been written, and my key contribution here is to localize the technique so you can learn to use it specifically in a work environment. In particular, it will do wonders with colleagues with whom you have little leverage, generally because they are above you in the org chart—like your manager or your manager’s manager—or because they sit in a sister organization in which you have little political weight.

In this article, I will first briefly cover some examples of epistemologies to give you more context, then I’ll give you a step-by-step guide on how to use street epistemology in a workplace environment. Finally, I have added plenty of links and materials at the end of this article if you want to dive further into the topic.

Six Patterns to Optimize Your Monolithic Codebase

Six Patterns to Optimize Your Monolithic Codebase

Published by Emmanuel Goossaert on September 22, 2021

Migrating to microservices isn’t always needed: first, you must fix your monolith.

The tech industry, and software engineers, are wired for the new and the flashy. That’s also why we see dozens of new javascript frameworks getting created every year, the majority of which end up burning into oblivion as they re-enter the Earth’s atmosphere—well, except for jQuery, which somehow keeps surviving.

The same can be said of architecture: almost every time I hear or read someone mention monolithic architecture, there’s almost always a negative connotation associated with it, because it has this feeling of old and outdated.

But simply because monolithic architectures are older doesn’t mean they’re bad, or that they’re less, compared to service-oriented architecture or to serverless.

This reputation comes from the fact that most monolithic architectures end up turning into giant spaghetti monsters of code, difficult to build, deploy, and evolve. I agree with that, that has also been my experience.

What I disagree with is the speed with which many engineers are ready to discard monolithic architectures entirely and switch to something else, say microservices, which they understand even less, instead of trying to fix what’s already there. There’s a lot of hype involved with such pushes, because it entails using new cool frameworks, new programming languages, and so on.

In addition to that, there’s often a lack of understanding from engineers that the decision of choosing an architecture must never depend only on technical considerations. In fact, it should be the other way around: picking an architecture should always be done by putting most weight on what will best serve the business needs and growth of the company over time, and take technical considerations only as a second-order concern.

And before discarding an entire architecture or codebase, one should always strive to fix it with what’s already there.

In this article, I want to share techniques I’ve seen deployed in production and which have helped make monolithic codebases easier to work with. I’ve seen first-hand that they were successful in improving build times and consequently deployment times.

The six patterns for optimizing your monolithic architecture are:

Remove build bottlenecks
Extract frequently updated code areas into their own modules
Clean up unneeded dependencies
Clean up unused code
Enable server-side caching in your CI/CD
Use subviews to mock dependencies

In the rest of this article, I will share more details about those techniques, and how to go about using them

I’ll be using the term “microservices,” as if I’m taking the perspective of a backend system. But this article also applies to frontend applications and to microfrontend architectures. Also, I’m going to stay very generic in my statements, and that’s intentional: I want to focus on the big picture ideas without being specific to a particular language or toolchain.

How to Get Your Silent 1-on-1s Back on Track

How to Get Your Silent 1-on-1s Back on Track

Published by Emmanuel Goossaert on September 9, 2021

During 1-on-1 meetings, I’ve often had a direct report who says “I have nothing to share” or “nothing from my side this week.”

When I was still an inexperienced manager, I would reply “okay great, let’s end the meeting and go back to work then!” However, after more years of running 1-on-1’s with dozens of different personalities, I’ve learned that ending the meeting is always the wrong thing to do.

Over time, I’ve developed a list of questions that I keep readily available in a corner of my mind in case those situations arise, as a way to unblock them and generate more insightful discussions. In this article, I’m sharing my approach.

The Most Important Step Of Every Great Conversation

The Most Important Step Of Every Great Conversation

Published by Emmanuel Goossaert on September 1, 2021

If you’re like me, chances are you walked into many high-stakes conversations without even realizing what was at stake, and without having either a goal or a game plan on how to achieve that goal.

And then, you walked out without understanding what the heck just happened and why everything turned out so wrong.

Having good conversations is a skill. You need to keep track of all of your interlocutors’ signals including values, beliefs, arguments, body language, logical fallacies, and so on, while keeping track of your own presence and communication.

So if on top of that you realize mid-flight that you didn’t plan exactly what preferred outcome you wanted from the interaction, then it’s game over.

Entering a conversation with a goal can be the deal-breaker that will make the conversation a success for both parties, or a drag and the beginning of a conflict.

Most shortcomings can be avoided by preparing and practicing the art of conversation, and by taking care of the most important step of all.

Making Teams Effective At Remote Work

Making Teams Effective At Remote Work

Published by Emmanuel Goossaert on August 17, 2021

On my quest to make my teams effective at remote work, I went through a boatload of content. Articles, podcasts, courses, videos, everything that was relevant, I consumed and annotated.

I reviewed 40+ resources about effective remote teams so you don’t have to. Here’s my takeaway.

Unsurprisingly, all the content offered by GitLab is brilliant. They really know what they’re doing, and the quality of what they put out there has been top-notch so far. I also didn’t want to use only them as an example, so I went out of my way to find other companies, and other examples of success to form an opinion that would be as objective and as realistic as possible.

After reviewing 40+ resources, spending hours absorbing and summarizing them, and boring my friends and colleagues about it, I thought I’d put everything into a nice little package to share what I’ve learned with others. This is what his article is.

The article is geared towards managers on how to adapt teams and organizations to become effective at remote work, and not so much on how to be a more productive individual within a remote setup.

If you’re an individual contributor, you will find interesting ideas in this article nonetheless, and also ideas on how to convince your manager to help your team and organization be effective at remote work, so read on!

To create the right environment for organizations and teams to be effective and successful, the topics you must cover are the following:

Be explicit about which ‘remote’ you pick
Set a culture of remote work from the top
Embrace an async-first mentality
Adopt management by objectives
Don’t let individuals choose their WFH days
Recognize the need for meaning and bonding
Organize for physical and mental health recovery
Adapt all the supporting organizational processes

The rest of this article dives into the details for each of those topics, and at the very end, I am sharing all the useful resources which I’ve come across.

Finally, note that this article explores all the main ideas and concepts for effective remote teams and organizations. However, it doesn’t cover how you would plan a transition and then execute this transition. I will cover this aspect in a future article. Join my email list to be notified when it comes out.

Burnout Is Real, and It’s No Picnic

Burnout Is Real, and It’s No Picnic

Published by Emmanuel Goossaert on July 28, 2021

Every knowledge worker will face burnout, or have coworkers who do. Here I share what I’ve learned about it as an engineering manager.

The Skills Map of Senior Tech Career Progression

The Skills Map of Senior Tech Career Progression

Published by Emmanuel Goossaert on July 15, 2021

Peter Drucker—the founder of modern management—said in his 1999 article “Managing Oneself” that knowledge workers should plan their second career well ahead of time.

That’s admirable advice.

Except that for the rest of us, planning our first career is already a major life struggle.

And I can talk at length from my own experience. A little more than ten years ago, back when I was still a naive junior engineer, career progression was a very nebulous concept.

Now that I’m at a point where I’m managing other tech managers, I’ve gained enough perspective on the topic that I can share valuable insights that my younger self would have loved to hear and learn.

In a previous article, I covered why soft skills matter and how they can make your career stagnate if you don’t address them. I also shared what the next job roles are from the senior developer role.

I wanted to create a simple representation to enable anyone with a career in tech to grasp how career progression looks like and what it requires.

In the rest of this article, I’m presenting a skills map of career progression, starting all the way from the senior developer role. This map covers both the individual contributor and managerial career paths.

Unlock Your Soft Skills To Win The Career Game

Unlock Your Soft Skills To Win The Career Game

Published by Emmanuel Goossaert on July 11, 2021

Have you ever received feedback from your manager that you should improve your communication skills? Or that you should create more visibility for your work? And another one, that you should work on your influencing skills? These are all related to soft skills, and it can be confusing what they mean and how to improve on them.

As a tech manager, I find myself giving that feedback regularly to engineers. About 50% of them get it, however, the other 50% roll their eyes and reply “Soft skills? Pffft, I’m an engineer, I don’t need that. All I gotta do is code harder and learn technologies A and B and I’ll keep on going.”

And that’s where they’re wrong, as sadly, I’ve seen such neglecting of soft skills ending up costing many of them years of stagnation for their tech career. The same could happen to you, or might already be happening to you without you realizing.

I wanted to follow up on my article about career progression for senior developers, by addressing the topic of how to map and learn the skills needed for tech jobs.

Soft skills and teamwork
skills are what’s gluing
hard skills together.

So in this series of three articles, I’ll first be covering what is the difference between hard skills and soft skills, and why soft skills matter even if a great part of your job is purely technical.

Another difficult problem is how to prioritize those skills so you can improve predictably. To address that, in the second article I’ll share a map that I’ve created and which shows how different types of skills relate to different career paths.

Finally, in the third and last article, I’ll cover the top skills you should focus on as a senior engineer or as an engineering manager if you want to see fast progress in your personal growth.

Let’s get started with defining the types of skills and why they matter.

Remote Work Stole Our Foundation

Remote Work Stole Our Foundation

Published by Emmanuel Goossaert on June 29, 2021

I’ve been thinking a lot about my personal remote work setup lately, and also about the organizational setup that my tech teams are using to work together.

When most of us still worked in collocated office spaces, there were many organizational features that we didn’t even realize were there and that we took for granted.

And it doesn’t matter that the pandemic started more than a year ago. It’s never too late to reflect on what can still be improved, and apply changes for the better.

I distilled it down to the following features.