DEV Community: Hamza

After Years of Building, Fixing, and Supporting Production Systems, I’m Looking for My Next Opportunity

Hamza — Wed, 23 Sep 2026 18:44:02 +0000

Hi DEV Community,

I hesitated before writing this post.

For years, I was used to being the person people called when something had to be built, fixed, investigated, deployed, or understood.

Today, I’m on the other side of that experience.

I’m looking for work.

And after months of applications, silence can become surprisingly heavy.

A little about me

My name is Hamza AIT-SIDI-SAID. I’m a software engineer from Morocco with more than six years of experience in web development.

My main stack is:

PHP · Symfony · Laravel · SQL · REST APIs · React · Git · CI/CD · Docker · Linux

But those technologies only tell a small part of the story.

During my most recent experience at Capgemini Morocco, I worked on enterprise applications for clients including ENGIE and UGI / Antargaz.

These were not side projects or tutorials.

They were real production systems, used by real businesses, where bugs had consequences and where reliability mattered.

I worked on application development, APIs, SQL optimization, production support, deployments, incident resolution, CI/CD, code reviews, application maintenance, and technical troubleshooting.

I also had the opportunity to support junior developers and share knowledge with the team.

There were days when everything worked normally.

And there were other days when a production incident appeared, something broke unexpectedly, or an application needed to go live.

Those moments taught me something that no framework documentation can teach:

software engineering is not only about writing code.

It is also about staying calm when something breaks.

Understanding systems you did not originally build.

Reading logs.

Asking the right questions.

Helping teammates.

Taking responsibility.

And sometimes spending hours chasing one small detail that turns out to be the entire problem.

Then suddenly, everything became quiet

My latest professional chapter ended in 2026.

I expected that with several years of experience, enterprise projects, production experience, and a solid technical background, finding the next opportunity would be relatively straightforward.

It hasn't been.

I have applied.

I have rewritten my CV.

I have adjusted my LinkedIn profile.

I have searched locally and internationally.

I have explored remote roles, freelance opportunities, relocation opportunities, and traditional employment.

And sometimes the answer is simply silence.

No rejection.

No technical interview.

No feedback.

Just silence.

I won't pretend that this is easy.

When you spend years being useful to teams and suddenly struggle to get even the first conversation, you start questioning things you never questioned before.

Your experience.

Your skills.

Your decisions.

Sometimes even your value as an engineer.

But I also know what I have done.

I know the systems I have supported.

I know the incidents I have solved.

I know the applications I have helped deliver.

I know how many times I had to learn something quickly because production could not wait.

So instead of keeping this search private, I decided to write this post.

What I can bring to a team

I’m particularly comfortable working on:

PHP and Symfony applications
Laravel projects
REST APIs and system integrations
MySQL, Oracle, PostgreSQL and SQL troubleshooting
Existing and legacy applications
Production incident investigation
Application maintenance and modernization
CI/CD pipelines
Backend architecture
Performance investigation
Code reviews
React when a project requires full-stack work
Technical support for business-critical applications

I am also comfortable joining an existing project.

I don't need everything to be greenfield.

Actually, some of the work I enjoy most is opening an unfamiliar codebase, understanding how it works, identifying where the problems are, and gradually making it better.

What I am looking for

I am currently open to:

Full-time positions
Remote work
Freelance missions
Contract work
Short-term projects
Backend PHP / Symfony roles
Full-stack PHP / React roles
International opportunities
Relocation opportunities

I am based in Morocco, but geography is not a limitation for the right collaboration.

If a company has an old PHP application nobody wants to touch anymore, I can help.

If a Symfony application needs new features, I can help.

If APIs need to be built or fixed, I can help.

If production issues keep returning, I can investigate them.

If your team has accumulated months of technical backlog, I can help reduce it.

And if you simply need another experienced engineer who can join a team, understand the context, and start contributing, I would be happy to have that conversation.

Why I am writing this publicly

Normally, job searches happen quietly.

You send applications.

Recruiters receive them.

Algorithms rank them.

ATS systems parse them.

And somewhere behind all of that is a human being.

So I wanted to try something different.

I'm putting my story here.

Maybe a CTO reads this.

Maybe a recruiter sees it.

Maybe another developer knows a team looking for someone.

Maybe someone has a Symfony project that has been sitting unfinished for months.

Or perhaps somebody simply shares this post with the right person.

Sometimes careers change because of one conversation.

I'm looking for that conversation.

If you can help

You don't have to offer me a job.

If you know someone who is hiring, sharing this post is already useful.

If your company needs a PHP/Symfony engineer, feel free to contact me.

If you have a freelance project, even a small one, I am open to discussing it.

And if you are another developer going through the same silence after months of applications:

I understand it much better now.

Keep building.

Keep learning.

Keep showing your work.

Eventually, someone has to open the door.

For me, this post is another knock on that door.

Contact

Hamza AIT-SIDI-SAID

Software Engineer
PHP · Symfony · Laravel · React · REST APIs · SQL · CI/CD

🌍 Morocco — Open to remote work and relocation

🔗 Portfolio: ait-sidi-said.work

🔗 LinkedIn: https://www.linkedin.com/in/hamza-ait-sidi-said/

🔗 GitHub: https://github.com/hamza-topo

📧 Email: hamzaaitsidisaid11@outlook.com

Thank you for reading.

And if you know someone who might need my experience, I would genuinely appreciate you sending this post their way.

I Built CaptureKit: A Privacy-First Browser Capture Extension

Hamza — Tue, 08 Sep 2026 16:21:37 +0000

I recently built CaptureKit, a browser extension for capturing web content without sending it to a remote server.

The idea was simple: I wanted one lightweight tool for the three capture actions I use most often:

Full-page screenshots
Selected-area screenshots
Short tab recordings

Why build another capture extension?

There are already many screenshot tools available, but I wanted CaptureKit to follow a local-first approach.

Captured content is processed locally in the browser. There is no account requirement, no cloud upload for captures, no analytics, and no advertising.

Short recordings are temporarily stored in the browser and automatically expire after 5 minutes.

The technical side

CaptureKit is built with:

WXT
React
TypeScript
IndexedDB
Browser Extension APIs
MediaRecorder

One interesting challenge was supporting multiple browsers.

Chromium-based browsers can use tabCapture for tab recording, while Firefox requires a different approach using its native display-media selection flow.

Full-page screenshots also required handling scrolling, viewport segmentation, device pixel ratio, image stitching, and restoring the page correctly after capture.

What CaptureKit can do

Full Page

Capture an entire webpage, including content outside the visible viewport.

Selected Area

Draw a selection directly on the page and capture only that region.

Record Tab

Create a short recording of a browser tab, with a maximum duration of 60 seconds.

Captures can then be previewed, copied, downloaded, or deleted locally.

Building for Chrome, Edge, and Firefox

One of my goals was to avoid maintaining three completely separate extensions.

WXT made it possible to share most of the codebase while still handling browser-specific behavior where necessary.

The project currently targets:

Chrome
Microsoft Edge
Firefox

I'm now going through the store publication process and testing the extension across the three browsers.

What's next?

The current focus is reliability: testing different websites, zoom levels, high-DPI displays, long pages, recording permissions, and browser-specific edge cases.

This project has also been a useful exercise in understanding how modern browser extension APIs differ between Chromium and Firefox.

If you work with browser extensions, I'd be interested to hear about the cross-browser issues you've encountered.

I built SketchStash — a small tool to store terminal commands and dev snippets

Hamza — Sun, 15 Mar 2026 04:52:27 +0000

Hi devs 👋

I built a small tool called SketchStash to store terminal commands, snippets and technical notes in one clean workspace.

Instead of losing commands in terminal history, the idea is to keep everything searchable and organized.

Current features:
• Code snippet editor
• Command search
• Tag system
• Pagination
• Focus audio player
• Dark / light theme
• Responsive UI

Stack:
React + TypeScript
Symfony API
Docker
MySQL

Coming soon:
Auth (register/login)
Tag management
Bulk delete

Would love your feedback 🙌

Live demo:
https://sketchstash.online

I built a tiny Linux tool that shouts “FAHH” when I type the wrong command

Hamza — Thu, 05 Mar 2026 13:53:48 +0000

I built a tiny Linux tool that shouts “FAHH” when I type the wrong command

A few weeks ago I noticed something about the way I work in the terminal.

When I’m focused and typing commands fast, I tend to make a lot of small mistakes.

Wrong command.

Misspelled command.

Sometimes I just type something that doesn't exist.

And the terminal just replies with the usual:

command not found

That message is… boring.

And also very easy to ignore.

So I started thinking:

What if the terminal could actually react when I type something wrong?

Not visually.

Not with an error popup.

But with sound.

Something dramatic.

Something like:

FAHH.

The idea

I wanted something very simple:

Whenever I type a command that doesn't exist in the terminal, play a sound.

Nothing fancy.

Just a tiny reaction that reminds me:

"Hey… that command doesn't exist."

I initially looked for something like this inside VSCode extensions.

There were some interesting ones, but they only worked inside the editor terminal.

I wanted something that works everywhere:

WSL
Debian
normal Linux terminals
zsh
bash

Basically anything I run in the shell.

So I decided to build a tiny CLI tool for it.

The result

I ended up creating a small tool called:

fahhctl

What it does is very simple.

When you type a command that doesn't exist:

fakecommand

You still see the normal error message:

command not found: fakecommand

But you also hear:

FAHH 🔊

How it works

The tool installs a small hook into your shell configuration.

When the shell detects a command that doesn't exist, it simply runs:

fahhctl play

Which plays a sound file.

That’s it.

No background process.

No daemon.

Just a tiny hook and a sound.

Installation

If you're curious and want to try it:

curl -fsSL https://raw.githubusercontent.com/hamza-topo/fahhctl/main/install.sh | bash

Then reload your shell:

source ~/.zshrc

Now try typing something wrong.

Customize the sound

The default sound is a dramatic FAHH, but you can replace it with anything.

The sound file lives here:

~/.local/share/fahh/fahh.mp3

So you can replace it with:

a meme sound
a warning beep
a voice saying "wrong command"
whatever you want

Why I actually like this

It sounds silly, but it’s surprisingly useful.

The sound acts like a tiny feedback loop.

Instead of silently ignoring mistakes, the terminal gives a quick reaction.

It helps me stay a bit more focused when I’m typing commands fast.

Also… it's just fun.

The project

If you're curious about the code or want to try it:

https://github.com/hamza-topo/fahhctl

It's a very small project, but it was fun to build.

And sometimes the smallest tools are the most satisfying ones.

React js & Github actions

Hamza — Thu, 05 Sep 2024 08:57:44 +0000

Introduction

Hey there, fellow developers! 🎉 Let's get your React app out into the world! 🚀 Today, we're going to deploy it to GitHub Pages, a super easy way to share your creations with everyone.

Step 1: Create Your GitHub Repository: (skipp this if you alread have done this)

Head over to GitHub and click the "New" button.
Name your repository (let's call it react-awesome-app).
(Optional) Add a description.
Choose "Public" visibility.
Click "Create repository".

Step 2: Set Up Your Local React Project

Open your terminal and run

npx create-react-app react-awesome-app

Navigate to your project:

cd react-awesome-app

Step 3: Connect Your Local Project to GitHub

Initialize Git:

git init.

Add all files:

git add .

Commit changes:

git commit -m 'Initial commit'

Create a main branch:

git branch -M main

Add the remote:

git remote add origin https://github.com/{your-github-username}/react-awesome-app.git

Push to GitHub:

git push -u origin main

Step 4: Build for Deployment

Run npm start to check everything works.
Create a production build: npm run build
Step 5: Configure GitHub Pages

Open package.json.
Add homepage:

"homepage": "https://{your-github-username}.github.io/react-awesome-app"
Step 6: Deploy Your App

Install gh-pages:

npm install gh-pages --save-dev
Add scripts to package.json:
"scripts": { "predeploy": "npm run build", "deploy": "gh-pages -d build" }

Deploy:

npm run deploy
That's it! 🎉 Your app is now live on GitHub Pages. Share the link with the world!

The public link for your application will be :

react-awesome-app to be replaced by your github repo name https://{username}.github.io/{repository-name}/

Laravel : DESIGN PATTERN REPOSITORY

Hamza — Tue, 06 Feb 2024 11:54:06 +0000

🏠 Short Story:

I vividly recall my initial encounter with the term "Design Pattern" – a moment of profound confusion as I grappled with whether it was a mere philosophical concept or a collection of abstract theories. The burning question in my mind was: how could such a concept be practically applied to something as tangible as my to-do list project 😅?

As it turns out, design patterns are not elusive philosophies; instead, they are a set of solutions crafted to address recurring problems encountered during the software design process. These solutions present a structured approach to overcome common challenges, equipping developers with established and efficient methods to handle issues that frequently arise during coding.

One of the most renowned examples of a design pattern is the Singleton pattern. Imagine creating a new instance of a MySQL database connection for every single request – not only is it inefficient, but it's also downright impractical. Enter the Singleton pattern, which ensures that only one instance of an object (such as a database connection) is created, streamlining operations and optimizing resource usage.

Certainly! Today, let's delve into one of the essential design patterns within the context of the Laravel framework: the Repository Design Pattern.

Repository Design Pattern:

The Repository Design Pattern, a structural pattern, serves to separate the logic responsible for retrieving data from the underlying storage (such as a database) from the rest of the application. In Laravel, this pattern is frequently employed to interact with database models.

In simpler terms, we introduce an intermediary layer between my UserController and UserModel, which I'll refer to as UserRepository. Familiar with CRUD methods, right? Well, let's consolidate them within UserRepository.

In my projects, I typically initiate the development process by establishing a dedicated folder named "Repositories" within the "app" directory. The next step is to create a PHP interface; I can name it RepositoryInterface.php:

namespace App\Repositories;

use Illuminate\Database\Eloquent\Collection;

interface RepositoryInterface {
    /**
     * create method
     * 
     * @author Topo <topo@test.com>
     * @param  mixed $model
     */
    public function create(array $model);
}

This interface serves as a blueprint containing prototypes for essential CRUD (Create, Read, Update, Delete) methods. These methods act as the foundation for implementing the repository design pattern, and for now, we will just use the create method.

Next, let's define our UserRepository class. To do so, let's create this class and implement the RepositoryInterface:

namespace App\Repositories;

use App\Models\User;

class UserRepository implements RepositoryInterface {

    public function create(array $user)
    {
        return User::create($user);
    }
}

Isn't that easy? Can you see how much your code looks well-separated, readable, and easy to maintain?

The question now is, how can I call this repository in my controller? Well, it's not a big deal. This is where we can use Dependency Injection (DI). In the code below:

namespace App\Http\Controllers;

use App\Repositories\UserRepository;

class UserController extends Controller {

//since im using php 8.x im allowed to use this syntax 😅
    public function __construct(protected UserRepository $userRepository)
    {
    }

    public function store(Request $request){
        // Validate your request 
        return $this->userRepository->create($request->all());
    }
}

Conclusion 👋
In conclusion, the Repository Design Pattern proves to be a powerful and indispensable tool for enhancing the readability of your code and adhering to the Single Responsibility Principle. By adopting this pattern, you can achieve a clean and modular architecture, keeping the logic responsible for data retrieval neatly separated from the rest of your application.

The introduction of the intermediary layer, such as the UserRepository, not only streamlines CRUD operations but also contributes to the overall maintainability of your codebase. No longer do you find User::create() directly in your controller 🤢, but rather, the creation logic is encapsulated within the dedicated repository. This separation of concerns not only enhances the clarity of your code but also ensures that each component has a specific and well-defined responsibility.

Embracing the Repository Design Pattern is not just about organizing code; it's a strategic move towards creating robust and scalable applications. It empowers developers with a systematic approach to handling data access, making your codebase more maintainable, readable, and aligned with best practices in software design.