3 ms·
Write everything (generally, new features) twice has turned out to be really good strategy for me, but it doesn't sit well with bizdev or project managers and t
by nkozyra 2y ago
Write everything (generally, new features) twice has turned out to be really good strategy for me, but it doesn't sit well with bizdev or project managers and tends to be perceived as unnecessary slowness.
But if you plow through a feature and get it "working," you'll do much of that work cleaning up the logic and refactoring through your first pass. What rewriting allows you to do is crystalize the logic flow you developed the first time and start cherry-picking in a more linear fashion to meet the blueprint. It also tends to reduce the urge (/ need) for larger scale refactorings later on.
- andsoitis 2y agoA project manager or bizdev person writes, rewrites, and rewrites again the document they produce do they not? Or do they write the perfect document at first go?
- stanac 2y agoWorst kind of jira ticket is just a link to a document that can be edited anytime. In that case I just replace the link with a new link pointing to the fixed version of the document and inform the author of the ticket/document about it.
- throwaway87483 2y agoDepending on what kind of document it is, I often resort to extracting its contents with pandoc by converting it into markdown, and then replacing the original description. Makes search work properly too.
- bdw5204 2y agoIf I'm writing something, I'm writing it once. That "prewriting" stuff they teach in schools just slows down the process and makes you overthink your choice of words. I take the same "1 take" approach with code with the idea being to write the best solution on the first try. Why waste time writing something bad just so you can fix it later? That doesn't make any sense. As I'm writing, I do go back and make changes as they pop into my head. But once I'm done writing it, I'm done unless I notice an obvious mistake after the fact.
- bckr 2y ago1. You don’t take any notes or make any bullet points? 2. > As I'm writing, I do go back and make changes as they pop into my head This contradicts the idea that you only write once. 3. You don’t get feedback on your first finished version and make changes?
- kccqzy 2y agoDon't think of the first iteration as "prewriting" and instead think of the subsequent iteration as "editing."
- dclowd9901 2y agoHow would they know? Are they monitoring your code writing?
- actionfromafar 2y agoDepending on how the dev environment is setup, yes. Maybe you need something to go through a CI/CD pipeline. If you can't test it on your local machine, it can easily be visible to many people.
- lylejantzi3rd 2y ago> it doesn't sit well with bizdev or project managers To be fair, it makes everything twice as expensive. Managers are always going to reflexively push back against that, even if the new feature covers that cost and more.
- edflsafoiewq 2y agoThe second time doesn't cost as much as the first.
- jrvarela56 2y agoAnd the first is cheaper than a ‘regular single version’ bc you build it with the thought that you will throw it away.
- nkozyra 2y agoYou throw it away but in truth much of it survives in a much better design.
- richk449 2y ago> To be fair, it makes everything twice as expensive. The article argues it makes it less expensive to reach any specific quality level (above some threshold). The threshold isn’t really addressed in the article, but it is implied that for any realistic quality need, the write twice approach will be cheaper. To conclude it makes everything twice as expensive, you have to ignore any cost except the initial write. That’s not realistic.
- ozim 2y agoWhat hits hard is realizing that most features are not worth it. They just shouldn’t be developed. Unfortunately biznes wants features and more of them and if possible for free.
- kmoser 2y agoI find half my job as a developer is writing code, and the other half is advising clients on which features not to implement.
- pjbster 2y ago> Write everything (generally, new features) twice has turned out to be really good strategy for me, but it doesn't sit well with bizdev or project managers and tends to be perceived as unnecessary slowness. Silo-isation compounds this. If the maintenance costs are borne by another team or if any rework will be funded out of a different project, the managers are not going to care about quality beyond the basic "signed off by uat".
- eschneider 2y agoI spent some time doing consulting with an engineering manager who would keep requesting different (correct) implementations of the same functionality until had seen enough and then he'd pick one. This did lead to some high quality software for what needed to be a high reliability product. I should probably mention that I was doing consulting engineering here because no employees work work for the guy...