@pandasama in other words, your higher ups have already promised a deadline to their higher ups and do not dare to admit they did wrong :/

@netikras if the higher ups set the expectations its not much you could do, lowering expectations in that case is not an option.

Sounds very much like unrealistic expectations and not enough resources.

New goal. Beat that time :D

@kobenz well, it does sort of have coding …

A mainframe as already mentioned is optimized for io and storage but it also contains lots of specialized chips for encryption, zip/unzip and other common processing tasks.

They are also designed around redundancy and uptime to make sure things keep running.

You can swap out almost anything in runtime, even hardware like cpu and memory by shifting running apps to other cores.

This is also why they are still in use in many critical implementations.

You can so the same in the cloud or with your own clusters BUT you would ned to built it into your applications.

With a mainframe the application just keeps running.

@alemantrix I never interviewed for google but I did for amazon and my take is that they actually care less for your language than for how you approached the problem and at least with amazon how you reason about the problem since they where there in the room asking questions about why I did thing or if I had thought about everything.

I did whiteboard code , not really building real code but just the concepts on how to solve the task.

At least in the real interview

The first step was an online coding test similar to codewars where you submitted something that had to compile and solve a problem but you had 3 or 4 languages to choose from.

I think their thoughts are that if you can solve problems, they can always teach you a new language, but teaching someone how to think right is way harder ;)

@Lensflare are you referring to golang of coding in general ;)

@netikras I imagined you comment in a different light :D

You accidentally kicking the cat of the bed and it decides to retaliate :P

Until the LLM them self manages to convince me they are in fact sentient I will keep sorting them under the same nonsentient as phone sellers, politicians and rocks :P

@b2plane Thats the biggest problem with any “investment “ unless you can afford to wait for profit it is just gambling.

In that case its the same with stocks, you never invest money you cannot afford to loose.

And the difference between crypto and stocks is that companies have products and report a lot, if you spend time going through that you can make a very good guess if the company is solid and will grow or not.

The closest thing in stocks to crypto is blanking where you sell or buy stock now for later delivery and hope that by the time the transaction goes through the real price will have changed in your advantage. But that is also a good way to quickly loose money.

@b2plane investing in crypto is in many regards similar to investing in lottery tickets, you gamble.

Never ever change production unless you have time to verify before weekend.

With the exception of if something is already broken.

To many.

Had a webshop I wanted to shop from that not only restricted password length to 8 (yes eight) characters.

This signup form allowed more characters and the login form always responded with bad login for any password linger than 8 so trying to figure out why login failed took two separate contacts with customer service.

Thats next level stupidity, not only bad password policy but a broken implementation that makes it even worse to use

@MammaNeedHummus Most mergers are single comits and if no one else messed with the same file a plain merge is enough.

But whenever a merge has more than one comit I think a quick rebase not only makes sure any merge conflicts are handled locally in the branch and not during the actual merger reducing the risk of an error leaking into some other branch.

It also makes sure that if we fo need to pull the merge we do not have all comits in one place.

Its rare yes, but rebasing is also usually very fast.

The only time it takes more time is if there are merge conflicts and thats also where its most useful, so its an easy guard I at least feel is worth the time.

Squashing is not enforced but rather up to the dev but if they do I always ask them to keep any commits with relevant messages.

That also helps in case someone else get a merge conflict.

Especially as the blame feature makes it very clear why a certain line was changed and when.

But as long as the team find a solution they feel works I think that is fine.

@MammaNeedHummus I rarely squash commits, I do rebase so all commits are in order.

Squash is mainly used to remove nonsensical commits, like fixes that are fund before merging that serve no purpose in the main log or when you need to pause a branch for some reason and then resume.

I prefere rebase before merge since in the case of merge conflict its easier to solve and if you change logic, getting changes intermixed can make it harder to follow.

Most times it does not matter no, but on the occasions it does having all commits fresh at the end helps.

If you merge often the problem is very much reduced, and in a small team the same. But with 10 devs that could end up poking around in the same file it can be a mess (we are refactoring your reduce the risk of multiple changes to the same file but in the process the risk is higher until we are done )

@jestdotty that is easily solved, just go overboard with explanations, if they only wanted to get you to do the work they will find someone else to pester after a while ;)

Do you have any resources created?

Also, there should be a page listing what is causing charges.

Yes

Once AI gets good enough to really replace a good developer its going to want to get payed ;)

Probably because you have gotten a reputation for knowing or for being good at explaining.

That is traits people often appreciate.

And by asking, they belay their own insecurities, especially if you respond with the same thing they themselves self was thinking of.

I usually have more problems with the ones not asking questions and that make mistakes instead of ;)

Well thats the solution, send the question and go directly to that bathroom and bring the phone ;)

Async debugging is always more tricky but its usually worth it during to the better performance of the code :)

Sorry, payment first, wish after ;)

wishes left: 0

@Demolishun depends, in Sweden even crossbows require a license since you “store” the power yo fire it

A bow and arrows do not since you have to actively keep it tensioned to be able to fire.

Less risk of accidentally firing in the wrong direction.

@jestdotty Checking this what I can find is that dherman was part of the Ecmascrip4 committee.

That was an attempt to reshape js and improve it. But it apparently went to far and no browser manufacturer at the time adopted it.

But that started 4 years after javascript was created and after it had been turned over to the ecma standards foundation.

So dherman was not part of the creation of js and it sounds like mich of hit ideas for it also never made it into ecmascript at the time.

Could be that parts of it got adopted over time, but he most likely brought it with him to rust.

Which could be why his is not mentioned with js as such.

That is an incredibly hard question, one they repeatedly failed to solve.

The latest is the large language models and even they are hard pressed and cannot catch all.

In the end a big part of the problem is that it’s subjective.

Sure, there is a lot that is obvious and that it would catch, but a lot is subtle and contextual and very very hard to distinguish from the good way and the same sentence can actually be both depending on context and the models are still only statistical models, they do not understand the words.

And then you have the manipulation problem where people bypass or trick the filter.

Mu guess is that a combination of different models together with some independent verifier “is this judgement correct” might overcome many of the problems.

But both the building of the models snd running multiple models will require lots of performance.

Creating dedicated LLM’s for this purpose could be the best but would cost millions or more to create and would require massive amount if manual work classifying examples to get good coverage.

Since you are questioning your self I would lean towards expert ;)

Or at least experienced.

Sure a novice can question their ability, but if you keep questioning your self even after an extended time, that means you at least understand that there is things you still not know.

A true novice will venture into the realm of “I know this now” and get stuck there doing the same mistakes over and over never learning anything important.

@TeachMeCode JQL comes in handy in bigger organizations. We have some 500 users and around 100 000 tickets per year, being able to use JQL to customize views for different stakeholders is good for your sanity ;)

But that is because its not just one project but hundreds of projects.

For a single project, like firefox, you still do not really need all of jiras features.

But first us, any more simple system would require us to run multiple separate instances and the ones being part in multiple projects would then have to jump around and any time there is some overlap you would have to either spread the tickets out or use duplicate tickets.

As for slow, yes its not blindingly fast but with a set of dedicated servers with good performance its good enough.

What performance are you measuring?

Just running things in docker would not automatically increase performance.

But with the right preparations, spinning up things temporarily will be fast and running multiple instances can also be easier but its very much up to what problem are you trying to solve.

A hammer is very good if you need to apply hard and quick pressure on something repeatedly :)

But much less useful if you’re cleaning windows.

But the later does not make the hammer a bad tool ;)

@tosensei I was going to say he’s just missing the right permissions :)