ResearchCode

Learn the concept better, not an exception to an incorrect rule. It seems like the model architecture just isn't good enough.

LLM engineers rushing to hard code B is A in their "AI". They call it reinforcement learning with human feedback.

You need business with them to browse the internet and now to even buy a car. There is a word for this.

You don't seem to understand them. German law does not force you to have a three month notice period at the start of your employment, you can negotiate for a shorter period without the at-will part.

That's very courteous, 28 days is plenty of time to find a new tech job. A real courtesy would be a golden parachute worth at least 6 months wages if you get laid off without cause. That's probably not more than a US sign-on bonus.

The alternative is giving real contracts to international hires, who already have a proven track record (otherwise why would you hire internationally).

Trial contracts were meant for people straight out of college, but in a race to the bottom some companies have started pushing that line further and further, even having people move across the world for temp contracts. You can't complain about labor shortage while behaving like that.

Or you don't and end up making a non-functional website for the public sector for $100M. Software projects fail often, and not for the lack of trying, there is not yet any evidence that you can micromanage them into succeeding.

It's pretty bold to give a trial period to an international hire. Employment security is a good thing, and since wages are much lower than in the US, there is not much risk.

I don't see the risk. It seems German companies are making weak offers with "probation periods" even for international hires. One problem might be that such offers are not very attractive.

Get rid of the scheduling too if you're doing it too often. Two times a year is good enough.

You're not wrong. Applied ML articles are not worth reading.

They don't help you do that, even though poor non-technical managers might think they do. That's why good software projects don't use them. I don't see any story ticket velocity points used in Linux kernel development.

You can't estimate non-trivial software, and if you are doing trivial predictable work, you should be automating it, not endlessly estimating it.

I didn't say I would "deliver" anything. It's done when it's done. You can't predict the outcome of a software project. Many of them fail and micromanagement makes them more likely to fail.

Then get rid of the "points" and maybe the "tickets" too.

I don't think they did. If churning out low-quality code for 6 months was good project management, the Linux Foundation would be doing it.

Those are not important at all, or the top software projects would be using them. Linux kernel is doing fine without the velocity point story tickets. Agile "planning" which is used in worse software projects is snake oil.

It is, unless you spend too much time in a lecture format with too little deep practice. Taking work home is not a good solution.

Practice during school hours is more than enough. Primary education is not so demanding that you need more to succeed.

The measure is called an accepted pull request. You don't need a ticket to submit a patch to the Linux kernel. If you're in a dysfunctional agile micro-management environment with "stories" and "backlogs" then look for a real job.

It's not a problem, that's how you create software. You can put some of those initiatives on a "road map" if you want, but there must be space for them. 50% "slack time" is a good standard for software engineering. Your software engineers likely know better than your middle-managers how to spend that time.

The "intelligence" of large language models needs to be evaluated like the abilities of self-proclaimed psychics. You send your binary to an independent third party and who evaluates it on new problems. It's only a "Human eval" once.

We are already five years late in autonomous vehicles replacing all truck drivers. We will see if we even have autonomous driving "long before" 33 years have passed. "AGI" (rebranded AI after "AI" failed to deliver) will of course still not be a thing.

Come close to solving the toy problem of autonomous driving first, we're still waiting.

Join a team that doesn't do "sprints" if you want to do meaningful work.

It can be reduced, like by cancelling most meetings that could have been an e-mail.

It's better to go somewhere where your colleagues and hopefully management are intelligent enough to recognize loud laboring as vulgar and an anti-signal.

If you look at the valuation of companies that hire or were started by top talent, all companies should want them. Crab mentality can make you rationalize scaring them away.

There's an abundance of people that can talk but do less. Real tech talent are rare, not that you find them by algorithms quizzes.

If you're doing a PhD, that point is a weekly chat with your supervisor. I don't see why a few hour "rabbit hole" would be a problem in software engineering. If we're even discussing hours unless billing hourly, that's a red flag for micromanagement.

Those "rabbit holes" are where you learn. Saving hours is more important if you bill hourly, less if you are salaried.

That sounds like micromanagement. Are you a contractor?

Or as they call it outside of the agile industrial complex, a to-do list. Nobody is stopping you from keeping one.