I absolutely do. Money and power is a great motivator. I don't feel bad about any of it. I took my shot and continue to do so.
>What a miserable existence that must be. How do you get that way? Should we blame LinkedIn or what is it?
It was not. I made some good side money. I always joke that I program to feed my computer habit. The benefit of it is you actually code like you are making a product, and there is usually a big skill difference between someone coding for fun and someone coding to make an actual sellable product; it's the 80/20 rule. That last 80% is what separates the good from the great. Like Jobs said, "Real artists ship."
I just want to point out that this goes beyond an argument explaining how hobby projects can be useful and enters the territory of personal attack. I presume you mean that whatever they made is substandard in some way ("[gluing] libraries together" is nonsense criticism; everything in software is someone's abstraction) but I don't see why you would think that.
I absolutely think gluing libraries together is a substandard default way of working that leads to poor results, by the way. "[...] everything in software is someone's abstraction" is a cop-out that ignores the massive gap that exists between finding the lowest level you can execute (in many cases an OS call that cannot be split up into a smaller part, or calls into the lowest API you can find like OpenGL, Vulkan, etc., where we have to play by a driver's rules) and executing a function in a library that calls a library that calls a library that calls the OS or the like.
Taking on the cost of countless layers of function calls, potentially manager code, etc., just because "everything in software is someone's abstraction" is, to use your phrasing, a "nonsense" excuse for poor work and not taking ownership of the code that will execute.
I have a former coworker that elected to use a tokenizer/parser library that clocked in at about 6k lines of Rust code, where I personally decided to simply write one in about 600 lines (in Odin, which probably is considered more verbose). The 600 line one was faster, used less memory and naturally was easier to understand (easy enough to understand for someone who literally had never written a tokenizer/parser before to use and extend). It's defensible to use a library for a tokenizer/parser, of course, because "everything in software is someone's abstraction", but do you see the problem here where we get worse software and no one ever learns how to make better things if everyone just decides to `cargo install` readymade solutions?
I'm not saying that my colleague could at that moment have written the Odin solution in this case, but he would certainly be more likely to if he implemented things from scratch as a way of practicing, or decided to otherwise take ownership of the code that runs in work projects.
The first yes, the second no. If you had a reason for the assumption, I think it would not be an assumption.
> I have a former coworker ...
One might assume you are thinking more about your former co-worker than you are about Clubber. They could make that assumption because you describe in detail an actual instance of what you complain about in the absence of any other such description in Clubber's comment.
Should they assume that? Even if they have reasons? Even if they're right? What does it add to the discussion?
I think you could have made a good point about their assessment missing the mark because I agree that the skills you write about are improved by "finding the lowest level you can execute" more than "coding to make an actual sellable product". Still, they might consider the latter to be no different from the former (the former is certainly a more precise description, regardless). Your story about the co-worker is a good one on that topic. It's unfortunate that the assumptions make your comments easier to dismiss.
To make something sellable, you usually have to make it not-so-technical and not-so-complex. Simply because of the time constraints of hobby work and solo work. Your effort would go mostly to the market analysis and your product would need more polish meaning that for a personal project, it would usually be trivial (You can sell a shopping list iOS app, but you can't easily sell a 5 year hobby project making an OS). The sellable OS would be a 500 man-year product. What yo do by coding a kernel for 5 years is possibly that you can improve the product that is yourself.
So unless you actually enjoy the goal of marketing/selling/running a business, then the Shopping list iOS app won't be a good hobby.
I'm not saying it's worthless by any means. I assume this would be the baseline. The benefit of making an actual sellable product is you learn how to finish, which is often a lesson not learned from hobbyists. It's fun to work on new tech, but if someone never learns how to make a product that can ship, their value in an organization is probably more limited than someone who can.
>Your effort would go mostly to the market analysis and your product would need more polish meaning that for a personal project,
It's the polish that's valuable, I couldn't care less about the business side of it, leave that to business people.
Let's use your example of working on the Linux Kernel. If Linus just made a kernel and said, "this is great!" we never would have had the GNU/Linux revolution. It was packaged and installers were created and distributions were made and it was eventually able to be installed pretty easily by anyone. That's making a viable product, that is finishing.
>To make something sellable, you usually have to make it not-so-technical and not-so-complex.
Sort of, you have to make a not-so-complex wrapper so other people can use it. The complexity is still there, but you have to abstract it so devs without that knowledge can use it. I feel that if no one else can use it, where's the value?
“The definition of genius is taking the complex and making it simple.”
Another simplistic example is I'm working on making a custom domain specific model. Getting it to infer properly is great (getting there), but the value to the company is to make it fast, wrap it in a usable API, get it to log useful errors, and integrate it into our software. The first is the fun part, the second is finishing to make it useful. That's value.