
Starting a new job – What can I do to avoid getting fired? - unfocused828
Hi folks,<p>I just accepted an offer at a company I&#x27;m super excited about. The interview process was a mix of the traditional whiteboard interviews and watching me write code, so I suspect they got a good impression of my skill. The company seems like they know what they are doing in terms of mentorship and development processes. However, I am still worried that in a few months they will realize that I am incompetent or unproductive and I will be fired. What are the most time-effective things I can do to rapidly become competent and productive and thereby avoid this? I have a few weeks before I start that I can use to prepare.<p>My current ideas are:<p>1) Enforce a rigorous sleep schedule on myself, getting the same 8.5hrs every night.<p>2) Make a list of the technologies they are currently using (RoR and react.js), then pay for the best tutorials I can find and run through them repeatedly to drill myself to work fluently in them. In particular, look for tutorials that also involve testing and debugging.<p>3) Build app using the above technologies as an open source project and find someone I can pay to do code reviews of it.<p>4) Make flashcards and rote-memorize things that will help me look things up and navigate the codebase more quickly.<p>5) Aggregate a list of 100 webpages and build imitations of them in html and css and thereby finally teach myself by rote how CSS layout works.<p>6) Find someone outside the company (so they don&#x27;t have any input on performance reviews) I can trust to talk to about things like project management or recognizing when I&#x27;m miscommunicating or taking the wrong approach.<p>7) Find someone inside the company that I exchange help on their tickets with in exchange for letting me watch how they work to see if I can borrow habits to become more efficient.<p>Does this seem like a good list? Do you have any things you might add? Any tips for any of these?
======
lxfontes
[https://en.wikipedia.org/wiki/Impostor_syndrome](https://en.wikipedia.org/wiki/Impostor_syndrome)

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

~~~
unfocused828
> 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?

~~~
Spoom
Why were you fired?

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

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

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

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

~~~
unfocused828
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?

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

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

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

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

------
JSeymourATL
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...](http://www.amazon.com/The-Leaders-100-Day-Action-
Plan/dp/1118097548)

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

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

------
tedmiston
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 :)

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

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

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

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

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

------
meric
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!

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

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

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

~~~
unfocused828
> 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?

~~~
jon-wood
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".

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

~~~
jon-wood
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.

~~~
distracted828
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

