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.