I don't know about every single day, but I've worked professionally as a software developer since 1998; and I've been writing code for fun outside of work since I got my first computer around 1985.

Work is when someone tells me what to do or where/how to do it, which is why they usually have to pay me obscene amounts to make it happen.

This one's very personal, it's only a good thing to do if you genuinely really enjoy it.

I used to be a maths teacher and I love maths, and would do it for fun outside of my job. That in turn often helped with the job itself, and certainly helped to keep my interest in the subject alive even when 90% of the job was teaching fairly basic stuff that wasn't particularly exciting.

I'm now a software engineer - I'm much happier in my job, but I don't love writing code enough to ever want to be doing it outside the 40 hours a week I'm paid for. I'm slightly jealous of the people who do, because I know first-hand that it's a great way to do better at work and keep feeling fresh and interested in what you do, but forcing yourself to do it doesn't bring any of the same benefits.

Once you've settled into a programming job there is actually very little that is new and intellectually challenging. If you don't do anything else you'll become obsolete and atrophied.

To have pet projects is to break out of this daily slow death and to keep learning and being intellectually challenged while keeping up with the industry.

Gather a bunch of co-workers and lobby for 15 % time! You should absolutely have some time for pet projects at work.

I think it's amazing if one can claim with a straight face people should `absolutely` be paid for pet projects at work.

If we're arguing here that it's a great form of professional development, why would it be a joke to get better at your job, on your job?

Furthermore, in some cases I think it is a great idea.

I've seen to many "interesting" technlogies being crammed into projects just because devs needed them on the CV.

If people can test out everything they want without having to claim that they need it on a project it can save ourselves a lot more than 15% on any project or product that lives for more than a year or two.

At work we are still sometimes suffering because of how cool Redux once was.

To be the devil's advocate, you wouldn't want to pay your plumber for time on his pet project while he's working on your bathroom.

No, but I might prefer a plumber from a company that pays their plumbers to train and work on the latest 'tech' in their down time. I might even be willing to pay a 15% premium, especially if I'm looking for a 'cutting edge' solution for my bathroom.

You really don’t want a "cutting edge" solution for your bathroom. You want a boring one that you will be able to maintain by yourself for years with standard tools from the store.

And I truly think it’s the same for your codebase.

Given the choice, I would absolutely go for the plumber that spends some of their time practising difficult plumbing jobs and doesn't just do routine cases. Even if they are 15 % more expensive. I honestly believe they'll be much better equipped to handle anomalies, should they occur.

Looking at it further, I would ignore a 15% difference if it came with any enticing reasonable. Any small difference in quality is certain to return me much more than 15%.

this is such a poor analogy

I give you that, haven't spent much time on coming up with it.

I would like a competent plumber and if he does some fancy work in his spare time and gets even better than great.

But I would raise an eyebrow if beside my work he will also want to be paid for 6 hours he spent in the weekend, experimenting on his bathroom...

I wouldn't expect to have professional development overtly included in a short term contract, either. I'd expect a much higher hourly rate to pay for it though, amongst other things.

I'd expect if the plumber worked for a plumbing company they'd probably invest some time and money into skills growth, and pay for it out of the money they charge you.

Because it makes sense. Learning should be part of most professions. People attend conferences and workshops. Companies pay for travel, accommodation, participation and other expenses. Giving your employees time to learn something new with a side project is incredibly cost-effective in comparison to external learning opportunities.

Besides the things others have said, some major innovations started as corporate-sponsored pet projects. Gmail is a commonly cited example. I believe many of 3Ms successes (including post-its) also belong to that category.

While I absolutely support the idea that employment should include professional development, let's be wary: first, of survivorship bias, and second, of perversion of incentives.

How many side projects, at Google, and then at other places, didn't turn into runaway successes?

More importantly, if you tell management "you should let us work on side projects because it could make the company millions of dollars", watch how fast "did you use your 15% time to invent anything that is marketable this week" becomes a part of your performance review, and your "side project for personal development" becomes "PMs breathing down your neck asking for progress and status".

Oh, no, I would be surprised if more than one in every 100 pet projects as much as break even.

But that's the point. Your run-of-the-mill incremental improvements with a fairly certain ROI of 0.5 % or 2 % is what you spend almost all week doing. Then you have a few hours of doing whatever you want. And a very small fraction of those things will have a ROI of thousands of percent. And you won't know when it happens until it's happened.

If you apply the other principles described in the blog post, you will probably save more than 15% of your time so if you spend 15% of your time learning everyone is still better off in the end.

If you do not offer the possibility to learn to your employees they will try to learn while working on a project which is where problems come from : speculative programming or hype-driven-development.

Speculative engineering often gets a bad wrap, mostly because people mis-characterize it. For example: a feature is written up for a product that talks to X third party system. The same organization has other teams using X system. Wouldn't it be wise to abstract that integration work out to allow other teams to use it instead of building their own, especially in the agile world where teams are highly autonomous? This is often characterized as speculative engineering, when in fact it's engineering for scale.

It begs the question, what is your boss more likely to say YES to? 15% raise, or 15% self learning time? (For me it is NO to both, but the self learning time is probably more realistic)

pet projects can still be relevant to work.. maybe you've been wanting to make some internal tool, etc

When I introduce this, my criterion is that whatever pet projects people work on during work hours should make the lives of people at the company better, if successful.

Beyond that, I don't care if it's cancer research, self-driving bicycles, an email client someone else at the company uses, or a script to automate some commonly performed actual work task.

I still (after over 30 years as pro) develop stuff for fun on the site. I don't see that as work (and I don't see my work as work either these days either).