TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ask HN: Tracking Coding Friction Points?

3 点作者 batguano11 个月前
I work with a stack that’s pretty brittle, and in a constant state of flux. As such, I spend <i>most</i> of my time fixing broken compiles, chasing down problems that are red herrings (e.g., my branch suddenly has a test failing, but it turns out that’s totally unrelated to my changes), etc. I spend only a small fraction of my time on the actual “business logic” (aka “useful work”).<p>I would love to be able to track this stuff, so at the end-of-the-week standup I have a better idea where all my time went.<p>I’m looking for a good tool to help me do this. Here’s the most important features:<p>1) Voice dictation, so I can say things like, “I’m now rebasing and recompiling the whole codebase, because test X is now broken and I haven’t changed anything that should affect it.” Taking text notes wouldn’t be a deal-breaker, but voice dictation seems like it would work better.<p>2) The ability to ask for an AI-based weekly summary. e.g.,<p><pre><code> - You finished the AAA refactor and got that installed. - you spent a full day and a half on spinning your wheels on BBB because of the change to CCC - you paired with Alice to debug DDD - you helped Bob fix his problem with EEE - while working on FFF, you found a problem with GGG and preemptively fixed it </code></pre> I’m not a contractor working on multiple client projects, so this isn’t a <i>billing</i> thing. I just find at the end of the week, I’m disappointed in how much stuff got closed. I forget all the friction points and distractions that sucked up time—as well as lots of little wins!<p>Would appreciate hearing how others approach this problem.

1 comment

Jugurtha11 个月前
If you use version control platforms, you&#x27;re probably creating issues&#x2F;tickets and use tags. Use many, many tags. You can then have stats and notice where most of your effort goes.<p>For example, you can use tags like &quot;compatibility&quot;, &quot;dependency&quot;, etc... Basically, words that describe the red herrings and why you&#x27;re working on the codebase.