I think the biggest misconception behind the idea of "you should code outside of work hours, too!" is that the only way you can grow as a software developer is by coding.
That couldn't be further from the truth.
Coding is only one (actually rather small) aspect of being a software developer. The rest is planning, architecture, automation, and all the other things that go into building software besides the code itself. And you know what? You can learn a great deal of those skills doing just about everything else in the world besides coding - and you'll be better balanced (and therefore less likely to burn out) doing other things besides code all the time.
Consider this:
I have a garden, but I'm as "productively lazy" about gardening as I am about tech. That is, I will front-load my time to automate things and build a system that works for me, so I'm not stuck doing the mundane and tedious maintenance stuff all the time that, let's face it, I won't do. I despise doing things over and over when it can be automated.
So what do I do with my garden? I designed and built my garden in such a way that a great many things are "automated" -- and no, I'm not talking about Arduino-powered weeders or fancy watering systems with moisture detection or whatever. Hell, I don't even have soaker hoses.
What I do have, though, are:
A thick layer of mulch on top of a layer of cardboard, which will keep weeds at bay while desired plants establish and help condition the soil as this layer decays.
Perennials that are (ideally) native or naturalized to my area, so they thrive in the climate as it is and once established will grow and produce more of what they produce than I could ever use on my own, with very little input from me.
A layer of dense, low-growing plants that act as living mulch (water retention) and help crowd out the more aggressive weeds.
A layer of taller herbs that also crowd out more aggressive weeds.
Bushes that provide the "foundation" of each area and create shade to allow for other plants that don't do well in an "ultra sun" environment ("full sun" is considered 6 hours; my front yard gets as much as 12-15 hours in the peak of summer), which increases biodiversity and thus, the health of the soil and ecosystem.
Passive ways to handle water, such as the terra cotta pot buried in one of my shade gardens that tends to flood when it rains, but dries way out during the summer, making it difficult to get the right plants (most like only one or the other, not both). The porous pot catches some of the excess water and holds on to it for a while, then slowly releases it as the surrounding earth dries out, keeping the soil moist for longer, without flooding it. The system as a whole in this garden bed also helps stop erosion - a problem that spot had for several years, due to lack of plants.
What does all that have to do with software development? It exercises "systems thinking" -- thinking about a thing as a holistic system of interdependent and interrelated parts. I could have gone the typical suburban gardener route and planted a bunch of random plants or whatever, not really paying attention to what I got and put where, or whether it'd really work for the climate. Or I could have planted annuals (often things like the typical pansies and begonias and marigolds and petunias) that look really pretty, but generally need replaced throughout the summer and of course need replanted or seeded every year. But both of those cases require a lot of ongoing input on my part, whereas if I apply systems thinking and think about the whole thing, I can find ways to create a fantastic pollinator habitat and wonderful garden, without much of any ongoing work.
It also exercises solving problems without just jumping to some kind of tech. Sure the tech can probably solve the problem at hand, but is it the only way? Probably not. I can probably achieve the same (or even better) results by thinking about the problem a little differently.
Then there was the time I learned how to think differently about failure while I was weight lifting...
That's not say that you shouldn't code outside of work ever. If you're drawn to coding such that you're even contemplating this question, then odds are good you're a maker at heart. You're very likely driven to create something pretty much all of the time. That's perfectly fine and should be embraced (because that's really the healthiest thing for a maker), but it doesn't always have to be code (and probably shouldn't always be code).
Make code if you're enjoying doing so, but make other stuff, too, and balance it out with "consuming" (for lack of a better word). I don't mean "spend just as much time watching TV" or whatever, but rather, don't forget to spend time just taking things in and not creating. It could include watching TV or playing video games. Just like how you can't just go without sleep or how you need rest days in a workout routine, you need periods of rest from creating, too. Those periods of rest help you solve the problems you're tackling and give you some distance to allow other parts of your brain to chew on the problem or idea for a while. It's why our "ah ha!" moments often come in places like the shower.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think the biggest misconception behind the idea of "you should code outside of work hours, too!" is that the only way you can grow as a software developer is by coding.
That couldn't be further from the truth.
Coding is only one (actually rather small) aspect of being a software developer. The rest is planning, architecture, automation, and all the other things that go into building software besides the code itself. And you know what? You can learn a great deal of those skills doing just about everything else in the world besides coding - and you'll be better balanced (and therefore less likely to burn out) doing other things besides code all the time.
Consider this:
I have a garden, but I'm as "productively lazy" about gardening as I am about tech. That is, I will front-load my time to automate things and build a system that works for me, so I'm not stuck doing the mundane and tedious maintenance stuff all the time that, let's face it, I won't do. I despise doing things over and over when it can be automated.
So what do I do with my garden? I designed and built my garden in such a way that a great many things are "automated" -- and no, I'm not talking about Arduino-powered weeders or fancy watering systems with moisture detection or whatever. Hell, I don't even have soaker hoses.
What I do have, though, are:
A thick layer of mulch on top of a layer of cardboard, which will keep weeds at bay while desired plants establish and help condition the soil as this layer decays.
Perennials that are (ideally) native or naturalized to my area, so they thrive in the climate as it is and once established will grow and produce more of what they produce than I could ever use on my own, with very little input from me.
A layer of dense, low-growing plants that act as living mulch (water retention) and help crowd out the more aggressive weeds.
A layer of taller herbs that also crowd out more aggressive weeds.
Bushes that provide the "foundation" of each area and create shade to allow for other plants that don't do well in an "ultra sun" environment ("full sun" is considered 6 hours; my front yard gets as much as 12-15 hours in the peak of summer), which increases biodiversity and thus, the health of the soil and ecosystem.
Passive ways to handle water, such as the terra cotta pot buried in one of my shade gardens that tends to flood when it rains, but dries way out during the summer, making it difficult to get the right plants (most like only one or the other, not both). The porous pot catches some of the excess water and holds on to it for a while, then slowly releases it as the surrounding earth dries out, keeping the soil moist for longer, without flooding it. The system as a whole in this garden bed also helps stop erosion - a problem that spot had for several years, due to lack of plants.
What does all that have to do with software development? It exercises "systems thinking" -- thinking about a thing as a holistic system of interdependent and interrelated parts. I could have gone the typical suburban gardener route and planted a bunch of random plants or whatever, not really paying attention to what I got and put where, or whether it'd really work for the climate. Or I could have planted annuals (often things like the typical pansies and begonias and marigolds and petunias) that look really pretty, but generally need replaced throughout the summer and of course need replanted or seeded every year. But both of those cases require a lot of ongoing input on my part, whereas if I apply systems thinking and think about the whole thing, I can find ways to create a fantastic pollinator habitat and wonderful garden, without much of any ongoing work.
It also exercises solving problems without just jumping to some kind of tech. Sure the tech can probably solve the problem at hand, but is it the only way? Probably not. I can probably achieve the same (or even better) results by thinking about the problem a little differently.
Then there was the time I learned how to think differently about failure while I was weight lifting...
That's not say that you shouldn't code outside of work ever. If you're drawn to coding such that you're even contemplating this question, then odds are good you're a maker at heart. You're very likely driven to create something pretty much all of the time. That's perfectly fine and should be embraced (because that's really the healthiest thing for a maker), but it doesn't always have to be code (and probably shouldn't always be code).
Make code if you're enjoying doing so, but make other stuff, too, and balance it out with "consuming" (for lack of a better word). I don't mean "spend just as much time watching TV" or whatever, but rather, don't forget to spend time just taking things in and not creating. It could include watching TV or playing video games. Just like how you can't just go without sleep or how you need rest days in a workout routine, you need periods of rest from creating, too. Those periods of rest help you solve the problems you're tackling and give you some distance to allow other parts of your brain to chew on the problem or idea for a while. It's why our "ah ha!" moments often come in places like the shower.