Hacker News Reader

https://en.wikipedia.org/wiki/Impostor_syndrome

Be yourself. Ask your manager for feedback every other week. Have fun.

> be yourself

Does the advice "be yourself" mean "do what you would tend by habit to do"? If so, I think that would probably have the same result it's had in 2/3 dev jobs I've held: me getting fired.

I originally thought I had impostor syndrome too, since it was constantly talked about at school. I should have mentioned that I've been fired from 2 dev jobs I've held before this, so apologies for that.

Explicitly asking for feedback is a good idea, though I worry that 2 weeks is too infrequent. Would every 1 week be annoying?

Why were you fired?

I do probably need to spend more time figuring out the root causes, though perhaps that is better done by talking with a friend rather than just thinking things over by myself. 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.

If your goal is to not get fired, work on these issues instead of burning yourself out with the intense study techniques you suggest in the OP.

Well the things I listed in my OP are my concrete ideas for how to approach these working on these things. If you have other concrete suggestions, I would love to hear them.

As an example: The reason why I focus on studying rails is that all of the debugging techniques I know about involve getting a better idea of the system at some layer of abstraction. I suspect that my best shot at getting better at debugging is to know the framework the code is written in very well and thereby be able to understand the codebase more easily.

For a problem like "I can't get clarity around what we are trying to do here.", it seems like there aren't any books on the topic. Thats why I figured that finding a mentor would be good.

The problems you describe sound like communication issues, not technical issues. Specifically, it sounds like you have a real problem with asking for help when you need it. Your time might be better spent reading a book on effective communication or perhaps taking a course at a local community college.

I'm always on the lookout for good books on effective communication. Ones that I've read and found insightful include:

- How to Win Friends and Influence People

- Difficult Conversations

- 5 Dysfunctions of a Team

I also bought Miscommunication by C. David Mortensen, but I haven't been able to get through more than a few pages because of how dry it is.

I suspect I need something more specifically focused on how to build mentorship relationships. Anything come to mind?

Getting copious sleep is a good idea! Generally, if your goal is to perform well at work, I recommend relaxing in your free time (instead of pushing yourself to train so hard) so that you'll be full of energy for the workday.

Of course, doing extracurricular professional development is fine and a lot of people love their side projects, but I'm worried that your attitude will lead you to burnout.

Your best bet is actually to trust that this company hires competently and that you'll be able to perform the job to their satisfaction after being onboarded. I know it's impossible to "just relax", but I wish you could do that <3

I would love to "just relax" and that's what I used to do. But after having been fired for underperformance twice, I want to figure out what it is about the way I work that leads to problems and to change that.

I'm completely sympathetic to your concern.

Cramming is a bad habit. My suggestion is to set aside 1-2 hours a day in the morning or evening to build things, do research and improve your skills. Continue this habit once you start your job. This will be plenty of time to keep up.

Of all the things you listed, building real apps is the only thing that will see you really making progress. Everything else is too shallow and it's also hard to stay engaged in it.

Keep in mind that your new job wants you to apply yourself daily using their bread-and-butter technologies more than they want you to understand new technologies. For example, they probably want you to bang out React components or Rails views more than they want you to understand the more esoteric bits of those. As a web developer, consistent work > insight, every time.

Strongly suggest retreating even further from idle Internet use if possible. It is not good for you.

I would say 1) as you have it above, and add a healthy lifestyle in general, then 2) try to pair as often as you can, figure out why your co-workers do the things they do

Honestly all that time outside of work might be better spent just being happy and using other parts of your brain, so that you can devote 6 hours during your work day to focusing on improving. Sure, you can exercise for 8 hours a day and get better progress than exercising for 3 hours a day, but for how long?

Edit: Read more comments. If you got fired for underperformance in the past, it might just be due to mis-alignment between yourself and the manager in charge. I had this at my last job. Sometimes it's tough for managers to properly assess work quality and production speed.

Make sure you understand the agenda and priorities of your superiors. If you 'focus' your time and energy working on their priorities you'll be all set.

Incidentally, you can drive your own onboarding plan-- George Bradt is an excellent place to start > http://www.amazon.com/The-Leaders-100-Day-Action-Plan/dp/111...

> However, I am still worried that in a few months they will realize that I am incompetent or unproductive and I will be fired.

Whoa, where is this coming from?! Jeez, is this your first job?

> Do you have any things you might add?

The note about sleep is good, you probably don't need the others. Let any of the above be driven only by your passions and interests. At work, communicate well and as clearly as possible. Show up, be positive, get your work done.

Ach, I left off the fact that I've been fired from 2/3 dev jobs for underperformance.

It is that last bit, "get your work done" that I'm worried about. I'm concerned that I'm going to not move fast enough. Since this has happened before, I figure that I need to do something significantly different than before.

I don't understand why you're so anxious about it.

Is this your first job out of school?

Showing up, being openminded, and putting forth full effort will help you shine.

Relax a little :)

Nope, this is my fourth job. I've been fired from 2/3 jobs for underperformance.

This is the real issue. You need to tell us more about why you were fired if you want to get useful feedback.

My advice at this stage is just work harder than everyone else. Be the first to arrive and the last to leave and the company will find it very hard to fire you because of the signal it sends.

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.

> 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"

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

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.

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.

I disagree with this advice. Quality of work and consistency is so much more important in a startup or small company, or any team that's distributed.

While you are right that spending the most time in the office sends the signal that you're working harder, it feels like veneer around the real issue.

Of course being productive is more important, but the OP was asking for advice on how to avoid being fired. My advice was given in the absence of any information on why the OP was fired 3 times previously - while spending the most time in the office won't solve the underlying issues, it might allow the OP to survive long enough to change.

Security is an illusion. You could be perfect and the company could go out of business for some strange reason.

The best advice is to stay upwind.

Man I totally and utterly understand what you're going through. I feel like I was looking at a mirror when I was reading your comments. I am at my first full-time software development job and I feel the exact same way.

I've been lucky enough to "fake my way" through it so far but I am anxious about future roles.

Anyways, I hope it works out for you.

Relax. Be aware (but not worried) of your surroundings and act as you do and everything will work out. Hey you got the job, right? That's got to count for something!

This is a healthy fear to have. But dude - they've hired you.

So you're probably up to the task as long as you apply yourself.

Apply yourself - especially for the first 6 months.

meh, just relax. i had the same mentality on my first job except yours still blows mine out of the water lol.

* Listen more than you talk.

* Show up with a good attitude, every day.

* Under-promise, over-deliver.

* Be consistent 100% of the time, not great 10% of the time and crappy the other 90%.

> under-promise, over-deliver

What do I do when I'm asked how long a feature will take and the honest answer is "I don't know"? I have tried to teach myself how to create software timeline estimates; I've still not figured it out, and it seems like nobody knows how to do it.

When I tell someone that I don't know and they still press me for an answer, I usually cave and give a random guess, followed by "but I would not rely on that." I feel so dishonest lying to people's faces like that but in the moment it feels like it is the only way to get the situation to end. Should I just get a friend and practice staing steadfast in refusing to answer? Is there something I can say that isn't going to sound like I am incompetent?

Learn to qualify your "I don't know"s with details of how you're going to find out. "I don't know, but here's a guess" is far less useful than "I don't know, but I can do an hour or two of research and then get back to you with a decent estimate".

The problem here is that I don't know how to generate an estimate except by actually doing the work.

Since you're new you might be able to get the time they have in mind by asking 'what are your expectations for this'. (keep in mind some managers aren't good at estimating development time or might try to low ball the time to see how productive you can be)

Other than that every task/spec is different. I would review the task/spec then get back with them with an estimated range of time. 4 to 6 hours/4 to 6 days and tell them you'll update them on your progress as it's completed.

Once you're working on if things are going faster complete it/test it/review the spec/double check it and then present it as things went better than my estimate.

If things are taking longer, go to them early with what is completed and an outline of items that are taking longer than your estimate and have a new estimate ready for the time to overcome these challenges and complete it.

I would say relax, be a good listener and communicator, re-read specs/requirements and make sure you're complete/thorough in your work keep them informed and you should do fine.

Since you're new try to find someone you can trust, to be your mentor, show you the ropes, help you out, bounce ideas off of, give you the lay of the office/land.

You're pretty new to the industry I'm guessing. Estimation is one of the hardest things a developer can be asked to do, and the only technique that will consistently work is getting experience so that you have similar tasks to compare the one you're estimating to.

In the meantime, try to break things down if you can't even start on an estimate - what are the steps involved in making Task X happen? Keep breaking those tasks down until you get to something you can estimate. That's what the estimation time you ask for is used for.

Yea, I've only had about 4 years since I got out of school. Trying to be better able to break the task down is part of why I want to do the studying

Use historical data (yours and/or the company's.) Find an IRC room or something where you can ask other developers how long something could take. Try writing down every small feature, or class required, or other chunk of project and multiply the length of that list by some number like 10 hours.

In my own opinion, just give a personal estimate and it's fine that it's not accurate. If you think they won't be wary of that, tell them that. I don't think this is something easy to estimate even after years and years of hard programming.

Starting a new job – What can I do to avoid getting fired?