Was about to type the same thing, am also pianist. Using small muscles to do repetitive things is exactly how you get RSI. Don't do stuff with small muscles that you can do with large ones.
Unfortunately, even in the piano community, this knowledge is not that widespread. Really common to see repetitive motion injuries from very finger heavy technique.
You shouldn't swallow errors like that in FP either. You can trap the error in an effect type and throw it at the top level of your app when your effect type gets run after all of the code that processes that error value has a chance to recover. See something like Zio for an example, though you can do similar things without Zio.
> It’s definitely hard to explain an idea like SVM, it’s applications, and how it works/what it does without a background in some linear algebra.
I don't actually think this is the case. The basic idea is that you can represent data as points in n-dimensional space and draw decision boundaries in that space. I think most people should at least be able to understand this geometrically for n=2/3 and then accept that it possibly extrapolates to n > 3.
I agree that in a vacuum, zero sum games aren't necessarily a bad thing. However, in our hypothetical economy, the actors obviously aren't at parity for their level of skill at playing the game. In a zero-sum economy, consolidation is inevitable. At least in the presence of growth, the avoidance of consolidation is a possibility.
> Suppose every year Farmer Joe has to borrow money to buy seeds and pay workers to plant, grow and harvest the crops. Then after harvest he sells the crops and uses the money to pay back the loan. Every year it's the same, every year he starts and ends the year with the same amount of money, there is no economic growth, but the lender is still earning interest on the loan every year.
> Meanwhile the lender is your 401K, so it makes money over time which you then spend down in your retirement and die with the same amount of money in real terms as your parents did, and so on indefinitely.
I feel like you're making the assumption that the agents in this system don't make an attempt to consolidate (and obviously if and when they do, they will have varying levels of skill at doing so.)
Completely agree with the last paragraph. The economy is tilted way too far towards incentivizing value extraction instead of incentivizing value creation.
Don't know that I agree with some of the previous stuff though. Even if we assume a steady state population, if the economy doesn't grow every year, we're playing a zero or negative sum game literally by definition.
RE your second paragraph, I both agree and disagree. As far as I can see (at least the US system) is predicated on ~4-7% economic growth being the way that people systematically grow relatively small savings into a large nest egg for retirement (not that this appears to be working particularly well, see your comments on pie stealing.) If we assumed a steady state for the population and economy, I don't see how people working for average salaries can set enough aside for retirement (without pushing themselves to a pretty low standard of living) without the benefit of ~4-7% compounding.
I have a developer's salary, so I could probably put away a couple million cash before my retirement even without the benefit of compound interest paid by economic growth. That's not the norm, or even the average though. Participating in society/the economy has to be an attractive enough proposition to incentivize people to do it, or bad social problems start popping up. In a steady state system, I don't see how we can make an offer more attractive than "Enjoy your subsistence lifestyle up to retirement, so you can have barely enough to have a subsistence level lifestyle in retirement."
I used to think this, but I've come around somewhat. The economy as a basic premise is expected to grow at least 3% a year or bad stuff starts happening. Obviously no kind of exponential growth is sustainable, even at a low rate. The best minds are getting sucked into this at least partly because the work is necessary to keep the economic wheels spinning. If we give up on having an average % of yearly growth, we're committing to living in an economy that's a zero or negative sum game.
So yes, we are stagnating scientifically, but it's not necessarily for no reason. The longer we keep running the economy as is, the more smart people are going to have to be allocated to figuring out how to keep up with the exponential growth our system demands. Unfortunately, no one seems to have cracked steady-state economics, so it looks like we'll be doing this for the foreseeable future...
Additionally, I don't know how we're supposed to keep up with this absurd need for exponential growth without leaning hard on technology (at least if we presume we don't want to wreck the planet more.) I feel like big tech is actually doing something important with regard to growing the economy disproportionately with the physical resources they consume.
You can be nouns first and still be anti-OOP. I think the objection anti-OOP people have with OOP is the business of folding your verbs up with your nouns, not being "noun oriented."
I don't know. I've been slinging Haskell on the side for the better part of a decade and do most of my day to day in RoR (trying to start moving clients over to Elixir/Phoenix.)
Haskell is an amazing language. I would totally buy that Haskell teams probably win in the medium to long-term as the wins you get in terms of support/maintenance/extensibility are pretty obvious.
However, anecdotally, Haskell forces me (and I imagine other programmers) to invest a lot more time up-front into getting your design in order. Haskell punishes an "oh I'll just hack that out" attitude pretty badly. Which, as I said above I would completely believe leads to wins in the medium to long-term. If I need to bang out an MVP over the weekend, I'm probably not choosing Haskell unless it's well-trodden Haskell territory.
Additionally, while the language itself is amazing, the ecosystem has issues (enumerated in the article.) Tooling sucks, there aren't enough examples of people doing normal things, there are frequently not libraries for basic things, obviously integrations with popular services are lacking, and the list goes on.
When Haskell has a decently mature and actively developed web framework that has reasonable docs, examples, and a not pathetic ecosystem (by the standard of modern web frameworks) I'll happily jump into using Haskell in production. Unfortunately, these aren't things enough of the community seems interested in to have significant movement on.
Servant looks very interesting with regards to what I'm looking for, but I'd be lying if I said I understood the types.
Was going to say exactly this. Major common misunderstanding about even Haskell. Mutable state has to eventually be a part of basically every program that does something useful. The Haskell philosophy is more about having an explicit and predictable boundary between the pure and effectful parts of your code/system.
Though you'd be surprised at how much you can do while forgoing mutable state entirely.
Skill-wise, absolutely. Demand-wise, absolutely not. I'm a freelance developer now, but before I was a senior engineer at an international software company. I've considered several times pivoting to productized Wordpress consulting because of how easy it is and relatively scalable vs other kinds of software development. The level of demand for basic Wordpress setup/configuration is really pretty astounding.
I suppose it's all relative, but at least in Rails, while I suppose it's trivial in an absolute sense, it's much harder than doing stuff "the rails way."
I didn't mean to say that SPAs were easier at all. They're not. I think they're under most circumstances much harder than traditional webapps. That being said, my experience is that users and in my case clients are starting to expect SPA features and it's harder to try and coax extensive SPA functionality out of a traditional web app than it is to just write a SPA.
It's been probably 2 years since I've seen a front-end dev listing that doesn't list experience with a SPA framework as mandatory. I'm not going to question that hybrid and traditional apps exist in the wild. I maintain some myself. That being said, I think it's pretty clear that at the very least the world is moving on. We are asking for more out of the web than what it was designed for, and it's difficult to meet the expectations of modern users without modern tooling.
By way of example, I do a lot of freelancing and have quite a lot of clients that I think would be better served by a traditional web app (much faster to develop, though not nearly as rich interactions dollar for dollar. Also a lower infra bill generally.) Many of them refuse though because they've been conditioned to expect the kinds of features that SPA's provide.
I write a lot of business automation sorts of apps for SMBs. Something I see requested a lot is wizard style workflows (on a web app.) This is trivial in a SPA and a major annoyance at best in the context of a traditional app framework. I totally agree that the world might not have moved on yet, but I think it's pretty clear which way the wind is blowing. Users are expecting rich SPA interactions as the new normal.
Nuclear is a political non-starter. No one wants to live near a nuclear power plant, and people tend to fight tooth and nail to fight the placement of nuclear power anywhere near them. The result of this is that nuclear power plants get foisted onto communities that don't have the political clout to fight them, or get thrown where there isn't anyone to fight. What ends up happening is that power plants get placed by politics instead of by science and engineering.
Further, it appears (at least to me) that proponents of nuclear underestimate the degree to which we (as a species) underpredict the likelihood of catastrophic events. In general, we're pretty bad at assessing the risk of so-called "black swans," but when the downside is so high, I understand why people are skeptical.
I personally am pro-nuclear, for many of the reasons described in the article, though I don't think the case is as clear cut as most nuclear proponents. On a rational level, I can understand that the likelihood of disaster is vanishingly small. I still don't want to live anywhere close to a nuclear power plant.
You don't want to participate in such a market even if it exists. Your wife is a human being and a professional, not a faucet. Participating in an undifferentiated labor market commodifies her and turns her into the latter rather than the former.
In those types of market places, the primary way for participants to differentiate themselves is price. It's not like you can exercise a lot of control over how any given platform is going to let you market. A bunch of people competing on price without being able to effectively differentiate in any other way is going to have predictable and unpleasant results.
So yeah, doing sales work sucks. But it doesn't suck as bad as the alternatives.
If you/your wife go down the road of trying to source hourly contracts from such markets, you're setting her up for a working situation that's almost strictly shittier than working a "real job." It's basically impossible to rack up 40 billable hours a week on a consistent basis. 25-30 is much more realistic. If she's charging 50/hr, that'll work out to about $58,000 gross a year assuming 75% utilization and that none of her clients ever flake out. Nevermind that the work is more precarious than a "real job", doesn't have insurance or other benefits, and you get slammed with self employment taxes. Also, you/she don't even get to count on a paycheck at any particular interval. If you provide net 30 (I don't recommend, but it's fairly standard,) you have to have enough of a financial buffer to deal with clients cutting you all of your invoices at once instead of as you bill them. Enjoy praying for the mailman to come before the bank closes so you can pay rent.
Finally, I assume your wife didn't spend 6-10 years of her life grinding out a PhD so she can make 58k a year in the most precarious possible way. Get off of this freelancer mentality, start a business, deliver real value, and get her the income and respect she deserves. If you/she bill yourself out like a commodity, people and businesses are going to treat you like one.
Caveat that networking is a slow "long term growth" activity. If she needs work now, researching businesses that fit a target profile and cold calling is the name of the game.
There's no magic here. I too am an engineer, and find sales work yucky. If you want to make more than 5$ an hour on upwork and you're not about working a "real job" sales work is going to be an unfortunate fact of life.
Given that a contract is probably worth 50k+ to your wife, traditional sales approaches are probably a good fit. Unless she wants to do data-set building, I would assume that her target businesses are sophisticated enough to be keeping data. So start there, make a list of businesses that fit the profile, find contacts (put them in a spreadsheet) and start calling or emailing. No magic, just a grind and a lot of rejection.
In terms of a longer-term strategy, she might pursue some sort of content strategy and start funnelling traffic to her website that way. Some % of that will convert to leads and some % of those will convert to clients. Once you get that pipeline set up, you can spend infinite time optimizing whatever parts of that pipeline. I assume though, that in the short-term, she needs work now and not x months from now. "Traditional sales" are likely a better fit in that case.
She might also consider joining a referral network like BNI if there's a local chapter(s) that look like there are enough members that fit your target profile.
And as the other commenter mentioned, your first port of call should be friends and family. Don't harangue them for a sale, just let them know your shingle is out. Presumably some % of them want you to succeed and you'll probably get a lead or two kicked your way in fairly short order.
I don't know what country you're in, but if it's the US, my advice would be to just start a company, throw up a decent looking website and start pounding the pavement. Most of the freelance sites encourage commodified race to the bottom behavior on your labor. Also, 50-100 is too low if you're in the US. If she wants to hit parity with what she would make in the industry working a "real job", she needs to charge closer to 200. (Assuming a target wage of ~150k)
Don't charge hourly, charge weekly or daily (if a week is too large of a unit). It will save you a lot of headaches and free you/her from time tracking at an annoyingly granular level. It also discourages clients from micromanaging your billing (which they definitely will do when you essentially turn in time sheets.)
When she's selling, the goal is to anchor your estimated price to the value of the project (you have to understand the client's business well enough to do this.) The idea is to frame your cost as a fraction of the total value. The rest of the sale is demonstrating you're low risk and that you can deliver. Typically you do this through social proof, or through a small starter project that demonstrates ROI.
Unfortunately, even in the piano community, this knowledge is not that widespread. Really common to see repetitive motion injuries from very finger heavy technique.