This was my earliest use-case for LLMs and it remains to this day as the most compelling value proposition of all the fancy new LLMs.
I have always tried to abide by DRY in my programming career with the huge exception of writing unit tests. I made the mistake, early in my career when Test-Driven Development was all the rage, of making unit tests reflect the inheritance structure of the actual code. It just made sense. Needless to say, it quickly descended into the most bizarre manifestation of inheritance hell as tests randomly failed with no correlation to the changes done in the core code.
Hence, I resolved to make unit tests the huge exception to DRY. The more straightforward your tests are, the better. Endeavor that each test method up to a test class should read understandably on its own.
This, of course, made tests quite a mechanical chore to write. Which makes it the perfect use case for these large, verbose, and humorless daemons. Bonus that they are also very good at vibing out the set-up needed for a test so I can focus on specifying the test cases I want rather than setting up mock after stub after fake.
The output is also very easy to review and verify. I see no moral quandary in this kind of usage.
I've been doing full-stack Dev (mostly Django though I foolishly had a brief moment where I kinda thought Flask was okay then fell for the same dumb thing briefly with FastAPI) for 20+ years and don't feel marketable.
I went from jQuery to a brief dalliance with Angular to HTMX+_HyperScript. Everyone wants full stack Devs to use react and struggle eternally with insane dependency trees and challenging client side state management.
I like to build things that can be maintained in perpetuity by small teams.
I'm full stack for 19 years and I love React, and I've been laid off for 1.5 years now. This is a terrible job market right now.
That doesn't mean you don't have good skills, it just means that too many people have them. It happens from time to time in every industrial, for all skills.
Obviously, I don't have any good advice about how to deal with it.
I've been an AppSec engineer for about 12 years, but it wasn't until about 5 years ago I started working somewhere that actually paid a market rate. I wasn't living paycheck to paycheck for the first 7 years, but certainly wasn't putting much away.
Now, I've got nearly a full year of after-tax paychecks in savings. I could easily go ~18 months without pay without a change in lifestyle. I could stretch it out to 3 years with some belt tightening.
In about 6 more years, the house will be paid off and any savings I have could last even longer.
That's not rare for a SWE in NA. Difficult is another matter. Plenty of SWE's in NA are now staring down the barrel of not being able to afford their own home for much longer (or to afford their first home).
If you've been working for three years as a junior and just put down a big down payment on a house you can barely afford, yes, you're going to have problems.
If in 19 years as a SWE, you haven't saved up a lot of money, you are one or more of:
1. Incredibly unfortunate in the jobs you've been taking.
2. Have made some incredibly bad investments.
3. Are spending like a sailor, burning every dollar as it comes in.
4. Have gone through one or more absolute life catastrophes.
... Then yes, you are also likely to have financial problems if you're out of work for two years.
I don't mean to say that these are incredibly uncommon. They aren't, especially in people chasing the startup carrot and ending up with nothing but the brown, sticky bit.
But I think it's fair to say that a large number of people in the profession should have managed to avoid all four. (With #3 being the main 'avoidable' culprit, and with #4 being largely unavoidable.)
Consider that somehow, people making less than a quarter of our prevailing wages manage to live... Fairly comfortably.
The parent comment mentioned North America. This is huge. Tech salaries in Europe are half what they are in NA. In India, they're like 1/4 to 1/3.
Saving is absolutely important, especially in such a layoff-ridden industry. You should really strive to get at least 6 months of living expenses into savings.
My company pays 10k a year for an Indian contractor, full time. I don't know what their agency pays them, but it can't be even 1/4 of a typical NA SWE salary. More like 1/12th.
Most of Europe has social security and reasonable health care. Cities even have working transit systems. Living costs are massively different. I expect the costs in India will also be.
Not that it means you'll be raking in a lot of surplus money, but that's also not directly tied to the size of your salary.
I actually find the opposite. I don't actually think either of us are wrong, it probably comes down to what we got started with. I love that in Gimp layers can have totally different canvas sizes, and I prefer it's foreground select tool.
But most of all, any comparison is going to be silly. Photoshop has lots of amazing features and in sure is better in a technical comparison to Gimp in many ways.
A lot of times the best tool for the job is the one that works great for you.
Most sensors can be implemented in a way that enables self-calibration.
I'm oversimplifying it here, but the macro process is taking some known attributes and mapping them to what you are observing. For example, if you can detect people, and you know the average height of a person, you can compute where your horizon is, and where you should (or shouldn't) expect to see people in the FOV. You can do this with cameras, lidar, etc. When you have multiple sensors you can do a lot more to have them all sample an object in their own ways and converge on agreement of where they are relative to each other and the object.
I’m not sure this has much to do with vision as opposed to fancy self-calibration software. At least a few years ago, Tesla cars would be in self-calibration mode for a while after delivery while they calibrated their cameras. I think the idea is that it’s cheaper to figure out in software where everything is than to calibrate the camera mounts and lenses at the factory.
I see no reason that LiDAR couldn’t participate in a similar algorithm.
A bigger issue would be knowing the shape of the car to avoid clipping an obstacle.
It probably could, but I imagine a LIDAR system would need a similar (large) amount of training data to enable effective self-calibration across a wide variety of situations.
At some point, with enough sensor suites, we might be able to generalize better and have effective lower(?)-shot training for self-calibration of sensor suites.
Isn’t the model needed rather similar to what’s needed for sensor fusion in general? If you can extract features from each sensor that you expect to match to features from a different sensor, then you can collect a bunch of samples of this sort of data and then use it to fit the transformation between one sensor’s world space and another sensor’s world space.
There is actually a photo of a Model 3 in factory line doing that precise positioned target stuff, so they do that precise positioned target stuff at the factory. It's also instant compared to a 10-minute drive.
I think the real reason why Tesla is known to require 10-minute calibration drive is, they shipped APHW2 long before the software matured, so they needed means to do it after the cars were shipped "blank". Other manufacturers only ship finalized hardware and software, and so they don't need a scalable tool-free calibration method.
Anyways, my point is that, Tesla cars need calibrations like anything else. This is same for any multi sensor SLAM systems, whether it uses sets of color cameras or laser spinny thingy or laser flash cameras or laser flash color camera thingy or combinations thereof.
Python has nothing on the sprawl of nodejs packages.
It is a fair criticism and some languages do fare better than others. Python is kind of in the middle there in my opinion. It's pretty easy to keep a relatively simple dependency graph with a little bit of discipline.
reply