I pride myself on being a bloody good maintenance programmer, except that that isn't quite the right term. I do write fair-sized things from scratch from time to time, but I'm much better at - and much prefer - taking an existing project and finishing it. I suppose that's why I got into the Linux distribution business, which is fundamentally about taking upstream code and finishing it (or that horrible word, "productising").
It also depends on what you count as "from scratch". After all, most software projects aren't standalone - if nothing else they depend on the OS unless they *are* an OS, and they often depend on piles of library code as well. The biggest project I've led was probably the Perl extensions to the Zeus web server, which was about 10K lines of C++ and XS (you may vomit now) but was still an extension to an existing program, albeit an extension that required its own ground-up design work and had a couple of "oh shit, it's all horribly wrong, rewrite" moments in its development. I don't know if that counts.
My current project at work involves a program that other people wrote sort of to our specifications, except that it didn't really follow our specifications at all under the hood and had some embedded awfulnesses, so I've had to gradually rewrite large bits of it until it no longer really resembles the original program and is now more or less what we originally designed. This is a rather curious approach to the "write a big program" task in that you get something mostly functional at each step along the way as you gradually morph it into what you intended it to be all along. I'm not sure I'd recommend it because it does tend to lead to a lot of accumulated cruft unless you're very disciplined.
When I get the chance to do so, my method usually involves sketching out enough top-level code that I can see the structure, and then dropping down to the bottom layer and writing library code until bits of the structure start to work.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
It also depends on what you count as "from scratch". After all, most software projects aren't standalone - if nothing else they depend on the OS unless they *are* an OS, and they often depend on piles of library code as well. The biggest project I've led was probably the Perl extensions to the Zeus web server, which was about 10K lines of C++ and XS (you may vomit now) but was still an extension to an existing program, albeit an extension that required its own ground-up design work and had a couple of "oh shit, it's all horribly wrong, rewrite" moments in its development. I don't know if that counts.
My current project at work involves a program that other people wrote sort of to our specifications, except that it didn't really follow our specifications at all under the hood and had some embedded awfulnesses, so I've had to gradually rewrite large bits of it until it no longer really resembles the original program and is now more or less what we originally designed. This is a rather curious approach to the "write a big program" task in that you get something mostly functional at each step along the way as you gradually morph it into what you intended it to be all along. I'm not sure I'd recommend it because it does tend to lead to a lot of accumulated cruft unless you're very disciplined.
When I get the chance to do so, my method usually involves sketching out enough top-level code that I can see the structure, and then dropping down to the bottom layer and writing library code until bits of the structure start to work.