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"
back
7 comments
> "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?"
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.
If you have to start giving reports, it kills creativity. The point is to do something everyone else may think is irrational, but you feel would lead somewhere interesting.
This also lets junior developers practice planning and self-management, since they basically have 12 hours to come up with something to show.
We call this development time at my workplace. Every two weeks, I spend the first half of my shift doing whatever I please, with encouragement for it to be work related, but no real guidance.
Last week I wrote a utility in Python to parse a configuration file that we had so far been editing by hand, or with bad, slow and cumbersome tools. Now our Linux guys can make the changes is seconds across multiple machines, and the parser is much safer than the bash hacks we had been tempted to use before.
Point being, development time can be great! More companies should embrace the idea of letting their employees improve their own workflow. Some of our best ideas were just that: a little spark that an employee had the opportunity to actually explore.
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.
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.
Some companies are already doing this. When I worked at Intuit we would have Whitespace days and Innovation days, roughly every month or so where you could spend 1-3 days doing whatever you want.
While I have a lot of freedom at work to explore side projects and random stuff and I spend a lot of time doing so, there is a part of me that feels like there's a reason software engineers, at least in the US, are paid so damn much. To me, it's kind of implied that I'm paid <ridiculous amount compared to virtually any other job with similar requiring similar amount of training> is because I'm going to be doing more than the 35-40whatever hours I spend at the office.
Part of that is support (though about half of the jobs I've had involved little to no on call duty), part of it is training one self, in addition to everything I have to do during the day.
Let's call it discretionary overtime baked in pay since we're usually salaried.
Agreed. It seems like side projects for work are basically research (and research is important!).
Or just say 20% of your time you can do what you want. Seems like a solved problem to me.
Having a solution to the problem and having people advocate for implementing that solution in their companies are too different things.
We know about lots of best practices but if no one is advocating for them at their companies those practices we'll just be shining cities on a hill that we look to from a deep, dark valley.
We actually do this. We plan the learning phase for the sprint and we time box these kind of things for 1-2 days.
100% this.
My side projects are absurdly over engineered and I get nothing done. But I learn what not to do when it matters.
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.
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.
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...
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. :)
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?)
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.
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.
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.
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.