3 ms·

It helped that I worked from a clear roadmap. After the first feature I was on a roll so I just keep chugging! It'd be rare to write this much on a single day

It helped that I worked from a clear roadmap. After the first feature I was on a roll so I just keep chugging! It'd be rare to write this much on a single day - after lunch I was exhausted. This codebase is on a mature stack - in particular, postgres and mature DB migration frameworks like alembic. I've learned through this process that as long as you get the data modeling basically right, everything else can be fixed as you proceed through testing your own work, from checking each little UI feature does what the code claims, all the way to end-to-end. Imagine you can do massive refactors just by asking the model a few questions, what does that unlock?

bluefirebrand 2y ago
> I've learned through this process that as long as you get the data modeling basically right, everything else can be fixed up as you proceed through "basically right" is not the same as "actually right" > Imagine you can do massive refactors just by asking the model a few questions, what does that unlock? It unlocks the ability to take an established codebase that is presumably well understood by the people who wrote it and turn it instantly into a completely new codebase that no one understands and is basically impossible to work on You sound like a junior developer who still thinks that the job is writing lines of code
- cadamsdotcom 2y ago
  First let me tip my hat and thank you for engaging on this. I think though that we're talking past each other which isn't my goal. So I'll try to explain a little clearer. The concerns you raise are valid. The process in my example is more rushed than I'd go through in a team context. This is a relatively immature project I'm exploring solo, so the appropriate level of "process overhead" is different than in a team context. I didn't take the time to separate that from what I'd do in a team. In a team, there'd be upfront discussion to align on what's in the "roadmap" (ie. we'd write a spec), there'd be discussion as the work proceeds if tech-debt emerges and refactors are needed, there'd be CI, tests, coverage, and code review. A good team would own the code forever, so they'd be happy with any refactoring. When I said massive refactors I meant within the context of one PR. It's insanely freeing to be able to draw with crayons all over your codebase, see what works, and then either `git reset --hard` or refactor it into shape. If a refactor of existing code is needed, that's its own PR. In summary, almost nothing changes at the level of team process. Keep all those guardrails - but use these tools to 1000x the amount of typing & exploration you can do!

bluefirebrand 2y ago

> I've learned through this process that as long as you get the data modeling basically right, everything else can be fixed up as you proceed through "basically right" is not the same as "actually right" > Imagine you can do massive refactors just by asking the model a few questions, what does that unlock? It unlocks the ability to take an established codebase that is presumably well understood by the people who wrote it and turn it instantly into a completely new codebase that no one understands and is basically impossible to work on You sound like a junior developer who still thinks that the job is writing lines of code

cadamsdotcom 2y ago
First let me tip my hat and thank you for engaging on this. I think though that we're talking past each other which isn't my goal. So I'll try to explain a little clearer. The concerns you raise are valid. The process in my example is more rushed than I'd go through in a team context. This is a relatively immature project I'm exploring solo, so the appropriate level of "process overhead" is different than in a team context. I didn't take the time to separate that from what I'd do in a team. In a team, there'd be upfront discussion to align on what's in the "roadmap" (ie. we'd write a spec), there'd be discussion as the work proceeds if tech-debt emerges and refactors are needed, there'd be CI, tests, coverage, and code review. A good team would own the code forever, so they'd be happy with any refactoring. When I said massive refactors I meant within the context of one PR. It's insanely freeing to be able to draw with crayons all over your codebase, see what works, and then either `git reset --hard` or refactor it into shape. If a refactor of existing code is needed, that's its own PR. In summary, almost nothing changes at the level of team process. Keep all those guardrails - but use these tools to 1000x the amount of typing & exploration you can do!