DEV Community: Giovanni Mazzuoccolo

I build (not really, Google AI studio did) an app to track babies sleep

Giovanni Mazzuoccolo — Sun, 21 Sep 2025 16:31:10 +0000

This post is my submission for DEV Education Track: Build Apps with Google AI Studio.

Building A Cute, AI-Powered Baby Sleep App with Google's AI Studio

I created "Nap Catcher," a simple app to track my baby's sleep and get AI-powered predictions for their next nap. The goal was to build a tool that makes life easier for new parents, offering smart predictions for a happier baby and a more rested you. Of course I can't promise that it works, every baby is different, but it was fun to ~~build~~ prompt.

What I Built AI built

I used Google's AI Studio to generate a simple, cute mobile app. My key prompts were to "create a cute and simple app to track a baby's sleep patterns" and "predict their next nap time with a touch of AI magic." I also asked for features like logging sleep times and displaying smart predictions.

Demo

You can play with the demo here!

The app features a clean, calming home screen with a large button to start and stop the sleep timer. A sleep log tracks all past naps, and the AI's prediction for the next nap time is displayed prominently. The interface is designed to be intuitive and easy to use, even when you're sleep-deprived.

My Experience

I was surprised that the AI picked React and Tailwind CSS as the libraries and not Angular, especially since AI Studio and Angular are both built by Google. I had explicitly asked the AI to make a "cute" app, because I wanted to avoid the look of a standard dashboard. Fortunately, the result was exactly what I had hoped for: an app with a reassuring and easy-to-use interface that feels perfect for a new parent. This project showed me how powerful and accessible AI development tools have become.

However, I see AI cheating sometimes 👀

useEffect(() => {
    const fetchPrediction = async () => {
      setIsLoading(true);
      const message = await getPredictionMessage(predictedNapTime, avgSleepDuration);
      setPredictionMessage(message);
      setIsLoading(false);
    };
    if (avgWakeDuration > 0) {
      fetchPrediction();
    }
  // eslint-disable-next-line react-hooks/exhaustive-deps
  }, [lastWakeUpTime, avgWakeDuration, avgSleepDuration]); // We only want to refetch if the core data changes.

I wouldn't disable eslint, but fix the code to have a cleaner and 100% bug free approach.

But I am very impressed and happy for the result!

What we can learn from the faulty CrowdStrike update

Giovanni Mazzuoccolo — Sun, 21 Jul 2024 20:47:38 +0000

Unless you lived on the Moon, you know what happened on July 19, 2024.

In a few words, a “defective” content update for Windows hosts caused the outage of many machines. Blue screens of death were everywhere, affecting airports, hospitals, and more.

A big mess.

But as developers, what can we learn from it?

1. Be careful about what you give access to.

What I find difficult to understand is how CrowdStrike had such easy access to the core of Windows. It reminds me of this xkdc comic

I understand the Windows world is huge, and maintaining its security is a challenge, almost to the level of "almost impossible." Windows is also considered insecure due to its past, and crackers want to target as many users as possible, which are on the Windows system.

So, when we download a third-party library, ask yourself 100 times if you really need it and what is behind it. It's like having a guest at home.

2. Testing is more important than the code you write.

Was it avoidable? Most probably yes. Overconfidence, strict timelines, and management pressure can lead developers to push untrusted code. And disaster is just around the corner. Finding time for testing is a developer's right, which needs to be explained multiple times to non-tech people.

3. Communication is important.

I appreciate the honesty of CrowdStrike. They recognised the issue and didn’t blame anyone else but themselves. The fix was late, but they didn’t make excuses for the non-tech people, who immediately believed it was a cracker attack.

4. Make a postmortem so everyone can learn about it.

Having a postmortem is important. It's a document where you analyze your mistakes and learn from them. It also gives honesty and transparency to the company.

And you? What are your thought about this?

What we can learn from programming memes for developers

Giovanni Mazzuoccolo — Mon, 14 Aug 2023 20:29:25 +0000

During a debugging session, code review, or normal coding session a colleague would probably send a programming meme.
Programming memes have emerged as more than just a source of amusement for developers. They show the frustrations, triumphs, and universal experiences of coding in a way that resonates across the digital landscape. But, aside the jokes, can we actually learn something form them? We will delving into the shared realities they depict and the valuable lessons they can teach us about the art of software development.

No documentation, yes problems.

Undocumented code, especially APIs, can make the codebase difficult to read, maintain, and prone to varied interpretations. This is particularly true when you aim to extract content without possessing prior knowledge. To illustrate, envision yourself in an unfamiliar foreign city, lacking a map and data on your phone. Extend a courtesy to both your colleagues and your future self: comment the code

Review, without losing the view

When collaborating within a team, your code is subject to scrutiny by a supervisor. Additionally, even if you're a junior developer, you might find yourself tasked with conducting code reviews. An effective code review goes beyond the surface; while well-written code adhering to conventions is essential, a more risky situation arises when the code appears flawless but fails to meet the definition of done. Such a scenario can be more problematic than code that may not strictly follow conventions but covers all cases, including error handling and less-expected paths. While spotting minor issues is straightforward, evaluating code's maintainability, stability, and scalability is a far harder.

Git blame yourself

I like to use GitLens VScode extension because it keeps git blame at the ready, allowing me to easily connect with the developer responsible for a piece of code. It's amusing how often the responsible developer is myself 😅. Dealing with old code can be a dilemma, particularly if it appears unstable or outdated. Yet, we don't always have the luxury of time to refactor it. The key is to ensure we don't forget to bookmark it, go back later and fix it.

I don't understand

This is crucial. Understanding why code works is even more fundamental to comprehending why it doesn't. Being unaware can be incredibly risky. I believe that bridging this gap is one of the most significant steps from a junior to a senior level.

Better than caffeine

This is my favorite meme, and it never fails to give a laugh when I share it with my colleagues. There isn't much to say about it, except the simple reminder: avoid doing something foolish, especially in production!

Most of the memes are taken from r/ProgrammerHumor on Reddit.

Now it is your turn! Share your favourite programming memes and comment on them!

Code with Sherlock, how the Science of Deduction helps to write better code.

Giovanni Mazzuoccolo — Sun, 23 Jul 2023 20:00:00 +0000

I'm currently reading "How to Think Like Sherlock: Improve Your Powers of Observation, Memory, and Deduction" by Daniel Smith. This interesting book explores the way Sherlock Holmes thinks and solves problems, and I've noticed many similarities between his methods and the daily life of a software developer.

So, let's wear our deerstalker (Sherlock's famous hat), and dive in!

1. The crime scene: Analysing Requirements

This is the part when Sherlock is scrutinizing a crime scene, trying to gather as much information as possible. Whenever we start a new task, a new project, or someone assigns an issue to us, the more information we collect, the more refined our work can be.

What can we learn?

Sometimes, Sherlock asks some basic questions to ensure everyone is on the same page (and, yes, to show off a little, but I am not suggesting you do that :) ). Before starting, any question is welcomed, even the most seemingly simple one. We can always introduce our question with phrases like: "Just for clarification" or "I have a simple question, ..."
Anything that is unclear needs to be made clear. If something is unclear, this is the best time to make it super clear! This includes deadlines, intermediate deliveries (milestones), requirements, and even the non-happy path scenarios. Think of it as a poker game with cards on the table."

2. Studying the enemy: Observing patterns

As Sherlock would observe and notice subtle details, we can benefit from recognizing patterns in the codebase. By understanding recurring design patterns or identifying common issues in the code, you can improve code quality and maintainability.

What can we learn?

By observing patterns, we can better understand our codebase, applying software principles like DRY (Don't Repeat Yourself) to identify pitfalls and potential future problems.

3. "Deduct" the bug to solve it.

When encountering bugs or issues in your code, a deductive mindset can be valuable in the debugging process. Analyze the symptoms, consider potential causes, and systematically narrow down the possibilities until you find the root cause.

What can we learn?

Understanding the bug before solving it is essential. Using Stack Overflow is helpful, with the caveat of understanding what we are copying and pasting rather than blindly relying on it. Sherlock would never do that.

4. Learning and Improving:

Just like Sherlock was a continuous learner, you should always seek to improve your coding skills. Dedicate time to learn new technologies, programming languages, and best practices, and apply them to your projects.

What can we learn?

Don't be scared of the unknown; big minds work with curiosity.
If you are spending too much on courses, it's wise to buy a new one only after completing the previous one.

5. The Dynamic Duo: Collaborating with Other Coders

Holmes and Watson were an unbeatable duo, and so shall you be with us coders! Apply deduction in collaboration, respecting others' perspectives while collectively deducing solutions. The synergy of minds shall birth innovative marvels that transcend the sum of their parts.

What can we learn?

"Do not be scared to delegate. This is very difficult for me. I am often worried about relying on others and getting poor results. But coding is a marathon, and helping each other is the best way to reach the common goal.
If you see that you are going to miss the deadline, telling before is better than informing after you miss it.
Proactive communication is vital in software development because it allows for better planning, resource allocation, and risk management. If you wait until after the deadline has passed to inform others about the delay, it can lead to disruptions, missed opportunities, and a loss of trust from stakeholders.

Do you find any other common things about the Science of Deduction and Software development? Let me know in the comments!

P.S. Check out my side project: Dutch for developers where you can learn Dutch and land a job in The Netherlands!