I hear senior developers saying I shouldn't do it because I will get burned out, I hear not so experienced ones saying we should use every moment we have to write another line of code. Some even look down on you and think you're not passionate/ serious enough about your job, just because you don't breath code 24/7.
While I do do work related things after clocking out (and I'm not opposed to that, since I don't have a great deal of experience and there are many things to learn), I can't help thinking about that people working in other fields are not really expected to take their work home with them - I don't see my friend who's a nurse going around and giving shots to her neighbors, after her working hours are done.
What's you opinion on this? Is the amount of time spent coding outside office hours an indicator of how good/ passionate of a developer you are?
Photo soource: Kevin Ku on Pexels
Latest comments (87)
In my opinion, passion and curiosity are the most important factors in growth, but recovery is also an important factor. Your mind solves problems and then recovers so that the next day, it should learn. That doesn't mean that they don't have passion; it means they prefer more productivity and quality time with full passion and curiosity to learn. Not for any job, only for her curiosity and hunger to learn, explore and build.
I think we shouldn't but we can for example read some articles or expand knowledge in other way. Writing a code is not the most important thing of coding :) Example with the nurse is not really a good one. Nurses often have to learn after their working hours or read news in their professional field to be up to date.
Time just for yourself is as important as time spend on learning or working. Good rest means good efficiency.
But that's just my opinion :)
Personally, I love coding and I find it as both a hobby and as a job. When I'm bored, I long for my PC and the editor and the pretty Linux terminal.
For others they'd probably view it as a job, something do be done with all seriousness without adding a bit of fun in it.
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.
I have occasionally worked on personal programming projects outside of work, but like others have said, only if it's something I find fun or engaging.
I think a good question to ask is why are so many employers not providing time for their employees' professional development? I'm fortunate enough to work for an employer who encourages some professional development on the clock, and I think this should be the norm, even though I know it's sadly pretty far from the current state of things.
As many have already said it is different for different people. Some people I know take part in coding challenges outside work while others do not. I think passion has nothing to do with the number of hours spent doing something but rather with how you talk about what you do and the amount of care you put into your work. I personally put a lot of care and attention into my work and will happily talk for hours about code and developer stuff but I have many other interests in life that I am also passionate about.
Having always some side project going on in the background totally changed my career, you don't realize but if you work at least 1 hour per day on something that it's not your job related then come up with amazing projects. I learned a lot, sometimes more than I do at work and about technologies that maybe I wouldn't use if I wasn't aware of them before. All those side projects I mentioned before ended up as open-source projects which I'm quite happy about!
I just recently talked about this in a podcast episode. Current dev culture tends to gravitate towards this "code is life" dogma, but the truth is it all depends on your seniority, your priorities and ambitions, your social circle, your current job, among a thousand of other things. The "Code is life" mantra is rather dangerous especially for junior developers who are getting into the industry and will think that's the standard for all devs, eventually leading a big part to a major burnout.
I was coding non-stop from 2013 to 2017 and I got burnt out so badly that I didn't want to know of anything tech-related for an entire year. After some time I was able to find other hobbies and was able to balance my work-life balance a bit better which led me to feel enthusiastic about front-end development again. Heck, I was even tinkering with new libraries and frameworks just for fun!
My personal opinion is that if you have the time, the discipline and/or the need to code outside of work, do it. Are you passionate enough that you crave to type lines of code after work hours? Then do it. But if you're doing it just because of culture/peer pressure, keep in mind you can always learn or be up-to-date by taking 30 minutes or 1 hour a day.
Knowing that your family/partner is a priority won't make you a crappy developer. Satisfying your need to explore a new activity outside of work, or your need to just relax and watch some crappy Netflix show, won't make you a crappy developer. You're already putting 8 hours a day, 5 days a week, into improving your craft, that's more than enough.
I think it's more a matter of balance. Coding "non-stop" can be a bad habit, coding only at work can be a bit unsastifying... I like to try a lot of stuff my work does not allow me to do... New frameworks, new languages, new plateforms, or old ones I've never tried... Other kind of development : I'm a web developer and I like that, but I'd also like to create games, electronic stuff with arduino or phone applications etc.
Having other hobbies is really important, of course ! But if you like coding, why not having this as a hobby ?
Note : I'm responding without having read all the answers, I'm confident I'm not the only one who's thinking like that ;)
"I don't see my friend who's a nurse going around and giving shots to her neighbors, after her working hours are done."
No.. but you DO see her studying her butt of constantly to keep up with medical procedures, new implementations, and newly discovered medications/side effects. I know because I live with a nurse :-)
If you aren't learning at your day job, you need to keep studying outside of working hours to keep up - that's the nature of this business. Don't burn out, but do a little bit to keep learning new things ;-)