[unfocused828]

I do probably need to spend more time figuring out why I was fired. My current understanding is this:

* When I'm confused about what a task really entails or what tools I can use and I try to get people to resolve that ambiguity, I sometimes cannot persuade them to do so.

* 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.

* I've gotten feedback that I "try to understand the universe" when debugging an unfamiliar system. That I should be more focused in my search. The difficulty here is that, when I'm working with an unfamiliar system, I don't know the lay of the land and so I end up spending a long time trying to get a sketch of a mental model of it because, well...how else could I solve problems?

* As my username suggests, I get distracted easily and sometimes find myself losing 5+ hours to distraction. I've been able to fight this to some degree using SelfControl.app and by making sure I get good sleep.

* 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. I really really hate lying to a coworker/supervisor's face and wish I could find a way avoid it. I've tried to learn how to do estimation and bought a book on it, but all of the advice seems to focus on projects on a months-long scale rather than things that should take a couple hours.

> the company will find it very hard to fire you because of the signal it sends.

I'm skeptical of this for a few reasons: I've done this at the previous jobs but to not much avail. Also, it isn't sustainable. Also, that sort of signal doesn't cut costs or add revenue, so why would it convince them to keep me on. It might make it more emotionally difficult to fire me, but firing someone is already emotionally difficult.

[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.

[danieltillett]

I think you are self-aware enough to know why you were fired so I won't comment more on this.

The reason why firing the person who comes in first and leaves last is so hard is because of the signal it sends to other employees. If the employee everyone sees working the hardest gets fired what does this mean for everyone else - are they about to get fired too? The only way you can get fired with this strategy is if you goof off at work. Keep your head down and work like crazy (or at least appear to work like crazy) and you will be fine.