|
|
|
|
|
|
by ChuckMcM
4021 days ago
|
|
|
I would echo the perfection/artist thing, I've known a lot of engineers and ones who are perceived as slow, are often also setting a really high bar for their code. The learning for those engineers is to develop an understanding of how good is necessary, and how good is ideal. If you find yourself rewriting your code a lot, consider using a technique that Pixar uses for making digital films which is they work on them on sections until they are "good enough" and they put that part aside with the label "Good enough, could use improvement", until they get everything in the can, now the film is completely "done" but all of the sections can use improvement. They order those sections from most impact to least and start working through them. At any point they could just print the film and ship it, but the longer they work the better it will get. Often there are other parts of the pipeline that have to be aligned and so they will get a chance to knock off a bunch of improvements before it actually ships. |
|
|
> If you find yourself rewriting your code a lot, consider using a technique that Pixar uses for making digital films which is they work on them on sections until they are "good enough"
This approach works for features where side-effects are isolated to a small part of the system (eg. UI changes). For anything major, it is worth doing right the first time. eg. A library on which other software is constructed. The mastery is in weighing up the scope and likelihood of rework that might be required in the future.