This is an open-source project. Link to the source code: https://github.com/avikalpg/typing-analyst

Wow, this is a very well-written article. I have experienced a lot of this in my own experience as a software developer.

This makes me wonder, the concept of pair programming has been around for a very long time. And yet, pull requests have grown in popularity while the use of pair programming remains pretty limited.

Does that mean that companies want to operate like a bunch of individuals instead of a team? Is independence valued more than speed & collaboration when it comes to software development teams?

Pairing doesn't replace code review because the reviewer needs to see the finished branch with fresh eyes, unbiased by discussion and false starts, to know whether it's safe and clearly explained in writing for every oncall in the future.

(I also need peace and quiet to think.)

I have heard the same as well. These days, I am thinking about how AI code gen can be affecting this. When AI is writing code, you can't assume yourself to be the pair programmer, because your speed is not even close to the AI's. You are basically reviewing the code that AI has written.

So should people be thinking about pair-reviewing AI code so that they get the benefits of pair programming along with the speed of AI?

In the "Knowledge Sharing" section of the article, the author says that "Distributed Practice" is one of the most effective ways to learn, and yet says that code reviews are not effective ways of knowledge sharing.

Isn't a code review EXACTLY a distributed practice? What am I missing?

And then he goes on to say "underlining and summarization while reading are least effective" -- I don't understand how is that even related to reviewing code.

If 42% of the comments on a pull request are related to increasing the understandability of the code, can we assume that just understanding the proposed code changes consumes the majority of the time spent on reviewing a pull request?

I found this article today and thought it was very interesting.

Wow, this looks very interesting. I saw the diagram of your own application and it looks more dynamic than the ones that I am generally used to at work.

I am curious about the motivation behind this project. What experiences triggered you to think that static diagrams are a problem?

Your answer will help me decide whether I'd like to use it for my own documentation or not.

Thank you for your comment!

I decided to work on gg because I want my colleagues to grok our complex software architecture, and I don't feel like I am able to achieve that with textual documentation + static diagrams alone.

I have been in a lot of brainstorming sessions drawing boxes and arrows on a whiteboard. I have produced a lot of diagrams with mermaid, draw.io, miro, etc. I produced a lot of documentation to explain how the software is built. Those are all good tools to get everyone on the same page, and yet, I feel like there is a missing piece of the puzzle to explain a software architecture simply and concisely that even the new junior developer recruit will understand.

It is good that you are already thinking about it. My wife and I have separate bank accounts but we operate as a single entity.

We are both completely aware of each other's incomes and expenses (we maintain a common expense manager).

When we got married, there was an immense difference in our incomes (I earned 10x more than her), so we decided that I would bear all the expenses and she could save her income for her future business plans.

Since I left my job to focus full-time on my startup last year, our incomes have been almost equal. Now, I pay the rent and the bills, and she handles all other expenses (groceries, appliances, travel plans, gifting and other purchases).

We transfer money to each other's accounts whenever there is a need (it's mostly from her to mine). Transparency is the key to happiness here.

Piano (keyboard) and Guitar. (Western classical training + pop songs)

I have also learned an Indian keyboard instrument called Harmonium. (Hindustani classical training)

And I love trying out new instruments :)

I am a bit confused about your stage as a product.

When you say "get people to try out your product", I feel that you are building a new product and looking for early feedback - your first design partner.

But then you say "offer long-term deals or any rewards" and "learn GTM for software products", which makes me think that you are done with your pilots proven that your product solves the problem much better than all the other solutions out there.

These two questions are very different. The first one is about validating if the problem is big enough for the person you are talking to. The second one is about communication and growth.

Thanks for the comment. I don't have PMF yet. I have a couple of paid customers but that's all there is. I don't see new sign up or response from people when I reach out to them over email or LinkedIn. Hence the question around long-term deals or rewards.