How Does Floatplane Launch Updates on Time? (It Doesn’t) 

I’m in a team where crunch does not exist. I feel blessed.

It's the Scotty rule of engineering. If something is going to take two hours, you tell the captain four. That way if all goes well you look like a hero and if it doesn't, you have extra time.

Luke just figured out what all of the MBA community can't. Focus on making everyone as productive as they can be, that way they will be as consistent as possible. Then slap on some buffer and hopefully you can use that time to add on some nice extras or deliver early. It's like this stuff is simple or something and you don't need some useless uni degree for it.

Linus not talking for 8 minutes straight felt strangely cathartic 🤣

In my 10y experience in big tech, 99% of the time, the estimations are grossly wrong and probably a harmful exercise. I think asking for them often comes from a place of mistrust. The only estimations I've seen be accurate are at resolutions of "probably less than a week", "probably less than a quarter", "probably more than a quarter".

That one works for us when estimating larger projects (3-12 month 3-15 Devs): Break it down into epics Break these down to tasks that range roughly from 1-15 Person days in complexity Estimate every items with three estimates: "Best possible situation" "Average situation" "worst case, everything goes wrong" in person days. Make sure to sanity check your assumptions, esp. that you don't repeat the "all goes wrooooong" scenario in multiple items. treat every line as an independent distribution and mix all together. The Central limit theorem allows you to approximate the sum as a normal distribution. That's also why having many small estimations helps. Now you have a normal distribution with a standard deviation. Set your confidence interval somewhere where you cover 75-85% of that distribution. So you will come out somewhere larger than the sum of the "average situation" estimate but well below the "the sky is falling" sum. Add "communication overhead", "Client babysitting" and "project organisation" overhead as a percentage on top based on experience with the situation.

Under promise over deliver

last time you guys actually crunched was the LTT hackening and if i recall luke had fun

If you’re a crunch person, I recommend crunching and then uncrunching. Work for 10 hours for 2 weeks straight, and then take 2 days off each week for the next 3-4 weeks, however that math works out. I have a flexible schedule and I can bank time and take it off later, and it helps so much

Everyone just saying "don't bother with deadlines, just let people make sure they do their best work" etc do seem to forget that time costs money, you need a deadline, you need to make sure people aren't taking longer than they need to. If a project takes longer, you pay more wages, and if the cost for something is going to massively outweigh the benefit you're company is going to fail

Only estimation system I developed to reliably predicted real time which task would take to do properly is duplication of intuitive estimation. If estimation is done by junior that multiply by four.

Always do the opposite of Elon Musk when estimating timelines, you underpromise and over-deliver. At my office I have scripts for everything I do and it does everything for my job in seconds. Everyone else does things manually, so I give them the manual time, finish in 10 minutes, do some extra sanity checks of the results, f*ck off for a few hours, and still deliver it in “half the time” looking like I am a miracle worker 🤣

Picture in Picture on floatplane would be nice. I know it’s going to take time tho. Appreciate the work you guys do!

Scrum doesn't work for fast moving teams breaking stuff to figure out what works and iterating quickly with flexible deadlines. It works for slow methodical teams that have specific requirements & set deadlines where you know exactly what needs to happen and can easily estimate that workload. Scrum is constantly criticized in game dev because of this. It tends to get in the way because you're in endless meetings about how things went when your time would be better spent just making stuff. Kanban with milestones is where it's at. Set a few goals of what you want in your game in each milestone, break down your goals into work items/tickets, then you don't move onto the next milestone until all that work is done. No reflection on how the last sprint went, no planning the next sprint (where most of the time you just carry tickets over anyway).

What human organ you have? (In your background)

I hate it when given deadline, I really would prefer I give the time

I personally say it will take x time without testing / reworks. I am always right on that time within - a couple of hours but holy crap the testing / reworks after is wildly inaccurate.

No AGILE methodology will guarantee will help to go faster. I recommend the book "clean Agile" by uncle bob and in ti he's pretty clear about how AGILE is a tool to let you know as fast as you can how late you're going to be, nothing more

To gaslighting and girl boss your way to success

Pretty sure we all know which employee that was lol.

plz hrie me lol, i could literally work for nothing as i living in india

If you feel you need to resort to crunch to get things done then you're doing it wrong and shouldn't manage a company. Simple as that.

Why as a society have we decided that this particular field is worthy of consideration when it comes to crunch i work in retail and i assure you there is an army of workers that work 70+ hours a week putting your food on the the shelves, but maybe you dont care about unskilled workers, Im told nurses are notoriously understaffed and over worked why arent there RU-vidrs putting out RU-vid videos talking about this?

If you announce a game when it's horrible you shouldn't have announced it 😶

This is the same in so many industries. Even when estimating myself on projects i have to buffer my wxpectwtions when communicating withh coworkiers and even my family. There are always unforseen circumstances or missed details that need addressing that can drastically change the completion time line.

As a developer, it's not necessarily overconfidence. Even not having been pressured too much on timelines, I feel a sense of pressure that would cause me to underestimate my timelines.. I try to force myself not to do this but am still developing a comfort level with that. Obviously no timeline can ever be 100% accurate, you can and should factor in time for the unknown hurdles you don't see until you get to that specific problem, but this happens often when you're solving problems. That's life.

Im so happy to hear others complain about scrum

I've been a software engineer for about 6 years and providing time estimates especially when there are multiple people involved is always very tricky. Personally, I have a habit of underpromising. I feel like there is another thing at play here, the solution to a problem may change depending on how much time I have. For example, a task with one day might do everything what the acceptance criteria asks for but giving more time will make the end product more robust. As for the crunch, it's a part of life and once in a while is expected but if a team is regularly forced to put in crunch then there is a problem with either the team or the management.

Slip the delivery date or slip the feature, you can’t have both all the time every time without crunch.

Very innacurate estimates stem from bad requirements. As a developer i always 2x or PIx my estimates because I never get enough information to give an accurate estimation. There's always something missing or the requirements change mid work. Then again a lot of people forget it's called ESTIMATES, it's just a well educated guess sprinkled with some fairydust.

Buffering dev estimates i think its part of scrum

Dogs on scrum's method of estimation and then just does the same thing just in his head. You assign an arbitrary number of "effort/complexity" a task will take. Then over time you figure out that person's "velocity," how fast they get through that arbitrary number and then use that for estimates. Scrum has it's problems but you can dog on it for one thing and then do that same thing and say it's better because it's not scrum lol

Forget timelines and estimations, just do proper agile, and I don't mean scrum or safe. How about instead of trying to predict what will be done weeks or months from now, and getting it wrong, just get something small out now, get it in front of real users, and get as much feedback as you can. You will make a better product and might not even have to do some things. Especially if you're setting you own deadlines, just stop setting arbitrary deadlines.