quadcore

At least in France we passed a law that says that if you subscribed to a service online, you can unsubscribed online too (no idea if we're first, or last).

That's a technique often used by toxic people.

(Disclaimer: im no american)

I believe this is absolutely wrong. Quale 2, 3 and Doom 3 were critical success, not commercial ones, which led ID to be bought.

John and John were like Paul and John from the beatles, they never made really great games anymore after their break up.

And to be clear, that's because the role of Romero in the success of ID is often underrated like here. He invented those games (Doom and Quake and Wolf) as much as Carmack did. For example, Romero was the guy who invented percent-based life. He removed the score. This guy invented the modern video game in many ways. Games that werent based on Atari or Nintendo. He invented Wolf, Doom and Quake setups which were considerably more mature than Mario and Bomberman and it was new at the time. Romero invented the deathmatch and its "frag". And on and on.

Thats a good question. I wonder if security (hidden cameras and network and stuff) could be a reason.

I dont know that it's true but if thats the case then its also the case for pictures.

Which means we'd found the so-called copies.

Which I understand as, it's gota be determined the extent of the lying to determine the extent of the fraud ; some you-didnt-read-the-contract-well-enough responsability may incumb on the customer(s).

holding assets on their customers' behalf

Who said he was, him?

Of course Im playing devil's advocate here to illustrate the logic of the law as presented by our friend here.

The biggest misconception game developers generaly have about games is they think they are content like movies/series amd music. That is that the average player plays hundreds of games, one after the other.

Games are successful or failed killer apps. Like any other software mind you. The average player spend 88% of his time / money playing a very few hits like Minecraft.

Which solves your middle-games paradox: those just don't sell anymore. In other words, if you'd make a Commander Keen today, you'd sell 3 copies to your grand-ma (yes grannies play games now).

There is always those who come to tell: I have hundreds of games in my Steam library. "Yes me too". Yes you do and on average you guys still spent 88% of your time / money on a handful of them. They are exceptions of course. There is a line that's somewhere but nowhere near "games are content"

Repeat after me: emotional intelligence and situational awareness. You've been asked that question not for the answer but to see how you'd respond to it. He knows you're alone. So he asks. Will you loose your shit? Will you understand what he's trully doing? Have you prepared for it? How come you let such an obvious hole in your defense?

Dont ever ever make the mistake to think people are dumb. They play dumb. Most people are engineers just like you. Except they dont do the same engineering than you do. They do emotional engineering. People love it. They crave for it.

Do you get it? If you're not sure, then you dont get it. So get it. People dont trust an emotionally dumb person. Period. Trust me I know.

Thats your answers to all your questions but the product. You will sell once you're emotionally smart because of the strong effect it has on people.

Everyone has a boss including the person who reads your application and it cant be rejected if you seem to be a perfect match socially speaking.

Emotional intelligence is the crack in the wall. All they want. They could not care more about how good you trully are providing they even know what a good dev is.

Play the social game. Buy new clothes that convey what they want you to convey. Study profile pictures and craft a great one. Study their mindset.

Aim for quality, not quantity.

Finally, you can do QA? Congratulation, now you've been a QA for the last 5 years. Do what you need to do. Fuck em. After all, you've contributed and now youre dumped. Employee is not viable. A new director arrives and decides your career is over when you, as a nerd, created his own fucking job. So do it with a fuck em mindset. Beat them as their own game. And let it be known that employee is not viable (without unions?).

Good luck.

I had been on half a litter of veg soup plus 2 eggs plus 2 sausages, some bread, some nuts. A day. For months. And I felt absolutely fantastic. Now okay its a tat too short, lack variety and all, and its to note i wasnt working much. I have since got more resources and been able to eat a more balanced diet. But this gives you an idea of what we are talking about here when we say you can eat less. You still need some amount of calories every day but its really all different on many levels and no chance you go on 4k calories for no reasons other than "youre hungry". This 16 hours fasting is marvelous. It's all about the intestines somehow. You want them clean.

Please adapt to your own situation, you may have physical conditions that could affect your ability to do that, check with a specialist.

May I be brutally honest with you? I mean this to try of being of some help (how many times I wished people would just tell me what they trully think, I cant count).

I think you are trying to do two things here.

Most developers are mediocre and always will be. They just cant be autonomous like that. Growing and nurturing talented junior devs is a whole problem in itself. It's chaotic. You could but then sell him to the client once you have one that working good with a client. And again, you wont be clearing a backlog, you are recruiting and nurturing a junior dev for a client.

On the other side, there is the clearing the backlog problem for which you can use mediocre programmers. They dont need to be juniors. They just need to be able to clear a task decently well once in a while. This however can scale big. Think about how coding is trending toward AI-generated code. Most of the menial tasks and bugs and unit tests could be done by less than good programmers as long as you have the UX/UI to paliate the fact they arent autonomous. And of course some of them would learn the craft doing just that, get plenty of stars on your platform and then get properly hired for 100k a year.

I clearly dont have your experience on the subject, Im just sharing my 2cs based on my experience. My instinct would tell me to focus on the client need to clear the backlog, without adding more human management. But only you know what it's worth.

If I receive one PR and its not good then my dopamine system is gonna say: it's a fail. GitStart you failed me and now Im gonna have to tell my sociopatic boss that the PR was no good for such and such and such reasons. Awful experience.

If I get 3 PRs, chances are, one is gonna be good and then they never was a single fail. Or if none is good but a combination of them could be, again, way way less of a fail for the dopamine system. "GitStart, it rocks".

I think the key idea is definitely to ship a PR with no code. You redefine the whole freaking house.

Another idea, maybe your PR is just a hook with no code initially, and then once the process is done via your UI, the final PR is shipped out - or the initial PR is patched.

We can make it even easier to ask for emoji reaction to the PR description instead of a comment to make it 2 click to take action

Absolutely, this is an entire experience to rethink. If they love the experience, boom, the way I see it, you made it. Because when you think about it, you are changing things (very) deeply. Everyone ever wanted the backlog to be outsourced. I used to say, "if only we had fucking debugguers" ; to take on those nasty bugs that are essentially just a nuisance for the bottom line of business.

However it's gota be a procress for it to work. Brogrammers are just gonna mess the thing up.

I was thinking, maybe have a link in the PR for a receiving programmer to take on the PR, and then, use emails to get the programmer in the dashboard at key moments (brainstorming here, can only guess the details of how your thing work). With a dashbard for management (probably you have that already).

Think Jira, agile, process, industrialization, linkedin skill, etc. Cause the way I see it, you cant do it if you dont do it with deep integration. Otherwise human will freak out a thousand ways. Maybe have 3 different PRs for one task, the engineer can quickly browse. I know it sounds crazy but you know how this works: work from the customer and backward. Wouldnt you love to have 3 PRs you can browse and say: combine this and that and this and we good. Just throwing ideas out.

Really love that startup your working on. It goes beyond what the eye can see. Companies are bad at managing software development, they always were. They dont understand they need engineers - and technicians. They cant tell the difference, they only see programmers. With your stuff, one can imagine a future where they understand that (theyd hire engineers internally, and have technicians outsourced). I dont know. Im dreaming and halucinating at the same time, but seems to me it goes in the right direction.

Yes. Always the same though (maybe with some variants you write over time). I think the best might be to guide the receiving party so they act exactly like you want.

Example:

"Hello nice to meet you. We are a bunch of junior devs learning to make production code. We'd appreciate if you'd read our PR. However, if at first glance it doesnt look at all like something you'd merge, please simply send us a "nope" and we'll figure out why ourselves with the help of our mentors. Our goal is for you not to spend time on totally off-road PRs.

However if the PR is interesting to you, please proceed like you always do.

You can always reach us via [some form url that's automatically generated for that PR]"

Something like that that someone who can write and think has writen.

Take control at every step to prevent the receiving party to roam freely with the PR so to speak (unless it's decently good), because they might gonna go left and right - and south otherwise. They'll attack you on superficial thing. Make them a smooth funnel so they dont have to talk to nobody to move forward.

That's what came to mind.

P.s. or send them a url they follow entirely.

1. Read the PR in 15 min and come back here

2. How do you like it at first glance? A) very much, it's merged already, B) it's okay but I have feedbacks, C) not at all what we need sorry.

Etc.

From the comments I read I can tell the receiving devs can easily become grumpy if things are not as they want to the semi-colon.

A few ideas to solve that problem.

1. Have an internal team of experienced devs who make CRs and onboard the team of juniors on a new projects. From my experience, after a couple mistakes or misfit code, juniors adapt themselves, learn and end-up doing perfectly well.

2. When you submit a PR, submit a process with it (in a readme of some sort) with instructions on how the receiving devs should proceed with the PR. If they are not happy with it, maybe they can just say "not happy with it" and you take on yourself to figure out why. That sort of instructions. The last thing you want is them complaining they spend more time on it than simply coding it.

Im pretty sure the management of the human interface here is key because the only way this can work is if you've got off-the-charts feedbacks. You need processes for that (you probably do already).