DEV Community: Loïc Boset

Why Asking the Right Questions Can Change How You Build Software

Loïc Boset — Wed, 14 Jan 2026 10:57:49 +0000

I often wonder how people who think critically come up with the questions they ask.

Sometimes, when I read good books, I’m struck by how powerful the author’s questions are. It keeps reinforcing a belief I have: good questions are the backbone of innovation and critical thinking.

If you ask yourself the right questions, you probably get closer to the right answers.

We know that AI is becoming more capable every day. And as a dev, I got scared of that, at first.

I am pretty much convinced that in the near future, we won’t spend most of our time writing code. We will be prompting and AI will execute.

So what’s left for the junior/mid/senior dev?

To me, the answer is clear: thinking.

And it's a good thing! That means less dummy work and more clever work. That means more impact. That means software engineering being available to more companies. More solutions created to our problems.

AI is incredibly good at execution. But someone still needs to decide what to build and how to build it. That future role for us looks much more like an architect than a pure executor. Someone who understands systems, trade-offs, users, constraints, and priorities. Someone who can zoom out.

Being a developer in this world doesn’t mean knowing everything. It means knowing a lot about many things, having one or two areas of real depth, and being able to connect dots. It means creating the strategy and choosing the tactics, not just blindly executing a plan.

A lot of fear around AI is driven by the job market and by media narratives. Developers worry about being replaced, about becoming irrelevant, about not keeping up. Juniors and seniors probably feel this differently. Juniors may fear that they don’t yet have enough to offer. Seniors may fear being outpaced by younger, more AI-native developers who move faster and experiment more.

But what if we flip the perspective and think like someone hiring a developer?

As an hiring manager I care about productivity. I care whether someone knows how to use AI. But raw output alone isn’t enough. Vibe coding might look fast, but speed without judgment is risky.

What I really want to see is whether someone can think.

Can they learn from mistakes? Can they plan instead of jumping on the first solution? Can they compare tools and approaches? Can they ask the right questions to the right people? That’s what critical thinking looks like in practice.

Being extremely good at one language mostly proves you’re good at execution. But can you think about architecture as a whole? About stakeholders? About users? About what actually makes an experience good? Those are the questions that create leverage.

Personally, I’m not afraid of AI anymore. It’s helped me elevate my craft. With a few years of experience, I can now operate more like an architect than a pure implementer. I can support my team by asking better questions, by challenging decisions, and by slowing things down when clarity is missing.

I’ve also become more aware of how my own thinking works. I notice patterns. I notice when someone asks a particularly good question—in a meeting or in a book—and I try to understand where that question came from. I pay attention to how I reason, where I rush, and where I cut corners.

That awareness leaks into everyday life too. Recently, I noticed I was wasting too much time on my phone right after waking up. So I changed one small thing: I left my phone in another room. The next morning, I have time to read some pages of my book instead. It feels good. I start the day already proud of myself.

I’m convinced that in the AI era, the developers who stand out won’t just be the fastest coders. They’ll be the ones who think clearly, ask better questions, and make better decisions.

I’m curious what other developers think! How do you practice critical thinking? Do you feel it becoming more important as AI gets better?

Why Reflective Practice Is Your Competitive Advantage in an AI-Driven Workplace

Loïc Boset — Thu, 08 Jan 2026 21:57:09 +0000

You start your day surrounded by tools that make everything faster.

Your inbox is summarized. Your code is suggested before you type it. Your documents write themselves.

You are more productive than ever — and yet, by the end of the day, something feels off. You did a lot, but it’s harder to explain why you made certain decisions, what you actually learned, or whether you’re moving in the right direction.

This is the paradox of modern work: output is exploding, but understanding is eroding.

And in an AI-driven workplace, that gap is where careers are now decided.

The Real Problem Isn’t AI

AI is not replacing thinking outright. It’s doing something subtler — and more dangerous.

It removes friction. The friction you experience when hitting a thinking wall.

The same way GPS removed the need to navigate*,* generative AI removes the need to struggle through uncertainty. Answers are instant. Decisions feel easier. Progress feels faster.

But friction was never the enemy. Friction is where learning happens.

When you consistently bypass that moment of effort — when you delegate not just execution but also judgment — you may move faster today but at the cost of growing slower tomorrow, as you are not learning anymore.

The Invisible Gap That Separates High Performers

There is a growing gap in our modern workplaces. The gap between doing and understanding.

Many people are busy. Few can clearly answer:

Why did I choose this approach?
What patterns are emerging in my work?
What am I actually getting better at?

Activity creates output, while understanding creates growth.

As philosopher John Dewey said:

“We do not learn from experience. We learn from reflecting on experience”

What is the difference between 5 years of experience and 5 times one year of experience?

Reflection.

Without reflection, experience doesn’t compound. You do not progress.

What Reflective Practice Actually Is

Reflective practice is the deliberate habit of examining your decisions, actions, and outcomes in order to improve future performance. **

It answers questions like:

What worked — and why?
What didn’t — and what assumption failed?
What should change next time?

This practice has been studied for decades in education, psychology, and business because it directly improves judgment, decision quality, and long-term performance.

In a world where execution is increasingly automated, judgment becomes the differentiator. Critical thinking is the skill you need to gain a competitive advantage.

AI as an Amplifier

AI introduces a fork in the road. On one path, the low performers use AI to:

Skip thinking
Accept first answers
Copy without understanding

This is cognitive offloading taken too far — turning knowledge workers into passive consumers of suggestions.

On the other path, the best performers use AI to:

Challenge their reasoning
Surface blind spots
Analyze patterns in their decisions
Track how their thinking evolves over time

The same tool. Two very different usages with two different outcomes in the long run.

Research already suggests that heavy, uncritical AI usage correlates with weaker critical thinking. At the same time, studies also show that balanced, intentional use of AI can enhance learning and performance.

The difference is not access to AI. It’s whether reflection is added into the loop.

Why This Matters for Your Career

As AI makes knowledge cheap and execution fast, employers care less about what you can produce and more about:

How you reason
How you learn
How you adapt
How you explain your decisions

Those who develop reflective practice will compound their advantage. Those who don’t may feel efficient — until they’re easily replaced.

Reflection Is Trainable — and Measurable

The good news is that reflection is not a personality trait. It’s a skill, and it can be trained.

A Harvard Business study paper demonstrated that even 15 minutes a day of structured reflection for only 10 days can already significantly improve your work performance.

The challenge has never been whether reflection works, but how to do it consistently, do it well and see progress over time.

This is where tools matter. Not tools that think for you, but tools that help you think better.

The Opportunity

AI doesn’t have to weaken your thinking. It can sharpen it, if reflection is part of your workflow.

In an AI-driven workplace, your edge is not speed not is it volume.

It’s your ability to pause, reflect, and turn experience into insight.

That is the skill that compounds. That is the skill AI cannot replace.

And that is why reflective practice is no longer optional. It’s essential. And it will be your differentiator in the next few years if you pick it up now.

I have created a tool called Jots with a friend of mine, to help us, devs, stay on top of our critical thinking skills.

It's free to use so give it a shot now and share your feedback with us!

The power of working with a friend on a side-project, and receiving love from the community!

Loïc Boset — Thu, 05 Jun 2025 06:31:04 +0000

Julien Avezou

Jun 4 '25

We launched on Product Hunt this week - was it worth it?

#showdev #webdev #opensource #devjournal

Comments 3

4 min read

I built a side project with a friend — and it’s way better than working alone.

Loïc Boset — Mon, 02 Jun 2025 07:00:00 +0000

Tomorrow, my friend and I are launching the side-project we’ve been working on for the past 3 months: Jots—a simple, developer-focused journaling tool with just a touch of AI.

Since I have been a dev, for the past 4+ years, I’ve always had side projects. My biggest one was Just Remind, which I created to stop forgetting the books I read.

The reason I build side projects is because I enjoy building stuff for fun. Mostly stuff that help me in my day-to-day. Stuff that solve my own problems, and hopefully help other people too. Being a dev is kinda like a superpower, to be able to take a problem and build yourself the solution. I love it!

But this was the first time I was working on a hobby project with someone else. Not building alone is a game changer. It cuts the burden of everything you have to do in half!

With this article, I want to share how our project started, to hopefully inspire some people to reach out to a friend and start building something together.

We built something to solve our own problem.

A key rule of project building (aka entrepreneurship) is to build a product that solves your own problem. Since creating something from scratch is immensely hard and requires a huge load of discipline and motivation, you’d better be off solving something you actually need for yourself.

So, Jots was born out of a shared frustration that we discovered while just talking with each other: as developers, we constantly code, debug, and maintain stuff, but we rarely pause to reflect, learn and grow. That was the basis of our problem. When we looked for solutions (every problem has at least two solutions), we discovered journaling.

Journaling is the intentional act of writing down your thoughts to reflect on them, leading to both personal and professional growth.

This solution looked like a great candidate for solving our problem, so we looked for existing journaling tools, but they all felt generic or bloated. We wanted something that felt like it was made for us—developers who want to improve their technical skills, track their progress, and drive their career growth.

So we said to each other “hey, why don’t we build our own?”. And things got started.

So you have a problem and a potential solution. Now what?

Now is the moment when you should validate your idea. Is the problem real or only in your head? Is your solution really solving this problem? Is there any better solution?

You’ll see a lot of advice online on this part, saying that you need to survey people, building a landing page, etc. But it’s difficult and not bullet-proof.

Another way is check if you have competition. Is there any other product out there, seemingly solving the same problem? If yes, that’s your confirmation. Unless you intend on investing your life savings into the project, this confirmation is enough for now.

So that’s what we did. Although we did not see any journaling tool dedicated specifically for devs, we saw many successful journaling tools for personal use. For us, that means that the need is real, people want to journal, and that it has benefits—it helps people improve.

Free and Open Source First

You’re working on a product, nobody knows you, why should they trust you?

That’s what we thought at first and that’s why we’re launching Jots free and open-source. We use open-source tools everyday. This is our way of giving back to the community. It felt like a good approach.

Our philosophy is simple: build something real, solve your own problem well, and only then consider monetization if it makes sense. Jots is built for the community, and we want to keep it that way. We are launching tomorrow the beta version for early-bird users, the kind that are not afraid to try new tools. And we have a Discord so they can participate in the product creation, by sharing ideas and feedback.

We also tried our best to build this as cheaply as possible to minimize our financial risk. And we’re lucking nowadays that there is plenty of free tools out there that enable any dev to build anything for pretty much free. So if you are part of a open-source community or if you ever contributed to open-source, we want to say thank you. We love you.

Enjoy the process, there is so much to learn

When building on the side, you have the freedom to work the way you want. To try things maybe you couldn’t try in a professional environment. To practice decision-making, that again maybe you wouldn’t at work. To be exposed to new problems, to new solutions, and to new learnings.

It is so rewarding. But it is also so demanding.

If you have a full-time job, building a side-project means sacrificing ~~some~~ a lot of your free hours. If you have normally a busy schedule, it means getting up earlier to work on it, or going to bed later. And working during your lunch break. And working during the weekend (today is a sunny Sunday, and I’ve spent already 4 hours on this side project, inside, while everybody is relaxing outside).

But in the end, you can feel proud to have a bit of yourself out there in the wild. Hopefully positively impacting people’s lives, even at a tiny scale (there’s nothing more joyful than receiving a thank you message by someone using your product).

Besides all the technical things you learn, you will also learn about the specific domain you are working on. For example with Jots, we learned so much about journaling, how it can help anyone get better.

Just Do It.

Reach out to a friend, to a co-worker or maybe a stranger on Reddit (but stay safe).

By the way, if you have a story of you building a product with other people, I’d love to hear it! Drop it in the comments below or to send me a message via Linkedin.

If you want to give journaling a shot, take some pen and paper, or fire up Notion, or try Jots if you want some augmented experience.

And if you want to give some love to Jots on Product Hunt, here’s the way → https://www.producthunt.com/products/jots?launch=jots

Thank you for reading, and happy coding!

Why You’re Stuck as a Developer (And How to Fix It in 5 Minutes a Day)

Loïc Boset — Tue, 18 Mar 2025 09:13:09 +0000

Ever spent hours debugging only to realize the answer was obvious in hindsight? Or struggled to remember what you actually learned last week?

You’re not alone. Most developers focus on writing code but neglect something just as important: thinking about how they write code.

Learning, Then Forgetting

You read a great article, solve a tricky bug, or learn a new framework—but a week later, it's all a blur. Without a system to capture and reflect on what you learn, progress is slow.

The best developers don’t just code. They reflect, analyse, and track their growth.

Journaling as a Solution

Spending just 5 minutes a day writing about:

What you learned today
What problems you faced and how you solved them
Ideas, experiments, and lessons from debugging

Those simple things can sharpen your thinking, improve your problem-solving skills, and will help you track your progress like nothing else.

Why Journaling Works

Debug Your Brain

Writing forces clarity. If you can’t explain an idea in your own words, you probably don’t fully understand it.

Never Lose Hard-Earned Knowledge

Every solved bug, every clever refactor, every “aha!” moment—logged and ready for future you.

Identify Patterns in Your Growth

Looking back on past entries can reveal recurring struggles and areas for improvement.

My Experience & The Tool I Built

I started journaling two months ago, and it has already helped me break down problems faster and retain knowledge better. Since existing tools didn’t quite fit what I needed, I built DevLog—a free and open-source journaling app designed specifically for developers.

It’s simple, distraction-free, and focused on helping devs think, reflect, and grow. Feel free to check it out!

Just Try

Try journaling for a week and you might be surprised how much it levels up your dev skills.

There are so many benefits, and no secret recipe. You just need to give it a go.

If you do pick it up, let me know how it worked for you! If you already journal, please share with others how it helped you grow as a developer or as a human 🙏

DevLog: A Journaling App for Developers

Loïc Boset — Sun, 16 Mar 2025 19:01:48 +0000

My friend and I decided a month ago to build a journaling app specifically designed to help developers establish a healthy journaling habit that can make them a little better every day.

How the Idea Came

During a discussion, we decided that we wanted to build a product together. First, because it’s fun to create something from scratch, and second, because it allows us to solve new problems and explore new technologies.

We both agreed that we wanted to work on something AI-related to better understand its capabilities. But we also wanted to build something that solved a real problem and brought value to developers like us.

As software engineers eager to progress in our careers, we often questioned the best ways to achieve success. That’s when journaling came into the discussion. We had both experimented with it on a personal level, as it’s widely recommended in self-development books. But what about work-related journaling? Could it help developers advance in their careers?

It turns out that career journaling is a well-known practice that brings numerous benefits: clearer goals, better problem-solving, and greater focus. However, when we looked around, we saw that developers were using scattered methods—text files, Notion, Obsidian, markdown, or even pen and paper. There wasn’t a dedicated tool to help devs build a structured journaling habit.

So we decided to build one: DevLog.

The Tech Stack

For the technical foundation, we wanted a mix of familiar and new technologies—something that would let us build fast while learning along the way.

Frontend: Next.js and React – These allow rapid development and are well-supported. Next.js also makes deployment seamless on Vercel, which is crucial since we wanted to keep costs at zero during the MVP phase.
Backend & Database: Supabase – We wanted an alternative to AWS, and Supabase’s free tier and developer-friendly approach made it a great choice.
UI System: Tailwind CSS & Tailwind UI – Speeds up development by providing ready-to-use components, avoiding unnecessary UI work.
Text Editor: Lexical – As the core of the app, we needed a robust, performant, and actively maintained rich-text editor. Lexical, developed by Meta, fit the bill perfectly.
Testing: Jest – A solid test suite is essential for maintaining stability as the app grows.

Community & Open Source

From the beginning, we wanted DevLog to be open-source. We believe in transparency, collaboration, and building in the open. Open source allows us to get feedback, contributions, and new ideas from other developers who see value in this tool.

To foster engagement, we also launched a Discord channel where developers can share their thoughts, suggest features, and help us shape DevLog into something truly valuable.

Getting Feedback

After a month of evenings and weekends work, the small MVP was built with enough functionality for devs to start journaling and seeing immediate benefits.

The next step is validating interest and gathering feedback to refine the product. We’re leveraging Reddit as a first step, since it’s an easy and free way to gauge interest. As we grow, we plan to expand to Product Hunt, LinkedIn, and relevant Slack communities.

What’s Next?

We’re excited about where DevLog is headed. If you’re a developer who wants to start journaling but never found the right tool, we’d love for you to try it out and share your thoughts.

Check out the open-source repo
Join the Discord community
Follow our journey as we build DevLog in public

If you’ve ever tried keeping a dev journal, what worked for you? What didn’t? We would love to hear your thoughts!

How to Make Sure Your Reading Leads to Real Growth

Loïc Boset — Wed, 21 Aug 2024 11:00:57 +0000

In the fast-paced world of software development, continuous learning is not just a choice—it's a necessity. We devour books, articles, and tutorials, all in the quest to sharpen our skills and stay ahead of the curve.

But here's the challenge: how much of what we read actually sticks? How often do we finish a chapter or article, only to forget the key insights by the time we need them?

If you're like most developers, you probably find it frustrating to invest time in reading, only to struggle with retaining and applying that knowledge when you need it.

The truth is, reading alone isn't enough; it's how you process, remember, and utilize that information that leads to real growth.

My Strategy For Retaining And Applying Knowledge

As a developer, I’m constantly reading—books, articles, documentation—all in the pursuit of becoming better. But two years ago, I noticed a problem: I was forgetting most of what I read.

The insights that could help me write cleaner code, solve problems faster, or improve my productivity were slipping away before I had a chance to apply them.

That’s when I started working on Just Remind. It’s a tool designed to help me - and others - retain and revisit the key takeaways from everything I read, should it be books I read on my Kindle, or articles I read here on DEV.

It's very simple. When I read books on my Kindle, I highlight the key parts. When I read articles online, I use the Just Remind google chrome extension to capture the important insights.

All of these highlights are stored in my Just Remind library, and each day, I receive an email with a selection of these highlights to review.

Since using Just Remind, I’ve noticed a significant improvement in how I apply what I learn. It made me more efficient.

Conclusion: Make Your Reading Work for You

If you’ve ever found yourself forgetting valuable information, Just Remind might be the solution you’re looking for.

The ability to retain and apply knowledge is crucial for growth. Just reading isn’t enough; you need a strategy to ensure that valuable insights become part of your skill set.

By using Just Remind to highlight, store, and review key takeaways, I’ve turned my reading into a tool for real growth. It’s transformed how I work and learn, making every piece of information more actionable and impactful.

Are you struggling with the same issue? How do you ensure that the knowledge you gain from your reading truly sticks? Share your thoughts and experiences in the comments!

DRY (Don’t Repeat Yourself)

Loïc Boset — Sun, 23 Apr 2023 07:30:17 +0000

TL;DR

DRY = Don’t Repeat Yourself
make sure you don’t duplicate code or knowledge
if you identify duplicate code, try to abstract it and make it reusable
keep your code modular (tackling one specific task) and decoupled (minimum number of dependencies)

"The code you write today will be somebody's legacy code tomorrow.” - The Pragmatic Programmer

Intro

Software engineering principles are guidelines that help software developers write good code.

Good code is efficient, maintainable, and scalable.

In this series of articles, we will cover some of the most important principles that we need to apply when writing code.

Today, we will be discussing the DRY (don’t repeat yourself) principle. Where does it come from? What does it mean? How can we apply it?

Origin

The DRY principle has been formulated by Andy Hunt and Dave Thomas in their book The Pragmatic Programmer, in 1991.

This book is a classic in the software development field and is a recommended-read for any developer.

Meaning

The DRY principle states that “Every piece of knowledge must have a single unambiguous, authoritative representation within a system”.

Unambiguous means that your code should be clear and not open to multiple interpretations.

Authoritative means that your code serves as the definitive reference for a particular functionality. In other words, you should not have 2 blocks of code doing the same thing.

By following the DRY principle, you ensure that your code is clear and free of duplication.

Application

There are a few rules you can follow to make sure your code is DRY:

1. Identify Code Duplications

When writing code, before creating a new function, a new component or any new piece of logic, make sure there is nothing similar already present in the codebase.

Now, imagine that in your codebase you need to transform milliseconds to minutes multiple times, at different places. You could have something like that:

// Component A
const functionA = () => {
    // some logic here ...

    const intervalInMilliseconds = 60_000;
    const intervalInMinutes = Math.floor(intervalInMilliseconds / 60_000);

    // some logic there ...
}:

// Component B
const functionB = () => {
    // some logic here ...

    const intervalInMilliseconds = 120_000;
    const intervalInMinutes = Math.floor(intervalInMilliseconds / 60_000);

    // some logic there ...
}:

You realise that you have duplicated logic. What can you do?

2. Make Your Code Reusable

If you identify duplicated logic, think about how you can make it generic and reusable in all the places it is needed. Create an abstraction (such as a function) that encapsulates that logic and reuse it wherever needed.

When you do that, you are creating a single authoritative representation of that logic.

Taking back our previous example, here’s what you can do:

// utils/millisecondsToMinutes.js

const millisecondsToMinutes = (ms) => {
  const minutes = Math.floor(ms / 60_000);
  return minutes;
}

export default millisToMinutes;

// utils/index.js
import millisToMinutes from './millisToMinutes';
// other utils functions here ...

export { 
    millisToMinutes,
    // other functions exported here ...
};

// Component A
import millisecondsToMinutes from 'utils'

const functionA = () => {
    // some logic here ...

    const intervalInMilliseconds = 60_000;
    const intervalInMinutes = millisecondsToMinutes(intervalInMilliseconds);

    // some logic there ...
}:

// Component B
import millisecondsToMinutes from 'utils'

const functionB = () => {
    // some logic here ...

    const intervalInMilliseconds = 120_000;
    const intervalInMinutes = millisecondsToMinutes(intervalInMilliseconds);

    // some logic there ...
}:

3. Keep Your Code Modular And Decoupled

Modularity means that your code is reduced to small modules, components, or functionalities, responsible for a specific task, such as you can easily reuse it.

Decoupling means that you have reduced to a minimum the dependencies of your logic, making it easier to modify or replace one module without affecting others.

Here’s an example of a non-modular and tightly coupled piece of code:

// Non-modular code with tight coupling
const calculateNetSalary = (baseSalary) => {
  const taxRate = 0.4; // Hardcoded tax rate
    const deduction = 100; // Hardcoded fixed deduction
  const taxAmount = baseSalary * taxRate;
  const netSalary baseSalary - taxAmount - 100;
    sendSalarySlipByEmail(netSalary);
    return netSalary;
}

In the above example, the function directly uses hardcoded values for tax rate and deduction. This makes the function dependent on these specific values and difficult to modify without changing the function's implementation. If these values need to be changed, the function would need to be updated directly, which can lead to maintenance issues and make the code less flexible.

The function is also not quite modular as it does more than one thing. In addition to calculating the net salary, it sends the payslip by email with the sendSalarySlipByEmail function integrated within it.

Here’s a more modular and less coupled version:

const calculateNetSalary = (baseSalary, taxRate, deduction) => {
  const taxAmount = baseSalary * taxRate;
  const netSalary = baseSalary - taxAmount - deduction;
  return netSalary;
}

const netSalary = calculateNetSalary(5000, 0.4, 100);
sendSalarySlipByEmail(netSalary);

4. Do Code Reviews

If you work with other people on the same codebase, ask someone to review your code, and review other developer’s code. Fresh perspectives can often identify smelly code (such as duplication) that may not be apparent to the original author.

Conclusion

Applying the DRY principle involves identifying and eliminating code duplication, making your code reusable, abstracting common functionalities, and keeping your code modular and decoupled.

Regular refactoring and code reviews can help in maintaining adherence to the DRY principle in day-to-day coding practices.

By following the DRY principle, you will create more efficient, maintainable, and high-quality softwares.

Open-sourcing my project that helps you remember the Kindle books you read

Loïc Boset — Mon, 23 Jan 2023 20:08:47 +0000

I have been working during the past 8 months on a side project called Just Remind. it's a free tool that helps you remember the Kindle books you read by sending you a daily email with your highlights.

Now, I reached a point where I want to share the projects with the community so it grows better!

Being new to this part of the open-source community (I always use them, but that's my first time contributing to it), I welcome any advice!

If you are interested in the tool, give it a try! If you actually enjoy it, feel free to visit the Github repo and start participating. It's coded in React, with Next. Any and all contributions, whether it be in the form of code, bug reports, or feature requests, are very much welcomed!

I have a few years of web development experience, so I am also eager to help junior developers who are interested in contributing to the project!

Feel free to reach out if you have any questions!

Cheers 👋

How I built a web app that emails me 5 random Kindle highlights daily

Loïc Boset — Sun, 12 Jun 2022 22:05:40 +0000

TL;DR

built almost for free with nextjs, vercel, react, google chrome extension, aws cognito, heroku and easycron
creating a product that solve your own problems is the best source of motivation
Reddit is of great help to discuss ideas, problems and solutions

The Problem To Solve

I read a lot. Fictions and non-fictions. All on my Kindle.

As I read, I like to highlight sentences that inspire me and that I want to remember.

The problem is, I always forget them.

I don't want to manually go check my Kindle highlights. I want my highlights to come to me.

The solution: a daily email with 5 random of my highlights.

It's not a particularly innovative solution as other web apps do that already, but I found them either not good enough or too expensive.

So I built my own -- called JustRemind, currently in Beta version.

Infrastructure

Next.js for a modern web framework and for the free hosting on Vercel
postgresql database hosted for free on Heroku
easycron for sending the daily email
AWS Cognito for the authentication system
Google Chrome extension built with React to fetch the highlights

Challenges

Fetching the Kindle data

The first and main challenge was to extract the highlights from my Kindle.

I wanted a quick and user-friendly way to do it. As I tested the already existing services online, I realised that the Google Chrome extension way was the easiest method at the moment, considering that Amazing doesn't have a Kindle API.

The extension is responsible for:

fetching each book and its highlights, and
sending all that data to the JustRemind web app.

The web app also needs to send the user data to the extension so it can link the books data to the correct user.

Overall it's been a pain to setup and I believe the Kindle eco-system would benefit from an API or at least a user-made well-maintained open-source alternative.

Importing lots of data

I have 59 books and +2100 highlights on my kindle. Syncing on JustRemind means sending a lot of data through the API that needs to be processed by the backend and written in the database.

I wrote the backend in Next and I used the free Vercel hosting plan. When processing all that data, I faced some issues as Vercel was timing out.

So mitigate that issue, I:

split the API calls when syncing (ex. if a user needs to import 200 books, 4 api calls will be made with 50 books each), and:
upgrading to Vercel Pro plan to increase the timeout time from 10 seconds to 60 seconds

As part of the job to be done to move from the Beta to the finished product, I am considering rewriting the backend in Python using Flask, hosted on AWS Beanstalk.

Using unknown tools

Although I am familiar with React, Next and Vercel, I was not at all with the entire Google Chrome extension and AWS ecosystems.

Learning to use new tools and techniques is part of the beauty of the web dev job. It can be very frustrating to see your development time drastically increase as you spend time reading docs and searching solutions online. But in the end, it is very rewarding to broaden your knowledge with these new skills.

Result

From the moment I realised I had this issue I wanted to solve to this day where the Beta version is ready, 3 months have passed.

I spent most of my evenings and weekends thinking, tinkering and building this web app and it has been a lot of ups and downs.

Right now, and even if I end up being the only user of my app, I am super happy to have completed it and I am even more happy to read my morning dose of re-inspiration with my highlights being served daily with my morning coffee!

Next Steps

The Beta version is currently open for free to anyone so I can collect user feedback -- feel free to join us!

To promote it, I am going to create a Twitter account to share highlights daily.

I hope this will inspire you to build solutions to your own problems!

Join a new open-source community!

Loïc Boset — Wed, 16 Feb 2022 06:04:05 +0000

Are a junior web dev? Do you want to improve your skills and meet new people while working on meaningful open-source web apps?

That was my wish when I started web development almost two years ago. At that time, I tried to contribute to existing open-source projects but finding beginner friendly issues was often time-consuming and, even then, existing code in repos are sometimes too complicated to understand or to add to. 🤯

I am dedicating a lot of my free time to side projects, and, while working on one of my small hobby projects (Peak, a web app that helps you remember faster!), I thought about how much cool and valuable it would be to work on small open-source web apps with other devs, as a community!

The Tiny App Stack

That's the reason I am creating the Tiny App Stack, a community of like-minded developers, growing and learning together while creating small and meaningful open-source applications! 🥳

Joining the Tiny App Stack, not only will you meet like-minded friendly people, but you will also improve your coding expertise, level-up your collaboration skills, share your struggles and discuss new coding patterns!

If you are a wannabe web developer, participating in open-source projects can also help you land your first job! 🚀

Join the tribe now!

Whatever is your field of interest, should it be web, design, or product development, or wether you are just curious and want to share ideas and feedback, you are welcome!

Join now the mailing list and I will invite you to join the slack when the community officially launches!

Let's have fun together while making the world a better place, one tiny app at a time! 💪

Peak | Memorize like a champion (Part 1 - Ideation & Design)

Loïc Boset — Fri, 12 Nov 2021 06:24:04 +0000

This article is for you to read if you like to create dummy apps for fun or if you are curious about this kind of exercise!

The Memory Champion

Few days ago, I finished reading Peak: Secrets from the New Science of Expertise written by Anders Ericsson a psychologist and professor who studied how expert performers acquired their superior performance.

The book starts with the story of Steve Faloon who was able to drastically increase his memory span from 7 to 79 digits establishing a new world record at that time.

The technique used by Ericsson to train Faloon's memory is quite simple. Ericsson was reading a string of digits and Faloon had to memorize them on the fly and repeat them. Each time Faloon made a mistake, Ericsson would go 2 step backwards to put him back into his confort zone. For example if he was not able to repeat a string of 14 digits, Ericsson would go back to 12 digits strings, which was easier for Faloon to memorize.

Will that work for me?

That story inspired me and I wanted to try this technique on my own. So I took 10 random React interview questions found on the Internet and I tried to memorize them the same way Faloon and Ericsson have trained, by going 2 questions backwards each time I made a mistake.

After only a few minutes, I knew all 10 questions by heart.

I thought it was amazing, effective and fun, so I decided to create a tool to also help others memorize like champs!

Development process

When I want to create a new project, I divide my development process into 5 stages:

1. Ideation & Design

What is the problem I want to solve
Do I experience the problem (if no, then stop here)
Who could be experiencing the problem (target audience)
What solutions already exist?
How can I produce a better solution?
Write down user journey

2. Design

Choose stack, list all required components (login system, alerts, tooltips, ...)
Createa a Figma design of all views for mobile and desktop

3. Assessment

Is the solution solving the problem I have in the correct way? If not, go back to 1.
Publish the Ideation & Design article on Dev.to

4. Development & deployment

Coding and deploy (use only free tiers)
Publish the Coding & Challenges article on Dev.to

5. Launch

Polish landing page
Publish the Conclusion article on Dev.to
Publish pitch on ProductHunt

Open Source Project

This is an open source project. The code will be publicly accessible and the tool will be free to use.
You can check out the app design in Figma here and let me know what you think!

You can also participate if you want! If you are a junior developer or a student, this can be a nice learning opportunity!

Feel free to send me a message or to comment below if you have any question, remarks or advice! :)

Cheers! 👋