1. 42

  2. 18

    I completely agree. The more I end up doing at work the less I end up doing on my own time. I am confident in my abilities to build, to learn, to grow, and the company that employs me believes in growing its employees. I spent a bulk of my free time on other stuff like audio production, photography, cooking, etc. You become one dimensional as a human if you only do one thing, and that goes for anything - not just software development.

    1. 17

      The more I end up doing at work the less I end up doing on my own time.

      I have definitely found this to be true, in a way. When my work project is interesting and clearly defined, meaning I am able to make good progress and feel like I’ve actually “done” something, I tend to write a lot less code on my own time. So programming on my own time is kind of a creative release “valve” that gives me an outlet when work doesn’t.

      1. 5

        Sometimes I satisfy my compulsion to create when it isn’t being satisfied at work by cooking.

        1. 4

          So programming on my own time is kind of a creative release “valve” that gives me an outlet when work doesn’t.

          This is exactly how it works for me.

          And if you see that I’m writing an operating system that aim to replace the whole stack from dynamic linking to JavaScript-enabled browsers with simpler and more effective solutions, you might get an idea about my deep frustration with hyped mainstream technologies.

          Without Jehanne I could simply explode.

        2. 5

          I also agree. I’m not experienced as some people since I’m just a junior developer but I’ve tried forcing myself to code in my free time and it just didn’t work out for me personally, either I would get burnt out and lose interest, or just not do it right at all. Now I’ve found other hobbies that I enjoy and do them when I can, and I’ve found that coding in my free time came from sudden ideas, like recently I’ve been coding a Discord bot and it has been slow going, but it’s been far more enjoyable than forcing myself to code at any given time.

        3. 14

          Actually a lot of people I know in skilled labor tend to employ it in off hours for fun. The carpenters & electricians will remodel their houses, the chefs cook, etc. Really that’s neither here nor there though…

          There’s multiple dimensions here really. There’s a difference between not coding outside work because you’re not passionate about it and because you choose to prioritize time differently. There’s a difference between not coding outside of work as a universal rule, and only doing it sometimes or rarely.

          There’s a difference between passion for side projects and passion for work.

          There’s also many different ways to be “passionate” and not all of them are healthy.

          When it gets down to it I’m inclined to believe they both have benefits. The benefits of passion are intuitive I think, but a certain sense of detachment and practicality can be good too.

          That of course doesn’t get into other aspects of it like building up a portfolio or socializing, but I don’t think that’s really what people are wondering about with this. There are other ways to achieve those ends.

          1. 1

            I agree with your analysis.

            A side project, for an experienced developer, means a nightly journey.

            The balance between what he learn and how tired he is at work might not be easy to measure.

            Still, in the right environment an hacker do not need a side project.
            If he cannot see a problem, he will not feel the need to fix it.

          2. 9

            I know some devs who only code at work and are fine. But if there were two identical candidates (a myth, I know) except one had side projects, guess who I pick?

            1. 7

              I’m not sure it’d be an easy choice for me, though a lot depends on how you resolve that bit about the “identical candidates”. To really generalize, my interactions with people who have side projects are that they learn a bunch of stuff outside of work that could be useful for work, but often would prefer to be doing those side projects too, so might be less focused and/or prone to bikeshedding. I include myself in the 2nd category, fwiw: I learn a lot of things “on my own time” but I’m not necessarily the world’s best employee if you just want to hire someone to produce code.

              If you had people with identical starting technical skill, but one had side projects, my no-other-information guess might even be that the person without side projects would be a more productive employee initially. It’s also probably true that they’d be less likely to keep up to date and/or proactively recommend new things unless there was an explicit framework in place to make that happen on work time. But I’m not sure that’s obviously worse in terms of what a company is looking for out of an employee.

              1. 10

                If they have identical technical skill and only one has technical side projects, the other is obviously more talented, because they picked up identical technical skills without spending out-of-work time on it.

              2. 3

                The one that had hobbies that improved their ability to communicate and work in a team? Maybe even to give and receive constructive criticism, and to compromise?

                That can be satisfied by coding projects, sure. If they’re, for example, participating in an open source project by actively participating in the mailing list or forum, and managing tickets or incoming patches. A solo side-project is the opposite of this, though. Anything where the candidate is spending their time being the sole person making decisions and in control won’t help them with teamwork. If they’re not going through code and architecture reviews, there’s an excellent chance it won’t help them be better coders, either.

                On the other hand, board gaming, team sports, playing D&D, or any number of things will help candidates with the stuff that will make them really productive employees. The kind that isn’t just an additive part of your team, but a potential multiplicative part.

                1. 1

                  If they’re not going through code and architecture reviews, there’s an excellent chance it won’t help them be better coders, either.

                  I don’t think this is true at all. Sure, it is a whole lot easier to improve when you have an experienced mentor pointing out ways that you can do better. But there are plenty of ways to advance as a programmer without someone else coaching you. Reading quality books and source code written by programmers that are better than yourself is a great way to fill that gap; and arguably something you should be doing even if you have a mentor. At the end of the day programming is no different than any other skill, the key to improving is practicing purposefully, practicing routinely, and taking plenty of time to reflect on that practice. If you’re not willing to do those things you’re not going to be very good even if you have someone telling you how to improve.

                  1. 3

                    Sure. It’s even possible to improve all on your own, without books or mentors, as long as you’re consistently pushing yourself out of your comfort zone, consistently failing, and consistently reflecting on your experiences and what weaknesses are best addressed next.

                    But that’s remarkably hard. Solo projects are great at getting you more familiar with a language, or more familiar with some specific libraries, but they’re just not the right tool if you want to improve your craft.

                    If you want to learn how to play violin, then sure you can try buying one, trying to play, and never performing. Reading an introductory text might help a bit. But it’s going to be much faster and better to learn from someone who knows how to play the violin, to perform so you’re confronted with feedback from uninterested parties, and to go back to the drawing board and repeat the process. You can improve at chess by reading books, but if you’re not playing games your progress will be slow. If you’re only playing games against people of similar and lesser skill than you, you’re unlikely to learn much at all.

                    Having teammates or other people who are better than you, and who are willing to thoughtfully critique your work and suggest improvements, is the most tried-and-true method of improving your skill at something.

                    Failure and feedback are the best tools we have. And they’re usually not provided by solo projects.

                    1. 1

                      Oh yeah, it’s a million times harder to go at it alone. And I suppose any solo project that would provide a good platform for improving, like writing an open source framework/library or building a complex application that makes it into production and has users, will eventually become collaborative. Because once you have users you’ve got to write some sort of documentation for them and they’re going to be telling you about all the issues they run into and all of the improvements they want made.

              3. 9

                It’s fun to watch generational counter-balances like this occur. Yes, in the past there was an ethic of: “Real programmers program in their off-time to get better.” Now, we try to counter it, which is good, but it is better to encourage people to take responsibility.

                Figure out what your career goals are. Figure out what you need to know. If they don’t match, take some time to learn. Some employers will help you with this. Some won’t. Sometimes you want to learn something because you’re just curious. Sometimes you just want to move to a different employer. When you take responsibility, what you need to do is obvious. The worst outcome is to be upset when other people take the positions you want because you denied the possible effect of not making particular career investments.

                1. 3

                  Certainly, but there are costs to not working on one’s skills outside of work. All other things being equal, someone who spends 1,000 hours studying a topic will know it better than someone who spent 100, and less than someone who spent 10,000. If you choose to spend your time not-coding, then you need to accept that someone who decides to spend his time otherwise may be better at coding than you (while perhaps being a worse musician, artist, friend or human being).

                  One really key point is that as we progress in our careers, our non-technical skills become more important than our technical skills. It turns out that investing all of our free time in coding is probably not the best use our resources.

                  Regardless, choices have consequences.

                  1. 1

                    I believe not only focusing on what you do at work allows you to be innovative at it, while being able to improve with your constant practice at work and being divergent in your spare time. This is a key fundament on creativity. Do not expect the same every time.