tudelo

Most of my work has been in core infra at large companies. Having the code written faster does not change rollout velocity all that much... It does help with signals and idiot proofing on bugs but when things break and cost real (very real) dollars AI is not an explanation. In that instance, its not even close. Development might be 10-20 percent of the actual work to get a change out.

I seriously doubt it. Degradation would be in some part related to the conditions the painting was held in, which would be nearly impossible to backtrack outside of one-off case studies. Imagine a painting that was stuck in a room full of smoke -- or was put on some less than good backing paper/framing.

There has been some research on what causes degradation on paper/pigment but as far as I know much of it ends up as a mystery, a fact of time...

I mean if you don't have your company paying for it I wouldn't bother... We are talking sessions of 500-1000 dollars in cost.

The only counter I have to this is that there are some workflows that have test environments, everything can't or shouldn't just run locally. Sometimes these test take time, and instead of babysitting the model to write code and run the build+deploy+test manually, you can send it off to work until the kinks are worked out.

Add to that I have worked on many projects that take more than 20 minutes to fully build and run tests... unfortunately. And I would consider that part of the job of implementing a feature, and to reduce cycles I have to take.

After the "green" signal I will manually review or send off some secondary reviews in other models. Is it wasteful? Probably. But its pretty damn fun (as long as I ignore the elephant in the room.)

The ping pong video you linked is clearly fake. Look at the paddle... anyways...

First off, appreciate you sharing your perspective. I just have a few questions.

> I've gone back to managing the context window in Emacs because I can't be bothered to learn how to deal with another model family that will be thrown out in six months.

Can you expand more on what you mean by that? I'm a bit of a noob on llm enabled dev work. Do you mean that you will kick off new sessions and provide a context that you manage yourself instead of relying on a longer running session to keep relevant information?

> Unironically learning vim or Emacs and the standard Unix code tools is still the best thing you can do to level up your llm usage.

I appreciate your insight but I'm failing to understand how exactly knowing these tools increases performance of llms. Is it because you can more precisely direct them via prompts?

I am rather positive that if you were sat down in a room and couldn't leave unless you did some mildly complicated long division, you would succeed. Just because it isn't a natural thing anymore and you have not done the drills in decades doesn't mean the knowledge is completely lost.

Probably won't find it remote. I would say gov contractors / gov jobs could be chill.. not sure how visa would interact with that process, sorry.

I don't know what it is but in basically every major airport I have struggled to get an uber/lyft. I expect at minimum one cancellation...

Alerting has to be a constant iterative process. Some things should be nice to know, and some things should be "halt what you are doing and investigate". The latter needs to really be decided based on what your SLI/SLAs have been defined as, and need to be high quality indicators. Whenever one of the halt-and-do things alerts start to be less high signal they should be downgraded or thresholds should be increased. Like I said, an iterative process. When you are talking about a system owned by a team there should be some occasional semi-formal review of current alerting practices and when someone is on-call and notices flaky/bad alerting they should spend time tweaking/fixing so the next person doesn't have the same churn.

There isn't a simple way but having some tooling to go from alert -> relevant dashboards -> remediation steps can help cut down on the process... it takes a lot of time investment to make these things work in a way that allows you to save time and not spend more time solving issues. FWIW I think developers need to be deeply involved in this process and basically own it. Static thresholds usually would just be a warning to look at later, you want more service level indicators. For example if you have a streaming system you probably want to know if one of your consumers are stuck or behind by a certain amount, and also if there is any measurable data loss. If you have automated pushes, you would probably want alerting for a push that is x amount of time stale. For rpc type systems you would want some recurrent health checks that might warn on cpu/etc but put higher severity alerting on whether or not responses are correct and as expected or not happening at all.

As a solo dev it might be easier just to do the troubleshooting process every time, but as a team grows it becomes a huge time sink and troubleshooting production issues is stressful, so the goal is to make it as easy as possible. Especially if downtime == $$.

I don't have good recommendations for tooling because I have used mostly internal tools but generally this is my experience.

Jesus. I lived in NYC and white truffles at the right time were no where near as expensive. I can't believe they felt worth it.

Quitting nicotine is absurdly overblown. I'm sure me saying this will annoy somebody, but I think it's much more of a habit than a physical addiction and people hide behind the physical addiction as an excuse. Maybe if you smoke a pack a day it is a different beast but daily smoking is really not hard to kick.

From my experience the only "FAANG" that has tried to get me to do a hackerrank was the one you listed in your last sentence so you might have hit the nail on the head.

If you live in the USA you should be able to order online and then go in person to like a labcorp or whatever. If you ever got a drug test for a job, thats the sort of place that usually does it. I think some states you may need a referral but most you do not. For a hormone related test covering testosterone and other factors it is going to cost >100 dollars.

any more details on "positive effects"? Have you had blood work?

Thanks for the link. Don't know if you are affiliated but there is a lot of link rot going on there with external links.

And how much money might have been saved not having some of that information available later... because that is totally a good reason to burn history.

A whole Burrata on a pizza sounds like heaven... thank you for opening my eyes

> Is it OK to just say, "I'm happy doing what I'm doing"?

Depends where you are and what level. I think you owe it to junior engineers to help guide them. It may be that someone 1 year in the workforce is a highly productive engineer and doesn't need growth, but I can't say that is the norm. They may be mostly productive but some experience must be learned, so I would say you should push them to get out of their comfort zone.

Some companies do up or out until a certain level, usually around senior engineer. I don't really agree with that completely as I think a codified system like that lacks humanity, but it makes sense more or less.

100 percent agree on the 6 month targets... feels like groundhog day, adds tons of stress, does not benefit employees.

Not sure. If you work for a large company with a diverse set of products I'm not sure how you could ever be sure.

For example, is a car company making the world a better place? I guess it depends on your world view... but it is pretty easy to answer yes or no.

But maybe you are asking to gauge how many people are working in a place where they know(think?) they are making the world worse?

I rely only on print debugging purely due to lack of investment in my tooling, both by myself and my work environment.

The thing is, it always just works. I don't need to think about it. I write code in 5+ languages fairly regularly, with some frameworks that have really weird... "support" for dev tools.

But maybe I am just a bad developer with bad excuses. If anyone has been in my shoes and seen the light, would love to hear how you manage jumping in to multiple different languages and keeping a consistent debugging experience (or, at least, more consistent than print).

Are there not situations where a learned model could be insufficient due to lack of real-time learning?

It is my understanding that a lot of current applications take a ton of training time / computing power and it's not so trivial to do in the moment. I guess this is less of a theoretical problem and more of a practical problem though.

One way that I was taught is via the HTDP "design contract". So in this case a "docstring" translates to defining the method contact (its inputs and outputs) and the purpose of the function (what the function does).

https://course.ccs.neu.edu/csg107/design-recipe.html is a random link that describes all the steps, with something like 2. being the one mentioned (I think, I'm not OP.)

Are there any drawbacks that you have experienced? Seems a lot more simple than using most game engines...

Yeah. Hardly any testing as in even with every single covid symptom you could not get a test depending on your age and prior conditions. Now, you can walk in to clinics with no wait and get a rapid test ASAP. It's very different.

Every road having a toll is your idea of the future? Or am I misunderstanding something.

So, since you seem to have some knowledge here, what would you suggest a single engineer trying to make a somewhat scalable multiplayer game? Either instanced with <64 players or a more larger user count.

I did some experimenting with rolling my own networking layer in c++ and it was a lot of work, and tried to do it through unity but it seems to require quite a large investment in time to understand how networking fits in the overall picture of the game. But maybe I'm looking for magic where it does not or can not exist :)

One pixel at a time, how else?

Any more insight into blockchain stuff? It was my (admittedly basic) understanding that most of the money to be made there was from getting some initial supply or speculative price increases.

Probably to determine quality of employee and to fully understand the process. It seems pretty risky to just assume you're not gonna screw all that part up