At Meta many engineers tried management and then went back to being an individual contributor. I'm not sure of the exact numbers but it was a very common career path. It did build up empathy for management on the senior IC side and meant that teams didn't get stuck with managers that didn't actually want to be a manager. If the company is not growing headcount this move makes perfect sense.
That's a pretty common thing once ICs reach a certain age. I've seen it everywhere I've worked. Sometimes it's because they fear age discrimination but more commonly I've found it caused by the organization not providing a great career path beyond a certain level. With wisdom comes the ability to accept that it's OK to stick at an engineering career level for years at a time.
A question to answer: is the enjoyment coming from actually being the machinist, or is it coming from assembling something you designed? The answer could be either. But if you just want to bring something you designed to physical fruition and you are limited on space then I would recommend finding machine shops that will make what you design for you. This is what Protolabs, Shapeways, Xometry, etc do. You don't need to actually have a 3D printer or laser cutter or CNC mill to get things built. You can probably find a local fabricator too. I found a guy that made handrails and would do random welding jobs, I used to go to his shop for all sorts of different things. Even if you get the money and space to build out a shop, there's a lot of skill to these crafts and people dedicate their whole career to becoming experts in them.
The goal is the end product, yes. But there's joy to be had in getting there. And more importantly, I know I won't be able to achieve it without a good feedback loop for iterating on my designs, which means doing at least some machining on my own.
For one thing, sketching out variations on a design typically reveals there's a wide space of possible parameters in the spec. In many cases it's obvious that only a small subset will actually be technically feasible (either for machining or for reasonable functionality of the finished artifact or both), but not obvious exactly what that subset will be.
I'm not even talking about what could be revealed by finite element analysis or other formal methods (though I'm not averse to learning those too). I mean the feel, the taste, and the intuition I can't get from just drawing and doing the math. Like Jackie Stewart said, "You don't have to be an engineer to be be a racing driver, but you do have to have Mechanical Sympathy." I have mechanical sympathy for computing systems, for rapidly narrowing down appropriate design spaces in software projects, but I don't yet have mechanical sympathy for mechanical systems.
I do not think the outcome is only Uber / Lyft but with AI, but if that is the outcome I still think it would be a win. Today supply of Uber / Lyft in my area at off hours is spotty, and that makes it unreliable. I have gotten stuck walking home 2+ miles multiple times in the last year because I couldn't get a ride at any price. That's not a problem in Manhattan, but not everywhere is Manhattan. Driverless cars would be on 24/7/365 so wouldn't have that problem. The more reliable these taxi services are, the more viable it is for people to get rid of their cars.
I also expect long term self driving cars will be safer than humans, and as a person that primarily walks around instead of driving that's a benefit to me even if I'm not in the car.
Why wouldn't driverless cars have the exact same problems? A driverless car is pretty expensive, so it needs to be making money a high fraction of the time or it's not economical for a company to invest in it, just like a regular taxi service (I'm really curious how they would handle 'surge' times - have fleets of cars that sit parked and unused 99% of the time??). Uber and Lyft actually have a lot of flexibility in this regard, since the cars already exist for other reasons (and don't cost Uber/Lyft anything when they're not driving). The idea that 'driverless' somehow means 'lots of cars, everywhere, at all times, very cheap' doesn't make any sense to me from an economics perspective.
For many years my "big question" has been "why do software engineering projects fail at a disproportionally higher rate than other engineering fields?"
Though I have to say the other engineering fields are not doing so hot lately either, so I might have the wrong question.
After 20+ years in the field: main reason is unclear requirements. Software malleability is taken for granted so much that the under specification and fluidity of requirements became a norm and canonicalized in “agile”. That’s not necessarily a bad thing, it does allow for quick advancement of what is possible but high failure rate is the price we pay. Second: unlike traditional engineering, there are not too many university or college programs that take rigorous approach to building software at scale. Till today, software is a free-for-all industry. That allowed us to grow very fast, but - again - high failure rate is the price we pay. Third - lack of formal standards and by that I mean not just APIs or protocol specs but formal requirements on things like performance, fault-tolerance, lifespan etc.
Also, bugs in software are seen as a fact of life. You can't get warranty on software (at least this holds in practice for most consumers). If MacOS deletes all your files, good luck proving that it wasn't your fault, and good luck suing Apple.
So this gives programmers a carte blanche to create crap, effectively.
That's a very broad big question. Like, do they really fail more? What's the numerator and denominator? There are are tons of high-profile failures, but there are innumerable successes as well. Do you count pushing the 100 or so versions of Chrome that have been pushed out, across millions of devices as one success, or a billion? How do you count projects that don't work right at launch, but do end up working okay after a couple versions?
I once saw someone complaining because they moved into a freshly-built apartment building and things were constantly wrong. A/C not working, shower not working, every time it came down to the contractor doing something wrong.
but the apartment building was finished, the project for building it didn't fail.
In the same way, software projects don't typically fail either, they just have a million things wrong with them.
I don't think I've ever actually seen a software project outright fail, it's more that it never lived up to expectations.
I'm not at all interested in finance / stock picking but found this to be one of the best walkthroughs of an ML system end-to-end that I've ever read. I'm not in the field of ML but I'm interested in learning more and this was fantastic, thank you.
As an owner of a vacation home and a large donor to homeless charities: this is completely divorced from the reality on the ground. It's a false dichotomy proposed as a way to block solving the problem of limited housing where it's acutely needed.
My ski house in Vermont does absolutely nothing for the homeless people in my neighborhood in New York. If you put someone in that ski house what would it do? Sure it would put a roof over their head, but there are no jobs, no soup kitchens, no homeless resources. They would need a car whereas in New York they can walk and use mass transit. The town in VT is already strapped supporting many in their community (I do charity there as well, and let me tell you it's more dire than much of the New York area).
The solution is to house them here in the New York area where they are (and in fact New York does a better than average job of this).
As for it being a misallocation, I own a $1M apartment in NYC and a $300K house in Vermont. If I just owned a $1.3M apartment in NYC my bills would be exactly the same, there would be 1 fewer "vacant house", and the homeless would still be unhoused. The real misallocation is how much I get paid as a software engineer relative to other professions of similar difficulty. I happen to spend my fun money on a ski house instead of a boat or a bunch of vacations, but there's no moral difference between a vacation home and other leisure spending. So really you are arguing that some people shouldn't have such a surplus when there are homeless people. Maybe that's true, but it's one of the most unpopular positions in American politics and if you are an ally of the homeless it's not a fruitful argument to make.
You seem to be focused on navigating the effects of the current system by relocating people. I'm not sure where you got this from.
I'm interested in modifying the system which allows for such outcomes, not managing the outcomes themselves. Please take a systems-level approach that seeks root-cause adjustment and not simply an amelioration of symptoms.
The root cause is primarily housing policy. Let developers build many apartments, and let them build small apartments. Zoning laws that make it a years-long process to just get a permit, or that force developers to build apartments with minimum square footage, or prevent large families living in a "small" apartment - these are all luxury laws forced upon poor people so that rich people can be more comfortable.
I count myself as progressive but am almost disgusted by how many progressives try to muddy the water here because they don't like to face the fact that they have to give something up to make their neighbourhood more accessible to those who are well-off people.
Anyone who doesn't take housing policy seriously on the issue of homelessness is either naive, or doesn't actually care about the issue and instead is trying to use it to push some other agenda.
You "system-level approach" is still missing OP's main point. If the system did not allow/encourage OP to buy his Vermont home, but instead 'successfully' managed to allocate it to a needing & worthy homeless person.... then what? As the old adage goes, it takes a village. This person still requires infrastructure to escape poverty/homelessness. You wont find that in a skitown in Vermont.
Where will this person find a job?
Where will this person get help organizing their lives?
How will this person transport themselves?
Where will this person get help for any significant issues in their lives (e.g. substance abuse, mental disorder, etc)?
This is where your "system-level approach" breaks down - you can't bring the support infrastructure for this to a small Vermony ski town and also to all the other small towns in America. This is, as your first post says, poor resource allocation.
I'm not sure why respondents are focusing on a specific home after it has been materialized in Vermont other than it serves as a specific example that any solution must address.
Zoom out a bit and observe the broader systems which conspired to guide the invisible hand to allocate a largely unproductive property in Vermont to exist in the first place. I'll be very clear - I'm not advocating for unhoused people from New York to inhabit this property. If that's how you've decided to read it I implore you to go back and begin steel-manning instead.
To be perfectly awful, 552K homeless out of 335M people is about 1.6% of the US population.
Even high-functioning and privileged individuals seldom have their shit together 98% of the time. I can't go 5 days without doing something chillingly stupid.
It is frankly astounding that we achieve better than 98% on any homelessness metric. A long forgotten ancestral memory says: there but for the grace of God go I.
Root cause: humans stink individually but we are robust in aggregate.
FB is pretty much on V1 of its GraphQL API with tens of thousands of engineers editing it for over a decade. Every single query is its own version, that's the point. If you want to change the semantics of a field, make a new field and leave the old one for the existing clients. What else would you have to version?
It shifts the complexity to the server side. The additional logic you are describing currently lives on the client, where it's harder to update and likely duplicative across platforms.
Every company I've worked for in the last 10 years had multiple apps across several platforms, each with many versions, all running in production at once. Even if you only care about the next version you are shipping and a handful in production that's a dozen variations.
In a REST paradigm you over fetch because not all of these variations need the same data, or you send less but then the clients thicker because they merge API calls and have divergent presentation logic, or you have a bajillion API versions.
There's often a lot of back and forth between the various teams for each rev of the API.
GraphQL lets the clients drive the definition of the data fetching. That's it.
95% of the criticism of GraphQL is people complaining that GraphQL doesn't solve the problem of preparing the API response for these different requests. While that's true, that's not what it's supposed to provide. Whether you have a REST API with 26 versions or a GraphQL API with 26 variations of query you're going to have to write a backend-for-frontend style service that resolves the results.
> 95% of the criticism of GraphQL is people complaining that GraphQL doesn't solve the problem of preparing the API response for these different requests.
This problem is solved by quite a few GraphQL providers nowadays. Hasura, DGraph (not true graphql but close enough), Prisma. I like Hasura quite a lot for many projects. Just define your database and you instantly have a full GQL API for the clients to use however they please, no backend required really. Doesn’t work for everything, but it’s pretty great for a wide swath of projects.
