←back to thread

Ask HN: What are you working on (August 2024)?

634 points david927 | 3 comments | 24 Aug 24 22:00 UTC | HN request time: 0s | source

What are you working on? Any new ideas that you're thinking about?
Show context
peterldowns ◴[24 Aug 24 23:34 UTC] No.41342829[source]▶
I'm working on Devlog — https://dev.log.xyz — software that I hope will help teams work better by making it more obvious who is doing what. It should help answer questions like "what did Sarah do last week?" or "who worked on frontend performance in the last year?" It's very much in alpha-stage, more a tech demo than a product, and I'm not sure if it will actually succeed. My cofounder just bailed on me but I'm going to keep trying to make it happen. Dogfooding it has made me a better engineer — I write better and clearer PRs — and as a former Senior Engineering Manager, I know it would save me time if I were still managing a larger team. But the setup is onerous (you have to connect your Github so it can analyze your PRs) and the value prop is more vitamin than painkiller unless your team is somewhat disfunctional, and no one likes to admit their team is disfunctional.

Happy to talk more about this with anyone. If you're at all interested in "software to make your team run better" I'd really love to hear what you're having trouble with and how your team runs, maybe I can figure out a way to help you, even if it's not at all related to what I've built already.

replies(1): >>41342971 #
cdfuller ◴[24 Aug 24 23:55 UTC] No.41342971[source]▶
Does it only work on PRs, or does it look at git history as well? Do you have plans to expand the knowledge it has access to?
replies(1): >>41343000 #
peterldowns ◴[25 Aug 24 00:00 UTC] No.41343000[source]▶
Right now it only looks at Github PRs, particularly the descriptions and titles (although I'm also experimenting with the code diff itself), for these reasons:

- Most teams that I'd sell to use Github PRs to write code.

- Looking at PRs, the "common unit of change" of most teams, lets Devlog work for teams regardless of how they end up merging in changes (merge commits vs squash vs rebase... doesn't matter because the PR is what is reviewed and submitted)

- I believe that part of being a great engineer is learning how to describe (a) what your code does, (b) why you're making the change, and the PR title+description is where we as an industry expect you to communicate this information.

- A commit history filled with great PR titles+descriptions is extremely valuable for your team and only becomes more valuable over time, so building tools that analyze this and incentivize you to do a better job of writing good titles+descriptions is good for your whole team.

I'm extremely open to looking at different sources of information (Linear/Jira/Github tickets; the diff itself; ???) if it improves the product. What were you thinking it should look at?

replies(1): >>41343547 #
1. cdfuller ◴[25 Aug 24 01:31 UTC] No.41343547{3}[source]▶
From my perspective as a dev, the question I find myself always asking is "Who's the SME that can I ask about this code that still works here?" So for me the benefit of your project would be using it basically as an intelligent git blame that says who's done what to a particular line/file/module/project, and why. If that SME isn't available anymore, I'd like your tool to help me build context around the issue I'm working on. I'd want to see at least git commit message history and authors included in the available knowledge. If the repo has docs included, even better.

Another reason I would want git history included is because I think it would make your product more valuable quicker. I see your tool as a way to improve the dev culture by promoting the points you mentioned, but it's not clear how long it takes it to start to pay off and be able to answer some of the more historical questions you've suggested. I question, if my team had poor/nonexistent PRs in the past, when would I be able to get any use out of it, and would there always be blindspots around code that didn't have a good PR.

replies(1): >>41343718 #
2. peterldowns ◴[25 Aug 24 02:06 UTC] No.41343718[source]▶
Thank you for taking the time to give me this feedback, really appreciate it. I think Devlog has the information needed to help answer these questions, but right now it doesn't do a particularly good job of making that easy.

> I question, if my team had poor/nonexistent PRs in the past, when would I be able to get any use out of it, and would there always be blindspots around code that didn't have a good PR.

This is a great question and the answer is that with poor/nonexistent PRs and documentation, Devlog cannot help you other than by incentivizing you to do a better job so that it can be useful — so not that helpful. I'd love to find a way to make it better in this kind of "cold start" case, that's part of why I appreciate your feedback about other potential uses. Thank you again.

replies(1): >>41344273 #
3. cdfuller ◴[25 Aug 24 04:01 UTC] No.41344273[source]▶
My pleasure! I've got a few more thoughts that came up.

It would be nice to know more about how I would interface with your product. It's not clear if it's a daily report, if it's a text box where I ask "What did Intern #3 work on last week?", if it's a chronological page, or something else.

Do different people get different answers? Would a CEO get a different answer than an engineer if they asked what the devops team worked on? Basically do you offer different levels of granularity for different user profiles.

Love the project and looking forward to watching it grow!