idk why people always suggest for you to break down tasks into smaller tasks

I find I dread starting the thing and then I'll stop what I'm doing to check the task list and then it just makes that dread feeling show up again and laziness because I crossed things off. also what's written in a list isn't EXACTLY the best way to be doing something so then I start rewriting the list to be more accurate and that gets me all miffed

ooor I could just start doing the thing and just do whatever is in front of me without any micromanaging and before I know it I'm done and I don't end up procrastinating 5 times over 7 days and instead just doing everything in one evening... because it's just "do the thing that's out of place in front of you" and it's really smooth like that

dumbest advice

It takes a lot of administration overhead indeed but it makes progress measurable. It's also satisfying to deliver a lot by doing several tasks a day instead of one for a whole week. With small tasks you can swap out tickets easily during the planning before every sprint what makes the process agile. People love that. What size tickets should be to work on is something you learn trough the process in every project. It's probably a good a idea to automate much of the flow / administration and instead of fighting it, mastering it. Enforce great DX. Would love to create such tools / automation. I think if done right, it would boost the development extremely. If the administration is a lot of work, you'll notice that all devs gonna fetch a coffee before actually doing it or whatever. Snek has an amazing DX, it's plug and play -> first registered user is always admin -> database auto synchronizes -> consistent approach of doing things. Bordii was able to contribute very fast.

For most people it’s actually good advice.

@whimsical provided some good arguments.

@Lensflare thank you. Professionally, I do administration very well. Privately I drop it completely. I do work professionally completely different than private. Private is totally focused on fun and velocity.

@whimsical yeah, same here ^^

Yeah, I think it's usually 'management' that does this. They do things in a chaotic manner anyway. For them to understand the precise way of working of a developer? Nah.

Ideally management should understand how computer science or even how mathematics work: we use abstractions to model that which we are trying to create and mimic in real life. Not all can be modeled in exactly the same way and neither is reality like that.

I can relate to this as I've been severely micromanaged towards the end of my previous job and according to my metrics I lost about 60%+ of productivity because of it. I can also relate to the flow that you described; much better than all that micro-interruption.

I'm guessing this is highly task-dependent.

0. "Write me a function that outputs a 'Hello World, motherfucker'.". - you can do that thing in one go.

1. "Write me a clone of 'Tetris' but w/ multiplayer capabilities.". - you'd definitely want to break this down into manageable chunks.

well it's an advice even outside software. for those productivity people (mostly students). it's given to business people, too

while in software I used it... used it in game development (and didn't get very far when I did, attributed the issues to something else at the time), I didn't realize it was the task dividing that was actually the problem... in this case I just had a bunch of people go through my apartment and make a mess of it, and I had written down everywhere that needs fixing and cleaning after them. but it's just easier to be in a room or on the way to a room and fix/clean stuff just as I see it (which is also how I coded)... but then because it was a lot of work I would stop at arbitrary spots (put a lot of pressure on myself to NOT code this way and it made me dread it) and then I spent forever correcting my stupid todo-lists... and it's much easier I guess to see how annoying and unhelpful all this is with physical things than abstract things