How do you approach complex tasks full of unknowns? Feeling stuck and overwhelmed
Posted by xeviltimx@reddit | ExperiencedDevs | View on Reddit | 67 comments
Hey everyone,
I'm currently stuck at work and could really use some advice.
I recently joined a new team, and I don’t know the product or the people that well yet. I’ve been given a task that has a lot of unknowns. It’s not some massive, staff-level project - I understand it’s a doable, mid-to-senior level task. But there’s just so much I don’t know: unfamiliar terms, systems I’ve never worked with, processes that aren’t fully documented, and references to past discussions I wasn’t part of.
I’ve read some documentation, had a couple of syncs, but I’m still frozen. It feels like there's a huge fog over the whole thing. I’ve been putting off diving into it properly for over a week. I keep trying to “start”, but end up bouncing between tabs or feeling mentally blocked.
The thing is, I know I can handle it - I’ve been in development for years, solved harder problems before. But for some reason, this time it feels like the amount of unknowns pushed me past a threshold, and I can’t seem to push through.
I’m basically looking for advice or frameworks on:
- How to approach and break down a task like this
- How to prioritize what to learn first (e.g. start with a glossary? diagram?)
- How to stay calm when the scope feels blurry
- How to be effective when ramping up in a new team and a new domain
I’m a mid-level engineer very close to a senior promotion, and I feel like this is exactly the kind of skill that separates a senior from a mid - being able to handle the messy stuff with confidence. So I want to improve here, not just push through one time.
If you’ve been through something similar, I’d love to hear how you approached it. Any tips, heuristics, or mindset shifts would be super appreciated.
Thanks!
davebren@reddit
I like to focus on the most core problem with the least certainty around it. Doing this is the fastest way to decrease the overall uncertainty of the task, and expose any fundamental issues early on.
SamPlinth@reddit
Have you tried asking to pair-program with someone that knows the project?
Many legacy systems have gotchas they you cannot anticipate. The only way to know about them is to have an experienced (with the system) dev point them out. If someone doesn't guide you through your first tasks, you could easily end up with a rejected PR - which is a waste of everyone's time.
You don't need to have someone continuously pairing with you, but having them describe the steps you need to take, pairing with you if you don't fully grok the area you are working in, and checking each step that you are not sure about is a good way to learn the system. And take copious notes so that they don't have to explain things twice. (Having to explain the same thing twice is super annoying.)
No two systems - or their domains - are the same. If they expect you to be able to just jump into a code base bash out code then they are being unreasonable.
grilledcheex@reddit
This should be the top comment. It is way too common to forget you’re a team. Pairing is very effective as a general approach, in OP’s situation even more so.
TheOnceAndFutureDoug@reddit
If you need to just get started? Pad estimates by at least 50% (usually double, really) and get to work.
If you have time? You create a technical brief that breaks the project down into tasks and flows, figure out where you have blind spots and don't know what needs to be done and you figure out the spikes to do to gain certainty.
If you're unfamiliar with spikes, it's basically small test projects and experiments. The code you're producing isn't inherently for production (though it's nice when it can be) and you can drop the project as soon as you get to the point of clarity. The goal is to find answers. Any other result is a bonus.
Cahnis@reddit
My PM almost had a heart attack when i padded the estimates. It was incredibly stressful. On a new job too.
TheOnceAndFutureDoug@reddit
Sounds like a shit PM. :D
xeviltimx@reddit (OP)
>that breaks the project down into tasks and flows
that's where I'm stuck. to do that I first need to understand the unknowns which is too scary for now. and i'm trying to understand if there are any lifehacks about how to split "tackle large task" into pieces first. like some checklist or something to help with do this, do that: like go through all the docs you have and write down all the unknown abbreviatrions, then try to build some schema, etc.
boring_pants@reddit
So start by understanding the knowns.
What are the tasks you can break down and understand?
The unknowns become much easier to reason about once you have a good understanding of the "knowns" around them.
If you know that you need to do some magic with data from the database then a good question is "so what does the data we have in the database look like?" That helps you constrain your solution. A million different things might be cool, but if we don't have the necessary data in the database then that's not gonna happen.
Perhaps you have to call some external API. What does that API expect? That again constrains you. Whatever you do, it has to end up in a shape that can be passed to that API.
Find the constraints, the limitations. All the "knowns", the interfaces you have to use, the data you're given, all the things that narrow down the decision space.
F0tNMC@reddit
I hear you. You can't know all of the tasks and flows, especially in the beginning when there a lot of unknowns. What you can do is figure out what the major steps *might* be or *could* be and write them down. And then start working n the smallest thing that can get your further down the path towards completion and more understanding. Then reassess your plan and revise as necessary and pick and execute the next step.
TheOnceAndFutureDoug@reddit
Nah, you don't. You break it down into a bulleted list and keep refining until you head a dead end, but move on to other bits. Whatever the task is you can always lay out way more of it than you "can't". Make logical leaps and assumptions, just make sure they're clearly marked. If you get to a point where you literally can't progress then you've hit something that either needs more discussion or a spike.
If you have a project you genuinely can't even start because there's just too much you don't know, then you need to go back to planning. You should know what you want to build just maybe not how. If you don't even know what you want to build then you've skipped important steps.
high_throughput@reddit
This is what they get seniors for. Navigating uncertainty and thriving in ambiguity.
Just get comfortable saying "let me look into it" and give off an aura of calm while keeping the panic on the inside lmao
Cahnis@reddit
thriving is a strong word, even at senior level it sucks.
Nuzzgok@reddit
Acting confident is the key. I still freak out the same when faced with uncertainty but my poker face is what pays the bills, more so than any technical skills
Material_Policy6327@reddit
I hate ambiguity but love the senior pay so I deal with it lol
TheOnceAndFutureDoug@reddit
Man, I love the ambiguity sometimes. Exploring options is fun.
Material_Policy6327@reddit
Exploring options is fun so long as you don’t have directors and pms breathing down your neck lol
ItsOkILoveYouMYbb@reddit
You really have to shift into the not giving a shit mindset, and give them time expectations that are way longer than you feel are internally reasonable. But once I started genuinely not giving a shit whether I keep the job or not, because I've been pissed off an disappointed too many times, directors and pms and external teams breathing down my neck didn't matter anymore. Eventually people get the message, and when you deliver they stop breathing down your neck as much and start defending you during uncertainty. At least that's been my experience so far.
And the people who don't stop pestering and try to micromanage due to their own anxiety I genuinely completely stop responding to them. It helps to have a boss that (eventually) completely trusts you though.
Only thing I still can't stand is external dependencies on IT teams excessively offshored and them being completely unreliable.
c3hearts@reddit
To put it simply we build the product, not them 🤷♀️ seems like tech has forgotten the buck stops with the engineers.
xeviltimx@reddit (OP)
>Navigating uncertainty and thriving in ambiguity.
Yeah, I kinda understand that. But the problem is how to proceed exactly. But eager to learn...
turningsteel@reddit
Well you could do what I do, which is look at the code, assess the options and then develop decision paralysis before choosing one at random and hoping for the best. No I’m kidding, don’t do that. It’s a bad habit of mine I’m trying to fix.
imagei@reddit
It’s hard to say really, as your description is as vague as the problem you’re describing 😂 but I’d say:
Talk to people, you’re new, that’s expected! Couple of syncs was clearly not enough. You sat with an experienced dev and ran the architecture with them on a whiteboard? After a meeting like this write or draw your own understanding of how stuff works and talk again. Twist until you get it at least somewhat right.
Then start making some changes and then talk to someone about it asking if it’s according to the team standards etc. Speak in some remaining questions.
Is there a test suite? Maybe start there and consult if this is what’s expected after you have a first draft.
Or you can start making bold changes, and after a day or two show it to someone as a experimental draft and ask for feedback.
Yes, all my suggestions are about talking to people , sorry 😉
aa-b@reddit
In my head, understanding systems at a new job is like solving a really hard jigsaw puzzle without a picture reference. You stick together little clumps of related knowledge and hopefully find some corners and edge pieces that feel more solidly anchored to your past experience and background.
It can take a long time for the clumps to start resembling anything like a complete picture, and in the meantime you're still expected to do useful work around these random clumps of stuff that might be in completely the wrong place, or upside down.
At least it's usually rewarding, because once you finally understand it's crazy how much easier it is to get things done. It never seems to get easier though, and if anything it's worse because people tend to ignore it more when young people make mistakes.
As a 40-year-old developer in a new role, I try to avoid saying anything obviously stupid, and to keep my mouth shut when I'm completely lost. YMMV, but it's easier to work with a slow developer than a bad one.
BrazenJester69@reddit
Real talk
Wide-Pop6050@reddit
You just have to start somewhere.
Who gave you the task? Ask them for the requirements. Then ask every other team who touches this for their requirements.
Ask them to walk you through their current process. That will give you the chance to learn more and you'll see what the weak parts actually are.
It's not a weakness to say "I don't know". Also people realize you're new and need time to acclimatize. Re-word it as "I'll look into it and get back to you" - and then do get back to them. Getting back to people when you said you would, and in a thorough way, generates a lot of trust and good will.
Agree with pad all estimates by at least 50%. Don't be hesitant to say that you'll look into it and then give an estimate.
You're senior enough now that you don't have to be "yes ma'am yes sir" at all. You are the SME here, you will do whatever research you need to and then decide. That is in your power
CapitalCheese@reddit
I'd recommend doing something to organize your thoughts outside your head. You won't have the whole picture in your head for a while, and if you wait to fully understand your project you'll never get anything done. Instead just start writing down what you do know, and try to physically organize that information in a way that makes sense. Then write down what you think you can do with that knowledge. It'd probably help to reframe your requirements in your own words too.
When you're stuck with more unknowns than knowns, you'll have to rely on context and intuition. Think of it like being told to identify what's in a box only by touch, without looking in the box. You'll have to spend some time feeling around and trying to identify individual parts of the thing, and imagine how those things in context of each other make sense. Eventually you'll have identified enough individual parts to have a pretty good idea of what the whole thing is.
It also goes a long way to believe you actually can figure it out. You just haven't found the right approach yet.
Tervaaja@reddit
Ask, ask, and ask more. You need to talk to people until you understand what you are doing.
deuteros@reddit
This happened to me when I started my current job. I was pretty senior when I started, but most of my prior experience was working on customer facing products and services. The team I'm on now is part of my company's data platform, and I knew nothing about big data or data engineering so there was a huge learning curve despite.
I was given a project to enhance a service my team owned. The scope was vague, and so was my understanding of the current implementation of the service. One thing that really helped was leaning a lot on the product manager to come up with really concrete requirements for the project (i.e. when this project is complete, what functionality should exist, what will customers be able to do, etc).
I also spent a lot of time talking to people who were familiar with the area I was working in to absorb some of their knowledge. Eventually it turned out that lots of people were making assumptions about how the service currently worked, and all of them were wrong and the service didn't work the way it was supposed to. I eventually did come up with a design plan, but it took several iterations, and my earliest designs were just crap because of knowledge gaps I had.
But nailing down those requirements early will really help a lot when you have a project with a lot of ambiguity. Seniors can work with ambiguity, but the end goal should be fairly well defined and concrete.
tanis112@reddit
There is a lot of great advice in this thread that isn't worth me reiterating, but for what it's worth, I read Thinking in Bets by Annie Duke once I got into a position where I had to manage many unknowns and iterate over the approach I was taking, and got a lot out of it.
garfvynneve@reddit
BanaTibor@reddit
Sounds like you still miss some domain knowledge both in the product and in the development process. My advice is to forget the documentation. Write down your questions, what a term means, what XY process consists, etc.. Grab a senior engineer, and ask your questions. Start with high level big picture and gradually dive into details.
This might be too much for one session. Pick the part of the task which is the clearest. If you grouped your questions you already have a partitioning of the task, and focus on that. I suggest you to start with the actual development. Which repo do you need, how is it built, anything what you need to implement it on a branch. Implement it. Then you can focus on the next step of the delivery process.
I like to do jigsaw puzzles. A problem like this is like a jigsaw, start with the fairly certain parts which are the edges, this is what you know, and when you have completed the edge you can focus on finding the next piece. (Advanced method is to grab a random piece and solve the problem from there :) )
Divide and conquer is the name of the game. Isolate a part with the least amount of unknowns and build from there. I think you got this specific problem to throw you into deep water, where you can sink or learn a lot, and I am not sure if sinking would mean failure if you learn a lot during the process.
Guisseppi@reddit
One of my first tasks at Amazon was that they wanted a widget that could “fetch data from anywhere, and display any type of data” with no proper onboarding and 2 weeks to deliver
ryuzaki49@reddit
It's doable by a mid level engineer that knows the product or at least knows who to ask questions to.
I was in that position. New to the project, asked for a task that sounded easy but took 3 months to complete. My mental health was abismal.
There's no way around not knowing. You can only go so far by yourself. You have to ask questions. It's better to be considered useless because you ask too much rather than being considered useless because you didnt ask anything and failed to deliver.
joshyatharva@reddit
This is a perfect use case for copilots (Cursor, Claude-Code). I’d suggest first opening Cursor and asking it to create a flowchart of the part of the code you’re working on. This will give you a clear idea of how the code flows. Then, traverse the code manually to understand the nuances. After that, ask Cursor again to break down the problem statement into smaller chunks (don’t ask it to write the solution - just to divide it into very small steps). Modify the steps if you feel something is off, then create pseudocode and start implementing.
I’ve had much better results with this approach.
P.S. If you’re unsure which model to choose, try Sonnet-4 and GPT-5.
vtmosaic@reddit
I have been where you are many times, since I've done a lot of contracting in my career. It's a slog, and exhausting.
My current employer embraces AI, and it's been a game changer in this area of my work. Now I have a helper who can read, research, and document those findings in a fraction of the time it used to take me. And then, as it learns, I can interact with it to do my analysis and design, help with my test planning, and generate documentation.
It feels like I'm wearing a mech suit! I've never been so productive at learning how to maintain and support a new-to-me application and its components.
Bowmolo@reddit
Without telling the problem at hand, you are actually asking for a generic, always applicable method to solve any complicated problem. If that would exist, everyone would be a senior.
The point of being a senior is to have a intuitive, non-explainable feeling - based on tacid knowledge gained by experience - where to start, famously expressed by the saying that true experts don't need a plan. (Obviously, this is bound to context.)
You have knowns, known unknowns, unknown unknowns and also unknowable unknowns.
Don't care for the latter ones, there's nothing you can do about them now.
Start with some area where you have some knowns and a low amount of known unknowns. Explore the latter, based on the former. If you stumble upon a unknown/unknowable unknown, good, you just made progress, because it's now known. If you convert any unknown into a known, good, you just made progress. If you're stuck somewhere for too long, explore a adjacent unknown.
(Literally) Draw a picture of what you find out. Help your brain to make sense out of you findings by visualizing relationships. Be prepared to restructure/redraw the image multiple times as you learn more.
I know that this is horribly generic (and hard to grasp), but as already said, without the concrete problem at hand, it's virtually impossible to give concrete advice.
Bowmolo@reddit
Minor correction: Maybe I overestimated how well-known the saying "true experts don't need a plan" is.
For those that are interested: It originates in research in a field called "Naturalistic Decision Making" and is well-supported by evidence collected / research done by Gary Klein. He found that professionals don't follow a formal planning/decision-making process but use their intuition in ~95% of cases (with better results than a formal planning process). The Dreyfus model of skill akquisition also points into that direction. Both build upon Michael Polanyi's research on tacit knowledge (from 1958).
StylesStMary@reddit
This is good advice, but it sounds like they’re paralyzed. Sometimes the best way to get out of this is to just start somewhere. If you have say 4 things you could do, don’t overthink or overanalyze it, but just randomly pick one. Doesn’t have to imply you are bad at prioritizing.
Keep at it, and hopefully the fog eventually lifts.
Bowmolo@reddit
That's what I hoped to get across with 'start in some area...' while trying to prevent that he picks one, where no progress can be made.
Refmak@reddit
Do due diligence with proper research first of all. Ask any question that comes up.
But then don’t be afraid to fail at first, but make sure to do so fast. People love drip feeding information as they see “a thing” - doesn’t matter if it’s working up for the purpose or not.
“Ah, but actually this won’t support the process because…”
“We won’t be able to use this since…”
kutjelul@reddit
Besides other comments that are really good: try to break it down into smaller tasks that are easier to reason about
NonchalantFossa@reddit
Something that my senior did when I joined a consulting gig was to give me a very simple ticket like "add this behavior to this button". It was just an excuse to get me started on the frontend and look around in the codebase. Then, I added some small SQL query in the backend and I built up from there.
I think trying to find the entry point of a project is also a good start: finding the main flow, core components, basically what is called in the "main" file when the application starts.
Something else I'm looking into is use git to see where the most changes happen.
For example,
will show you the files with most commits, you can use
--sinceto select from a certain date, as some older files that went through a lot of changes might not be relevant anymore.Here's an example of looking for the files with the most commit since the beginning of the year, in the
numpyproject, I'm filtering on the Python files. There's a lot of test files so I know a lot of the current activity/effort on the repo must be on those features and I can start and read.Another interesting one is getting the number of lines changed instead of the number of commits, they might be correlated but not the same. It's a bit of cursed
awkI'll admit it but useful nonetheless.Another one is looking into CI/CD or deployment pipelines and see what it takes for the app to be deployed. You can then try to go onto the dev environment and deploy a "dumb" version for yourself. Depending on how complex the setup is, it might take a week or two but it's time well-invested imo.
03263@reddit
Typical process is like, ask a lot of questions, start working even if I'm blind and have only a vague idea, write down all my new questions and ask those...
Sometimes it's like pulling teeth and you can't get answers until you've already done the "wrong" work especially when clients are involved they don't know what they want until they see some demo product and then start pointing out how is not what they wanted. Well they never told you what they wanted but, you can't say that, you just have to go revise it and keep billing them.
PayLegitimate7167@reddit
This sounds like me. I’ve been told it takes 6 months to properly get productive
Dexterus@reddit
Make a list of questions and start hunting down people for the smaller stuff. Once you get into the bigger stuff, hunt down more people and have bigger chats or calls.
pardoman@reddit
Write your plan in a document you can share with other team members. Include questions you have. Share the document with your team and gather feedback. If feedback is not sufficient, set up a meeting with your team to discuss the proposed solution and go over the remaining questions you have.
Your job is to navigate the complexity of the business, not to have all the answers: get those answers from the appropriate sources.
Good luck.
Historical_Cook_1664@reddit
Also include stuff that follows from the information you're given but is obviously wrong and have people sign up on this.
Efficient-Design-174@reddit
Start filling out a good Technical Design Document. Show it to people who know what they are doing. Incorporate their feedback. Give credit where it's due. Repeat until there are no more holes left. Then start implementation, disagree and commit style.
drcforbin@reddit
I heard somewhere that that's the difference between junior developer, sr. developer, staff developer, etc...at each level, you're dealing with more and more ambiguity. On one end, change this func in this file this way to fix this bug, at the other end, find a way to integrate AI into the product for buzzword compliance.
Find a starting point. For a concrete task I usually find an actual entry point, like "what triggers this" and follow it around the codebase. For a less defined task, I usually end up spending more time studying the product and then drilling down.
Getting into senior, lean on your team. Get them involved, ask them for help and to share knowledge. Eventually you'll be delegating tasks, and bridge building is important. Later you'll spend a lot of questions talking up, trying to understand the need and requirements and translating them from whomever started the initiative to whomever is going to be implementing. Later on still, you'll be the one everyone is asking.
DeterminedQuokka@reddit
This is true.
Junior is “do this”
Mid is “solve this”
Senior is “build this requirement”
Staff is “does that cloud look like it might be a requirement”
TheOnceAndFutureDoug@reddit
I think this is the third time I've quoted myself for this... I have a shoelace analogy I use:
Junior: I know how to tie my shoes (mostly) but I'm going to need you to watch and I'm going to need help on the regular.
Mid: I know how to tie my shoes and I have some thoughts about shoelaces in general. You can kinda just let me do my thing and check in every so often.
Senior: I know how to tie my shoes and your shoes. I've tried a bunch of different shoe laces and styes of tying. I have thoughts on all of this and I will tell you about them if you ask. You're probably going to ask.
Staff: I don't tie shoe laces as often as I used to but I've forgotten more about shoe laces than you know about them. I'm the person you come to for deciding how we as a group tie shoe laces, which ones we use, how we talk about it, etc.
Lead: I make sure you're all tying your shoe laces like we (Staff) have decided. I make sure the person who needs to be tying a shoelace is doing so.
Manager: I talk about shoe laces with people who barely understand shoes. A lot. I make sure my engineers have plenty of laces to work with. I try to keep other people from changing our laces too often at random and inopportune moments.
Project Manager: I make sure we have a steady stream of shoelaces and that everyone is keeping up with their shoe lace quota. If, for some reason, I'm part of product I also help them add extra shoelaces we didn't agree to do initially and just hope we can pick up the slack to get it done.
Product: I think about shoelaces conceptually. I have "interesting" ideas about how we could "improve" the shoelaces. I heard about a new shoelace buzzword and that our competition is also hearing about it so I'm throwing out all our current shoe laces and we're pivoting to velcro now.
Executives: I don't know what shoelaces are but I once ate a rubber band and I'm sure it's the same thing.
snorktacular@reddit
I feel like I'm over here advocating for sandals
DeterminedQuokka@reddit
I’m advocating for everyone getting vessi shoes so we never have to tie shoes again
drcforbin@reddit
It makes me a little sad how accurate this is, but I really appreciate your posting it again
armahillo@reddit
Can you pair with someone with more domain knowledge?
When I’m tackling a tough problem I give myself one day to spin my wheels and try to figure it out. If I still feel lost, I reach out to my coworkers and find someone who has the domain knowledge that can help orient me.
The worst thing you can do is keep spinning your wheels and feeling lost.
dijkstras_revenge@reddit
Ask ChatGPT
throwaway1736484@reddit
Material_Policy6327@reddit
I drill in with business stakeholders and nail down at least 1 think that’s solid and well understood. Then from Then the rest usually starts to fall into place but it does take some time. Find a foundation then build Out
MrDontCare12@reddit
Came to say this! Business knows terms and features, technical is your problem tho.
MoreRopePlease@reddit
Formulate a specific question. Then come up with a way to answer it. Then start trying to answer it. Write down other questions as they occur to you. Draw pictures, flowcharts, etc, as you dig into code.
Use git blame to find out who to talk to if you have questions about business rules or things in the code that look weird. Take notes so you don't ask the same questions repeatedly.
When you think you have answers, run it by someone on your team and get feedback.
As you're doing this, you may realize your first question was not a good one to pursue. In that case, formulate a different questions and follow the process again. Write everything down.
Something that helps, is draw a graph of questions. Question 1 produces questions 2-5. Question 3 produces questions 6-8. And so on. As you answer a question, you then free up another question to be pursued.
shifty_lifty_doodah@reddit
You just start at one end and keep working at it
Dry_Author8849@reddit
Yeah, it's paralisys from analysis. It's common for human beings when the number of unknowns surpasses some threshold.
This is one thing that AI can help with. Try it. It can help tackling unknowns until you unblock.
Cheers!
StuntMan_Mike_@reddit
Sometimes you just have to start. Give yourself an hour to diagram out the big broad strokes of what you need to do. After that hour, pick the CSCI you feel most confident in (!! Or, pick the one that makes the most sense. If everything is going to interact with one particular orchestration piece, probably start on that.) Then go to your lead and teammates (maybe in your morning tagup), show them the diagram, and say “I’m going to use this general approach to solve the problem and I’m going to start on this part because xyz.” If no one opposes you, you probably aren’t planning the worst thing in the world. Then you start. You might make csci 1, then 2, then 3, then realize you need to update 1 to handle what 3 needs, etc. That’s fine; it’s going back and fixing your mistakes or correcting for oversights or bad assumptions is part of building stuff.
bland3rs@reddit
Learn why things exists. Learn the product.
Details are not important at this stage of investigation.
Everything starts making sense and you start piecing together how components interconnect once you realize what problems each component is solving.
EmotionalQuestions@reddit
Personally, I start with a list of every damn open question that's tripping me up and who might be able to answer. "Known unknowns" if you will, then I try to get a little time with each of those folks to go through the questions. I take tons of notes in these meetings.
During this time I try to create an ordered list of how I might start the project and dive into step 1 , writing down all my open questions as I go.
It calms me down to capture stuff on paper and feel like I have a plan to resolve some of the unknowns vs having a giant amorphous blob of "I don't know".
natescode@reddit
Start by creating a use case diagram. Ask the appropriate stakeholders questions on the use cases and business value. Who are the users? What is the business value? Diagrams are visual and easy to share with the business.
Once the uses cases are well defined then create a COM diagram. This highlights the high level architecture. Model how the use case will cause information to flow through the system. This will naturally bring up your questions which you can ask the senior developers.
At this point the lower level details like UI design, database schema etc can be decided.
opideron@reddit
Here are a few tips:
In other words, don't think you actually have to figure out how to do six impossible things every day. Just analyze the problem and assess. One of my biggest successes was pointing out that the new API they told me to integrate doesn't even begin to deliver the data we require. Entire project ended once that was clear. This is an example of "fail fast".
DeterminedQuokka@reddit
I try something, literally anything and see what happens and then I do a hard revert. I keep doing that until I have an idea. Not like a full final idea but when I think I know one step. I revert and I do that single commit. Then I start just poking at stuff again.