5 ms·

Thanks for sharing your experiences, this is really interesting. It seems like you had a pretty unpleasant experience as a traditional employee, which I can app

Thanks for sharing your experiences, this is really interesting. It seems like you had a pretty unpleasant experience as a traditional employee, which I can appreciate. I'm curious about this part: >I was one of the best people someone could hire for things that are necessary, but not glamorous -- database performance tuning, data warehousing, ETL process development, and cleaning up disasters. Yet getting market rate for salary as a senior dev was like pulling teeth. At the time I was gritting my teeth to collect a paycheck. The skills that you polished -- to the point of being "one of the best people someone could hire" -- seem heavily reliant on experiential learning. For example, I can't see how someone could get to be really good at "cleaning up disasters" without cleaning up a lot of disasters first. Would you say your experience as a (chronically underpaid) senior dev is what prepared you to be able to go out and perform the work that companies value so highly? Is the trick for us less-senior folks just to... keep working?

MrFoof 9y ago
>Would you say your experience as a (chronically underpaid) senior dev Oh, I wasn't chronically underpaid. I got paid 95-100% of market rate, but you were basically held in contempt for getting it, even if you proceeded to vastly outperform all expectations after starting. A lot of places would offer 70% of market rate and not budge (was their budget), and I swiftly killed negotiations in response. These places that tried to get more for less were great to remember though. Years later, several have become clients, and I can confirm they definitely got what they paid for after having done a lot of cleanup. They are a solid leads, because eventually their hiring strategy catches up with them, and they need a pro to bail them out. >The skills that you polished -- to the point of being "one of the best people someone could hire" -- seem heavily reliant on experiential learning. For example, I can't see how someone could get to be really good at "cleaning up disasters" without cleaning up a lot of disasters first This is easier than you think. Cleaning up disasters is mostly two things. A) Knowing how to make a simple solution that does a task exceptionally well (objectively) and B) Knowing how to read and profile code to know what's worth replacing with A. The only other thing I would say is C) Constantly tell yourself that everything you write can be better, so you constantly improve A. This isn't high-falutin' bleeding edge architecture astronaut stuff. Most of what I deal with are basic things done badly. I've walked into shops in the past few years where people couldn't reliably load text files into tables. In one investment firm about 4 years ago, they had a 24-core server backed by tons of solid state LUNs, and the effective throughput of the ETL process was less than 10KB/sec because instead of write once, they decided to write once and then update the same data thirty eight times (no exaggeration -- actual number). As basic an application you can think of, I've seen some very memorable disaster versions of them. I've seen things, man! Including identical disasters in the latest NoSQL database, with an application glued together using the language du jour. If you genuinely know what you're doing, and are willing to always convince yourself that you still don't know enough (and keep learning), age 30 can easily be the time to give it a shot.

MrFoof 9y ago

>Would you say your experience as a (chronically underpaid) senior dev Oh, I wasn't chronically underpaid. I got paid 95-100% of market rate, but you were basically held in contempt for getting it, even if you proceeded to vastly outperform all expectations after starting. A lot of places would offer 70% of market rate and not budge (was their budget), and I swiftly killed negotiations in response. These places that tried to get more for less were great to remember though. Years later, several have become clients, and I can confirm they definitely got what they paid for after having done a lot of cleanup. They are a solid leads, because eventually their hiring strategy catches up with them, and they need a pro to bail them out. >The skills that you polished -- to the point of being "one of the best people someone could hire" -- seem heavily reliant on experiential learning. For example, I can't see how someone could get to be really good at "cleaning up disasters" without cleaning up a lot of disasters first This is easier than you think. Cleaning up disasters is mostly two things. A) Knowing how to make a simple solution that does a task exceptionally well (objectively) and B) Knowing how to read and profile code to know what's worth replacing with A. The only other thing I would say is C) Constantly tell yourself that everything you write can be better, so you constantly improve A. This isn't high-falutin' bleeding edge architecture astronaut stuff. Most of what I deal with are basic things done badly. I've walked into shops in the past few years where people couldn't reliably load text files into tables. In one investment firm about 4 years ago, they had a 24-core server backed by tons of solid state LUNs, and the effective throughput of the ETL process was less than 10KB/sec because instead of write once, they decided to write once and then update the same data thirty eight times (no exaggeration -- actual number). As basic an application you can think of, I've seen some very memorable disaster versions of them. I've seen things, man! Including identical disasters in the latest NoSQL database, with an application glued together using the language du jour. If you genuinely know what you're doing, and are willing to always convince yourself that you still don't know enough (and keep learning), age 30 can easily be the time to give it a shot.