5 ms·

Exactly. When I see a coworker start irrationally focusing on a new technology at work the first thing I think is "This person probably has no side projects to

Exactly. When I see a coworker start irrationally focusing on a new technology at work the first thing I think is "This person probably has no side projects to play with"

deleted 9y ago
[deleted]
shados 9y ago
100% this. My side projects are absurdly over engineered and I get nothing done. But I learn what not to do when it matters.
- karrotwaltz 9y ago
  I recently built a C++ meta-programming monster for a side project. I want to make an article about that in the near future, and I am somewhat afraid that some people might think of reusing it in a real project. I had a lot of fun doing it, and indeed learnt to not do it in prod, the compiler errors are a nightmare to read and good luck maintaining that in the long run.
  - mindfulplay 9y ago
    That seems like a great side project. The one that let's you understand things NOT to do. At the same time, it helps engender basic traits like curiosity, try-until-you-fail-and-try-again, engineering skills etc. There are two types of side-projects though: one such as yours, where you try and understand a concept or engineer something just for the fun of it. And there is second one: a game that will mature into something; a hobby project that will actually develop into a company. I think it's good to disambiguate these two as the OP was more about the latter where you may never get to a point to see it run or build let alone flourish into something meaningful - as overengineering kills the fail fast fail often mentality and the project itself.
  - wellthen 9y ago
    My constant on-again/off-again side project is something similar but in C#. Spending a week building a preprocessor and then discarding it because I didn't need it was both infuriating and strangely pleasing at once. :)
  - jpfed 9y ago
    Maybe the real lesson here is that the last open task on your project is something that can present human-readable digests from parsing the compiler errors...
taeric 9y ago
To be fair, many of us have plenty of side projects that are just not computer related. Reality is those should also provide teaching opportunities. (Indeed, for many, teaching children is essentially a full time job in terms of time commitment.) Still, I completely agree with the point that "experiments" should be kept off the critical path as much as possible. It all depends where your risk/reward is, though. The people that took the risk on a stack and got rewarded with success are highly visible. Just as many took the risk and failed. (Probably more?)
markcerqueira 9y ago
> "This person probably has no side projects to play with" Exploring new technologies that could be beneficial (or harmful) to the company shouldn't be a side project. Perhaps we can shift the thinking from "this person doesn't have time for side projects" to "how can we make exploring new technologies a part of the job?"
- closed 9y ago
  Agreed. It seems like side projects for work are basically research (and research is important!).
- Raphmedia 9y ago
  Depends. Using a new stack for the company's blog is fine. Forcing a new technology into the middle of an existing project isn't.
  - CodeCube 9y ago
    It doesn't even have to be something "productive" ... what's being proposed here is that companies invest in literally having developers research new technologies, without expectations that said research will result in anything immediately profitable.
- WalterSear 9y ago
  How about making wednesday mornings, a 4hr 'personal project' time? Make it a requirement that everyone has to work with tools at the edge of their skillset, that is also relevant to work, but let them choose what, why, how. They could work on a personal project, or experiment with a new library or tool they would like to incorporate. Start the day with a "not really a standup", where people can quickly explain what they want to accomplish in the next four hours. Once a month, you spend a couple of hours of the time demoing the work you have done for each other, explaining the technology and what you have learned, and then discussing and evaluating our individual technical weaknesses and deciding what to do next. This rest of this monthly meeting could also be spent improving social coding skills - code and commit hygiene, team processes etc. Not only would this keep people technically sharp but it keeps them from playing with toys in production and breaks up the work week, while still fulfilling company goals.
patrickmclaren 9y ago
IMO, there's room for both approaches, perhaps with the exclusion of the most the irrational situations as you describe. It's unreasonable to expect engineers to bring battle-tested solutions to the table 100% of the time.
- Ainsley66 9y ago
  mÿ frïënd's stëp sïstër ġëts 77 ëvërÿ höür fröm hömë.. shë's bëën fïrëd fröm ä jöb för 2 mönths... läst mönth hër päÿċhëċk wäs 16993 jüst wörkïnġ ön thë ïntërnët ä fëw höürs ëvërÿ däÿ.. ċhëċk öüt thïs sïtë ====http://www.bosscyber.com http://www.bosscyber.com
devmunchies 9y ago
I have a side project where I'm using the new Crystal language and even wrote a post on my company blog about it but we don't actually use it, nor do I try to get us to use it.
FooHentai 9y ago
Now that's a good point - I've noticed a tendency to use side projects as a buffer for frustrations being experienced at work. Maybe there is a fundamental amount of true engineering I need to do on a weekly basis; if I'm not getting my fix at work it'll spill over to hobbies. Lately I'm pulling back from technical deep diving at work. A lot. My role as an enterprise architect (bleh, don't judge too much plz) means I necessarily have to shift to big picture guff and stop spending time on the details pieces. In short, I don't really get to engineer as much as before. Of course, I'm an engineer at heart so the idea of ignoring the details is anathema and it frustrates me. When I'm deep in whiteboards, board meetings and shitty powerpoint at work, the side projects and home lab become my release valve. It's a coping mechanism, I think. Likewise, when I'm sucked into low-level grind at work which happens from time to time, side projects stagnate. I don't need them for a while.
TeMPOraL 9y ago
Or they're bored out of their minds and trying to make their work not be so much of a waste of time. Most of the stuff I've seen done at typical development companies are intellectually interesting maybe to people who really started learning to code on the job, and generally don't have much experience. They're discovering new things every day, so it's fun! However, if someone has already few languages and various types of projects behind them, then the job becomes much less technically challenging and much more repetitive.

Exactly. When I see a coworker start irrationally focusing on a new technology at work the first thing I think is "This person probably has no side projects to play with"

deleted 9y ago

[deleted]

shados 9y ago

100% this. My side projects are absurdly over engineered and I get nothing done. But I learn what not to do when it matters.

karrotwaltz 9y ago
I recently built a C++ meta-programming monster for a side project. I want to make an article about that in the near future, and I am somewhat afraid that some people might think of reusing it in a real project. I had a lot of fun doing it, and indeed learnt to not do it in prod, the compiler errors are a nightmare to read and good luck maintaining that in the long run.
- mindfulplay 9y ago
  That seems like a great side project. The one that let's you understand things NOT to do. At the same time, it helps engender basic traits like curiosity, try-until-you-fail-and-try-again, engineering skills etc. There are two types of side-projects though: one such as yours, where you try and understand a concept or engineer something just for the fun of it. And there is second one: a game that will mature into something; a hobby project that will actually develop into a company. I think it's good to disambiguate these two as the OP was more about the latter where you may never get to a point to see it run or build let alone flourish into something meaningful - as overengineering kills the fail fast fail often mentality and the project itself.
- wellthen 9y ago
  My constant on-again/off-again side project is something similar but in C#. Spending a week building a preprocessor and then discarding it because I didn't need it was both infuriating and strangely pleasing at once. :)
- jpfed 9y ago
  Maybe the real lesson here is that the last open task on your project is something that can present human-readable digests from parsing the compiler errors...

taeric 9y ago

To be fair, many of us have plenty of side projects that are just not computer related. Reality is those should also provide teaching opportunities. (Indeed, for many, teaching children is essentially a full time job in terms of time commitment.) Still, I completely agree with the point that "experiments" should be kept off the critical path as much as possible. It all depends where your risk/reward is, though. The people that took the risk on a stack and got rewarded with success are highly visible. Just as many took the risk and failed. (Probably more?)

markcerqueira 9y ago

> "This person probably has no side projects to play with" Exploring new technologies that could be beneficial (or harmful) to the company shouldn't be a side project. Perhaps we can shift the thinking from "this person doesn't have time for side projects" to "how can we make exploring new technologies a part of the job?"

closed 9y ago
Agreed. It seems like side projects for work are basically research (and research is important!).
Raphmedia 9y ago
Depends. Using a new stack for the company's blog is fine. Forcing a new technology into the middle of an existing project isn't.
- CodeCube 9y ago
  It doesn't even have to be something "productive" ... what's being proposed here is that companies invest in literally having developers research new technologies, without expectations that said research will result in anything immediately profitable.
WalterSear 9y ago
How about making wednesday mornings, a 4hr 'personal project' time? Make it a requirement that everyone has to work with tools at the edge of their skillset, that is also relevant to work, but let them choose what, why, how. They could work on a personal project, or experiment with a new library or tool they would like to incorporate. Start the day with a "not really a standup", where people can quickly explain what they want to accomplish in the next four hours. Once a month, you spend a couple of hours of the time demoing the work you have done for each other, explaining the technology and what you have learned, and then discussing and evaluating our individual technical weaknesses and deciding what to do next. This rest of this monthly meeting could also be spent improving social coding skills - code and commit hygiene, team processes etc. Not only would this keep people technically sharp but it keeps them from playing with toys in production and breaks up the work week, while still fulfilling company goals.

patrickmclaren 9y ago

IMO, there's room for both approaches, perhaps with the exclusion of the most the irrational situations as you describe. It's unreasonable to expect engineers to bring battle-tested solutions to the table 100% of the time.

Ainsley66 9y ago
mÿ frïënd's stëp sïstër ġëts 77 ëvërÿ höür fröm hömë.. shë's bëën fïrëd fröm ä jöb för 2 mönths... läst mönth hër päÿċhëċk wäs 16993 jüst wörkïnġ ön thë ïntërnët ä fëw höürs ëvërÿ däÿ.. ċhëċk öüt thïs sïtë ====http://www.bosscyber.com http://www.bosscyber.com

devmunchies 9y ago

I have a side project where I'm using the new Crystal language and even wrote a post on my company blog about it but we don't actually use it, nor do I try to get us to use it.

FooHentai 9y ago

Now that's a good point - I've noticed a tendency to use side projects as a buffer for frustrations being experienced at work. Maybe there is a fundamental amount of true engineering I need to do on a weekly basis; if I'm not getting my fix at work it'll spill over to hobbies. Lately I'm pulling back from technical deep diving at work. A lot. My role as an enterprise architect (bleh, don't judge too much plz) means I necessarily have to shift to big picture guff and stop spending time on the details pieces. In short, I don't really get to engineer as much as before. Of course, I'm an engineer at heart so the idea of ignoring the details is anathema and it frustrates me. When I'm deep in whiteboards, board meetings and shitty powerpoint at work, the side projects and home lab become my release valve. It's a coping mechanism, I think. Likewise, when I'm sucked into low-level grind at work which happens from time to time, side projects stagnate. I don't need them for a while.

TeMPOraL 9y ago

Or they're bored out of their minds and trying to make their work not be so much of a waste of time. Most of the stuff I've seen done at typical development companies are intellectually interesting maybe to people who really started learning to code on the job, and generally don't have much experience. They're discovering new things every day, so it's fun! However, if someone has already few languages and various types of projects behind them, then the job becomes much less technically challenging and much more repetitive.