People listen to podcasts because they are personal. If you keep listening is not just about the content but also about the style of the podcast, their voices, jokes, etc. Podcasts are deeply personal, I don't think AI generated podcasts will be of any value.
What could be nice though is if _I_ can tell an AI to summarize and read a set of articles for me which I can listen to while traveling or whatever.
Sure, there are general guidelines that can be applied in many cases (testing, keep it simple, ...). However, many things depend on the company and the team you are working in.
A lot about production grade code is also to make sure it's easy to read and understand (thus maintainable).
A good question to ask is also "What happens when X goes wrong?". What happens to the system in general, how critical is it, and how can you understand what happened. This is about logging and moire general observability.
In the AI/ML field production grade code doesn't necessarily mean that you need to have super abstract things. A lot of this is actually the MLOps part: getting the data to your model, saving the model in some artifactory, running inference, ... . To make this easier it's most important that your code is somewhat modular and not just a plain script that you run when you need it.
Also, don't be to hard on yourself. Your last two lines sound a lot like imposter syndrome. Look back at your code from 4 years ago and see how it has changed and how much you have learned.
As soon as you happen to have more than a 150 to 200 connections you really need to curate your feed to make it useful: Unfollow or click "you don't want to see this kind of content" for specific posts.
Anyway, LinkedIn is really slow and does everything to make it miserable. I believe it's only surviving because almost everyone is on there now.
What annoys me most now is the amount of auto-generated AI content. They all look the same, never really interact with the post in general. It's so annoying.
However, when you found a "community" inside LinkedIn it can be really nice interacting with them: posting, sharing, messaging, etc.
I use obsidian to keep track of most things that are unstructured. This is where I keep my todos, my personal project documentation, meeting notes, etc.
For managing clients (or contacts really) I would use a table or a spreadsheet. This is you most important asset to be honest. Separate clients, leads and other contacts in extra lists. Keep track of when you met them, how you met them, their email, company, phone number and any random comment to understand what you can ask them for. Also, connect with other freelancers and try to help each other out.
For time management I use clockodo although there are many options: toggle, clockify, ... They all have their pros and cons.
Payments shouldn't be too complicated. As a solo contractor you will likely only have 1-3 clients at the same time. So it shouldn't be too hard to keep track of incoming payments. When you bill them, add a calendar entry when to check if it has been paid.
Generally, don't over-complicate things. Use simple tools as long as you are a solo contractor.
Nowadays, there are a lot of positions that are devops engineers, but that's mostly sysadmin-like work but automating a lot by configuring systems through yaml instead of directly working on said machines.
Of course, there are also people who develop internal tooling, and platforms enabling the developers to simply create test environment themselves. The real problem here is that every company has their own version of what they think that is ;)
Backend developers might work on this a little bit, depending on the company but usually providing the infrastructure is usually not they main responsibility.
There are data breaches that leak a lot more information than just an identity. Sometimes the mere fact that your identity is in a breach is problematic already.
Maybe authenticity was not the right choice of works. I meant to say the authentic thing that is the company's business logic. IE the point of the website/application or the product is the data. Which for programmers that should also be a common thread.which is why its good to really define your data model first if you can.
Lol, linkedin really can do whatever they want and I am glad that they stop 3rd party companies scraping profiles, even public ones. I know that linkedin uses the data on my profile as well as my usage data to make money with me, I am not dumb, but that's kind of what I signed up for when i created an account
I have worked on algorithms and system analysis in very similar projects and it's highly doubtful that these results are worth anything.
The radar sounder design and the numerical studies are flawed due to the used simulation methods. Numerical simulations are computationally expensive (in time and in space). Therefore many approximations are made (e.g. no real antenna pattern, no influence of the rover, thin slices of ground that is being simulated and than put together, ...)
Reading such radargrams is like reading tea leaves. I am pretty sure that most of the echos in the radargram are surface clutter from bigger rocks or hilly areas in the distance. In one of our simulation works for a very similar project we have actually shown that this has a heavy influence on the radargram and is never considered in any of the works analyzing the results from Mars (or any other space object).
These projects are extremely political even though they shouldn't be. Groups that have had instruments on previous missions will be part of the next mission, too, because they have flown instruments already. So, any study or inclination that the instrument as it is does not work is buried quickly and often unknown to many of the people in the science teams, too.
I know, it's quite cynic but it's my experience and I know that I am not the only one feeling that way. So, while the rover and the measurements themselves are impressive, the analysis is wonky at best.
This surprises me, I have seen ground penetrating radar results that have shown buried items which have then been dug up, why is this result different?
What does it matter if it's calibrated on earth? If the problem is the antenna pattern, influence of the rover itself, etc, why can't it be calibrated with the exact duplicate of the rover we have?
Radio waves propagate at different speeds through different mediums so the GPR gain and time window have to be calibrated for each soil type and other environmental factors like how wet the ground is. Once calibrated, then any deviations become interesting. Otherwise it’s just a bunch of sensor noise.
Correct. The easiest way to calibrate a GPR is to stick a metal plate in the ground and cover it with a few feet of earth dug up on location. Can’t do that with some awkward rovers and an experimental helicopter.
NASA can do some fancy signal processing to get some useful data but until its properly calibrated, any interpretation of that data especially visual should be taken with a Phobos sized grain of salt.
I still don't understand. Even if you are off about density, aren't you studying the differences in density, so that the image you generate would still be showing where those differences are located relative to each other -- even if scale might be somewhat off if you have your base density off? It doesn't seem like it would be abject failure, but more like incrementally less useful. It sounds like you are saying it is almost at abject failure on the scale of usefulness.
Yes and no. The radar isn’t only looking down into the ground. The antenna pattern has side lobes which can potentially generate large echos in the radargram, e.g. from rocks on the surface etc. you only know that there is something in some distance (or rather time delay).
The useful signal is extremely weak anyway and the clutter from the surface hides the useful signal in many cases unless you habe really strong scatterers (large and highly reflective) buried in the ground.
Plenty of commercial GPR devices operate on Earth just fine with the explicit goal to detect changes in the subsurface's dielectric properties. It doesn't matter if you're on Mars or here, GPR works in the same way and I'm pretty sure that the antenna and the signal processing has been designed for the purpose, possibly even more meticulously than the antennas of commercial GPR pushcarts. Your comment makes something simple sound highly involved and problematic.
Your understanding is correct. It's about detecting variations in dielectric properties across layer interfaces. GPR works just fine for that, whether here or on Mars. The other commenter's negativity and theorized worries about side lobes and reflectors are unwarranted.
NASA isn't doing anything here but providing the platform for the instrument.I mean, that's a lot but they are not the one in charge of running the instrument. The science teams are. GPR is a complex topic and *maybe* these signals contain the information that they think they do, but it's unlikely in my opinion.
I think the main problem of the current setup is that the science teams are not balanced enough.
The radar sounding science team is mostly geophysicists because the interpretations are geophysical in nature, but there are not enough people who are experts in radar sounding, radar system and radio frequency wave propagation in general. The reason for that is, that this is not considered science and is looked down upon as mere "engineering".
Privatized exploration would initially solve some of these problems for sure, but once a group of people and its structure has manifested I believe they would eventually suffer from the same problem.
Anyway, this is a pretty complex topic which covers many aspects such as research funding, incentives in academia, vain egos, etc.
The public sector doesn't have a monopoly on internal politics. Posturing between departments to be included in the next big initiative happens in lots of companies.
That's not guaranteed. Really it's a question of incentive structure more than public vs private.
For example there are cases I can point to of poor competition and high costs in NASA picking private companies to do big cost-plus development contracts, and cases where they did fixed-price contract bidding among a larger pool of competitors and got much better results.
While that might be true the costs of going up there are so high that there won't be 10 companies who get a crack at it.
Besides, the radar isn't the only instrument on the rover. There aren't many companies/groups in the world who have the know-how and financial means to do what NASA does here.
It feels like hybrid is always the worst of both worlds.
It's very likely that most people are actually in office and there is a unspoken expectation that you are in the office at least a couple of days. Typically, the work culture is centered around direct conversations in the office. If that is the case, you are more likely to succeed if you are in the office. Few companies or teams are looking for better tooling to support remote or hybrid work.
Companies that have a great remote culture are all about async communication. You also don't necessarily need dailies to be a live event but each team should figure out what works best for them in that regard.
What could be nice though is if _I_ can tell an AI to summarize and read a set of articles for me which I can listen to while traveling or whatever.