I Didn’t Know How to Do It Yet

I do not always know how to complete a task when someone first gives it to me.

What I do know is how to research it, test different approaches, break a few things, rebuild them and come back with the best work I can produce.

Today, I am in Belgium looking for a software engineering, data or AI role. In the meantime, I experiment with a Proxmox server, local AI models, agentic workflows, machine learning, LLMs and whatever new technology catches my attention.

But that confidence did not exist when I first opened BlueJ.

Montréal, 2019

My journey into software development really started in 2019, when I was accepted into the computer science bachelor’s programme at UQAM in Montréal.

I arrived as an international student, which meant paying the full international tuition fees and completing some additional courses.

I was also 18.

In Québec, most local students complete a college programme before university, so my best friend Axel and I were among the only 18-year-olds in rooms filled with people who were already in their twenties.

It felt as though everyone else had already completed the tutorial for adult life while we had just reached the character creation screen.

We did not know exactly what to expect from university, but we had enrolled together, and we were ready to find out.

The first software I fell in love with

University was also where I discovered Notion.

I had always liked minimalist design, and Notion had exactly the right balance between structure and flexibility for me.

Its block-based system allowed me to organise notes, courses and ideas without forcing me into one specific way of working. As a student who had no idea what university would require from him, that flexibility felt perfect.

I immediately saw its potential.

I even emailed Notion to suggest some form of student training programme or badge. They became the first major technology company to answer one of my emails.

I have had a soft spot for them ever since.

I would still love to work with them one day.

Looking back, my reaction to Notion already revealed something about how I think. I like tools that create order without getting in the way. I like systems that are flexible but not chaotic.

BlueJ was not one of those tools.

Java as a first language is wild

My first real programming course introduced us to Java using BlueJ.

I hated the interface.

I hated the colours, I hated the absence of autocomplete (once i tested it, it was inavoidable), and most of the time I felt completely lost.

Java as a first programming language is wild. You are trying to understand variables, conditions, loops, methods, classes and objects while dealing with a syntax stricter than my mother.

At the same time, I was too afraid to move to Eclipse.

It was not that I thought Eclipse was impossible to use. I was afraid that my environment would no longer match the professor’s. If something looked different on my screen, I worried that I would be unable to follow the course.

When you are completely new to programming, even choosing a different editor can feel like abandoning the map.

I stayed with BlueJ.

It was also the last time I used a professor’s preferred IDE simply because it was the professor’s preferred IDE.

Later, I moved to the JetBrains ecosystem and began choosing tools based on how I worked rather than trying to reproduce someone else’s environment exactly.

That was a small change, but an important one.

Learning how you work is also part of becoming a developer.

Programming without a compiler

Our programming exams were completed on paper.

There was no autocomplete, no compiler, no documentation, no Stack Overflow and definitely no AI assistant.

You had to inspect every semicolon, follow every variable and mentally execute the program line by line.

When I say I earned every point, I mean it.

There was no runtime available to accidentally agree with me.

At the time, I probably saw those exams as an unnecessary challenge. Looking back, they forced me to pay attention to what the code was actually doing rather than relying entirely on a tool to tell me what was wrong.

Seven Linux installations later

One of the courses I appreciate the most today is also one I definitely did not appreciate at the time.

It introduced us to Linux, Bash, the command line, permissions, processes, file systems and the general idea that there was an entire world underneath the graphical interface of a computer.

During that period, I reinstalled Linux seven times.

Not because the course required it.

I simply kept breaking the operating system while trying things I did not fully understand.

Install Linux.

Explore.

Break something.

Reinstall Linux.

Promise to be more careful.

Become curious again.

Break something else.

At the time, each reinstall felt like proof that I did not know what I was doing.

Today, I see it differently.

My curiosity usually arrived before my competence. Fortunately, competence followed.

I still have the same habit. I like experimenting, testing tools and changing configurations. I also hate digital clutter, so I reinstall my computer every year or two to rebuild a clean workspace containing only what I actually use.

Some people treat their operating system like a home they gradually decorate.

I treat mine more like a seasonal construction project.

Finding another way

The second programming language I learned was C.

I remember one exercise in particular because the teacher had previously shown us an alternative way to repeat an operation.

Instead of simply reproducing that solution, I researched the problem and discovered how to write a for loop in C.

When I showed it to the teacher, he was surprised that I had found it myself.

It was probably a small moment from his perspective.

For me, it represented something important.

I had stopped seeing the course material as the full boundary of what I was allowed to know.

There could be another solution. I could search for it. I could understand it and bring it back.

That method would later become the foundation of how I approach almost every technical problem.

The Bash adventure game

We were also given an assignment to create a small adventure game using Bash and ASCII graphics.

I may have misunderstood the expected scope.

I wrote the game logic, the gameplay loop, the enemies and enough lore to suggest that I was preparing the foundation of a franchise.

The visual side of the project was assigned to the other members of the group.

That portion did not come together well enough for us to release the complete game as originally intended.

However, I was still able to show the teacher my functional work, and he gave me a good mark for what I had built.

It was one of my first lessons about the difference between completing your part and delivering a complete product.

A user does not experience each contributor’s work separately. They experience the final result.

You can have excellent logic underneath, but if the interface is broken or the different components do not work together, the product is still incomplete.

That lesson would become much more important once I started working on real projects.

When the original plan ended

Then COVID happened.

Returning to the Caribbean was initially a necessity caused by the pandemic.

The university was not prepared to recreate the learning experience properly through remote courses, and the atmosphere after the transition became terrible.

The version of university life I had started in 2019 no longer existed.

I eventually continued my studies in the Caribbean through a MIAGE programme.

MIAGE is slightly different from a traditional computer science degree because it combines software, information systems, data, management and business subjects.

I will probably write an entire article about it another day.

The main reason I chose it was simpler: it offered an apprenticeship.

I had always wanted to start working as soon as possible.

Not because I disliked learning, but because I wanted to apply what I was learning to real situations. I wanted to leave the classroom, enter a company and solve problems that mattered to someone.

That was one of the main reasons I had chosen computer science in the first place.

From assignments to responsibility

During the final year of my licence, I joined Orange as a data analyst apprentice.

It became one of the best experiences of my life.

I worked with competent, studious and caring people who trusted me with real responsibilities.

My tutor, Gregory, may have been the best tutor I could have asked for.

He taught me about geomarketing, business intelligence and corporate etiquette. More importantly, he taught me that technical work is not only about proving that you can build something.

It is about building something that other people can safely rely on.

One lesson stayed with me:

Make sure your numbers are correct, because more than 80 people depend on them and they are counting on you.

Before Orange, a wrong number might have cost me points on an assignment.

At Orange, a wrong number could affect the work and decisions of dozens of people.

That changed the way I approached my work.

One of the projects that made me think, “This is why I chose computer science,” was the creation of a complete suite of business-intelligence and geographic-analysis tools using Python, pandas and Streamlit.

I was no longer writing code only to satisfy a course requirement.

I was cleaning real data, building dashboards, presenting geographic information and creating tools that colleagues could use to perform their jobs.

The value was no longer hidden inside the code.

It existed in what the code allowed other people to do.

A master’s degree without a cinematic ending

Orange extended my apprenticeship for another two years, which allowed me to continue into a MIAGE master’s degree.

I completed most of this journey before generative AI became permanently attached to the developer workflow.

I did almost all of it without AI.

Crazy, right?

At the time, I already believed AI would become a wonderful tool. I thought it could eventually complete my abilities, but not replace my judgement, curiosity or responsibility.

I still believe that.

AI can produce code, explanations and possible answers.

But it cannot take responsibility for whether 80 people should trust the number.

When I finally completed my master’s degree, I did not feel a dramatic wave of emotion.

I had always been convinced that I would succeed academically.

Graduation was important, but it had never been the real objective.

The objective was getting a job in technology and building a career where I could continue solving meaningful problems.

I thought life was sweet

After graduating, I wanted to leave the Caribbean and work internationally.

I moved to Belgium believing that finding a technology job would be relatively straightforward.

I had a master’s degree.

I had several years of apprenticeship experience.

I had built real tools for a large company.

I genuinely thought life was sweet.

Reality has been more complicated.

Maybe I underestimated the market. Maybe AI changed companies’ expectations of junior candidates faster than I expected. Maybe the long political uncertainty in Brussels made organisations more cautious.

More likely, several things changed at the same time.

I do not have a complete answer yet.

What I do still have is confidence in the way I work.

When someone gives me a task, it is rarely about already knowing the exact solution.

It is about researching the problem, experimenting, iterating and returning with the best work possible.

That is where I know I am strong.

The next classroom

While searching for the right software engineering, data or AI role in Belgium, I have continued learning independently.

I built a homelab around a Proxmox server.

I experiment with virtual machines, infrastructure, local AI models, agentic workflows, machine learning and LLMs.

I have also become a big fan of the Snowflake platform because it sits at an intersection I enjoy: software, data, infrastructure and tools that help people make sense of complex systems.

In many ways, my homelab is simply the modern version of those first Linux installations.

Create an environment.

Explore it.

Break part of it.

Understand why it broke.

Rebuild it properly.

The technologies have changed, but the learning method has remained almost identical.

Not final

In 2019, I was afraid to switch from BlueJ to Eclipse because I thought I might lose the professor’s path.

Today, I run my own servers, experiment with local models and build software, data and AI projects that rarely arrive with a complete set of instructions.

I still get lost.

The difference is that I no longer interpret being lost as evidence that I do not belong.

It usually means I have found the next thing worth learning.

A developer is not someone who already knows every answer.

A developer is someone who can be trusted to find one.

This blog is where I will document the experiments, projects and lessons that come from continuing to become a developer.

Because none of this is final.

If you are interested in software engineering, data, AI, local models, agents, homelabs or tools that are still slightly unfinished, reach out to me on X at @notfinaldev.