DEV Community: Samuel-Zacharie FAURE

The AI development trap that wastes your time

Samuel-Zacharie FAURE — Thu, 30 Oct 2025 11:33:09 +0000

Have this ever happened to you?

You are asking your AI agent to develop something, correct a bug, or whatnot.

It's currently completely lost. You are burning a huge amount of tokens, and wasting your time. Despite refining your prompts more and more, it's just refusing to correctly do what you're asking it to do.

What's happening and how to avoid this annoying cycle?

Take a step back: Why are we using AI in the first place?

Experienced programmers know this: the real gains of AI is not in the speed of development. A good senior can often fix a bug or develop a small feature faster than AI.

The real gain of AI is in the cognitive load reduction.

Writing code is hard, at the very least because your syntax must be perfect. And even for small logic iterations, you need to use your brain. And brain use is a finite resource - You have a fixed amount of thinking in you which refreshes when you take a break or sleep.

The real productivity gains of AI come from cognitive load reduction: because you are using your brain less, you can do much more during your day of work.

But this is a delicate balance. How much thinking should you really be doing?

Too much thinking and you're wasting on productivity gains. Not enough thinking, and you're entering the sunk-cost fallacy loop.

This probably happened to you

You're prompting and prompting again, and usually it works great, but today for some reason, your agent is completely lost.

You realize you would have been done much sooner if you hadn't used AI at all, but you're in too deep by now, surely by the next prompt it will finally do what you're asking for... Okay, the next... Okay, the next for sure...

The thing is, because you didn't invest the initial cognitive load, you are just a little bit too lost. But thinking is hard and you don't want to spend this cognitive load now, especially since this would be equivalent to basically starting all over. After all this time and tokens burnt.

So you keep prompting and hoping for the best, and it only gets worse.

What to do in this situation?

Take a step back and a deep breath. Realize the problem is that you haven't engaged your brain enough on this task.

Ask yourself those questions:

Do I understand exactly the specifications I'm trying to implement, or the bug I'm trying to solve?

If not, then take some time to define the specifications or understand the issue better. You can ask for help from the AI, but no coding authorized!

Do I have an exact plan for implementing my changes?

If not, then take some time to think about your implementation plan. Use the atomic git commit workflow if you need to. Humans should take baby steps when developing, and so should AI.

What is the current abstraction level to which I should be prompting now?

Prompting can be high-level ("Implement this feature") or it can be low-level ("Refactor this method, rename this variable"). High-level prompting is more desirable in terms of productivity gains, but if AI could be consistently efficient at high-level, we'd all be out of a job by now.

Entering the sunk-cost fallacy cycle generally means you've overestimated the level of prompting you can ask from your model for this specific task. Take it down one or two levels. Right now, you need to take your AI by the hand and gently guide it to your solution.

Which other information am I lacking?

Think about any information you need to make your changes which is not absolutely clear for you at the moment. Use AI to explore the codebase if you need to, or to brainstorm solutions; but then again, no coding authorized for now!

Bonus: Work with your agent in TDD

Test-Driven development is a great programming method (Although I know this is controversial opinion) but with the popularization of AI agents, it became (in my opinion) a must-have.

Do you have your tests successfully failing? The bug is well reproduced? The specifications are well defined? If not, start your agent here. Writing tests has never been so quick and easy thanks to AI.

Just keep in mind that this is the most important part of development, and also the hardest. This is the part where your brain needs to be in full alert, everything should be crystal-clear and well defined.

You will also need to be very specific in your prompts about not coding the actual solution but only coding the tests for now. AI Agents have been trained to code solutions, so by default it will try, even when you didn't ask for it.

If nothing works

Close your AI agent. Go back to the whiteboard. Reset both yours and the agent's context.

You will manage just fine! Just stop wasting your time on a sunk-cost fallacy cycle. It is a hard pill to swallow, but nothing you can't do. Stay in the command chair, and it will all work out.

An old proverb says: "Alcohol is a great servant, but a terrible master" - This is also true for AI. Be the master of your AI, not its servant.

Does your Pull Request pass the Hangover test?

Samuel-Zacharie FAURE — Tue, 29 Jul 2025 09:30:55 +0000

This is a short reminder about what Programming is.

Programming has and will always be about reducing complexity first and foremost.

If you ask a coworker to review your pull request, always ask yourself: does it pass the Hangover test?

Can your coworker turn on his computer after having drank too much the previous evening and still be able to understand your code with minimal effort?

It's always easy to write complex code on a good day. Complexity is easy to write; simplicity is not. Just because you had an easy time writing it on that day doesn't mean it's simple enough for someone else to understand it on a bad day.

Because you don't write code for writing it, you write it for it to be read - it will be written once but read 50 times or more.

If you're not writing for Hangover Coworker, you're making your life -and the life of every colleague, present and future- harder.

Remember that Complex code is not a sign of intelligence, it's a sign of sloppiness.

So can someone kill their brain cells with too much alcohol and the next morning still make sense of your code with relative ease?

If not, back to the drawing board 🔁 Make it better until it passes the Hangover test.

The Junior's path to Keyboard Proficiency

Samuel-Zacharie FAURE — Fri, 04 Apr 2025 09:50:07 +0000

Proficiency: A high degree of skill; expertise.

If you're serious about becoming a highly skilled programmer, you will probably want to be extremely proficient with the keyboard.

Your job is to interact with the computer, and you interact with the computer using a keyboard (and if your first reaction is to say "and a mouse," then this article is definitely for you).

I apologize in advance if anyone finds this article elitist. This is not about pretending someone is a better programmer if they touch-type and a worse one if they don't. This is about you being more comfortable, efficient, and having more fun in your job. Pretending you're a better programmer just because you do things like the experts is cargo culting.

We'll start with the basics and move toward more advanced stuff.

Learn how to use the keyboard correctly

You are supposed to use all of your fingers (for most people, 10) on the keyboard. A lot of people only use three or four. Because one can type quite fast even with just two fingers, one does not realize they're using the keyboard wrong. That was certainly my case for way longer than I am willing to admit.

Learning to type as typing was intended will increase your performance in the medium-to-long term, but most importantly, it's just much more comfortable and ergonomic (casual reminder that your body will grow old if you're lucky).

The process of learning correct typing is pretty much the same as learning the piano: practice 10 minutes a day for two months. Use a web app for that. I used TypingClub and recommend it.

And absolutely learn to touch-type. A good pianist doesn't look at his instrument, so why should you?

Say no to Windows

If you aren't working with Microsoft proprietary Windows-related technologies, you should not be on Windows.

I have mentored aspiring webdev students for many years, and in my experience, you can sort the ones who will succeed from the ones who won't by asking them to do two things and seeing if they actually do them:

If you use Windows, ditch it.
If you don't speak English fluently, learn it.

100% of my students who did these two things succeeded. 100% of those who didn't, failed.

Say no to your desktop environment

Learn to use the shell and use it for everything. I mean it: everything.

Moving files around with your mouse might seem more efficient at first, but when you're good at talking to your operating system via the shell, you'll realize desktop environments only limit your power.

Say yes to Vim

To be honest, I am not sure that Vim is right for everyone. Or rather, as a Vim fanatic, I think it is, but I also realize I'm extremely biased. Here's some general advice if you want to go down this rabbit hole anyway.

Realize that Vim is a sport. A very nerdy sport. It has a very steep learning curve. It takes years to be proficient with it. And I am not even sure it's so much more efficient, but anyone will tell you, it's so damn fun.
Start with this mandatory reading.
I say "Vim," but actually use Neovim. Basically the same but better.
Build your custom config. DO NOT copy-paste an existing wall-of-code config. Instead, start small and increment yourself based on your needs. Be sure to save it somewhere, preferably on a remote Git server.
Write your config in Lua, not Vimscript. Learn Lua if you need to—it's easy.
Spend some time configuring your (Neo)Vim so it's pleasant to look at. You will probably look at it all day for years.
Use a good plugin manager. I recommend Lazyvim.
If one of your plugins slows your Vim experience (some language servers notably might do this), get rid of it. Vim is cool because it's super fast and responsive, and there's always a faster alternative.
Advance your Vim learning incrementally. Every time you learn something new, make sure to practice. And sooner than later, get rid of your mouse. Hard at first, but so good long-term.
Be prepared to take heavy psychic damage for the rest of your life every time you have to use a text editor that doesn't integrate Vim motions.

Throw your mouse away

Once you start to be proficient with the shell and Vim, you can say bye-bye to your mouse. You won't need it anymore.

Actually, scratch that. Sadly, you might still need it in your browser (unless you install the amazing Vimium extension) or in other graphical programs. But the rest of the time, the keyboard is your (only) friend, and you'll realize how cozy it feels to never move your hands from it.

The most important part

Have fun! I'm serious.

This is not about you looking like a 10X dev-haxxor (although I won't lie, it's pretty cool to impress people); it's about being comfortable and having fun.

Efficiency is nice, but typing faster or moving your files around more efficiently will not make you better at programming. You can be the most amazing programmer while typing with 3 fingers, while rarely opening a shell, or even while using a mouse... But why would you do this to yourself?

Be comfortable instead. Have fun. Enjoy yourself.

🕸 Networking is easy, fun, and probably not what you think it is.

Samuel-Zacharie FAURE — Mon, 24 Jun 2024 06:54:49 +0000

Networking is extremely important for your career.

They say the most valuable thing about going to Harvard is not the education you'll receive or the skills you'll learn, but the connections you'll make. And they're right.

However, many people will say networking is hard, boring, impossible for some, especially neurodivergent folks. So just for context, I'll clarify that this article is written by an introverted senior software engineer with autism. Turns out, I am a natural networker anyway! And maybe so are you.

When you think of networking, you probably have some kind of tech meet-up in mind. Maybe there is free coffee, pizza, and petit-fours, which you eat while talking to people from your industry who you can add on LinkedIn after.

While this is definitely an example of networking, this is also what people think networking is. In truth, this is only a very niche kind of networking.

Thinking you need to practice this specific ritual to gain the benefits of networking is like thinking you absolutely need to go to speed-dating events to get married. It might work out for you, but that's not what dating or marriage is as a whole, and it's not even how most people find their significant others.

The reality is, networking can be something you intentionally do, but more often than not it's something that just happens, and you benefit from it if you have the right skills and the right attitude.

How I got my dream career

Here are two stories that led to me working at my dream job today.

I Was Bored At A School Party

I never graduated in CS. I graduated in Food science. My first job was making energy drinks.

I met my friend J. during an engineering school party 15-20 years ago. We had similar interests and vibed together. He was studying computer science in that same school and later went on to become one of the top-leading experts in Ruby on Rails.

A decade after said party, as I was complaining about my lack of job prospects and interest for my current career, he asked me, "Have you considered coding?"

I Talked To Some Teenagers Under A Tree

More than two decades ago, I was studying in a somewhat fancy high school, mostly middle-class / high-middle class students.

There was a tree in the courtyard where myself and a group of other teenagers would hang out. Eventually, we talked. We became friends.

One of them went into computer science and made a new group of friends. At some point, two people in this group started a new project for a client. They needed programmers. They hired me as an intern.

This is what networking is.

I went to a bunch of professional meet-ups, coding-related events, and tech talks. No opportunity ever came out from any of those.

I don't regret going because I had no expectations outside of having a little fun and indulging in free pizza. Again, this is like dating, you have very little chance of finding your life partner on a random date so you have to learn to enjoy the process.

Instead, opportunities arise organically from just living life.

Real networking advice

So how does one become "good at networking"?

Be curious

Curiosity is an incredibly powerful human drive for growth.

Be curious about other people. People are fascinating, each individual is a universe of its own. There is so much to discover in a person, and so many persons to discover.

When you take an interest in other people, you're making their abilities, knowledge, and skills yours, and there is tremendous power in alternative views.

So what you're doing is spreading a net, extending far and wide - this is networking.

Geopolitical footnote: You will notice that, historically, the more insular a country is, the more stunted their economic growth is. This speaks volumes to the importance of human connections.

Be open to opportunities

To continue the fishing metaphor, once your net is spread, eventually you catch some fish. Now it's just a matter of picking up the fish.

Sounds easy enough, but some fishes are not easy to pick. Sometimes opportunities carry risk. Each situation is unique so it's hard to generalize here, but it is my opinion people generally have much to gain by being at least a little bit more bold.

Be kind

Humans are fundamentally social creatures. We are designed for cooperation. Well, turns out humans prefer to cooperate with people who are well-suited for cooperation, and a big part of it is treating others with kindness.

If you are a pleasure to interact with, people will want to interact with you. This is true for friendship, companionship, but also work.

Sidenote, I am not advocating that you should be kind for personal gain, since I believe in the value of kindness for its own sake. However, if this convinces an unkind person to start being kind for their personal gain, I will consider that a complete win.

Be generous

I am infinitely grateful to the people that helped me be where I am today.

But what goes around comes around. As people helped me, I helped others. I was turned into a software engineer, I turned others into software engineers.

At least one of them became a cybersecurity expert. He deepens my understanding of the topic on a regular basis. Helping him made me better at my job.

I spend some of my free time volunteering to mentor people who try to make software engineering their career. I mostly do this out of love for human connection & helping people. I have nothing else to gain from this & never gained anything from it, but who knows! I have the feeling some day this net might bring in some fish.

Life is not a zero-sum game. When you help someone you are often helping yourself.

Privilege-checkpoint ✋🛑

I want to highlight something important.

You might have noticed that, even though I did not go to Harvard, I went to a somewhat fancy high school, and then to a somewhat fancy engineering school. Those are the places where my connections eventually led to getting into tech & finding my dream job.

This was only possible because I come from middle-class. Had I come from a more modest background, those opportunities would not have been there for me to seize in the first place.

I point this out because while it is easy to remember the hard work we achieved to get to where we are today, it is also easy to not notice the subtle ways invisible privileges made all of this possible for us. Let's all be mindful of this.

What if I'm an introvert?

A final word for introverts. Introversion is characterized by "being drained by social interactions". I am absolutely such a person, social interactions drain my energy quite fast.

But then, so does physical exercise. Yet, almost anyone can eventually run a marathon with enough training.

Both social interactions and running can be torture when you start. Still, those are fundamental abilities of humans. We are literally designed for it. We can learn it, and with enough training we end up loving it.

Running is good for you, so is interacting with other humans, so go out there and train that muscle. It might always be tiring, but you'll enjoy it eventually.

Conclusion

Networking is not (only, nor mostly) eating pizza at tech events.

It's first and foremost about connecting with others humans.

It's not really something you do for your job, it's something you do because that's what humans do and enjoy doing.

So go out there and connect, and keep an eye out for opportunities to cooperate. Who knows, you might end up cooperating!

💵 Why diversity is important, no, really, actually for real

Samuel-Zacharie FAURE — Tue, 07 May 2024 07:47:39 +0000

Also available on my blog

No one really cares about diversity, and that's a huge mistake.

Behind all the corporate crap that gets published on LinkedIn, we all know a company is an amoral entity whose only goal is to make as much money as possible.

This is why no one actually cares about diversity. Because diversity is seen as a Good Thing® that the company should strive for. But since "doing the right thing" doesn't bring money to the table, well, no one actually cares.

But good news! Sometimes, doing the moral thing also makes you money. Diversity is one of those.

Also, bad news: no one seems to actually realise this. Hence this article. I want to explain why diversity actually is a profitable endeavor, while avoiding any dishonest coping.

While you're reading this, I will kindly ask that you to throw away all ethics, and think purely like a cold, calculating capitalist machine. Let's go:

Skills means money

Let's think in terms of what a company needs. A company needs knowledge and skills to thrive.

In tech, we care about hard skills. A great knowledge of languages and frameworks. I would argue those are the skills that are both the easiest to develop, to learn, and to find on the job market.

We also talk about soft skills such as communication and teamwork. Those are the skills that are the hardest to develop, to learn, and to find on the job market. Seasoned developers will also argue that those are the most importants skills. You can have a React genius in your team, it will only get you so far if you're unable to communicate with them or if they can't work with the team.

I would argue that there are skills that are even harder to measure, to develop, and to acquire. Let's call them softer skills.

The softest of the soft skills

When you think "Tech worker" you will usually think: 30-something middle-class white man with glasses, with a computer science degree. Let's call this archetype the techbro.

Well, there are only so much knowledge and skills that one single group of individuals can have.

When you hire people from different backgrounds, you're hiring people with different experiences, different ways of thinking, different ways of solving problems. You're hiring people with different softer skills.

Let's explore a few scenarios to understand how this can drive profit.

Knowing your clients

When you're building a product, you're building it for someone. You're building it for a client, a user, a human being. And human beings are diverse. They have different needs, different ways of thinking, different ways of using your product.

When you have a diverse team, you have a team that can understand those different needs, those different ways of thinking, those different ways of using your product. You have a team that can build a product that is better suited for a diverse audience.

Us tech wizards have all the power from the internet revolution right at our fingertips. We can build anything and solve almost any issue in the world. Yet, the amazing ideas the tech world came to were "How can I get food delivered efficiently at my doorstep" and "How can I get a taxi to come to me". Yes, those are the most pressing issues for a middle-class techbro. What about the rest of the world?

But whatever, you've already built your food-delivery empire, now you need great engineers to make it work. Your goal is to make the best possible app both for your delivery workers, and for your clients.

Turns out delivery workers are mostly people who don't have a computer science degree. They're not of the same socioeconomic background as your average techbro. In fact, their lives are so drastically different that you probably cannot design something that works for them without having someone of that same background in your team.

You will also want to deliver food to people who are not middle-class techbros. You will want to deliver food to people who are not able to use a computer as easily as you do, use a smartphone as easily as you do, or even are not able to read as well as you do.

Sidenote: sometimes, I really wonder if the executives at UberEats realise that a lot of their clients are quite high on weed when they order food, and if they take this into account while designing their user experience. My guess is they don't.

This is why you need diversity: to build a product that works for everyone, and get all the money from all the people.

Sidenote: Remember when Google launched their Stadia console with an incredibly terrible pricing plan, and everyone was wondering just what they were thinking? To the surprise of absolutely no one, the Stadia crashed and burned completely. A more diverse team could have prevented such a horrible decisions and saved millions.

Solving problems

We talked about the skills a diverse team can bring regarding your clients. What about the skills a diverse team can bring to the company itself?

Bootcamps are not evil

The average techbro usually got a solid computer science degree from a solid university. They have a solid career in tech, and mostly evolved in that world. I would argue they often do not have a lot of experience in rest of the vast real world.

This is why you should heavily consider hiring some bootcamp graduates. They often are very interesting people, with a lot of experience from the real world, from other fields, and from different ways of life.

In terms of hard skills, it is absolutely clear that 5 years of computer science from a reputable university absolutely obliterates 6 months of React bootcamp. You just can't get solid fundamentals in such a short period of time. But in term of softer skills, bootcamp graduates often have a lot to bring to the table.

I interviewed a bunch of applicants, CS graduates and bootcampers. Contrary to popular belief, I would argue it is often less risky to hire a bootcamper. Usually, if they're in the top of their classes, they're a sure bet. I would hire the top 3 graduates in a class of 20 bootcampers in a heartbeat. The CS graduates on the other hand, well, while they usually have solid fundamentals, you can't always be so sure they'll bring much more to the table, especially if your team is already 90% CS graduates.

Experience is found in the weirdest places

One of my articles recently got trendy on HackerNews. Comments were mostly supportive, but a few were quite vitriolic, dismissing my work as the uneducated opinion from someone who graduated with "A fake degree from a fake school".
This is because I studied at 42 coding school in Paris, a fact I do not hide. However, I absolutely disagree with the statement that I graduated with a fake degree from a fake school. And this is because I never even graduated from 42. I dropped out as soon as I got a good job.

I have been wise enough to not engage with the vitriol - and this wisdom comes from my past experiences. Because in another life, long before finding my way in tech, I had already established myself as a microcelebrity content creator in a completely different domain. I got the experience of do and don't. Also, you're still reading, so my guess is that I manage to stay interesting enough, and where do you think I got that skill from?

Amongst other things I did in my life, I got an actual-not-fake engineering degree in food science. I designed energy drinks. I spent a year in the jungle meeting amazonian tribes to study how they made juices from palm trees fruits. I spent three months just walking from France to Portugal. I taught physics and chemistry in high school. I'm not sure how it all relates to a job in tech, but I know the sum of my experiences matters to what I bring to the table.

During my fake studies at my fake school, I met incredible people. A professional poker player, now working in legaltech. A genius that wrote his first C program at the age of 12, because he was bored of Javascript which he learnt at the age of 10. An entrepreneur from marketing school that launched his startup right after. He's now a multi-millionaire. Too bad he also dropped out, he could have been a billionaire.

A company hires people. Experienced, skilled people. Always hiring the same kind of people would be like furnishing your toolshed with only hammers. Hammers are important, they're also not all you need to build a house.

Hiring processes need to account for this

In the AI-driven, process-fueled recruiting world, this sadly all goes through the window. Hiring processes are now mostly automated. Human Resources do not account for the richness of the human experience. Heck, they are still looking for "Engineers with X years of experience in Y", not even accounting for the fact that X years of experience for some people in some situations absolutely doesn't mean the same for some other people in some other situations. Numbers really can only get you so far.

Should I even mention technical interviews, especially the ones including leetcode? A lot has been said about it, so I probably don't need to.

I will however rant about how inhumane the process is for neurodivergent people. It's not even about direct discrimination, albeit this does happen (and it did happen to me). But the whole process of recruiting just doesn't account for neurodivergent profiles. As an autistic person, I already can't wrap my head around the fact that you are expected, and even supposed to lie during job interviews.

This is such a sad state of affairs, because neurodivergence really is a rich source of skills and experiences that can be extremely beneficial to a company. It's literally different ways to see the world, to think, to solve problems.

Conclusion

Diversity is not (only) a moral choice. It is a profitable one. I sincerely hope companies, executives and recruiters starts to realize this and account for it.

In the meantime, if you agree with this article, enjoyed it or found it interesting, please get the word out. The way we think about diversity is wrong, and we need to correct it.

💡What contributing to open-source is, and what it isn't.

Samuel-Zacharie FAURE — Fri, 19 Apr 2024 07:34:36 +0000

I've been a senior developer for quite some time now, yet I've just recently understood some advice I've been given at the very beginning of my career:

Participate in Open Source! It will be great for your career!

Well, as such, this is extremely bad advice.

How to contribute to open-source the WRONG way

I get it. You're a student or a junior developer. It's hard out there and you want to boost your career. You don't know what to do. Or maybe you're just enthusiastic about open-source and want to contribute.

Well, you probably shouldn't.

Let's build a school together!

In French, we have an idiom for contributing: "To bring your stone (brick) to the building".

Imagine if people in your city decided to gather together and build a school for the community. What an inspiring collaborative effort!

So you're arriving on the building site with your brick and enthusiasm in your eyes. And very little knowledge of how building actually works, and even less knowledge on how this particular building is being built.

Well, let's be honest, despite your great intentions you're probably going to be more of a nuisance than anything else here.

Now imagine if, not only you do this, but two thousands other people are coming with you. Not only does this lower the odds of the school ever being built, the end result would probably be a school where no child should ever set foot.

Hacktoberfest and its consequences have been a disaster for the human race

I did Hacktoberfest three times, so I own three of their t-shirts (I'm wearing one right now. Very cozy.)

As you can see on my Github profile (go like and subscribe©) I am a huge open-source contributor. Well, not really. I'm a freelancer and most of my clients open-source their products. That's how I make my living. So that doesn't count, right? (More on that later).

Hacktoberfest is a great, deeply flawed initiative. Trying to make people contribute to open-source is very commendable. It's also something you should absolutely not do. You don't tell people to take their bricks and find a random school to help. You're just going to make everything worse for everyone.

Experienced builders will lose time and patience because of the spam, and young builders will leave bitter, believing open-source is not welcoming and/or not for them.

Hacktoberfest is trying to do good, but it is promoting the very wrong idea that juniors should just go and find a place where to put a brick.

So who should build the school?

The parents whose kids will be at the school, that's who. And the teachers as well. They're the ones who are going to use that school, after all.

Heck, with proper supervision the kids themselves can help too. You can do open source as a beginner, you don't need to be a senior for that.

But you need to be involved in the project and act accordingly, you don't just go and throw bricks around.

Open-source is not about coding

It's hard to get hired as a junior developer. You want to both get more skilled, and show that you're more skilled. Open-source contributions are seen as a potential career-boost, and that's because they are (more on that later). But just because they are, doesn't mean that this is a good reason to contribute.

Why do you build a school? Because you want a school to be built. Because you need a school. Because you believe free, communal schools are important, in a world where education gets more and more expensive.

You build it to enjoy the final product, you don't build it for the sake of building it, or (mostly) to train your building skills. You can enjoy building, that's fine, but that's not the point. Your love for building won't make for a good product in the end.

Comic source: Oglaf

How to contribute to open-source the RIGHT way

The following point is by far the most important part of this article.

If you don't use it, you lose it

The best thing you can do to contribute to open-source is to actually use open-source products.

By being an open-source user, you open yourself to being an open-source contributor. An annoying bug? Report it, so it can get fixed, so both you and other users can enjoy a better product.

There's a feature you wish the product had? Ask for it!

No one is fixing that bug, no one is adding your feature? Well, guess it's time to get your own hands dirty then.

This is how you do open-source. You follow the purpose of open-source, not just your love for building.

And of course, always ask the other contributors before doing anything (usually via opening an issue). Remember that this is a team effort.

Contributing to open-source means taking responsibility

I'm an Arch Linux user btw, and I only recently started maintaining a package on the AUR (a community-managed collection of packages).

I've been needing this package, but no one was maintaining it. Infuriating! I can't use an unmaintained package! If only there was a solution!

Oh, right, almost forgot. I can do that myself.

You know it's good, useful open-source when it feels like a chore. You do the job because, well, you kinda have to. The fact that it's open source just means other people will enjoy your work for free, and in turn you will enjoy their work for free.

Sidenote: Did you know squirrels can't remember where they store acorns for the winter? They solve this via communal efforts. If all squirrels fill the forest with acorn reserves, then they will easily stumble upon acorns when the winter comes.

To hell with contributing, just make your own thing.

When aspiring junior devs ask me what they should build, I always reply: "Well, what do you need?".

Think hard. You probably need a tool that either:

do not exist
or it exists as a paid service
or it is free but is spying on your data
or the most common situation, it already exists but got enshittified.

Well, just go and make it, and open your code while you're at it. Congratulation, you're doing open source, and doing it right!

Or just get paid for it

I've been building stuff for the French government for many years now. One of the reasons why I keep working with this client is that all the code we produce is open-sourced by default.

One of the first projects I built was a public API for querying public data. This open-source project has been used by thousands of private companies, one of them even ended up hiring me.

So yeah, open source can indeed help your career. For me, working in open source was both an ideological and career-savvy move. I helped myself while also helping the common good. Just because you get paid for it doesn't mean you aren't doing open source and doing it right.

So I'm keeping those Hacktoberfest t-shirts.

🧠 How to be a great software engineer without using your brain.

Samuel-Zacharie FAURE — Tue, 09 Apr 2024 08:55:35 +0000

Edit: Now also available on my blog.

I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it. - Bill Gates

This article is intended to teach you how to do your daily job as a software engineer -and do it very well- with the minimal amount of efforts.

While I do believe this will have some interesting information for most readers, it will be an especially great read for people who struggle with ADHD. If you know a programmer or aspiring programmer in this situation, you might help them (and myself) by sharing this article.

Let's start.

I - Using Your Brain Considered Harmful

I dislike using my brain.

The reason is, using your brain is hard. Most people will avoid doing hard things too often. If you can do a great job without efforts, then why should you? You don't get extra points for difficulty.

Job satisfaction increases when you're not suffering. Your energy levels stays high, your productivity as well.

There is a secret to achieving high efficiency with minimal efforts, it's called "being smart about it". Martial artists achieve high efficiency by applying high pressure onto an opponent's sensitive points. That's knowledge well used.

Let's be smart about it then.

II - Problem: Software engineering is complicated.

Well, then we just have to make it simple, this way we won't have to think too much.

Turns out, this task is also the best description of the work of a software engineer: reducing complexity.

Complexity is bad. Very, very bad. It is your job to make everything as simple as possible. As we will discuss later, this is the part where you actually need to be smart and use your brain.

We achieve simplicity via both programming practices, and work methodologies. Some examples:

Programming practices
Elegant, high-quality code. Following best practices. Using the right OOP patterns at the right time, functional programming when it makes sense. Refactoring. Avoiding technical debt and spaghetti code. You get the idea, but this is not what this article is about, we're here for the next section:

Work methodologies
Let's explore some work methods that will help you save on all that precious brainpower.

III - When to think hard, and how to do it.

As you will notice, the methodologies I will detail are not really about not thinking. They are about thinking hard, at the right time.

I do believe there are merits in the saying: "Sleep only when you're very sleepy, eat only when you're very hungry". I would add: "Think hard only when you really need to think hard".

Knowing when to think hard and then actually thinking hard is key to building great software.

Here are two great work methods to achieve great thinking:

Deep work: as explained by Cal Newport in his (amazing) book, it's all about maximizing work efficiency by achieving high focus.

Pomodoros: By cutting your work into small time fractions and combining this with deep work, you can actually achieve your best work.

Feel free to research those topics, because I will not detail them here. We're going to focus less on how to use your brain and more on when to use your brain.

IV - Work methodologies for the dumb and the lazy.

Atomic Git commits

The way you use Git can force you to use your brain more efficiently. I strongly advise you to read the linked article, it explains why quite well.

The gist is: using Atomic Git commits forces you to map in your head the exact suite of commits necessary to achieve your goals, in small steps.

Breaking up a big task into smaller, simpler, easier steps? That's the textbook recipe for reducing complexity!

The difficulty with this method is that you have to pay in mental currency at the very beginning. As they say, "A week of coding can save on 30 minutes of planning". Still, because thinking is hard, we tend not to do it. That is a mistake, because you will have to pay the interests later.

Once you've cut your task into smaller steps, you can turn off your brain. You won't need that bag of meat anymore.

BDD, Not TDD.

So I'm definitely not making friends here (hello ThePrimeagen, hope you like this one as well), since this is a very controversial topic. This will digress somewhat, but I think in an interesting way. Disclaimer, this is only my opinion, yadda-yadda.

I strongly believe that Behavior-Driven Development is an amazing tool to use your brain as little as possible while achieving high-quality code.

I use the term "Behavior-Driven Development" to address a common criticism of Test-Driven Development, which is "You don't know what you want at first, so when doing TDD you have to rewrite your tests once you know what you want".

I believe there is a misunderstanding here between opponents and proponents of TDD, and the misunderstanding might stem from confusion between TDD and BDD.

What supporters of TDD/BDD are hearing is: "I don't know the specifications I'm supposed to fulfill". This sounds ridiculous: If you don't know what you're supposed to achieve, you should definitely go have a brain-using session until you clarified your specifications.

What the opponents of TDD are actually saying is: "I don't know the steps that will lead me to fulfill my specifications".

The difference between those is basically unit testing. Of course you very rarely know what the details of your code will look like before you write it, so if you're unit testing small portions of code -such as your methods- you will end up rewriting a lot of (mostly useless) tests and have a miserable time.

The right smallest unit to test in an OOP context is in my opinion generally the Class. And if you thought long enough about the architecture of your code (for example when you were breaking down your task in smaller steps, see Atomic Git Commits), you will know which classes you want at every step of the way.

Hence, you will never have to rewrite anything.

As I said before, I do believe that you should think long and hard before doing any coding, at least until you know exactly what your specifications are, including some hard thinking about possible edge cases.

This is what BDD is all about: thinking hard about your exact specifications and coding them first. You know what you want, and once it's in the code, you just need to make the specs go brrrr green.

Frankly, once your specs are written down, you can turn off your brain. The rest of the work can barely be called "work".

Conclusion

I hope you found something interesting in this article. Don't hesitate to share if you think this can help someone struggle less with the daily demands of software engineering.

As for discussing pro or against TDD/BDD, the comment section is down there 👇.

12 Signs you might be burning out 🔥🚒

Samuel-Zacharie FAURE — Fri, 24 Nov 2023 15:29:07 +0000

I - You aren't excited about work anymore

If you aren't happy about working, either your job sucks or you're burning out. In both cases you need to act on it.

II - Your social life is dipping

You haven't seen your friends in a while.

III - You're making more mistakes at work

Would you have introduced this bug if you were at the top of your game?

IV - You feel "Lazy" about shipping high-quality code

It's working. It does the job. Who cares if it's not perfect? (the technical debt, that's who).

V - You think the situation will be better when X will be gone

"I just need to finish this project then it will all be better" - you probably need some rest, then it will actually be all better.

VI - You feel like crap in the evenings

Work isn't supposed to make your life worse, it's supposed to make your life better.

VII - You have "very good reasons" to not take any time off

That's also a red flag. If for any reason you can't afford to take some time off, you probably overworked yourself already. And you almost always can actually take some time off, and definitely should.

VIII - Your life hygiene has been deteriorating

Been skipping leg day at the gym recently? Started smoking again? Been drinking a bit more than usual? Have your sleep been worse lately? Are your back pains back? Think deeply about what you're doing to yourself.

IX - You can't immediately tell when you took your last vacations

If it's so far behind you that you don't remember the last time you took them, then it's time for new vacations.

X - You think about work when you're not working

Not just a little bit, and not in an excited, positive way.

XI - You feel bad on Sunday evenings

Good old Sunday evening blues. Anybody with a crappy job, or who's burning out, will know about them.

XII - If you're honest with yourself, you just know it

We Humans are terrifyingly good at lying to ourselves, but deep down we often know the truth and how we should act on it.

If this list rings a bell or several, please take some time to reflect on it.

Ask your significant other(s), your friends and family for their opinions. They aren't driving the car, which means they're in a better position to see the landscape.

Take care of yourself first. What's better for you is also better for your job.

The robot invasion of Dev.to

Samuel-Zacharie FAURE — Fri, 28 Apr 2023 08:55:47 +0000

In a previous article, I've been complaining about the sheer lack of quality on Dev.to, or at the very least about the incredibly low signal-to-noise ratio.

Authors Vs Readers

As I was explaining, the incentives of the platform and readers are at odds with the incentives of (most of) the authors.

The readers on Dev.to want good quality content which can easily be found.

The authors on Dev.to want recognition, personal branding, and sometimes just good old link building (linking to their personal product/pages for SEO).

Sidenote: Not all authors. Some do seem to enjoy writing and sharing knowledge. But looking at what's published, this seems to be an extreme minority.

Now, I personally think it's great that authors get personal benefits for sharing their knowledge online. I love writing, but I also love being read, and if a future recruiter love what I wrote, that's a good motivation booster.

But there are two ways to go for that. You either spend a long time carefully crafting an interesting, insightful article... or you just spam whatever.

Since my last article complaining about the state of affairs (Published on the 6 of July, 2021), we lived through an AI revolution. And now, I would say that the robot invasion have begun, but that's not true. The robots have already invaded, and they won. Dev.to belongs to the Robots.

The ChatGPT problem on Dev.to

Searching for interesting articles on the "relevant" section, a tremendous amount are GPT-generated. Almost all of them via ChatGPT: you can recognize the subtle flavor inherent to ChatGPT's training, such as its tendency to reply in 5 to 10 bullet points.

We do live in an age where you can't be sure that something was AI-generated, or is just poorly-written human content. Thankfully, we have tools such as zeroGPT to detect if something is AI-generated.

I even suspect the process to be automatized. It would be trivial to write a list of 20 prompts somewhere, then write a script to regularly copy-paste directly from ChatGPT to Dev.to. There you go, 20 "interesting" articles for your personal branding.

There are (almost) no AI-assisted articles on the platform

It's all generated. Sometimes it is clear the author took less than a minute modifying a few words and adding titles or even an introduction. But the articles are completely AI-generated.

Very few posts are actually "chat-assisted", meaning GPT was used to write parts of the article, but a human wrote big pieces of the article themselves. Most of them are entirely, completely, copy-pasted from ChatGPT.

I checked more than 100 AI-generated articles, only 1 or 2 were detected as "AI-assisted". I'm not a fan of AI-assisting for writing, but this isn't the problem here. The problem is AI-generation and extreme laziness leading to terrible content.

Obviously, this is very bad.

Our AI technology is impressive. Revolutionary, even. But we still haven't breached the AGI milestone where an AI can actually produce new, interesting, insightful content.

So this is only amplifying the biggest issue on Dev.to: the lack of good, interesting content, and the drowning of such content in a sea of mediocrity.

What are Dev.to guidelines on this?

This is my personal interpretation of Dev.to's Guidelines for AI-assisted content..

I mention this is a personal interpretation of the guidelines, because I personally find them unclear and a tad confusing.

It seems that Dev.to authorizes AI-generated content, under the conditions that the post discloses that the content was AI-generated.

On the 100+ posts I detected were AI-generated (not AI-assisted, but 100% generated), absolutely none disclosed that information.

The guidelines also mention that AI-assisted and AI-generated articles should not:

Be published with the main purpose of building a personal brand, building a social media presence, or gaining clout.

While this rule is great in spirit, it is absolutely unenforceable and therefore useless. Without the ability to read minds, you cannot know the main intentions of an author.

What can be done?

Here are some acting suggestions:

Hardening & clarifying the guidelines: My personal opinion is that AI-generated content, and maybe even AI-enhanced content, have absolutely no place on Dev.to or any publishing website that strives for a modicum of quality. Any breaking of this rule should be cause for a ban.
Hiring extra moderators to enforce those rules. As much as I love to report guidelines-breaking articles in an effort to increase Dev.to's overall quality, it feels not only like removing a drop of water from the ocean, but instead passing that drop of water to another person who might or might not decide it belongs in the ocean.

I did not find any way to become a moderator myself, just a "trusted user", which doesn't seem to confer extra moderation power.

The lowest hanging fruit: Implementing auto-detection for GPT-generated text on each new publication. The technology exists and is already reliable and robust.

Conclusion

I love writing on Dev.to. I love publishing on a platform full of enthusiast developers. I love the sense of community, and I love the efforts from the team to curate content. My last two articles made it to 'Top 7 weekly', and I'm infinitely grateful to the team for choosing me.

But I don't love reading on Dev.to. It's just so hard to find insightful, interesting content in the sea of robots all yelling for your attention.

I do hope it gets better in the future, but it won't happen by itself. We need to do something about the robots.

📈 Productivity and Well-being: A summary of what works.

Samuel-Zacharie FAURE — Wed, 19 Apr 2023 13:31:39 +0000

I've been working for a very long time in remote-only positions by now, while mentoring remote-working students.

This article will summarize what I found worked for me and most of my students. Most of this should work for you too, and it will work particularly well in a remote work setting.

Introduction

Some people think more productivity means less well-being. Those people are wrong. They might be victims of management structures that do not understand the fundamental truth of intellectual work:

Your productivity is a direct byproduct of your well-being;

Your well-being tend to increase when you're productive (up to a point).

By taking care of yourself, you are fulfilling your duties both to yourself and to your employer.

Step One: Setting your priorities straight

Do a quick categorization of what are the most important things in your life right now. Here's mine:

1/ Health
2/ Family and closest friends
3/ Work

If your health and close relationships aren't on top, please ask yourself why that is, and what the consequences of such a choice could mean for your future.

Now that we agreed about your priorities, we can start the process.

Step Two: Life hygiene

"Life hygiene" is a french idiom that (very) imperfectly translates to "Lifestyle".

We're stating the obvious in that one, but the obvious often bears repeating.

Physical exercise

This is NOT optional.

Not only does your health need it, it will increase your mood and your focus.

Sleep

This is literally how your brain learns things. If you don't have a good sleep schedule, absolutely prioritize working on that issue.

Posture

Back pains suck. They really do. And let's be clear: if you want a career in programming, you WILL have back pain issues if you don't work on it. If you don't already know the 101 of correct posture, google it right after reading this article (or better, ask ChatGPT).

So you should maintain a correct posture while sitting, right? Well, yes, but it won't be enough for most people. You will probably still end up with bad back pains.

A standing desk can be life-changing. It will also not be enough; you will want a solution where you can alternate between sitting and standing, for two reasons:

Standing all day can be very hard when you first start.
Standing all day can bring about as many issues as sitting all day.

Before anything, take regular breaks and move around. Alternate postures as much as possible. The best posture is your next posture.

Finally, if all of this is not enough (and I suspect for many of you it won't be), learn Yoga. A daily deep yogi muscle relaxation is the most powerful tool there is against back pain.

Bonus: Yoga Crash Course

Lay down on the floor on your back. Inhale 5 to 7 seconds in, hold for 2, exhale for 9 seconds. Try to relax your body as much as possible. Do this 10 mins everyday. Congratulations, you're doing Yoga.

Food

Please don't underestimate how much what you're eating can make you feel like shit.

Before devoting my life to code, I used to work as a food scientist. I can sum up years of research about what you should probably be eating, in the form of a haiku:

Bit of everything,
But mostly vegetables.
Yes. Vegetables.

Taking care of your Circadian rhythm

Most people with sleep issues just have a fucked-up circadian rhythm, or "internal clock". Do take care of that.

The single most important advice I have on this topic is to get outside, first thing in the morning, for about 10 minutes. The morning light entering your eyes will tune your internal clock to the "morning" setting.

For more tips on this topic, and as a general amazing resource for science-based tools for your well-being, I recommend the entirety of The Huberman Podcast.

Step Three: Focusing

Noise-cancelling headphones

They will be of tremendous help to you if you can't focus with sounds around you (or without music). If you work in an open space, that might even be mandatory.

Choose a model that you can wear for long hours without any pain (you're not working hard to avoid back pains just to end up with head pains). Sony's WH-1000 XM4 are a solid choice if you can afford them.

Be by yourself. Or don't.

Some people work better alone in a room. Some people work better when other people are present. If you can afford a choice here, try and see what works for you.

The Pomodoro technique

Many guides exist on that topic, so I won't go into details. The gist of it is to work in cycles of 50 minutes + 10 minute breaks.

During those 50 minutes of work, you should practice Deep work. Absolutely no distraction, work on your focus.

During those 10 minute breaks, I highly recommend that you stretch.

I am not kidding when I say that the Pomodoro technique is the most important productivity tool for remote work.

Although the pomodoro technique works extremely very well for some people, many of them end up not using it anyway. Knowing something works and not doing it anyway is a classic problem. Don't be like this: if something works for you, persevere.

Sidenote: the opposite is also true. If something doesn't work for you, absolutely do not persevere as it, but change something.

Stimulants

Coffee works great if you use it with moderation, as long as it's not disrupting your sleep.

A Big Screen Or two

Many companies researched how to boost productivity for their employees. Apparently, the only two things that they found worked were: Coffee, and bigger screens.

If you're working on a small laptop screen, consider investing in at least one bigger screen.

Step Four: Making Space

Cleaning your environment

<< A clean space is a clean mind >>. When your head is a mess, your environment is a mess. When your environment is a mess, your head is a mess.

This applies both to real life and to your virtual environment: files everywhere on your computer are increasing your mental load as well. Clean your spaces, including your desktop, including the one inside your computer.

Cleaning your head

If you're not managing your stress, you're not managing your head.

A regular meditation practice will not only help you focus better by directly training your focus skills, but will also clear your head of the unnecessary clutter.

Cleaning your code

Having technical debt is really bad for your productivity, but also for your well-being. Here's an article explaining why.. So work on your technical debt. Keep it as small as possible

A great method to clean your space - virtual, mental, and code - is the Marie Kondo philosophy. Throw things away. For more informations on this, read the Marie Kondo guide for the Clean Developer.

Step Five: Work methodologies

Being able to focus is great, but if you don't have a good workflow, it will be useless.

TDD

Test-driven development is a cult. And I'm in it. We keep preaching this methodology for a good reason: it works.

It's actually extremely hard to practice TDD well; just like the game of Go, you can know the rules yet still suck at it. It takes years and years of practice to actually do well.

When you suck at TDD, it still saves you time on the middle and long-term. When you're good at TDD, it also saves you time on the short term.

Atomic Git Commits

Please refer to my article on the topic.

AI is your friend

Artificial Intelligence will probably not replace us in the near future, but using AI will definitely boost your productivity by an order of magnitude. I'm not sponsored by Github but I'll say it anyway: 10 dollars a month for Copilot is more than worth it.

And don't be afraid to ask ChatGPT immediately when you don't know something. AI is the new Google.

And while this article was not written by ChatGPT, most of my automated tests at work mostly are. Just copy-paste your class, ask for some tests, and 80% of the work is done.

Step Six: Don't Overdo It

The problem with an increased productivity is that you'll be able to work a lot.

The problem with working a lot is that you might end up working too much.

The problem with working too much is that you'll end up harming your well-being, hence your productivity.

A note about deep work: deep work is much, much more intense than non-deep work. You probably cannot produce 8 hours of your best code every day without burning out real fast.

Manage yourself, respect yourself, this is a marathon not a sprint.

Conclusion

If you implement everything we discussed here, not only will you be a more productive person, you'll also be significantly happier. I promise you as much.

Also, if I forgot anything that works for you, please tell me in the comments!

Happy life, happy coding.

How atomic Git commits dramatically increased my productivity - and will increase yours too

Samuel-Zacharie FAURE — Tue, 07 Mar 2023 06:02:22 +0000

Atomic: of or forming a single irreducible unit or component in a larger system.

Also available on my blog.

Knowing VS Actually Knowing

I remember when my first mentor told me about Test-Driven Development. A great methodological approach to software engineering. It took me just a few minutes to understand what it was and how it worked.

Then I spent the next six months actively not practicing it. TDD is hard when you start, so you just... don't.

Half a year later, I was hitting my head against a wall trying to build a new feature. I forced myself for the first time to actually do TDD by the book. The wall that was blocking my progress disappeared instantly.

In a previous article, I explained how many managers and tech leads often know exactly how to make our industry better... yet don't. There is always a good reason to not do things right. And somehow we still end up surprised when we're doing things wrong.

This long introduction is here to illustrate a point: you can know what you should do, but you might not know how important it is to actually do it. So many people out there, just like I did before, know how TDD is great... yet still don't use it.

The simplest concepts can often completely change the way you work... if you would only apply them. Introducing: the atomic git commits.

What's an atomic git commit?

Working with atomic git commits means your commits are of the smallest possible size. Each commit does one, and only one simple thing, that can be summed up in a simple sentence.

The amount of code change doesn't matter. It can be a letter or it can be a hundred thousand lines, but you should be able to describe the change with one simple short sentence.

Ideally, you also want your test suite to be in the green when you commit. Your changes might be "atomic", i.e the smallest possible, but they should also be "complete", which means your test suite always follow through.

As small as possible, but complete: this is an atomic git commit.

Why should you write atomic git commits?

There are a few great advantages to practicing atomic git commits, and we'll briefly detail them. But the last one really is the most important. It might completely change the way you approach your work, increase your productivity by an order of magnitude, and make your job much more enjoyable.

Reason number 1: An atomic change is a reversible change

We all know this simple truth about software: the requirements are always changing. By writing atomic git commits, we allow ourselves to revert any changes by a simple commit revert. This already increases your productivity tremendously.

Reason number 2: A clean git history

When shit hit the fan, a clean git history means the difference between pain and salvation. It's like insuring your house: seems useless, until there's a fire.

Reason number 3: Pull requests are much easier to review

Your team will absolutely love you for this.

Reason number 4: A much, much better workflow

This is by far the most important reason to practice atomic git commits: it completely alters the way you approach problem-solving.

If you're like me, you might have a tendency while developing a feature, to just... do it. Entirely.

Then you realize how you did not think everything through.

You need to change more that you expected. Some edge cases aren't taken into account. You broke some unrelated tests, they need fixing. Soon, you end up in a maze of your own making. You're lost. Your head hurts. You can't make any progress without being entirely focused.

Now, this is the wrong way to do things. And worse, you already know the right way, because it's so obvious.

The well-known method to complete a big, complex task: cut it down into smaller, manageable, tiny steps. Each step -its own simple problem to solve. This is obvious advice that you probably already heard many times... But are you actually practicing it in your daily job?

Well, here's a great way to actually practice it: write atomic git commits.

By forcefully working in atomic commits, you're approaching the work the right way, by simplifying it into smaller steps. After all, simplifying complexity is the very core of our job. So why aren't we always consciously doing it?

Of course this advice might sound obvious. But if my past experience proves anything, it's that the obvious really bears repeating, and even more importantly, it bears practicing.

Make your work simpler, better, more manageable, and most importantly: make it easier. Take small steps. Write small commits. Atomic commits. You will love them.

Why aren't you on Neovim yet?

Samuel-Zacharie FAURE — Wed, 11 May 2022 08:47:02 +0000

Just discovered Neovim today. I can't believe how much I've been missing out!

Exactly like VIM, but faster
Better performances
Works out-of-the-box with my extensive VIM configuration
Installation and configuration was a breeze, don't need to change anything
Did I mention that it was faster?

And obviously it's free and open-source.

Here's a quick installation guide if you want to get started: just copy-paste this in ~/.config/nvim/init.vim

set runtimepath^=~/.vim runtimepath+=~/.vim/after
let &packpath = &runtimepath
source ~/.vimrc

This will make Neovim pick up your current VIM config. So if you end up not liking Neovim for some reason, your VIM config is still intact. You can even have both installed at the same time.

So, why aren't you on Neovim yet?