Forem: jenoH

Developer journey: From Working Code to Maintainable Code

jenoH — Tue, 27 May 2025 11:31:00 +0000

This post isn’t technical, it doesn’t cover specific design patterns or advanced techniques. It’s more about stepping back and thinking about how complexity shows up in everyday coding. I wrote it to reflect on the kinds of questions I try to ask myself when writing or reading code, to be more thoughtful about structure, clarity, and how things evolve over time.

When I was learning to code, the goal was simple: make it work. In school projects or small personal projects, once the program ran and the output was correct, it felt like the job was done.

But as I started working on larger systems, especially with multiple engineers involved, I began to notice something: even when the code worked, coming back to it later was confusing. Small changes would break things unexpectedly. Features that sounded simple ended up being surprisingly messy to implement. I started realizing that writing code that works isn’t the same as writing code that lasts.

This is where the idea of complexity enters the picture. As systems grow, complexity builds up, and it quietly becomes one of the biggest challenges in software development. It makes code harder to understand, slower to modify, and more fragile over time.

“Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system.”

— John Ousterhout, A Philosophy of Software Design (2018)

This post is just me trying to reflect on what I’ve started to notice about complexity. I'm still figuring it out, but writing this down helps me make sense of the patterns I'm seeing and the habits I want to build going forward.

The Cost of Ignoring Complexity

At first, complexity doesn’t seem like a big deal. The code works, the tests pass, and features get shipped. But slowly, things start to drag. Small changes take longer. Bugs are harder to fix. New team members (or even future-you) need more time to understand how things work.

These issues don’t show up overnight, they creep in. But if you pay attention, there are early signs.

Change Amplification

Sometimes, making a small change in one place means updating five other files, multiple tests, and maybe even other services. A small rename turns into a mini refactor.

This is called change amplification, and it usually means parts of the system are too tightly connected. It makes even safe changes feel risky, and slows everyone down.

High Cognitive Load

When things are too coupled, full of edge cases, or just hard to follow, it takes a lot of mental effort to get going. That’s what people mean by high cognitive load, you have to keep too much in your head at once.

Unclear Change Points

A bug shows up in one place, but the root cause is somewhere else. Or a new feature needs to touch several parts of the code, and I’m not sure which one should be updated, or if I should add something new.

Early Habits That (I Think) Help

I'm still learning, but here are some habits that seem to help reduce complexity, or at least make it more manageable.

Try to Keep Boundaries Clear

Even in small projects, I’ve started paying more attention to what belongs where. A function should do one thing. A module should have a clear role. When boundaries get fuzzy, everything gets harder to change later.

Read Code to Understand Design

Whenever I’m working in an unfamiliar part of the codebase, I try to slow down a little and ask: why is it written this way? Not just how it works, but what the intent might have been.

Doing this regularly is helping me build a kind of intuition for what “clean” or “messy” really means in context.

Understand Tradeoffs (Not Just Rules)

I’ve come across a lot of advice like “keep functions short” or “don’t repeat yourself.” These are useful, but I’ve also seen how following rules blindly can sometimes make code worse.

What I’m starting to realize is that most decisions are tradeoffs. It’s not about always doing the same thing, it’s about thinking through the consequences.

One question I’ve started asking myself more often: will this make the next change easier or harder?

Complexity Feels Like a Design Problem

One of the most valuable lessons I’m learning is that complexity isn’t usually caused by “bad code.” More often, it comes from design decisions that were made under pressure, with limited context, or simply as the best idea at the time.

Code tends to grow around real-world constraints: deadlines, changing requirements, evolving teams. Sometimes the structure doesn’t keep up, and things start to feel messy or hard to change.

What I’ve started to realize is that complexity is often a design problem, not a personal one. It's about how pieces fit together, and how decisions made early on affect everything that comes later.

Final Thoughts

Complexity is part of the job. It can’t be avoided entirely, but I’ve learned that it can be managed. And the earlier you start noticing it, the more control you have over it.

Automate the deployment of a virtual machine on AWS using Terraform and Github Actions

jenoH — Fri, 27 Jan 2023 14:09:06 +0000

First, I want to notify that I'm a software developer and not a devops engineer. That's why if you have any good practice tips, feel free to give me feedback, I will enjoy that!

The goal of this guide is to show you a way to automate the deployment of your virtual machine on AWS. We will need to use Terraform to describe our infrastructure as code and Github Action to trigger/automate the deployment. This combo is very powerful if you want a flexible infrastructure, so I will try to show you a clean overview of what you can do for your professional/side projects.

Terraform

Terraform creates and manages resources on cloud platforms and other services through their application programming interfaces (APIs). Providers enable Terraform to work with virtually any platform or service with an accessible API.

The benefit of using Terraform

Terraform will allow you to define your infrastructure as code. Combined with pipeline like Github Action you can automize the deployment of your entire infrastructure. You can deploy, destroy and change your cloud infrastructure with one command line, thank's to the Terraform CLI.

Introduction

First, you will need to install Terraform in your machine. I let you have a look at the documentation here. If you are using macOS and brew like me, type these two commands:

brew tap hashicorp/tap
brew install hashicorp/tap/terraform

To use your IAM credentials to authenticate the Terraform AWS provider, set the AWS_ACCESS_KEY_ID and the AWS_SECRET_ACCESS_KEY environment variables.

export AWS_ACCESS_KEY_ID=
export AWS_SECRET_ACCESS_KEY=

Files architecture

I'll present you a way to arrange your Terraform files into a terraform folder (for readability reasons).

File	Description
ec2.tf	Configuration of our virtual machine (in our case an ec2 from aws).
security_group.tf	Rules of security for the machine.
variables.tf	Set variables from our environment.
vpc.tf	Definition of our virtual private network.

Let's build our virtual machine !

Now, I'll explain how to define a simple EC2 virtual machine. First, we need to create an SSH key pair to allow access remote on the machine. If you don't know how to do, take a look at the Github documentation.

Now that you have your SSH key pair, you should set the TF_VAR_SSH_PUB_KEY of your public key.

Notice: All your environment variables used for Terraform will need the TF_VAR prefix.

# variables.tf

variable "SSH_PUB_KEY" {
    type = string
}

The goal of the provider.tf file, is to define the provider we are going to use, here we will specify AWS with the region (for french people, you can use eu-west-3)

# provider.tf

provider "aws" {
    region = "eu-west-3"
}

Then, we can write our ec2.tf file, which is the heart of the configuration :

# ec2.tf

resource "aws_key_pair" "admin" {
    key_name = "admin"
    public_key = var.SSH_PUB_KEY
}

resource "aws_instance" "SRV-Front-ESP" {
    ami = "ami-002ff2c881c910aa8"
    instance_type = "t2.nano"
    key_name = "admin"

    tags = {
        Name = "SRV-Front-ESP"
        "Application" = "Web-ESP"
        "Environment" = "PRD"
        "OS" = "Debian"
        "Role" = "Frontend"
    }
}

resource "aws_eip_association" "eip_assoc" {
    instance_id = aws_instance.SRV-Front-ESP.id 
    allocation_id = var.EIP_ASSOC_FRONTEND
}

terraform {
    backend "s3" {
    bucket = "kom-front-bucket-ml"
    key = "terraform.tfstate"
    region = "eu-west-3"
    }
}

Each resource block define a feature of our ec2. The aws_key_pair resource will store into the virtual machine the public key. We should specify a name, to be able to manage multiples key pair. Here, I named my key admin.

The next resource aws_instance is very important, it may change with your needs. First, we will need to define an ami. An ami (Amazon Machine Images) as its name indicates, is the image for your virtual machine, In my case I choose a Debian image. You can also create your own ami, if you have specific needs.
Next, I defined t2.nano as instance_type. The t2.nano is a virtual machine with 1 vcpu ans 0.5 GiB of ram, it's the smallest offer. If you need more power, you can choose another offer here.

The key_name is used to provide the good SSH key for your virtual machine. And finally, the block tags is here to provide informations, you can fill it as you want.

Now, let me introduce you the state in Terraform. The notion of state is very important to understand how Terraform works. This state is used by Terraform to map real world resources to your configuration. It's stored by default in a local file named "terraform.tfstate", but it can also be stored remotely, which works better in a team environment.

That's why I use a bucket from Amason S3 to store the terraform.tfstate. Now, your file in your bucket will be up to date compared to the actual state of your server.

That's all, now you can run terraform init, this command performs several different initialization steps in order to prepare the current working directory for use with Terraform. After initialization, you can run terraform plan to see what will make your terraform configuration. If you are ok with the result of the plan, you can finally run terraform apply and see your virtual machine alive !

Now that we can deploy our virtual machine, we will need to setup Github Actions to automate the deployment.

Github Actions

Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline.
The global idea is to have in your Github repository of your project, a Terraform folder with your Terraform config and a .github folder with your jobs workflow.

Introduction

To run Terraform in your workflow, you will need to setup our secrets in the settings of your github's repository or your github organization (to share your secrets between repositories).

AWS credentials:

Terraform environment variables:

Let's build our workflow !

A workflow run is made up of one or more jobs, which run in parallel by default. In our case, we need just one job. This job should setup and run Terraform.

# .github/workflows/deploy.yml

name: DEPLOY

on:
  pull_request:
    branches:
      - main
    types: [closed]

jobs: 
  deploy-vm:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1

      - name: Install terraform
        run: sudo apt-get install -y software-properties-common gnupg2 curl

      - name: Install dependencies
        run: |
          curl https://apt.releases.hashicorp.com/gpg | gpg --dearmor > hashicorp.gpg
          sudo install -o root -g root -m 644 hashicorp.gpg /etc/apt/trusted.gpg.d/
          sudo apt-add-repository "deb [arch=$(dpkg --print-architecture)] https://apt.releases.hashicorp.com focal main"
          sudo apt update
          sudo apt install terraform

      - name: Terraform init
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          TF_VAR_EIP_ASSOC_FRONTEND: ${{ secrets.TF_VAR_EIP_ASSOC_FRONTEND }}
          TF_VAR_SSH_PUB_KEY: ${{ secrets.TF_VAR_SSH_PUB_KEY }}
        run: |
          pwd
          ls -la 
          cd terraform
          terraform init

      - name: Terraform apply
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          TF_VAR_EIP_ASSOC_FRONTEND: ${{ secrets.TF_VAR_EIP_ASSOC_FRONTEND }}
          TF_VAR_SSH_PUB_KEY: ${{ secrets.TF_VAR_SSH_PUB_KEY }}
        run: |
          cd terraform
          terraform apply -auto-approve

First, we define when we want to trigger the pipeline with the on block. Here, I have decided to deploy/apply changes on my virtual machine for each closed merge request on the main branch, but you can change for scheduled task, push on develop, etc..

Finally, you can define one step to install dependencies. Here I have defined ubuntu-latest as image for the pipeline, so I should install dependencies with the package manager apt-get. And now, you can write two steps, for terraform init and terraform apply.

And voila ! You can see your workflows in the Actions tab of your repository !

That's all ! I hope I have helped you to see it more clearly !

As said at the beginning, I'm a software developer, I just love learning new things, but I understand that I can tell some mistakes, feel free to give me feedback ! I will fix it.

Théo "jenoH". Twitter Github.

How I have created my own technological survey with node.js and Gitlab CI/CD.

jenoH — Thu, 11 Jun 2020 09:34:54 +0000

Disclaimer: It's my first article, and I'm not yet proud of my English level. Nice read at all !

Hello guys, how are you ? Do you subscribes to newsletters for your daily technological survey and don't read any articles ?

I realized that some time ago. So I have decided to create my own "private" flux of news/articles.

In theory.

The theory is really simple:

We need to find some rss flux of what you want to read.
After this search, we need to make a script who send an email every morning at your favorite email address.
And at the end, you can run this script on a server as a cron or you can also use Gitlab CI/CD.

Notice that I have make the minimum at the moment. We can add more rss flux, and clear articles/news before send an email to improve your technological survey.

Let's code !

I want to improve my javascript level so I have pick this technology, but you can do the same thing with another techno..

I will not explain a lot my code because you can do what you want, and you will probably understand my code easily !

My gitlab repository.

For my example I have take a Reddit rss like this :

let feed = await parser.parseURL('https://www.reddit.com/r/softwaredevelopment/.rss');

Sending email with nodemailer and handlebars.

Sending email with node.js is really simple with nodemailer !
First, we need to define the transport for nodemailer, in my case I have use gmail, but you can take mailgun, or whatever, but gmail is easy to set up.

var transporter = nodemailer.createTransport({
  service: 'gmail',
  auth: {
    user: 'cronjenoh@gmail.com',
    pass: process.env.MAIL_PASS
  }
});

Next, we have to feed our HTML with our news previously collected on the rss flux.

For that, I have used Handlebars. Handlebars is a simple templating language. It uses a template and an input object to generate HTML or other text formats.

It's working like this :

 readHTMLFile(__dirname + '/email.html', function (err, html) {
    var template = handlebars.compile(html);
    var replacements = {
      posts: posts
    };
    var htmlToSend = template(replacements);

In the htmlToSend variable we have the template with our news. (My repository have an example of an email template).

Running the srcipt as a cron

In my case, I have choose GitLab CI/CD.
GitLab CI/CD is a tool built into GitLab for software development through the continuous methodologies:

Continuous Integration (CI)
Continuous Delivery (CD)
Continuous Deployment (CD)

It's perfect when you need to run a scrips as a cron, it's easy to use.
So, first step, we need to add a .gitlab-ci.yml file in our repository.

default:
  image: node:latest

stages:
  - run

cron run:
  stage: run
  script:
    - npm i
    - node cron.js

The first line is facultive, in fact if we remove this, Gitlab will take the default image for your docker container, but I have decided to take a node image (more coherent with my project).

Second step, we should whrite a stage and a job. In the job we should set the list of actions to setup the project. For a node project, we need to install packages with npm i and run the cron node cron.js.

After that, if you push you will see in CI/CD settings of your project that a pipeline as been created.

Final step, go to your schedules settings in CI/CD and set up your cron, with the target branch, timezone, recurrence ..

And it's done !

I hope you have enjoyed my article, I did it with pleasure ❤️.