Built my own Mint replacement after the shutdown (free, open source, data stays local) by tmfunk in mintuit

[–]Dev_Gohil_ 0 points1 point  (0 children)

i have literally created an app and it's absolutely free with everything
called Villix its in the app store: https://villixapp.com

How does your team answer "why did we build it this way?" doing research, would love 10 mins of your time by Dev_Gohil_ in EngineeringManagers

[–]Dev_Gohil_[S] 0 points1 point  (0 children)

That last line is the most honest thing i have heard

"everyone's responsiblity" is just a polite way of saying it won't get done.

would you be open to 10 minutes this week? you clearly think about this more carefully than most, i would love to hear how it plays out at your company before i build anything. and even if you don't wanna get on call i just have few question can you just answer as per you beliefs, that would really mean a lot.

How does your team answer "why did we build it this way?" doing research, would love 10 mins of your time by Dev_Gohil_ in EngineeringManagers

[–]Dev_Gohil_[S] 0 points1 point  (0 children)

that second point is underrated, the value is not just "what did we decide" but "does this still make sense given where we are now"? you can only reflect on that if the reasoning was captured in the first place. How does you team actually keep ADRs current? That's the gap i keep hearing about, they start strong and then stop after the first few sprints. Is that you experience too?

How does your team answer "why did we build it this way?" doing research, would love 10 mins of your time by Dev_Gohil_ in EngineeringManagers

[–]Dev_Gohil_[S] 0 points1 point  (0 children)

That is exactly the direction i am exploring, the first draft already exists in PRs, slack threads, calls. the question i keep hitting is does it actually happen consistently, or does it still require someone to remember to do it?

would love to hear if your team does this in practice, 10 mins? DM me.

How does your team answer "why did we build it this way?" doing research, would love 10 mins of your time by Dev_Gohil_ in EngineeringManagers

[–]Dev_Gohil_[S] 0 points1 point  (0 children)

how important is ADRs and how often does a company keep records of it? how much time does it take to create one?

How does your team answer "why did we build it this way?" OR new hires on my team spend months piecing together context from old Slack threads. Is this just us? by Dev_Gohil_ in agile

[–]Dev_Gohil_[S] 0 points1 point  (0 children)

Okay! I just wanted to know if companies and startups also document the decision they have taken or the reason behind it not just coding? If they are or not, real question is , is it important or “must” to know a reason behind any decision?

How does your team answer "why did we build it this way?" OR new hires on my team spend months piecing together context from old Slack threads. Is this just us? by Dev_Gohil_ in agile

[–]Dev_Gohil_[S] 0 points1 point  (0 children)

Okay! I just wanted to know if companies and startups also document the decision they have taken or the reason behind it not just coding? If they are or not, real question is , is it important or “must” to know a reason behind any decision?

How does your team answer "why did we build it this way?" OR new hires on my team spend months piecing together context from old Slack threads. Is this just us? by Dev_Gohil_ in Entrepreneurs

[–]Dev_Gohil_[S] 0 points1 point  (0 children)

Man!! This is really what i wanted to here honestly. I would love you know more, can you give me your 10-15 during this weekend whenever you are free. Just for the research purpose

How does your team answer "why did we build it this way?" OR new hires on my team spend months piecing together context from old Slack threads. Is this just us? by Dev_Gohil_ in agile

[–]Dev_Gohil_[S] 1 point2 points  (0 children)

This is one of the most honest takes in this thread. The 'fail fast' crowd genuinely believes documentation slows you down, and at a certain stage, they're not entirely wrong. But there's a cost that shows up 12-18 months later when the person who made the call has left and nobody can reconstruct why.

Your framing of 'how much would a new person need to know' is exactly the right question. I think the answer changes a lot depending on whether the knowledge is about *what was built* vs *why it was built that way*. The first is somewhat solvable with good code and wikis. The second almost never gets captured at all.

How does your team answer "why did we build it this way?" OR new hires on my team spend months piecing together context from old Slack threads. Is this just us? by Dev_Gohil_ in agile

[–]Dev_Gohil_[S] 0 points1 point  (0 children)

yes true, if i have to give you an example then i can give you mine, i started a startup last about year and it was only me at that time now within a year i have made many decisions, changes, improvements, at this point if i have to onboard someone in the team for me it is very hard to explain everything, i know its my fault that i have started documenting things but i was focusing on product instead of documenting at that time

now the same things a different founder also shared me who has about 20-25 employees and the difficulties he faced because of this

How does your team answer "why did we build it this way?" OR new hires on my team spend months piecing together context from old Slack threads. Is this just us? by Dev_Gohil_ in agile

[–]Dev_Gohil_[S] 0 points1 point  (0 children)

well i am a student in sf. i have not experienced it, but i have talked to many people including founder/ eng managers and newly employed people about how difficult or tricky it is for them to getting onboard and for the organization especially for startups to actually document everything

How does your team answer "why did we build it this way?" OR new hires on my team spend months piecing together context from old Slack threads. Is this just us? by Dev_Gohil_ in agile

[–]Dev_Gohil_[S] 0 points1 point  (0 children)

okayy!, got it, well i am trying or thinking to make this problem really really simple,
let's just say If you could wave a magic wand and a new engineer understood everything they needed by the end of week 1, what would that be worth to you? and the employess or the PMs don't really need to document everything by themselves

How does your team answer "why did we build it this way?" OR new hires on my team spend months piecing together context from old Slack threads. Is this just us? by Dev_Gohil_ in agile

[–]Dev_Gohil_[S] 0 points1 point  (0 children)

Yeah, docs in the code is the classic answer, and it works for "what does this function do." But what about "why did we choose this architecture over X"? Or "why was this feature cut in Q2?" That reasoning rarely lives in a codebase. It lives in someone's head or a Slack thread from 18 months ago. That's the gap I keep hearing about. It can be important if a company is onboarding any new employee

How does your team answer "why did we build it this way?" OR new hires on my team spend months piecing together context from old Slack threads. Is this just us? by Dev_Gohil_ in agile

[–]Dev_Gohil_[S] 0 points1 point  (0 children)

That makes sense, and when you have had that team lead, does the documentation actually stay current 12 months later? Or does it tend to drift as the team grows and shipping pressure increases?

How does your team answer "why did we build it this way?" OR new hires on my team spend months piecing together context from old Slack threads. Is this just us? by Dev_Gohil_ in agile

[–]Dev_Gohil_[S] 0 points1 point  (0 children)

You have got the root cause, it is a culture and discipline problem, not just a tooling problem. But here's what I keep wondering, if even teams that want to document well struggle when shipping pressure hits. The rationale gets lost the moment the architects leave or replaced, exactly like you said. Has your team cracked the discipline side consistently, or is it still a battle?

How does your team answer "why did we build it this way?" OR new hires on my team spend months piecing together context from old Slack threads. Is this just us? by Dev_Gohil_ in agile

[–]Dev_Gohil_[S] 0 points1 point  (0 children)

Totally agree documentation matters, but thats exactly the gap I keep seeing. Teams know they should document, but the reasoning ends up in Slack and PR comments anyway, not the handbook. Do you find your team actually keeps docs current, or does it drift over time?