3 ms·

> Github shows what sort of tools are actually optimized for productivity, because when you are working on something for yourself in your spare time, you don't

> Github shows what sort of tools are actually optimized for productivity, because when you are working on something for yourself in your spare time, you don't have time to waste. It shows which tools are optimized for low bootstrap overhead. When working on something simple for yourself, expected productivity is governed by rather different aspects of your toolchain than when you're working on more complex projects that involve other programmers and even long-term maintenance.

jrockway 17y ago
All I can say is that 99% of personal projects I've worked on are much nicer in terms of test coverage, deployability, documentation, and maintainability than anything I've worked on with a large group of paid ("professional") developers. Like I said, developers working on their own projects optimize for productivity; documentation, test coverage, maintainable design, easy deployment, and so on all save time and make the project more enjoyable to work on. Personal projects have enormous time pressure on them; instead of "can I build this by the amorphous deadline in three months", it's "can I build this feature and still get a few hours of sleep before work tomorrow". That's a whole order of magnitude (or two!) different from paid software development. That harsh evolutionary pressure has brought out the best techniques, because these good techniques increase productivity by so much. In the corporate world, there is too much negative inertia and too little incentive to improve productivity, so people just do whatever, and "whatever" is not usually the best way to be productive. (Write some tests, and your coworker just breaks them the next time he wants to make a quick fix without thinking about design. Now there are two problems, and it ends up being easier to just not write the tests; it's better for the app to break in production so your manager allocates you a chunk of time to fix it. And so the cycle continues; the software getting buggier and buggier, until you need a team of 100 people just to keep it alive.) I will point out that not all corporate paid development is like this. My $work at a large company is very much like an open source project; there are shared libraries that everyone uses, and if you change them, you need to update the docs and make the tests pass. Your own stuff that nobody else uses; do what you want. It works very well. But of course, it's not Java or C++ :)

jrockway 17y ago

All I can say is that 99% of personal projects I've worked on are much nicer in terms of test coverage, deployability, documentation, and maintainability than anything I've worked on with a large group of paid ("professional") developers. Like I said, developers working on their own projects optimize for productivity; documentation, test coverage, maintainable design, easy deployment, and so on all save time and make the project more enjoyable to work on. Personal projects have enormous time pressure on them; instead of "can I build this by the amorphous deadline in three months", it's "can I build this feature and still get a few hours of sleep before work tomorrow". That's a whole order of magnitude (or two!) different from paid software development. That harsh evolutionary pressure has brought out the best techniques, because these good techniques increase productivity by so much. In the corporate world, there is too much negative inertia and too little incentive to improve productivity, so people just do whatever, and "whatever" is not usually the best way to be productive. (Write some tests, and your coworker just breaks them the next time he wants to make a quick fix without thinking about design. Now there are two problems, and it ends up being easier to just not write the tests; it's better for the app to break in production so your manager allocates you a chunk of time to fix it. And so the cycle continues; the software getting buggier and buggier, until you need a team of 100 people just to keep it alive.) I will point out that not all corporate paid development is like this. My $work at a large company is very much like an open source project; there are shared libraries that everyone uses, and if you change them, you need to update the docs and make the tests pass. Your own stuff that nobody else uses; do what you want. It works very well. But of course, it's not Java or C++ :)