Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Social pressure on this is also ridiculous. Every time you start doing things, even if you actually stick to it as a hobby to make you happy, people, inc. family, will go "but you could make money out of this".

Don't fall for it. Most of us will not be able to do money from art, from photography, from aikido. Enjoy it, do it for your own sake, to balance your life.



My wife was musing on her photography hobby the other night. She really enjoys it, and was thinking, "I really wish I could make this my job."

I told her that I'm really happy that photography makes her happy, but that there's no way she'll make much money doing it and she already knows that. It would make life more stressful and ruin the fun she now enjoys. And since I once tried turning a creative hobby into freelance work, she knows I'm telling her the truth from my own experience. I wouldn't want to tell the most important person in my life some BS flattery--if I'm really going to support her, I have to be totally honest.


I like bicycle stuff quite a bit. Riding bikes, working on bikes, etc. But, it's not my job... I do IT stuff.

This past weekend there was a bunch of bike maintenance to be done. Swapping parts around, cleaning things, fixing stuff... It all kinda came to a head yesterday morning where I very clearly thought "this is fun, but I'm VERY glad this isn't my job -- this is a lot of fiddly work".

It's very common for folks to try to turn their hobbies into a job, only to have that realization too late. I feel fortunate to have had that realization before considering it.


Absolutely. As one of our great American sages recognized, "It's only work if somebody makes you do it"[0].

The corollary being that a hobby can stop being fun when you stop being able to freely put it down when you want to -- when you've barked your knuckles on the chainring for the 33rd time. And it's also pretty clearly backed up by studies that show that autonomy is a strong factor in workplace happiness and effectiveness.

[0]:https://www.gocomics.com/calvinandhobbes/1989/08/28


In short: "it's only fun when there is no boss".

But I don't buy into that, I believe that you can lose the joy just as much, or more, when you are following the self-employed model.

Working for a boss it's still quite possible (but maybe not easy) to separate work hours from leasure projects in the same fields, but when self-employed, all "off" projects have the potential to become "on" or something in between.


When self-employed, one is one's own boss. That boss may be more ruthless than any boss that would actually hire you.

I've seen this effect in a few self-employed and founder friends.


Yeah, there being another person involved isn't the issue, I think, it's that (ultimately) you either do the work or you don't eat. Which is never the case when it's "just a hobby".


So the golden path in keeping a hobby on the fun side is to select one that is sufficiently expensive to never ever be at risk of seeing a break-even line at the horizon.

/wanders off to browse carbon handlebars


It's a shame to ruin a perfectly good hobby by making it a job.


I had this attitude until my late 20s. Then I realized that I really need a career to set myself up in life. So now I'm a senior programmer.

And my programming hobby? Better than ever! Turns out, having actual professional experience makes things easier and I can just play around with it whenever I want with a lot less stress than if I didn't also do it as a job.

Of course, I also have other hobbies. But making money on my main hobby was great in the long run.


I recall discussing this with some one who had switched to web dev from music - he had a Phd and was a London Session musician who had played on top 10 hits.

At some point it stops being fun - 8 hour days practicing for example he mentioned.


Most professional musicians I've heard from would be thrilled to even spend that much time on music itself, what with all the other annoying business details to manage.


I think that's the story of trying to turn anything hobby-like into a living. You start out as a photographer or an artist, but you end up having to be a general manager and an accountant.


It's the age-old tension between "do what you love, and you'll never work a day in your life", and "the best way to ruin your hobby is to make it your job."


I think this was when he was intensively studying for His PHD and was for an extended period.


Your comment reminds me of another from HN a few years ago, "If you love software development, don't do it for a living."


There is also value in keeping your passion as something you enjoy and brings you happiness in your leisure time, rather than turning it into something that brings you stress and pressure full-time.


I think one can make some money by selling photos to photo stock sites. It's a kind of semi-passive income possible when you shoot landscapes or common objects.

It of course is unlikely to become a primary, or significant, source of income. It also unlikely to affect what you do for fun.


It gets weirder, often they'll insult you because it's not a 'real job'.

I still cannot understand but to many, sitting at a desk idleing is incomparably better than doing something on your own. Be it maths, electronics .. doesnt matter.


It's not weird at all. All it takes to make something a "real job" is to not want to do it.


In economics there's something called the Wilt Chamberlain Problem, where Chamberlain explained that he liked basketball so much that he'd play for free. Yet he was paid millions. So every dollar that he was paid produced no incentive for further supply, which caused economists to consider this situation more like rent than wages. With the rent of land, no greater supply of land is manifest when the landowner is paid.


I understand but that's an utilitarian view of life. And also how do you value things like that .. again, we're back to the relativistic nature of money.


Envy / misery loves company. They don’t think they could do that thing, so you shouldn’t get to either.


In the misery dept I think there's a "we suffered work, you must too"


Puritan work ethic never really went anywhere, and this is the dark side of it.


I'm not sure I understand you fully. Mindless jobs are the dark side of necessary imperfect jobs ?


I think they mean that the Puritan work ethic is that working hard is good, always, and if you're not working hard, you're not being good, so they get on your case about doing something you like or something not traditionally seen as work (i.e. painting, writing novels, etc)

As for their mindless job, they might not see it as so. They could have stress and deadlines for their bullshit work and feel like they're working hard, even though the they are basically doing the same as taking a bucket out into the ocean and scooping up the water and dumping it out into the rest of the ocean.

So they're working hard and they're good, and you're just messing about, and you're bad. Which of course is not a healthy way of looking at things, hence the dark side of the Puritan work ethic.


Does it have to be mutually exclusive? I mean, Can a hobby that we enjoy to have fun not also make money?

Here's the relationship is unidirectional - do something for fun and if it makes money then it's well and good. Why to drop that just because it makes money (which isn't the original motive).


The article highlights how trying to make money can quickly and thoroughly poison your hobby. The golden quote:

> “Hmm…I want to write a book. I would really love to write a sappy romance novel because I think they’re so fun to write. But I need to turn it into profit, so I should do market research and see what’s trending and build off that. Self-help is big, let’s try to focus on that, even though I personally hate self-help books.”

Note the change. "I really want to write a romance novel. I did market research. Self-help sells better. I'll write self-help then."

Following this thinking, you'll end up doing something you hate (and probably produce a barely sellable garbage). Hobby is about a thing ("I want to write a romance novel"). Making money is about money, and the thing is only means to an end ("I'll write whatever sells best, and maybe I should reconsider whether I can do something else than writing for even more money.").

I'd argue that even in professional life, this kind of thinking taken to the extreme is poison, and part of what ruins our societies and the planet. That is, companies which are really indifferent to what they're doing, and only focused on whether they can make money on it.

(One could argue that this is how market economy is supposed to work - don't think for yourself, don't feel for yourself, just do what the Market tells you to. We can see both good and bad consequences of that thinking all around us.)


I agree that taking it to an extreme can be a poison, but neglecting it entirely can be a poison too.

I've said this before on HN, but my recommendation is this: Most people can find a set of things they're willing to do. If you only have one thing you think you can do with your life, first try expanding your wings and sampling a few more things.

Then, write down on one list the things you want to do with life, in some rough order of preference. On another list, write down the marketable things you think you're capable of, in some rough order of lucrativeness.

Odds are, there's going to be something that shows up reasonably positioned on both lists. "Software engineer" was certainly not my #1 on my "list of things I'd like to do", but my personal #1 was frankly absurdly unrealistic and barely shows on the "what I can make money with" list at all. (The modal outcome is quite likely $0/yr, honestly.) But software engineer was a pretty solid #2. On the other side of the list, I probably could have been a lawyer, and may well have made more money at it, but it didn't show very high on my "list of things I'd like to do". Software engineer was somewhere around #2 on both lists, so it won. I have no regrets. It was a fine choice. And it was something I could easily figure out how to angle for, and there was no simply blundering into a career.

If you do want to write something, and you want to make money at it, I recommend a similar approach. Wanting to write a romance novel and deciding to write a self-help book may not bring you joy, but wanting to write a romance novel and instead writing a YA romance novel because that's where the money is may not be such a sacrifice.


I missed that on HN before, so thanks for writing again. I never thought of writing down two lists, even though it's obvious in retrospect. I'll try this exercise.

I did come to the conclusion some time ago that since writing code is my #1 money-making skill and in top #3 of "things I'd love to do" (and a part of #1 too), but the types of programs to write are different, I need to focus on finding overlap in what I write when looking for jobs or (now) customers.


Somebody needs to write self help books for the people who need them. That somebody should do a lot of boring research (note that I said should: the implication that they might not is intentional).

Society would fall apart without people who clean sewers, take the trash, and many other tasks that are unpleasant. Maybe you are lucky enough to get paid well to do what you love. Maybe you are not willing to do some unpleasant job that would pay better than your own. Likely you are unable to do some jobs (lack of training or lack of physical ability). No matter what you do, and no matter what your abilities: there is some other job that you could do instead. The market economy works because it provides motivation for people to not do a job they would love and instead do something else.


> Somebody needs to write self help books for the people who need them. That somebody should do a lot of boring research (note that I said should: the implication that they might not is intentional).

That doesn't mean it should be the author. If he hates self-help books as a concept, he'd probably do a shit job at it. That is, he might make money, but the book wouldn't be useful. Market economy as it is today, in practice, is pretty bad at rewarding quality. Marketing gives much greater ROI.

> The market economy works because it provides motivation for people to not do a job they would love and instead do something else.

I recognize that and this is the main thing I meant under "good" when I wrote about "good and bad" consequences. Unfortunately, Sturgeon's law applies - "90% of everything is crap". The market doesn't seem good at reducing this percentage. In self-help space, we need more Carnegies and Coveys, and less copycats who arrive in the space through "market research" and crap out nonsense that ultimately wastes buyers' money. Same thing applies to all other spaces. My complaint isn't really about the market telling you what to do - I'm just wishing the market was better at directing the right people to the right jobs, ensuring there's "impedance match" between the worker and the work.

I'm not sure how we can get there, though I think it would have to start with completely destroying the marketing industry. The world won't stop drowning in bad products and services for as long as a dollar spent on marketing buys you more profit than a dollar spent on product development or improving your service. Marketing completely scrambles people's ability to evaluate and reward quality and utility.


This conversation is about hobbies. No one is cleaning sewers as a hobby (they wouldn't even let you!)


That was my point: someone needs to clean sewers, and nobody would do it as a first choice.


Then again, is using the same whip to drive people to cleaning sewers and writing books an optimal solution?


Because by sharing your work, especially if you charge money, you’ll start feeling the pressure ... to improve, to support your customers, to react to your competition.

This is actually the reason for why many open source developers burn out, even if they aren’t making any money, which is tragic.

And you might say that you’ll not fall for it. Well good luck with that.

In my experience the minute you share your work with others, that’s when it becomes slightly less fun and it’s all downhill from there.


> In my experience the minute you share your work with others, that’s when it becomes slightly less fun and it’s all downhill from there.

Unfortunately, this is often true -- but there are exceptions. I've had a couple of projects where the experience has been almost entirely positive. There's a lot of satisfaction in seeing that something I designed and created purely to suit my needs has turned out to be used and appreciated by others as well.


I have a program I created as a hobby, put on github, then it grew popular enough to need occasional support and updating. Sometimes I wish I did not put it out there.

It can quickly become work instead of fun; work you are not paid for. Though if you accept donations for it, then you have an obligation to keep it going.


> Sometimes I wish I did not put it out there.

You can always take it down or disable issues[1].

> Though if you accept donations for it, then you have an obligation to keep it going.

You most certainly do not. In the same place you ask for donations, make it clear they’re for people to thank you for the work you already put into it, not to “buy” future work time.

If you don’t want to work on a feature, say “no”. If a user acts entitled, explain (tip: keep a non-confrontational text snippet ready) that you’ve developed the software in your free time and are under no obligation to fix other people’s bugs; when you do, it’s because you want to. Lock the thread if need be. Does the user come back to open another issue, guns blazing? Block them.

I spend hours every day on open-source. I’ve learnt that most users are reasonable and can take a “no” if you add a “because”. It does not have to be the soul-wrenching experience many maintainers make it out to be.

[1]: https://help.github.com/en/articles/disabling-issues


Just tell people to make pull requests. There’s nothing wrong with that.


Sadly that doesn't work out so well. Just look at the recent npm event-stream debacle for an example.

An author didn't really want to deal with a library any more, someone came out and offered to maintain it, the original creator agreed and moved things over, and the new author added exploits to the code.

Most of HN and other social media was lambasting the original creator for doing something so "careless". Many people wanted them to just shut it down when they were done with it, others wanted them to more carefully vet potential maintainers, still others said that shutting the project down would be irresponsible as there could be vulnerabilities found that need to be fixed.

There really isn't a right answer, and with how social media sites feel these days with witch hunts and outrage flying around everywhere, I personally have shied away from open sourcing a few tools that I've created simply because I don't have the time or care to maintain them. The last thing I want is "social media" to collectively decide that I've made terrible mistakes that no sane programmer would ever make in their code, and that I deserve to never work in this industry again.


>Most of HN

I'm part of HN, my general attitude here is that the maintainers of the consuming software are at fault.

If you have so many dependencies (especially in javascript, hah) that you can't keep track of what's happening with them then either your scope is too big or you're just carelessly glueing things together because you can't be bothered to build sane things on your own.

I understand using things like jasmine and one or two other big things, but at that point those big things are critical components of what you've built and you need to be paying close attention to them for the duration that you're responsible for the maintenance of the code.

TL;DR: the fault is with the consumers for being careless, not the people who actually put work in.


But you can't hope to watch every dependency of every dependency of every dependency all the way down, at some point you need to trust that the code will do what it says.

Dependencies don't just end at a package.json. Their dependencies matter, as do theirs. The C++ code use in the javascript engine is a dependency, as is the python code they use during the build process, which itself relies on Python and their interpreter, which is again more C code, which means you need a compiler, which also has a large suite of dependencies and relies on an OS to provide many things, which themselves rely on more compilers and eventually machine code that should be consumed correctly, and that depends on the microcode running in the CPU to be created correctly and without any vulnerabilities. Of course that microcode is generated using more higher-level code, and the cycle continues.

You literally can't check everything, and I'd argue that you can't even check more than 2 steps out from your own code realistically.

That's not to say you shouldn't try, but you can't just pretend that it's the fault of the consuming dev that they got exploited just like you can't pretend that it's the fault of the original creator of the code who doesn't want to maintain it any more.

These things are going to happen, and I think we would all be better off if we just accepted that, stopped trying to place blame on a specific person or group, and instead continue working on making it harder to accomplish those bad things. Otherwise we get into a situation where "the only winning move is not to play".


No you absolutely do need to trust the dependency code unless you're working on a toy application. If you're building something real where reliability and security actually matter then you have to either verify the dependencies yourself, or actually pay vendors to do it for you and get written contracts for support. Unfortunately many developers have fooled themselves into believing they can get something for nothing, and then act surprised when the inevitable consequences hit.


So how many layers of verification do you or the companies you work at pay for? How many layers of dependencies do you pay someone to verify? Do they pay others themselves to verify the layers below them?

What do you do when someone has a dependency on something like OpenSSL, GCC, V8, Chromium, or even Linux? It's easy to say "oh well just pay someone", but who would I pay, and what would I pay them for?

We use npm to install 2 dependencies for a project i'm currently on. I can vet those 2 dependencies, and luckily in this case they are simple and each only depend on another 4 or 5 themselves, and in total I have 20 deps. I can review that, and it all looks good (for the sake of discussion let's assume I can actually carefully review and understand every line, when we both know that's not possible in the real world).

Now what? Well I'd also need to validate that the tool `npm` isn't hacked, and now that's a massive amount of work, then throw on node on top, and then v8 on top of that. So let's throw away all of javascript because I don't have a few hundred million dollars laying around to spend on auditing the entire javascript ecosystem.

So what platforms do you use? C/C++ are out of the question, GCC is massive and I don't think I have the money to pay for audits for that either, let alone libc and OS kernels. So does that rule out everything except for small embedded systems and custom designed chips? Maybe there are some assemblers out there that can compile some simple code and are small enough to be audited by a smaller company. I mean you'd still have supply chain attacks that you need to protect against and verify, but hey those are easy to fix right?

Or do those dependencies not count for some reason?

And that's even assuming that an audit of a codebase will catch much of anything, which we both know they won't in all cases. So then what do you do when one slips through the cracks? Find someone to blame like that'll help anything? Tell the company that got owned that if they just added a few more zeros to the end of the check they wrote someone would have caught this?

This "just verify it" stuff gets so tiring, it's literally not possible.

Maybe I'm really living in a bubble of the wild west of computer programming, but somehow I just can't see this magical world just out of reach where everyone else verifies and vets every single dependency and that chain continues unbroken all the way down to the firmware and even the hardware and nobody ever makes mistakes and nobody ever pushes changes out at any level without hundreds of people reviewing and improving and fixing and re-verifying every single change.

The idea that anything even close to resembling this happens in the real world is so laughable to me, it's just the same old "only REAL programmers do x" gatekeeping that is so prevalent in this industry. And this is exactly the kind of thing that makes me not want to contribute back any changes. Because god forbid I don't spend wheelbarrows of cash on vetting every single part of my stack, and that my code isn't absolutely perfect in every way, or I'll be dragged across the coals and made into some kind of demon for having done something so stupid that a "real programmer" would obviously never do.


This is how you end up with stuff like QNX. It's really not nice to program for but you have a whole company who's job it is to produce a set of more or less verified dependencies.

Also: there are compilers other than gcc that are much smaller.


It's not complicated. You can pay Red Hat or one of their competitors for Linux verification and support (including security patches for included libraries), and in turn they'll pay whichever other vendors are necessary to deliver on that contract. Get it in writing. For accountability you need a "single throat to choke".

If you're using npm for something important then just realize that you're taking a huge risk and don't be surprised when it blows up in your face. Most of the discussions on HN are about toy applications which don't really count for anything. I would be surprised if the Visa payment processing system uses npm.


He still has to review those requests. Depending on the quality of contributor, that might be MORE work!


It can then inadvertently turn into a second job. For some people that won’t be a problem, if they develop a true passion for their hobby then it might be a great outcome!

However, for some people it might sap the original enjoyment they had. Now you’re concerned about profitability and maintaining your audience and market etc. Soon your mindless pastime is causing you stress and anxiety, which defeats the point.


Basically do whichever and whatever makes sense to you, for you.


Every time I bring up that I'm building an app on my own time, without fail I'm asked "How are you going to make money off it?"

People never listen when I tell them that I code because I enjoy it. It makes me wonder how much people actually enjoy aspects of their own lives. If I make money off what I do, that's great, but most of my motivation is to satisfy the "what if" and "could I" type questions that run through my brain.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: