Forem: CarGDev

Researchers Are Begging for This: The Academic LinkedIn

CarGDev — Sun, 15 Feb 2026 17:03:19 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

Endorsement — a frontend-only Researcher Endorsement & Collaboration Platform built with React (19), Vite, TypeScript and Zustand. The app is a client-side mock of an academic social feed where junior researchers can create profiles, post markdown abstracts, attach in-memory markdown content, receive endorsements on specialties and posts, and share endorsement links.

The project emphasizes discoverability across disciplines, a simple endorsement graph, and a clean modular architecture ready for a future backend.

The application has mocked data and not backend was developed at this time.

Demo

Repository: https://github.com/CarGDev/endorsment
Intended host / homepage: https://endorsment.cargdev.io

My Experience with GitHub Copilot CLI

I consulted the official GitHub Copilot CLI documentation while preparing this submission to ensure accurate descriptions of CLI capabilities and commands. In this session the Copilot "documentation fetch" was used programmatically to confirm features (models, installation options, experimental flags, and available commands) and to cite how Copilot CLI can be launched and configured.

Practically, the project edits and file operations were driven by the Copilot-assisted terminal workflow in this environment: files were created and edited, CSS adjustments applied, and git commits executed. The CLI docs informed correct terminology and helped shape the explanation below so the submission is accurate about Copilot CLI features.

Session prompts, knowledge and actions (summary)

Below is a concise chronological summary of the visible user prompts I have used and the corresponding actions taken during creating the application.

Initial product specification
- I provided a detailed spec (React 19 + Vite + TypeScript + Zustand, routes, types, components, store actions, seed data, and UI behavior).
- Action: scaffolded project files and implemented core store, types, routes, and components according to the spec.
Dependency & build issues
- npm install failed due to a specific unavailable zustand sub-version.
- Action: updated package.json to use "zustand": "^4" so installation succeeds.

Vite failed to load @vitejs/plugin-react ESM plugin (require vs ESM issue).
Action: added "type": "module" in package.json to allow ESM plugin loading.

Runtime errors & quick fixes
- App.tsx threw ReferenceError: PDFModal is not defined.
- Action: replaced the undefined reference with the existing MarkdownModal and committed the fix.
UX / UI adjustments requested by the user
- Add a 5px gap on tags row → updated CSS (.tags-row { gap: 5px }).
- Move "Share something..." to the top of the feed → updated Home.tsx to place the create input above the feed and open the create modal on focus.
- Make the whole PostCard clickable to view detail; keep internal buttons interactive → updated PostCard to navigate to /post/:id on card click and used event.stopPropagation() for buttons and links.
- Move "Open MD" control next to Endorse and under the preview → adjusted PostCard layout accordingly.
- Add breadcrumb on PostDetail → added a simple "← Home" link above the post card.
- Replace alert() usage with a top-right NotificationCenter → implemented NotificationCenter component, added store.notifications, and replaced alert calls with addNotification(...) calls.
Markdown instead of PDF
- User requested markdown attachments (mocked) instead of real PDF handling.
- Action: adapted posts to support attachedMarkdown { name, content } and added MarkdownPreview / MarkdownModal components.
Formatting, linting and project metadata
- Added README.md with author details and the screenshot path.
- Updated package.json with my data (author: cargdev carlos.gutierrez@carg.dev, homepage, repository) and added a prettier script.
- Created .prettierrc and .prettierignore, added ESLint config (.eslintrc.cjs) and .eslintignore, and added lint and prettier scripts to package.json.
Commits
- Performed git add and git commit operations at several points to save progressive changes (commits recorded in the repository).
- Note: the markdown submission created by this request is intentionally created but not committed (per your instruction).
Tools and helper actions used during the session
- File operations: created and edited files (components, routes, store, styles, README and configs).
- Searches: located occurrences of alert() and other patterns to replace them.
- Git: staged and committed changes via shell commands.
- Copilot docs fetch: programmatically retrieved official Copilot CLI docs to ensure accurate description for this submission.

Notes and follow-ups

The app is frontend-only and uses an in-memory Zustand store with seed data; localStorage persistence is optional and not required for the MVP.
Markdown rendering used in the demo is a lightweight approach for mock content; for production use, replace the simple renderer with a proper parser + sanitizer (e.g., marked + DOMPurify).

Vibe Coding Is Addictive, and It’s Quietly Destroying Software Quality

CarGDev — Thu, 22 Jan 2026 05:15:29 +0000

Recently I have been use the claude code cli to create some internal projects to myself, to get into Vibe Coding area, it is an incredible app I may say, probably I will continue use it more and more, but I still have complains and of course I have a complain with the price that is quite expensive, I won't focus on that, I think the LLMs are actually even more costly but we are not seeing the real prices yet. Companies have to gain customers in the area first, and then they will get the real costs.

As I said before, I have this thought: when you're going to code, with money or without, ships will be really fast, but that doesn't mean it will be good; it just means I don't need to Google it or Stack Overflow it (if that is a verb).

Reflections on AI-generated code and developer responsibility

I have generated a project with 1396 directories and 17121 files, which I have to review one by one, and I have already started. It will take time, but this helps me to understand what the LLM is trying to do. I'm talking about Opus 4.5 here, which is the best LLM for coding so far. So recently, I watched many videos about how software engineers will disappear. I doubt it, but let's think for a second that this is true and that developers are people who never evolve with new frameworks.

So, how companies will generate products will be either prompted by another LLM or by a few people writing prompts insanely because, you know:

"Fix this, this time has to work, please."

The reality is that, for many years, we've said as software developers/engineers that our work is not about code; coding is just one part of the task we have, and LLMs beat us at typing for sure, though not at creativity.

As I mentioned, I have generated 17121 files, which is insane now. As a developer, I'm lazy; that is why I use NVim. I don't need to think about what I'm doing. I just have to do it (that is another discussion, but use NVim).

Reviewing structure, trade-offs, and maintainability

At this point, let's talk about the structure. The structure actually was a mess. I wrote rules within .claude/ to maintain the structure the most accurately as possible, even with this, the LLM hallucinates sometimes. So let's analyze what I got as a product:

The good part

The good part that I got from this was:

I have the architecture I wanted
I wrote a bunch of code insanely fast
I kind of manage Claude's code to either approve or deny the changes
The functions most of the time are written in modules
It follows the agents' files and skills

The issues

As soon as I have to read the code I found:

I have to learn how the code was written. I know the rules, but not how this app was created or coded
I have mixes between files in JavaScript with Typescript
If something is hard to get, Claude will mock the code to make it appear to be working
I have imports where literally importing a function and types like

import {
    functionA,
    functionB,
    type functionC
    functionC
    type functionB
} from '@/tools/some'

The most common will be getting imports like:

import {
    functionA,
    functionB,
    functionC
} from '@/tools/some';

import type {
    functionB,
    functionC
} from '@/types/some';

Then I have to change the functions and types in separate files, which will be easier to debug in the future

I got functions where the types were imported directly on a random function on line 450, just because
I face code defining the types directly on the line:

state.push({
  role: role as 'user' | 'admin',
  content: content,
});

I got functional programming in the same file where I exported a class

The code is really hard to debug in the first instance, has comments everywhere, and overwrites the logic elsewhere. I found issues like using the exact same logic in multiple functions and files; that part isn't scalable. Again, it looks super good because it is faster, but it is not maintainable.

Where velocity creates risk

There will be people who will tell me that companies want to get things faster, be the best on the market, and stay competitive. Stay on the podium faster than their competitors. I agree on all those the companies need revenue year after year to keep their bussiness but be quicker is not same as get quality, the software is antrophic and changes over the time, those products Vibe coded today will be a pain on the near future, does not need to be 10 years on the market to say a software is not scalable, as soon as you have customer coming to your application, a lot of issues will be arised and with that could be vulnerabilities.

Talking about vulnerabilities is another thing with LLMs; we write software to define an architecture and add layers to the application. But the LLMs seem they hate layers and find a way to be more effective, that does not matter if they need to connect the database directly with the UI, it is working and was fast. That is the reason the LLMs have a lot of insecure things, with a simple emoji, and an LLM can get prompt injection.

That is because the LLMs are to generate content. They are super good at predicting what the token needs to be after the previous token to sound coherent, cohesive, and trustworthy. When they mock data to make the app run, they are calculating the probability that the code will work. I have worked with LLMs that review the code I write, too, and again, it is the same story. The LLM is losing context over the time. I've seen reviews where I implemented the changes it suggested in the PR comment, and then it complains about the suggestion the LLM made a couple of commits ago.

When to rely on AI, and when not to

This is not easy because prompting feels good and gives you the feeling you are doing the best thing ever, but when I suggest avoiding the AI:

When you want to create an application in a language you don't know. It is easier for me to review code written in TypeScript because it is the language I primarily know, but I have to check code generated by the LLM in Rust. I'll probably say yes to everything.
Learn how to do it by yourself first, if you are not able to understand what it means and the API, before creating one. The LLM will give you anything, and you will be very proud of the result.
Review every single line generated by the LLM. It is cool to get a lot of lines that look colorful on the IDE, but read every line to see if that makes sense.
Read about how things work, be curious about. Educate yourself, you don't need to make everything you learn but you have to get an idea and knowledge about how everything works, if tomorrow you are on a plane and you only have the flight time to finish a piece of code, you have to be able to do it by yourself.

Now, when I suggest, it's cool to use the AI:

When you have expertise in the language
When you know the product and understand the business logic
When you want a quick explanation of how the code is written

Why understanding comes first

The issue is not that LLMs can code; it is how we use them to generate that code. How the LLM contribute myself to be better tomorrow, everything that is discovered or invented has to make us better. If in 10 years we saw that AI was really a bad thing (like social media), then even if it is the best thing ever, it would be useless; it wouldn't matter because, as humans, the tool isn't helping us to be better or stay in a better position.

Use all the tools out there, but first learn how to be a software engineer without any tools. A brief story: when I was in middle school, I started learning about algebra, and there were calculators that solved equations; I have never used one of those. I wanted to know how the equations work, even though I didn't use the quadratic formula, I learn how we got the quadratic formula, and then everything clicked. It will happen the same with the LLM for me; if I don't how to code on some language first I need to learning it before speed myself.

The AI Bubble: Why I’m Getting Out Before 2026

CarGDev — Mon, 22 Dec 2025 00:14:22 +0000

The AI is here, and by passing the 2025 I faced, everyone is realizing that the AI is good at completing tasks such as reading emails, organizing them, writing letters, and generating images. I have created the pictures for my blog using AI, and they are impressive. If I think about it, it is good to maintain my pattern.

So, why am I running away from AI in 2026 if the hype is still there, the race to acquire the best AI is still ongoing in our world, and models are continually improving? At some point, it becomes counterintuitive and feels like a bad decision if you think about it, especially given the news that the AGI could possibly be raised by 2030, which is the goal.

Everything started with the illusion of thinking. I read that paper, and something resonated with me. Then, I read "The Illusion of the Illusion of Thinking," which takes the opposite stance, explaining why Apple Papers feel bad and what they did wrong in their research.

Both papers are extraordinary in understanding the key point of AI.

The real truth about the system

After reading the book The Art of Doing Science and Engineering: Learning to Learn, and making an LLM prototype by myself, I realized the pattern is still clear, we have a super models that basically run from the same pattern, connecting dots based on the prompts by generating the most credible idea based on the most probable answer any user is looking for.

So that is why if I ask any LLM:

What is the command to display where my folders are mount

I will get this answer below:

Which is correct and saves me the time to Google it. There is, however, a paradox: creating the illusion that I know how to use the terminal, and perhaps I do; it may also be creating an illusion that I understand something I do not clearly comprehend. I am not saying that we should learn all the commands by memory.

Imagine now an application made by someone that does not know how to code or create applications, it is some requirements as software engineer you need to follow but how to get all those requirements within the code to then create an application, that is tricky behavior it is not only code the lines of code or modeling the system requirements is synergy of everything and understand what you are doing what every you are doing.

The path is missing out.

At this point, it is clear why I'm moving away from LLMs. I feel I need to buy something to be super fast and feel productive by just paying to be smart. We are buying the power of thinking, or at least that's what it seems like.

It is the same feeling on video games 20 years back and nowadays, where you clearly need to buy the best skin instead of demonstrating your best ability. We are, in fact, showing who is wealthier than others, generally speaking.

The feeling of being extraordinary without being extraordinary feels real, and we must remember that all these products are maintained by companies, so they have to generate revenue in the end, right? We should think about how we utilize the new technology added to our lives to maximize its benefits to our advantage.

What's going to be my 2026

In fact, I won't stop using AI tools at all, but I won't spend too much money on learning and practicing with them. After building my own LLM, where I felt I could understand much better how the AI works and what the AI is by removing all the hype.

I will follow my own pattern of learning. I will still be using AI to code if I know the language, after all. Once I am on an LLM loop, I need to be able to write the code myself. It is okay if I don't remember a command line; I can ask an LLM or look it up on Google. Though I will remember it for next time, I will write it down in a notebook to reinforce my own learning.

If I need to write something valuable or feel the need to convey an idea, I will draft it myself and figure out how to make it sound better. At the end, I will just use an LLM to correct grammar and congruency rather than simply typing a prompt to create something that will make me feel good about it. Perhaps I don't have the idea about.

How a Performance Study Changed the Way I Think About Optimization

CarGDev — Mon, 08 Dec 2025 18:40:55 +0000

I recently read a paper on high-performance computing (HPC), which reshaped my understanding of performance work. I used to think HPC was mostly about having the “fastest algorithm.” Perhaps, the more I delved into the research and my own experiments, the more I realized that HPC is fundamentally about how algorithms behave when they interact with real hardware, compilers, memory systems, and parallel execution models.

The paper I was reading analyzed 1,700-ish commits across 186 confirmed performance bugs. What blew me out is that these weren’t exotic edge cases. Most were everyday issues caused by the way algorithms interact with memory, data structures, and parallel execution.

It made one thing very clear: HPC performance is about managing complexity, not just writing clever code.

The Five Root Causes of HPC Performance Bugs

The study categorizes performance bugs into five distinct categories, each with its own unique characteristics.

Once I reviewed the paper more, I understood that most performance problems aren’t about things being “too slow” in an obvious way. They’re about using the wrong data structure, over-synchronizing threads, performing unnecessary allocations, or tripping on memory alignment. They’re subtle, and they often hide in plain sight.

In most cases, a minor issue is resolved by just 10 to 20 lines of code, which can take weeks to find. And the experience level of developers also plays a role: senior and expert engineers introduce fewer performance bugs because they’ve learned how to avoid the traps before stepping into them.

A Closer Look at the GitHub Issue

One example that really caught my attention was a GitHub issue in OpenBLAS, where users noticed that matrix multiplication performance could vary by up to 2 times depending on how memory was aligned.
Let's consider this issue for a moment: the same code, the same matrix sizes, the same function, but wildly different runtimes depending on where the data happens to land in memory. The issue came down to something simple but easily overlooked.

C++ heap allocations are typically aligned to 16 bytes, but AVX kernels in BLAS libraries perform best when memory is aligned to 32 or 64 bytes. Misalignment means the CPU has to fetch data across cache line boundaries, which can sometimes cause extra loads or partial cache line accesses.

The end result is unpredictable performance. Not slower in a consistent way, but irregular, sometimes aligned memory is faster, sometimes misaligned is faster.

That unpredictability is what makes this kind of bug so frustrating.

What the Results Actually Looked Like

Across matrix sizes ranging from 512 to 2048, the aligned and misaligned versions alternated in position. On my setup:

At 512, aligned memory was clearly faster
At 1024 and 2048, misaligned memory actually edged ahead
At 1500, alignment mattered again

The key takeaway is that the pattern isn’t stable. The performance varies depending on the CPU architecture, cache behavior, OS memory allocator behavior, and even the matrix dimensions themselves.
This also supports one of the key arguments in the empirical study: memory-management performance bugs typically take a long time to diagnose because their symptoms aren’t consistent.

What This Taught Me About HPC

After working through both the research and the experiments, I walked away with a different perspective on HPC optimization.

HPC isn’t really about making code fast. Anyone can make something fast once. HPC is about making performance predictable. A “fast” algorithm that sometimes runs twice as slow is a liability.

A few lessons hit especially hard:

Hardware details matter more than most people think.
Data movement is often a bigger bottleneck than computation.
Alignment, caching, and parallel scheduling can completely change performance.
Many performance bugs are really architectural misunderstandings.

Final Thoughts

Reading the empirical study and experimenting on my own, my machine and my own alignment-sensitive benchmark made HPC feel much more real to me. Instead of thinking in terms of algorithms on paper, I began to consider how code is loaded into memory, how the CPU fetches it, how cache boundaries influence performance, and how seemingly minor decisions can ripple outward into unpredictable behavior.

HPC isn’t just about writing efficient code. It’s about understanding the environment in which the code runs. And once you see it that way, performance becomes a much more interesting and much more challenging problem.

My Journey into Computer Architecture: From Basics to gem5 Experiments

CarGDev — Wed, 24 Sep 2025 09:45:39 +0000

When I started studying computer architecture, I knew I was entering a field that quietly shapes the way modern technology works. Behind every phone, server, or smart sensor is a set of design decisions that balance speed, energy, and complexity. What I didn’t realize was just how much of this world I would explore through hands-on experiments with gem5, a powerful simulation tool.

Laying the Foundation

The first step in my journey was simply getting things ready. Installing and building gem5 on my own system wasn’t glamorous, but it grounded me in the practical side of architecture. I learned how to structure my work properly—keeping source code, builds, workloads, and results cleanly separated. That organization became essential later when the number of runs and configurations started to multiply.

Running a simple “hello world” program on the x86 ISA may sound trivial, but it gave me confidence. It was proof that my simulation environment worked, and it reminded me that even the most complex systems begin with small steps.

Memory Hierarchy: Where Performance Meets Reality

As I moved deeper, I studied memory hierarchies—the layers of SRAM, DRAM, Flash, and newer technologies like HBM and NVRAM. Each level carries trade-offs between speed, cost, and capacity. What struck me is how much of modern performance depends not on raw processor speed but on how well we hide or manage memory latency.

Through gem5 experiments, I tested cache parameters: adjusting sizes, associativity, and line sizes. The results were eye-opening. Doubling the cache line size, for example, increased per-miss latency but actually improved execution time overall by better capturing spatial locality. It was a practical lesson in how design trade-offs play out in measurable ways.

Instruction-Level Parallelism (ILP): Squeezing More from a Single Core

Another turning point was exploring Instruction-Level Parallelism (ILP). At first, the idea seems simple: overlap independent instructions so the processor stays busy. But the deeper I went, the more I understood the challenges—data, control, and structural hazards constantly get in the way.

I experimented with pipelining, superscalar configurations, branch prediction, and simultaneous multithreading in gem5. Out-of-order execution and speculation, once just abstract textbook concepts, became real when I saw how they changed throughput and latency. At the same time, I came to appreciate why hardware complexity and power consumption limit how far we can push ILP. The so-called “power wall” isn’t just theory—it shapes the future of processor design.

Connecting to Modern Trends

What excites me most is how these classical concepts connect to emerging directions. Heterogeneous architectures—where CPUs, GPUs, and accelerators cooperate—are the industry’s way of sidestepping ILP’s diminishing returns. Similarly, cache innovations, persistent memory, and interconnect standards like CXL point to a world where efficiency and scalability matter as much as raw speed.

Closing Thoughts

Studying computer architecture has been more than an academic exercise for me. It has been a journey from abstract principles to hands-on experiments, where theory meets measurable results. Running gem5 taught me that architecture is not about chasing “the fastest processor” but about balancing trade-offs: latency versus throughput, performance versus power, simplicity versus complexity.

Every experiment left me with a sense of discovery. Whether it was watching a tiny benchmark expose cache behavior or seeing how branch prediction changes pipeline flow, I realized that architecture is as much about creativity as it is about engineering discipline.

I’m still at the beginning of this road, but one thing is clear: understanding computer architecture gives me a new lens to look at technology, not as a black box but as a carefully tuned system where every choice matters.

From Minimal to Mighty: Reimagining ideaDrop.nvim for Serious Idea Management in Neovim

CarGDev — Tue, 29 Jul 2025 00:00:19 +0000

You know that feeling when a tool grows beyond its original purpose?

That's exactly what happened with ideaDrop.nvim—my little side project that began as a floating Markdown sidebar for quick brain dumps and now... well, it's a full-blown idea management system for Neovim.

Let me walk you through the transformation—from a humble plugin to a power user's dream.

The Seed: What ideaDrop Used to Be

The first version of ideaDrop.nvim was minimal by design. Think quick access, minimal interface, and just enough file handling to stay out of your way.

What it did well:

Let you drop thoughts into a floating Markdown file
Saved files automatically
Let you name and nest them in folders
Gave you a fuzzy picker to open existing notes

Simple. Effective. And very much just enough.

But... something kept nagging me.

The Realization: Notes Deserve Power, Not Just Simplicity

As I started using ideaDrop more regularly—jotting down project specs, startup ideas, random midnight epiphanies—I realized I needed more:

A persistent view that doesn't vanish when I switch buffers
A way to browse ideas by tags, not just filenames
A file tree to see everything at a glance
Real search, not just a fuzzy filename picker

And most importantly: it needed to scale. Ideas are chaotic. Your tools shouldn’t be.

Multiple View Modes

Forget being stuck with just a floating window. Now you can:

Pop ideas into a persistent right-side buffer (perfect for long work sessions)
Replace your current buffer
Still enjoy the original floating modal
Or use the new Tree View powered by nvim-tree

It’s your workspace—view it how you want.

Tagging, Supercharged

Idea tagging is now first-class:

Add or remove tags with commands (:IdeaAddTag, :IdeaRemoveTag)
Browse by tags (:IdeaTags)
Search ideas with a specific tag (:IdeaSearchTag)
Auto-indexes tags from your #hashtags in Markdown

It’s like Obsidian meets Neovim. And it just works.

Fuzzy Search on Steroids

The old fuzzy picker? That was cute.

Now you can:

:IdeaSearch across titles and content
Narrow it down with :IdeaSearchTitle or :IdeaSearchContent
Get instant results as you type
Jump to exact matches

Seriously, it’s creepily fast.

Built-in File Tree Navigation

If you’re a visual thinker (or just messy like me), the new Tree View is 🔥.

Use :IdeaTree to pop open nvim-tree, and you can:

Navigate through all your idea folders
Click to open files
Create, rename, or delete ideas
See your whole mental world at a glance

Cleaner, Safer, Smarter

Under the hood, I’ve:

Added auto-save (no more accidental loss)
Implemented date-based file naming
Kept everything in clean, human-readable Markdown
Improved configuration defaults, but left full control to you

New Keymaps = Instant Productivity

You now get opinionated, intuitive defaults:

Keymap	Action
`<leader>id`	Open today’s idea (right buffer)
`<leader>in`	Open named idea (right buffer)
`<leader>it`	Launch the file tree
`<leader>is`	Search through all ideas
`<leader>ig`	Browse tags
`<leader>if`	Open today’s idea (floating)

Customize them or stick with mine—your call.

🫶 Final Thoughts

I didn’t set out to build a full-featured PKM tool inside Neovim.

But here we are.

If you're a developer who lives in Neovim and needs a fast, private, keyboard-first way to manage your brain—ideaDrop.nvim might just be your new second brain.

I use it every day now.

And I built it for people like me. Maybe people like you, too.

👉 Check it out on GitHub

⭐ Star it.

🐛 Break it.

🔧 Hack it.

❤️ Use it.

— Carlos

Detox Week

CarGDev — Mon, 07 Jul 2025 23:00:09 +0000

This week, I started working on nothing.
Yeah, I know — that sounds like I didn’t even open the terminal.
Well, in strict theory, I wasn’t allowed to.

I started the week with some basic rules:

No reading anything
No social media
No work
No emails
No learning
No LLMs like ChatGPT
No music with lyrics
No podcasts
No multitasking
No messages (WhatsApp, iMessage, etc.)

Note: The rules above could be broken only if something important came up.

One of the hardest rules was not reading. If you do this exercise, you’ll quickly realize how difficult it is not to read when you’re trying to avoid it. We don’t notice how much we read during the day — even the small labels on a whole milk package. You’re still reading, and that becomes mental trash for your brain.

The goal for setting this titanic task for the week was simple: get a detox.
Simple, but hard to follow. By the third day, I was really fighting against the boredom.
I found myself counting stuff in my house — I have 4 chairs and 1 table.
Then I started wondering: when was the first dinner at that table?
Before tables existed, did people even have dinner and lunch "times"?

First Day

The first day was filled with constant thoughts like: What am I doing? Why am I opening social media again when I know I can’t do anything?
I would just close it and put my phone back in my pocket.
I deactivated notifications on my Apple Watch.
I was on a very strict regimen.
I felt like I was going insane, doing this.

But the day happened normally. I interacted more with people at the office, talked more, and saw people I hadn’t seen before.
It was interesting, to be honest — not tough at all.

Second and Third Day

These days were the toughest — the most difficult on my calendar.
I was dying of boredom.

At work, I had a schedule to follow. It was hard to maintain.
Obviously, I had to keep reading emails and messages, but I avoided going deep into conversations unless they tagged me — if it’s not important, I let it go.

At home, it was even harder. I had nothing to do.
I watched a documentary about the Titan submersible.
If you remember that day in 2023 when a group of people went underwater to explore the Titanic wreck — that one.

It was the first time I finished a documentary in one sitting.
I hadn’t realized how often I’d watch 2-hour documentaries in fragments over months.

On the third day, I was extremely bored.
I started drawing to keep my mind busy.
That small act helped me: to start something and finish it — just because sometimes you need to finish what you start.

Fourth Day

A day without music, without podcasts, taught me about the micro-trash in my mind.
All that noise and stimulus forces my brain to be in response mode all the time.

That day, my anxiety was lower.
It helped me analyze myself and reflect on the constant rush of change happening every day in tech.

Final Day

The final day was smooth.
I think I lost my phone for most of it.
No messages — only the Apple Watch, in case I needed to answer a call.

I enjoyed that day.
With a cigar.
In nature.
Just listening to the sounds and peace.

I hadn’t felt that kind of peace in a very long time.

Thoughts

During this week, I wrote a lot.
I observed more.
I listened to people more.
I interacted more.

I did a retro inspection with myself — having internal discussions I had buried in my rush to be productive.
It felt like a pause in a chaotic world.

I wrote again on paper — adding all my ideas, questioning myself:
What do I want to do?
Why am I doing what I’m doing?
How do I see myself in 5 years?
How do I see myself as an 80-year-old man?

Yes, those are cliché questions — but they help when you stop for a second and really think.

Learning

This week didn’t change my life — I wish I could say that just to get more views.
But It did open my mind though.

It’s okay to rest.
It’s okay to be sad.
It’s okay to not finish that book.
It’s okay to not finish that project.

what’s not okay is losing the present though.
Losing the connection as a human being.

There’s a long way to go.
I still have things to learn, stuff to accomplish, projects to get done.
Maybe I’m one week behind others — but this isn’t a competition.
It’s not even a race.

This week showed me the positive side of boredom: it leads to creation.
I drew. I picked colors. I made combinations.
Maybe people will say it’s the worst drawing — but who cares?

I wrote things I’ll probably never read again.
But that was a mental drain I needed.

The negative side of boredom wasn’t that bad either.
It just showed me how badly my brain had gotten addicted to quick answers, quick feedback, quick everything.

From now on, I’ll probably set a 10-minute timer for social media.
10 minutes for reading emails.

By the end of the week, I had received 150 emails on my personal account — and 95% were trash.
All that junk is taking up space in my brain, displacing the important stuff I actually want to do.

No, I won’t finish my projects in one day — but the 2–3 hours I used to spend on social media?
That could be one more line of code.
Or just paying better attention to the podcast I actually care about.

I really love listening to music.
Anyone who knows me knows I’m that guy blasting music in the morning on the way to work.
But I had never noticed there was a lake on the way to work.
Walking was better.
I breathed better — without headphones or my phone.

It’s okay to not answer the phone.
If it’s important, they’ll call you.
Trust me.

Pause, Just Once

If any part of this resonated with you, I invite you to try your own version of a detox week. You don’t need to follow every rule I did—just pick a few and notice what happens when the noise fades. Give yourself space to be bored, to reflect, to observe without distraction. It might be uncomfortable at first, but on the other side of that silence, you might rediscover parts of yourself you’ve been too busy to hear.

I built an MVP couple/personal finance app

CarGDev — Sun, 15 Jun 2025 01:16:26 +0000

Why did I do this?
That’s probably your first question: Why is this guy adding yet another finance app when there are already so many on the market?

Well, I’ve got something to say: none of the apps out there really talk to each other or follow your spending in a way that actually reflects your life. They’re disconnected, rigid, and often built around assumptions that just don’t match reality — especially for couples.

I’ve got tons of ideas for where this can go, but I had to start somewhere. My mindset was simple: If this app helps me, maybe it can help other couples in the same situation too.

Let’s Talk About the Money
Money’s hard to talk about — especially if, like me, you come from a Latin American background where money is still a bit of a taboo. But why should that be the case with your partner? That’s the person who's right next to you, day in and day out.

Not everyone got the best financial education growing up. And that’s exactly why y’all need to talk more about money — to figure out if you're on the right track or heading in the wrong direction.

Me and my wife started doing a weekly financial check-in — it’s non-negotiable now. That meeting helped clear up so many things:

Where your money is being spent
What goals y’all need to set as a couple
How much y’all have for groceries, gas, and fun
What your real budget looks like
How y’all are investing in retirement (or not yet)
Why I Built This
I've been tracking finances in Excel for 15+ years. I’m fast with it, I know VBA, I’ve built dashboards — the whole deal.

But now, I’m not doing finances solo. And let’s be real: it’s 2025 — apps should be better than spreadsheets by now.

Even with all my Excel experience, juggling data, keeping it synced, and getting real insights was becoming a mess. So I built the tool I wish existed: a simple, connected, private-first finance tracker that works for individuals and couples.

It’s live now:
👉 https://finances.cargdev.io

What It Does
✅ Track income, expenses, and credit card balances
✅ Split bills with your partner or housemate
✅ View your savings rate, spending trends, and budget categories
✅ Keep your data private — no 3rd-party syncing
✅ Fast, simple, flexible — works the way you need it to
What I Need From Y’all
I’m in the validation stage — here’s where y’all come in:

Try it out and see if it fits your flow
Send honest feedback — UX, bugs, missing features
Tell me if this solves something real for you
Try It Now
Head to https://finances.cargdev.io
Create an account (no email verification needed)
Add some transactions or split a bill
Explore the dashboard — and tell me what makes sense, what doesn’t, and what’s missing
Let’s Connect
If this idea speaks to you — whether you’re a user, developer, investor, or just curious — I’d love to talk.

Leave a comment, DM me on LinkedIn, or email me at carlos.gutierrez@carg.dev.

Thanks for reading. And thanks even more if you give it a try.