DEV Community: Steve Alves-Blyt

An example of kindness in tech: the case of “shitty code”

Steve Alves-Blyt — Wed, 03 Dec 2025 20:39:05 +0000

Disclaimer: this article shows my opinion and is not intended to be an absolute truth.
So all constructive feedbacks are welcome !

Introduction

During my short career, I saw countless times a developer picking at the code and yelling or mumbling to himself "what a shitty code". We all have gone through it, me the first. Even Robert C. Martin considered it as a metric of "bad code" in the book Clean Code !
However, as the years passed I questioned myself about this expression. "Shitty code"... There is no kindness in it, only pure emotional frustration and disdain. So, how can we judge code ? should we qualify it as shitty without further explanations or else ? And if we go deeper, what is a code of great quality ?

The issue of the expression

Apart from the disappointment, this expression brings no constructive value: no explanation, no will to help your colleague be a better professional and is pure judgment. Moreover, it is also a dangerous expression because it can bring tension in the team. How your colleague would react if you say that to the code he just wrote ? Even if we look for less ego in our sector, no one would be happy to hear that.

Even if you are in the perfect team (ie a team that has no ego or very little), you would have a remark.

But the egoless principle says that we should be hard to the code and kind to the people.
So has I am not targeting a person, just saying that this code is shit, there is no need to be sensitive about it.

As a member of the team, it can make sense. However, as a manager perspective, it can be poisonous. Unless you are a buddhist monk or a self-accomplished man with nothing to prouve, ego will always twist it and can potentially damage the team inter-relationships.

Moreover, this sentence is a nonsense in my opinion. The perception of good and bad practices vary over time. A good code in the 2000's can be considered as a bad one 20 years later.
One example is that in the 90's it was common to put business rules in the database layer with procedures. Now, it is presented as an antipattern because of its difficulty to maintain and unit test.

Another aspect often overlooked is that going quick and dirty can be useful or even necessary. A startup that is looking to validate its business model puts velocity first and quality second at best. In that case, buying technical debt is a choice. the MVP won't be perfect or well-designed and structured and that's fine ! At that stage we are not looking to create a masterpiece but to quickly deliver value to the customer and be resilient and agile.

Some TDD experts will argue that TDD is the way to unify velocity and quality in software development but this kind of profile is very rare and hard to hire for a startup I would say. So I consider that the average developer goes faster with the old quick and dirty philosophy

So, talking about "shitty" code is very tricky because of its very contextualized use.

The danger of this expression

At first sight, we would say that as everyone says it, so it can be considered as normal. But it can bring you 2 issues in the long run:

prevents you from creating a "psychologically safe" area
having access to candid feedbacks which can hinder your team and prevent the team from reaching its full potential and productivity.

Many researches shows that the number one criteria of good teams is Psychological Safety.
How a manager can create a safe zone if at anytime someone can shout that the code written is "shitty" ? Sure, psychological safety is about talking openly, but it also embarks a notion of respect and no judgment.

As a manager, how to deal with ?

If you stumble into this kind of case, and you see that it makes the team uncomfortable, the worst case would be to minimise it and let it go for the reasons explained above. I advised you to do a 1:1 meeting with the person to explain him.

if your team struggles, you can use a workaround. I often saw the term suboptimal code. it is not perfect and can bring to many discussion (or disputes) but it is the best consensus I found.
If you plan on removing the word, the transition has to be smooth. One idea can be to turn it into some kind of joke or game in the team. For instance, when someone says the "s-word", immediately he brings the croissant the next day (yes I am French ! :D) or other fancy stuff.

Afterward, if you see that this word federates your foes, you can keep it as part of the team culture. On the contrary, you can try to remove it.

As a developer, what should I do ?

No need to look for complex solutions; just stay neutral and non-offensive by explaining about the reasons you think this code need to be improved and how is enough.
It delights the conversation and make your colleague grow.

Conclusion

In this short essay, we tried to explain what could be the reasons why the expression "shitty code" has to be prohibited. We presented the potentials harms to your teammates and how to resolve it.
We finished with an attempt to find a workaround expression.

TL;DR

don't use it, it's harmful
stay neutral and constructive
don't let it go if you hear it
you can use "suboptimal code" as a replacement

# What is seniority in software engineering ? An attempt to qualify it

Steve Alves-Blyt — Thu, 21 Dec 2023 21:07:08 +0000

Disclaimer: This article is an essay written from my personal experience. It is not supposed to be a scientific article that bring some absolute thruth. Every constructive comments are welcome.

Introduction

We see a lot of job offers, coworkers, teammates talking about "seniority". Even if the definition of seniority differs from one company to another, the consensus is that he is a more experienced person that handles more responsibility and has a broader job requirement. Also, the level of "seniority" can be higher following the company. Indeed, a senior from a GAFAM has a probability to be more skilled that a senior in a local tech company.

However, it seems that there is no common full definition of it. Is it a mirror of years of experience ? the result of meeting various contexts or making a lots of mistakes ? A bit of evrything said before ?

Let's break up some misconception beforehand, I do think that years of experience have at most a minor impact on seniority. If you debug the same application without asking questions for years, your technical and business knowledge won't increase much. Hence, seniority comes with curiosity and going outside your job day-to-day routine, your comfort zone to take risks and be in your boldness zone.

So, what is the aspects of a senior ?

The common characteristics of a "senior"

Usually, the senior one is the most reliable person on the develoment team. He is the most important person, without him the software has good chances to become unmaintainable quite fast because of lack of lisibility and extensibility. Indeed, an unmaintanble software lead to an explosion of costs, a decrease of deliveries and difficulties to attract new poeple. Which can lead a company to its demise.

The senior can handle complex code, help the team to enhance their skills and help the project board to take the best decisions.

However, in my career, i saw that "seniority" can be splitted into 2 types: the "familiar" and the "technical expert".

Familairity ? Expertise ?

What is the "familiar" and the "technical expert" ?

On the first hand, the familiar is someone that is an expert / specialist of a domain apart from the project / business. It is usually the person that is in the company for several years or decades and know everyone, the domain etc... He knows all or most of the history of the project/product or company. He is a precious person because:

He can warn of the potential obstacles if someone wants to introduce some new stuff
He knows at least most of the source code so he can help teammates to troubleshoot bugs and creates new feature
He knows most of poeple and can deal with potential processes issues
ease onboardings

On the contrary, his limits are:

he has not a very deep technical knowledge compared to the other one.
He can be a "guard temple" blocking most of the innovation attempts of the team

To become one is quite simple, you just have to stay in the company. It rewards stability.

On the other hand, the technical expert is, as the name suggest, a specialist of a technical subject like architectural patterns/frameworks and so on... He knows less about the domain or the project itself but knows the limits of its area of expertise. He is also a very important person because:

He can deal with most of the technical issues very fast
provide some "external eye" on a subject and bring some innovation
help teammates on their technical expertise
speed up development and prevents unmaintability issues
warn of the potential issues for a specific issue (framework, architecture etc...)

However he can be a burden because:

He has no deep knowledge of the company context
He can promote some very risky changes

Contrary to the familiar one, I advise to switch context and subjects regularly to catch enough experience to go deeper in your choosen fields. It rewards instability.

We can go deeper if we include de years of experience in there:

I think that a familiar that has too few years of experience is very unlikely to have. Namely, it means someone that knows the business and the company very well but with few years of presence. Unless you have the sun of the CEO and he is very invested from the beginning, i don't think someone can.

As a manager, the 3 other personas have their place in a team, especially the young expert. He is someone very talented that a manager has to help him grow and cherish.
The remaining two, the familiar and the expert with lots of years of experience are the most common cases.

In my opinion, there is no good or bad one, they are very complementary and i think that a team need both to operate smoothly.

How they can interact each other ? and how we can organize a team ?

As they are compatible, the interaction should come up very naturally. Each member will fill the weakness of the other.

As they are veterans, the manager should aproach them equally and with the same management style: a very participative one. They have to be included in all aspects of decisions.
Indeed, one can warn if some new idea have already been tested before and explain why it has failed and the other can propose new technical ideas. They are the leaders of the development team.

Off course, these types can be embodied by the same person: lucky for you! Cherish him and do everything to keep him motivated and afloat. However, as a managerial mindset, he is a valuable resource and also the biggest risks. He can be some kind of "hero" preventing the team to succeed as a all. Moreover, if he is not present for random reasons (sickness, quitting, parental leave etc...) the team will suffer and productivity also. Thus, the task of the manager is to create a system where the knowledge and expertise is shared between teammates. Here is some avenues:

favor pair programming and mob programming
hunt information retention
share regularly technical surveillance
do code reviews

Also, some Domain Driven Design principles like event storming can help your team discover the business and become more familiar.

Conclusion

The concept of seniority is quite vague and very context-dependant to provide an exhaustive definition. Nevertheless, I think that this split can help managers and teams to better select their seniors and
make a more balanced team.

TL;DR

there is two types of seniority: familiarity and technical expertise
Familiarity is the fact that someone knows very well the project/source code/business context
Technical expertise is someone that has a deep knowledge of its area of expertise regardless the project
Both are very valuable and complementary person for a project to succeed
Both have to be treated equaly and no hierarchy should be put in them. Both have to lead the team and the younger persons

The complete guide to env variable in react native

Steve Alves-Blyt — Tue, 21 Mar 2023 15:44:28 +0000

Environment variables are very useful in software engineering. It allows you to gain more flexibility on your configuration, bring feature flags,
avoid duplicates and be 12 factor compliant.
For instance, you can declare several domain for your backend api and with just a few lines of code you switch.
Usually, in the frontend world, dealing with env variables is pretty straightforward. However, in the React Native world, there is a few differences that can
be confusing for any newcomer.
Thus, the aim of this article is to help you clear away the deadwood from it.

Nota Bene: the example shown can be accessed here

What ? no need to write an article about that just use `process.env`

process is a module exclusive to NodeJS. However, React Native doesn't
use Node to run its JS bundle but relies on the Hermes engine. Unfortunately, hermes doesn't embark the process module or a way to emulate it.

However, one exception exists: process.env.NODE_ENV have been implemented for convenience purposes (it is like a standard).

That's why we need to use a separate library or implement our custom one. Nowadays, The React Native ecosystem provide two popular alternatives:

Both share the same purpose but uses different strategies that we'll explain right away.

NB: some ressources advices to use
this babel plugin
It doesn't work on newer version of RN because the process.env doesn't exist.

react-native-dotenv

react-native-dotenv is a babel plugin that let you inject your environment variable into your javascript environment. You declare it as a plugin in your
.babelrc file and that's it ! Let us ding into and example.

here is our .env file:

FEATURE_ENABLED=true

and it can be accessed in our code like this:

import {FEATURE_ENABLED} from "@env"

console.log(FEATURE_ENABLED)

For typescript users, you'll have to create a definition file env.d.ts to have code completion.

declare module '@env' {
    export const FEATURE_ENABLED: boolean;
}

As we can see, as it is a babel plugin, our variables are accessible ONLY in the JS part. So, if we want to have access within the native part, we'll have to use another library
the react-native-config

react-native-config

As said above, the specificity of this library is that it allows you to access your variables on both sides. They did that by parsing the .env files directly on the native sides
and generating a map.

On the JS side, the use is similar as the previous lib:

import Config from "react-native-config";

Config.FEATURE_ENABLED; // true

and on the native side:

public Boolean isFeatureEnabled(){
    return BuildConfig.FEATURE_ENABLED;
        }

on the gradle configuration:

defaultConfig {
    applicationId project.env.get("FEATURE_ENABLED")
}

As we can see, this library provides more possibilities. However, as it is implemented on the native side, it would require to cross the bridge if you want to access the value of
an environment variable on the JS side, causing some performance issues if not dealt well or an unnecessary round trip. That's why we recommend this library if you are sure that
you would need an access on the native side.

Conclusion

As we saw, there is a couple of choices to handle env variables in React Native. According to your needs, you would need one or another.
Below lies a summary:

TL;DR

two librairies are mainly used: react-native-dotenv and react-native-config
both are easy to use and easy to configure
use react-native-dotenv if your variables are needed only in the JS part
use react-native-config if your variables are needed on both parts (native and JS).
process.env can't be used in the RN ecosystem as it does not run inside a NodeJS app but a Hermes engine one instead.

How does the 'behavior' property of the KeyboardAvoidingView component works ?

Steve Alves-Blyt — Wed, 22 Feb 2023 10:22:51 +0000

React Native is a framework that have been in the landscape for many years (since 2015) and is widely used today.
This fame brings several challenges, one of them is the Developer Experience (DX for short). DX partly relies on the documentation: a bad one can
prevent the framework adoption. So, one job of the maintainers is to update/improve it with the help or not of the community.

About React Native, one of the documentation flows I noticed regards The 'KeyboardAvoidingView' component and the 'behavior' attribute.
The documentation is quite terse on the subject unfortunately. That's the purpose of this article: trying to clarify the behavior of the attribute.
What does it do ? For that we'll look at the source code.

Disclaimer: you can find the source code here

Overview

The behavior props is an enum of 3 values:

height
position
padding

And as it is a facultative prop, a default behavior is implemented.

Each one adapts the position of the children components following the keyboard dimensions using a specific method. Using the 'height' css atribute or the 'padding' one for instance.
The 'position' value acts differently and nor accordingly from its name, ie, doesn't use the 'position' css attribute.

Let's show some code ! All the logic is contained in the 'render' method and a switch case.

height

Here is an extract of the source code:

    case 'height':
        let heightStyle;
        if (this._frame != null && this.state.bottom > 0) {
          heightStyle = {
            height: this._initialFrameHeight - bottomHeight,
            flex: 0,
          };
        }
        return (
          <View
            ref={this.viewRef}
            style={StyleSheet.compose(
              style,
              heightStyle,
            )}
            onLayout={this._onLayout}
            {...props}>
            {children}
          </View>
        );

In this case, we check if the keyboard is present via the bottom state variable (a state variable containing the height of the keyboard). And if yes, we create a view whose style has a defined height attribute equals to the substraction of
the frame heigth and the size of the keyboard. Also, a flex: 0 is set, meaning that the View just takes the place defined by its heigth, no extra calculus done to make it bigger or smaller.
The condition is present to make the heigth revert if the user closes the keyboard, otherwise it would have been stucked.

So, this behavior is equivalent to create a View component with a fixed defined height.

padding

Here is an extract of the source code:

    case 'padding':
        return (
            <View
                    ref={this.viewRef}
                    style={StyleSheet.compose(
                            style,
                            {paddingBottom: bottomHeight},
                    )}
                    onLayout={this._onLayout}
                    {...props}>
              {children}
            </View>
        );

For this behavior, the framework creates a View component, as the previous one but this time we play with the paddingBottom attribute, ie the component enlarges itself from the bottom
by a value defined by a bottomHeigth, which is the height of the keyboard. So, we push the content of the view above to make place for the keyboard by making the container larger.

So, this behavior is equivalent to create a View component with a bottom padding large enough to welcome the keyboard.

position

Here is an extract of the source code:

    case 'position':
        return (
            <View
                    ref={this.viewRef}
                    style={style}
                    onLayout={this._onLayout}
                    {...props}>
              <View
                      style={StyleSheet.compose(
                              contentContainerStyle,
                              {
                                bottom: bottomHeight,
                              },
                      )}>
                {children}
              </View>
            </View>
        );

This one differs from the previous. Indeed, in this case the View is not enlarged but placed higher in the screen regardless of the other components. Its position is absolute.
Moreover, we create 2 nested views, one with the props and style and the other with the newly applied property plus another style provided by the contentContainerStyle property.

So, this behavior is equivalent to create two Views component with an absolute placement of the size of the keyboard.

default

Here is an extract of the source code:

    default:
        return (
            <View
                    ref={this.viewRef}
                    onLayout={this._onLayout}
                    style={style}
                    {...props}>
              {children}
            </View>
        );

As you can see, no extra styling are added so we fallback into the default configuration. It behaves differently according the OS:

in android, it tries to adjust the size of the screen to let place to the keyboard thanks to the adjustResize attribute defined by default in the manifest
in ios, the view doesn't resizes so the keyboard overlaps the input. Indeed, by default, no attributes exists and some code is needed to do that

So this behavior lets the OS places the keyboard natively.

Conclusion

Unfortunately, we can't predict exactly the behavior according the OS and they both
interact with this prop differently.

That's why we recommend:

To set this prop and act as it is a mandatory one, by wrapping it with a component making it required. An example:

import {KeyboardAvoidingView as RNKeyboardAvoidingView} from 'react-native';
import {KeyboardAvoidingViewProps} from 'react-native/Libraries/Components/Keyboard/KeyboardAvoidingView';

interface KeyboardAvoidingViewType extends KeyboardAvoidingViewProps {}

const KeyboardAvoidingView = ({
                                behavior,
                                children,
                                ...props
                              }: KeyboardAvoidingViewType) => {
  return (
          <RNKeyboardAvoidingView behavior={behavior} {...props}>
            {children}
          </RNKeyboardAvoidingView>
  );
};

export default KeyboardAvoidingView;

2.To trial and error with the different possibilities, and not hesitating to change the value following the OS.
For instance, in our test case (a simple text input emulated on a ios 14 and pixel xl), only the height
attribute worked for and android and the other two only for ios.

Dependency injection with AWS Lambdas in java

Steve Alves-Blyt — Sat, 11 Feb 2023 19:42:23 +0000

Disclaimer: for those who wants to see the solution, the github is here

No need to present the AWS Lambdas ; those have been disruptive innovations and they made the app development process smoother and more flexible. In this article, I will expose a way to add dependency injection within your lambdas.

Why dependency injection with nanoservices ?

The question is fair. Indeed, as each function is independent from the other, why bother yourself adding a new level of abstraction and complexity ?

In fact, if you you want to follow the good practices of scalable code, some parts of your code is shared between functions. For instance, the services querying the database. Thus, your source code grows in complexity and becomes similar to a more « classic » web application, inviting you to follow the SOLID acronym.

Off course, depending on your needs and situation, it would be better to not do it but if you target the long run, it would be suicide to unfollow the good practices (exponential growth of maintenance costs…).

As said in the title, we will focus on the dependency inversion principle and one of its application : dependency injection. For production-ready applications, it would be better to rely on a framework and not implement its own container. For it, the java ecosystem have 3 frameworks available : Spring, Guice and Dagger.

Spring and Guice

In the java world, Spring is THE most-used solution. Proven, maintained at a constant pace, it became the standard. However, its ecosystem is too large (IOC, MVC…) for our needs so we’ll have to install a lot of useless frameworks just for dependency injection making the package size not optimal. Moreover, all the injection is done at runtime making your cold start even longer ! Needless to say that all the binding errors will be detected at runtime so when the lambda is launched. Thus, Spring is not a good choice.

On the other hand, Guice is another dependency injection framework created by Google. It a good alternative because :

Framework package size much lighter than Spring
No external configuration file to setup (no properties or xml files)

However, it wouldn’t feet our needs because like Spring all the injection is done at runtime.

Then, is there a good solution ? yes and it is Dagger !

Dagger ?

Dagger is a dependency injection framework developed by Square and forked by Google. It is widely used in the Android ecosystem. Its key points are :

Lightness : juste dependency injection
Use of **java.inject annotation**
Last but not least, the injection is done at compilation. No more binding errors at runtime ! Thus, all the injection is done at the packaging of our lambda bringing the cold start to its bare minimum.

Let’s deep dive a little.

Short overview of Dagger

Dagger is built around 2 concepts : Modules *and *Components.

A module is a container, represented by a class, where you declare your classes and define the dependency relationship between them. An example :

A component is an interface used as the entry point of the application. It also links the modules needed to make the application run. Here goes an example :

From there, Dagger will generate factories from modules and Builders from components.

Use case

The example is quite simple. We have 3 services : AService, BService, AgregateService. Each one has a print function which returns the eponym letter. The AgregateService similarly returns « ABC ».

All the plue-value is at the **LambdaDispatcher **class. This is a dispatcher acting as an entry-point and allowing to :

Generate the component and the dependency tree
Forward the request to the related service
Bring an abstract lawyer splitting the business code from the infrastructure one (ie AWS and Dagger librairies) making the code more maintable and testable.

Here is the implementation :

And the component :

Module :

As an image worth 1000 words :

Here is the github.

How to type hex colors in typescript ?

Steve Alves-Blyt — Mon, 06 Feb 2023 16:45:19 +0000

As typescript doesn't accept regex in types, we had to find a way
to type our hex colors in our design system. Indeed, it wouldn't be very efficient to make a string type like that:

export type ColorValueHex = string;

as it will accept all strings.
For that, we came up with 2 solutions: a simple but less rigorous
and an exhaustive one but more complex. We'll present those two solutions and explain which one we had to choose.

The simple and straightforward solution:

The idea is to use the string template feature of typescript to shrink the type a little:

export type ColorValueHex = `#${string}`;

With that, we don't allow all types of string but only the ones beginning with the '#' character. Moreover, it is
quite readable and maintainable thanks to its simplicity.

However, we wanted to push it a little further to check if it would be possible to tackle all the cases.

The exhaustive one :

type HexaNumber = 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9;
type HexaLetter = 'A' | 'B' | 'C' | 'D' | 'E' | 'F';
type HexaChar = HexaLetter | HexaNumber;
type Hexa3 = `${HexaChar}${HexaChar}${HexaChar}`;
type Hexa6 = `${Hexa3}${Hexa3}`;
type Hexa8 = `${Hexa6}${HexaChar}${HexaChar}`;
type ColorValueHexComplex = `#${Hexa3 | Hexa6 | Hexa8}`;

We cover all the use cases, but we faced another issue. We found that typescript put in memory all possible the possible values
to evaluate a type. It meant to us 16^8=4,294,967,296 namely more than 4 billions ! So we had the TS2590: Expression produces a union type that is too complex to represent
error from our 16Gb RAM macs.

NB: Instead of doing an union type, we could have done a type Range using tail recursion instead of writing the number and letters one by one. Here is an example of Range type:

type Range<N extends number, Acc extends Array<number> = []> = (Acc['length'] extends N ? Acc : Range<N, [...Acc, Acc['length']]>);
type NumberRange = Mapped<9>[number];

However, we kept the previous one mainly for readability purposes (the unions types are quite small).

Conclusion

Finally, we came up with the first one. Pushing it into the last solution allowed us to reach the limit of typescript and learn about how
typescript runs under the wheel.
So until big changes in typescript, we advice that the best way to type an hex color is to use following type:

export type ColorValueHex = `#${string}`;

DEV Community: Steve Alves-Blyt

An example of kindness in tech: the case of “shitty code”

Introduction

The issue of the expression

The danger of this expression

As a manager, how to deal with ?

As a developer, what should I do ?

Conclusion

TL;DR

# What is seniority in software engineering ? An attempt to qualify it

Introduction

The common characteristics of a "senior"

Familairity ? Expertise ?

How they can interact each other ? and how we can organize a team ?

Conclusion

TL;DR

The complete guide to env variable in react native

What ? no need to write an article about that just use process.env

react-native-dotenv

react-native-config

Conclusion

TL;DR

How does the 'behavior' property of the KeyboardAvoidingView component works ?

Overview

height

padding

position

default

Conclusion

Dependency injection with AWS Lambdas in java

How to type hex colors in typescript ?

The simple and straightforward solution:

The exhaustive one :

Conclusion

What ? no need to write an article about that just use `process.env`