3 ms·

Works only if the work is frontend though. With backend work, there’s usually not a lot to show unless you specifically optimize for making a demonstratable pro

Works only if the work is frontend though. With backend work, there’s usually not a lot to show unless you specifically optimize for making a demonstratable prototype a specific deliverable, which to me seems like just a distraction and missing the overall goal.

tomcat27 6y ago
Absolutely!
capableweb 6y ago
Why? If you're backend, show that things are working in the backend, not much different than frontend work. Or show your design work. Or video editing progress, or anything. If there is _no_ progress but in your head, at least what you can do is write it down. Then you end up with a document. Demo your document. And yeah, if it's missing the overall goal, then it's clear halfway through that we're missing the goal, so you can correct earlier.
eatonphil 6y ago
I see this argument a lot from folks who never worked in the frontend. Having worked in both it's much clearer there are always ways you can demo changes in a backend. You can show new docs made available or before/after performance numbers of simply just describe what would now be possible for clients. No matter what you work on there _has_ to be a way to show the impact you had unless you had no impact.
darrylb42 6y ago
Lots of ways to demo a backend. Are you doing REST? Postman to show the API functioning. Have tests, show the test suite. The person writing the backend needs some way to drive it to test their own work this should be demonstrable to a technical audience.
Smaug123 6y ago
I agree with the siblings that this isn't true. I've recently finished a big refactor of something entirely back-end with almost no user-visible changes at all (except ahem for a bug I wrote), and I could still present progress. The work was the migration of six or so different components: they used to conform to one API, and I moved them to a different API. I found a way to order the changes so that they could be done sequentially rather than big-bang. Bam: a clear progress marker. This kind of progress is pretty common, in my experience. I've already written about defunctionalising an algebra before (https://www.gresearch.co.uk/article/defunctionalisation/ https://www.gresearch.co.uk/article/defunctionalisation/), and that is another example of a task where the work can often divide itself into discrete chunks. You can show your progress to your team, all without the end-user being able to see anything.

tomcat27 6y ago

Absolutely!

capableweb 6y ago

Why? If you're backend, show that things are working in the backend, not much different than frontend work. Or show your design work. Or video editing progress, or anything. If there is _no_ progress but in your head, at least what you can do is write it down. Then you end up with a document. Demo your document. And yeah, if it's missing the overall goal, then it's clear halfway through that we're missing the goal, so you can correct earlier.

eatonphil 6y ago

I see this argument a lot from folks who never worked in the frontend. Having worked in both it's much clearer there are always ways you can demo changes in a backend. You can show new docs made available or before/after performance numbers of simply just describe what would now be possible for clients. No matter what you work on there _has_ to be a way to show the impact you had unless you had no impact.

darrylb42 6y ago

Lots of ways to demo a backend. Are you doing REST? Postman to show the API functioning. Have tests, show the test suite. The person writing the backend needs some way to drive it to test their own work this should be demonstrable to a technical audience.

Smaug123 6y ago

I agree with the siblings that this isn't true. I've recently finished a big refactor of something entirely back-end with almost no user-visible changes at all (except ahem for a bug I wrote), and I could still present progress. The work was the migration of six or so different components: they used to conform to one API, and I moved them to a different API. I found a way to order the changes so that they could be done sequentially rather than big-bang. Bam: a clear progress marker. This kind of progress is pretty common, in my experience. I've already written about defunctionalising an algebra before (https://www.gresearch.co.uk/article/defunctionalisation/ https://www.gresearch.co.uk/article/defunctionalisation/), and that is another example of a task where the work can often divide itself into discrete chunks. You can show your progress to your team, all without the end-user being able to see anything.