HN user

dylandevelops

2 karma

I am a game developer, programmer, and student passionate about building scalable, creative, and innovative applications. With intimate knowledge of full-stack software development, project management, and game design, I build systems that allow users to see the world in a new way.

Portfolio: <https://dylanravel.com> GitHub: <https://github.com/dylandevelops>

Posts4
Comments5
View on HN
github.com 4mo ago

Show HN: tmpo – CLI time tracker with automatic project detection

dylandevelops
2pts2
github.com 5mo ago

Show HN: tmpo – Local-first CLI time tracker with automatic project detection

dylandevelops
2pts0
github.com 6mo ago

Show HN: tmpo – CLI time tracker with Git integration and local-first storage

dylandevelops
2pts0
github.com 7mo ago

Show HN: tmpo – Minimal CLI time tracker with auto-detection for developers

dylandevelops
1pts2
Claude Fable 5 1 month ago

I agree with you. The more I vibe code, the less interested I feel in what I'm building. Working with models that force me to think, especially with personal projects, helps me stay engaged and enjoy what I am doing more.

0ThreadHN
Claude Fable 5 1 month ago

I agree with you here. Unfortunately, this tends to be the case, with smaller developers paying the price.

0ThreadHN
Ask HN: What do you use to manage your coding projects? 7 months ago

Love using GitHub for managing everything. I can create issues of features and bugs and work through completing them in each pull request. I have also recently created my own tool called tmpo, which I use to log my time when working on projects that require billing. Trying to create my own custom tools to speed up my workflow as much as I can.

0ThreadHN
Show HN: tmpo – Minimal CLI time tracker with auto-detection for developers 7 months ago

Thank you!

I'm thrilled that the Unix-y approach resonates with you, as that is exactly what I am aiming for!

And yes, you have hit the main tradeoff that I have and am currently struggling with. The auto-detection works great for "I'm in X project, working on X," but it doesn't work well for the exact cases you mentioned.

Right now, this is how I handle these types of scenarios:

1. Context switches in the same repo: I use the description field to differentiate: `tmpo start "Refactoring auth module"` `tmpo start "Fixing CSS bugs"`

    This has the same project name but with different descriptions. When you export for invoicing or just personal statistics, you can see this breakdown.
2. "Non-directory work" (meetings, research, etc): I use `tmpo manual` to create entries after the fact. `tmpo manual` (opens interactive prompt for project/time/description)
    Or I just run `tmpo start "Team standup"` from wherever I am and let it tag to whatever directory I'm in. This is obviously a bit janky.
To be honest, I am still working on solving this problem. I optimized for what I think is most "solo dev working in project directories" because that is my workflow; however, I'd love to get more feedback and contributors to help make it work for others!

A feature I am also working on currently is a category/phase system that can significantly improve tagging time entries.

What is your current workflow? Do you switch contexts within the same repo often, or is the non-directory work the bigger pain point?

0ThreadHN