[EdwardMSmith]

> Sometimes I don't recognize that I lack the knowledge/documentation to do something and instead approach it with an "I'm smart and resourceful; I'll figure it out" attitude. By the time I convince myself that I need to ask for help, I'm embarrassed about not having made progress.

At my old job, we used the "15 minute rule" which worked pretty well for us. When you are coming to the realization that you're stuck, and don't know how to do something, you give it 15 more minutes to figure it out. If you haven't made progress in that 15 minutes, you must go get help.

It works both ways - for people that tend to ask for help too soon, without actually trying to figure it out for themselves, and for people that tend to try to figure it out themselves for too long, when asking another person may get it figured out quickly.

> I don't know how to come up with task estimates that have any relationship with reality. I've said "I don't know how to give software timeline estimates", but often get pushed to give a number anyway.

This is often difficult in that it seems like what we do as software developers is always novel and new. But, the techniques for estimation are the same, whether the project is months long, or hours long.

Break the task down into smaller and smaller bits until you hit bits that you CAN estimate the time of - then add them up.. and then probably double it...

In the beginning, you won't be able to do this off the cuff in a meeting, but the correct answer should be, "I don't know right now, but I'll have that estimate for you by Xpm today"

[unfocused828]

> break the task down into smaller and smaller bits

One problem here is that if I don't really know everything the task entails, then I end up asking myself "am I going to really need to do this?" and can't think of a way to answer that question without writing code. Maybe the right approach here is to accept this and to write a few automated tests for external APIs.

Another is that I just need to be disciplined enough to do this consistently.

[EdwardMSmith]

You don't need to know everything that the task entails to begin.

Surely you can do a first level breakdown of what needs to happen.

"First I receive data, then I process the data, then I send the data over there.

Ok, to receive the data, I'll be getting an HTTPS post, so I'll need to have an endpoint set up.

I don't know how endpoints are set up here, I'll need to ask, but I do know that it will be a POST, and the data will need to look like this...

After I get the data, I'll need to process it. It starts out looking like this, and I want it to end up looking like that. I do know that I will need to save the data in the database. I don't know what libraries/ORMs, whatever, I'll need to ask."

and so on.

I think you're still thinking from the bottom up - what are the all the details, from the beginning. But, think from the top down, making the task into smaller and smaller bits until you have reached an understanding of each bit.