n: the command-line tool that I wrote without writing any code

There are three reasons I wanted to write this blog post:

Just because I’m still exited! Exited about writing a tool in an afternoon. Exited about the way I did it and the flow I was in.
Because I wanted to talk about beads.
Because I wanted to mention n.

A tool in an afternoon

The idea of a command line tool that will fit my needs was planted quite a while a go. Couldn’t find the time or didn’t have the energy to act on it so it remained just that, an idea.

Until yesterday that I saw this video. At some point, beads gets mentioned. I was curious as to what it does exactly that decided that it was now or never:
I created a repo, added beads to it, bought some credits in warp.dev and vibe coded the tool I had in mind!

This was the initial prompt:

	I am an engineering manager and I want to create a terminal tool, named n, that will allow me to take quick notes about my reports.

	The idea is that whenever I want to note something down about one of my reports I will open a terminal and write: n <reports name> <my note>.

	The notes must be organized in markdown files named after the report name. For example if I write "n leonidas a simple note" the tool must create a file named "leonidas.md".
	The note must be added to the file under a header with the current datetime in the format YYYY/MM/DD hh:mm:ss.
	For example:
	"n leonidas one note" and "n leonidas another note" will result in:
	## 2026/01/03 14:16:03
	one note

	## 2026/01/03 18:20:00
	another note

	The tool must be configurable. It will read its configuration from "~/.n/config". Its first configurable setting is the folder where it saves the markdown files. By default it saves them in "~/.n/db/".
	The first the user runs the tool it checks if config exists and if not it creates it alongside the db folder.

	I don't know which technology to use so I want you to help me decide and then create a plan for implementing the tool using the selected technology.

view raw n-initial-prompt.txt hosted with ❤ by GitHub

Warp provided a few options with their pros and cons. I chose Go and asked it to provide an initial plan. It did, I accepted it and after a couple of minutes I had a first version of my tool.

Watching the tool working was a pivotal moment. The “features gate” opened and all those ideas just poured out. Here is where beads saved the day.

Beads

The description in its repo is

A memory upgrade for your coding agent

The idea is to provide to your coding agent a way to create tasks keeping its context window small and its concentration at the task at hand. The initial setup is provided by the tool and leverages conventions like AGENTS.md, CLAUDE.md etc

I guess I didn’t push the agent enough to make it create tasks on its own but the fact that I had a tool to save all those ideas and then prompt the agent to “Lets work on the next task” put me in a great flow:

I was asking the agent to work on the next task
While it was working I was playing around with n and adding tasks to beads with either bugs or new features
Go to step 1

That cycle kept me going for a couple of hours!

A simple command-line tool for taking quick notes about your reports.

I’ve always been a terminal guy. Seeing how coding agents increased even more the time I spent to it made me realize that the way I keep notes about my reports must migrate to the terminal too.

The idea is simple. Every time I want to note something down I write:

n name note

this creates a folder name and in that folder a file with the current date which contains the note.

The tool provides a way to tag, edit and delete notes. It provides a way to backup your notes using github and a few ways to see your notes about a report.

Its not much and I know there are better tools out there but this one is exactly as I want it and was implemented in an afternoon!

PS1: I vibe coded it which means that I did not see at the code at all. Don’t judge it 😛 !
PS2: The idea of having all notes in files is to provide them later on in an LLM and have a conversation to figure out the report’s growth.

I guess i’m an engineering manager now

It took me two and half years to come to terms with my new role. So, why now? I guess its a process like everything else. You start something new and feel completely out of your league. You educate yourself and try to apply your learnings. You make mistakes and feel awful. You try something else, make progress and feel better. A roller coaster of feelings! But you keep on pushing and some day you wake up knowing exactly what your job is.

The individual contributor to engineering manager transition

I don’t know about other industries but in software development the transition from an IC to EM is a bit hard. You have to leave a role where everything can be solved with code and where you can showcase your progress and your skills and move to a role that you might not write code for weeks!

So it took me all that time to accept the transition and most importantly to embrace the fact that it is OK to do or not to do a few things.

It’s OK to…

It’s OK not knowing everything and not having all the answers. My job is not to be a dictionary. My job is to be there, help in the research and assist on picking the more suitable solution.

It’s OK not solving everything myself. My job is not being a 10x developer. My job is building a 10x team. So when a problem occurs, I have to define it properly, set a few guidelines and let someone else do the solving.

It’s OK not being the first figuring out that there is a problem. Being a leader does not mean that I have to monitor everything and prevent problems before they occur. My job is to listen when someone brings an issue, assess the situation and prioritise any work that needs to be done while having the best interest of both the team and the codebase.

It’s OK not writing code that much. My job is not measured by the features I implement any more. My job is measured by the features my team is implementing and the level of quality the project has. I might not write code but I do write everything else. Goals, guidelines and documents that will help the team align and work towards the same end.

It’s OK not to be the first to speak. I’m not here to be heard. My job is to foster an environment where everyone has a say.

It’s OK not be right, it’s OK to ask for help. Being in a leading position does not mean you have to do everything perfect. My job is to build a healthy team that its members support each other. What a better way to do that by setting the example that we can all be wrong from time to time and that we will need someone to guide us.

Changing my status

I truly believe that a title in LinkedIn, or anywhere else, does not mean a thing on its own. Having said that I will be updating my title in LinkedIn because (a) I finally feel more comfortable with my role and (b) it is a psychological hack to help me invest even more in my new craft.

PS: I will still answer software engineer when someone asks me what I do for a living 😛

Bring me both your problems and your suggestions

It’s been a little over a year that I have the role of an engineering manager for the first time in my career. Needless to say that I’m still learning. I read the dos and don’ts and try to incorporate them in my everyday work life. Sometimes everything works fine, some others everything goes wrong!

The don’t I keep doing

The one thing that I often find myself doing is providing, immediately, a solution to a problem that was brought to my attention. No “tell me what you think we should do”, no “what approaches have you tried?”, nothing that will spark a dialogue between me and my report. A dialogue that will helps us to figure things out and grow as engineers.

Figuring something on your own, instead of being told about it, has proven to be vital in understanding it better. So, if I want my reports to grow as engineers, I must lead them to a solution rather than give them one. The aforementioned questions must be my first reaction.

The do we can start doing

this part is a message to all my current and future reports

My hope is that writing about this don’t will make me more conscious about this behavior and avoid doing it. But, we are all humans and it will be better to have a safeguard.

So, what I propose is for you to come to me both with a problem and a suggestion as to how we can solve it. This will keep me from offering an answer right away and, most importantly, it will help you grow as an engineer. Forcing yourself to think about a suggestion or to reflect upon the approaches you’ve taken will make you understand the problem and its domain better. That alone will benefit our discussion or, even better, might lead you in a solution without any help!

Let me be a feedback loop for you

(this post was written with the intent to give it to my current, and future, direct reports in an attempt to establish part of our relationship)

Every time we need to solve a problem (or implement a feature) the process is the same

First we think the approach we are going to follow. This is an abstract flow that we believe will solve the problem.
Based on that we divide our approach to one or more components (modules / classes / functions, whatever suits the size of the problem) and assign a certain behavior to each one of them.
Finally, we start implementing each component.

Feedback loop

How do we know if something we implemented is correct?

By getting feedback. Based on it we make improvements and try again. This loop keeps us on track and allows us to deliver something valuable.

This is why we try to have frequent and short feedback loops. This way any corrections occur sooner than later and we don’t spend time and effort into something that might, potentially, thrown away.

Tech lead as a feedback loop

Looking back to the process of solving a problem we could say that two out of the three steps do have a feedback loop to helps us.

In the implementation step we can argue that the compiler / linter / etc gives us immediate feedback on what we wrote. We fix it and move forward.

For the behavior step we get the feedback through tests. Is the component’s behavior the expected one? How about the components API? Can we use it easily in our tests? Answering these question helps in having solid components.

But what about the approach step? This is where the tech lead comes in.

Right before writing any code, thus putting effort into something, prepare a simple list with the steps you are about to take and discuss them with your tech lead. If there is any feedback use it to improve your approach and have another meeting.

Is it time consuming?
No. In case the approach needs improvement after the implementation the time to fix it will be longer.

Do you feel bad on spending your TL’s time?
Don’t. It is, literally, their job to help you.