Is it getting context from the code, reading through docs, writing tests, updating old tests, or even writing new docs?
A few things I’m curious about:
Where do you feel the most time gets wasted in your dev workflow?
What do you wish your IDE or tooling understood better?
What’s the silent productivity killer nobody talks about?
What have you tried to fix — and what’s actually worked?
Would love to hear from folks across roles and stacks. Honest, unfiltered answers are appreciated.
Thanks, Raoul
diggan•9mo ago
"Wasted", specifically? Probably libraries/frameworks changing APIs with zero regard for backwards compatibility instead of caring for their user's time.
> What do you wish your IDE or tooling understood better?
That I could edit any code like you edit Clojure/Lisp code, where you move/modify forms rather than text.
> What’s the silent productivity killer nobody talks about?
Not caring up the design/architecture up front, and how moving slower actually enables you to move faster.
> What have you tried to fix — and what’s actually worked?
Thinking more about design and data structures, setup automated tests for more things, being more intentional with everything, not rushing, spend time shortening the feedback cycle. All improved my overall productivity and made me move faster, not slower.
raoulscalise•9mo ago
Can you give an example of the latest library or framework that changed?
The part where you mentioned editing code like you edit Clojure/Lisp, moving/ modifying forms rather than text — I don't fully understand, but it sounds super interesting.
Can you point to some specific examples of design patterns and data structures? And regarding the tests — are you talking about unit tests, integration tests, or E2E tests? Also, don't you think setting up tests takes a lot of time? Do you feel it provides a net gain in productivity?
Thanks a lot
diggan•9mo ago
I guess the most famous example of this sort of API churn is react-router which completely changes how it works internally and externally every major version, rather than keeping the APIs the same but changing internally. I stopped using it myself after the second or third version where everything changed. Most mainstream libraries/frameworks has this sort of churn, just differs what level of churn they introduce each version.
> The part where you mentioned editing code like you edit Clojure/Lisp, moving/ modifying forms rather than text — I don't fully understand, but it sounds super interesting.
It's called "Structural Editing" (or similar). Some references:
- https://clojure.org/guides/structural_editing
- https://www.editorworld.com/article/What-is-Structural-Editi...
- https://en.wikipedia.org/wiki/Structure_editor
> Can you point to some specific examples of design patterns and data structures?
Not really, depends on the problem you're trying to solve. I guess where I see others and myself getting bogged down, is when you've chosen the wrong data structure for a job, and everything after that becomes harder. Usually re-evaluating what data structure you use (a list instead of a map, or vice-versa) can make the usages a lot easier.
> are you talking about unit tests, integration tests, or E2E tests?
Yes :)
> Also, don't you think setting up tests takes a lot of time?
It does take time, yes. But usually you spend even more time manually verifying that you didn't break anything and that it works correctly. And if that manual verifying takes 5 minutes each time you want to do it, you do it less often, so it's more likely something broke and you didn't even notice. So by spending 30 minutes setting up proper tests, you can save N*5minutes, depending on how often you run those tests and how much of a hassle it is to manually test.
> Do you feel it provides a net gain in productivity?
Most of the time, yeah. Sometimes you test too little, so you spend too much time manually testing. Other times, writing the tests themselves take longer than the time you'd recover to simply test it manually.
Like all things in programming, I think it's about balances and "doing enough", not dogmatically just follow whatever is trendy. If something feels stupid, it probably is.