
Ask HN: How do I perform given a 1 month probation period? - pzk1
A bit of background. Dev exp 3 years of on&#x2F;off .Net, no git, a bit of Java in college, previous role is closer to an analyst for IT projects in reality.<p>Starts to learn JS. After few startups and projects in the space of half a year, got into 1 of the most popular startups in the region.<p>Then life hits -- daily scrums, JIRA, talented full stack devs, Some tasks I did well but some didn&#x27;t, e.g too long to finish, have to be redo by the CTO due to regressions and poor code quality.<p>So today is the end of my third month here. CTO decides on giving me another month of probation. We both agree I am not up to par with most of the output of the other seasoned devs.<p>Things I need todo: framing problems, asking the right questions, focusing on a specific repo rather than trying to be involved in all repos, and thinking creatively to create quality code.<p>But how do I create quality code, elegant solutions and fast, in the space of 1 month? Do I finish up Code Complete 2? Or do I practice my fundamental JS knowledge doing exercises?
======
partisan
Read the code of the other developers whom you respect and admire at your
company. Look at how they have solved problems, but better still, understand
what the problems were that they were facing. One thing I notice in newer and
less experienced devs is that they tend to feel like the solutions they see
are "stupid" or "wrong" and aren't open to understanding the solutions they
see in existing code. By reading and understanding code written by others with
an open, empathetic mind, you can understand the types of solutions that are
favored in your workplace.

This is not the silver bullet, but just one of the things you can do to
improve your situation.

~~~
pzk1
Spot on i would say. I guess it's just due to "ego" or lazy to spend a few
minutes understanding.

------
yawgmoth
I think there's a third option - perhaps it is in your best interest to work
elsewhere. Somewhere with a CTO / team lead who accepts your skill level as
junior where you can grow without your job being on the line.

I personally would feel very pressured and don't know how much I could focus
and be happy if I were in your situation. Perhaps you are not bothered by it
at all, in which case I don't think my advice fits you very well. But consider
it.

~~~
pzk1
This has crossed my mind. But I'm certain a short stint is not gonna be good
in my resume, plus being a subpar performer at your previous company looks
awful whatever the reason is. I'm just gonna try my best and if things still
don't work out, I'll just be glad that at least I worked my heart out. Thanks
anyway for your advice.

------
1123581321
Think about how you'd like to solve a problem. Then ask one of your more
seasoned peers to talk through it with you. "Lisa, I'm working through the XYZ
changes and I'd like a second pair of eyes on my planned solution. Do you have
a few minutes to go over it?"

~~~
pzk1
Yup. One of things I am planning to do much much more. Sometimes feel a bit
lost when couldn't even "start" to solve a particular problem.

~~~
1123581321
I deeply sympathize. Things will get better!

------
endswapper
I have to believe that you are intelligent even if you aren't smart about
technical aspects. Otherwise, they would not have hired you, and given you the
additional probationary time. Let that really sink in. You got a second chance
at something most people don't get a first chance at (based on what you
described).

I would start by answering two questions: 1) Why did they hire me? 2) Where
can I provide the most value?

Apparently, they have a bunch of smart, capable people that are performing at
a higher level than you in certain areas. Why, or where are you unique within
in the organization, where are they going or trying to get to? These will get
you started in answering the first questions objectively.

I don't think blindly focusing on fundamentals will make you competitive with
people that are already well beyond you. And if you did become competitive on
that level, so what? Do they need another person with the same skill-set?

This brings me to the second question. Other than LISTENING, strategically
identifying their weaknesses is the best way to get started on question two.
Providing practical solutions in the most efficient way possible is where you
provide value. It's great when it doesn't have to be, but often the ideas that
move things forward in a significant or meaningful way are cross-functional
and collaborative. Perhaps it is part of the reason they can be so elusive.
Based on your analyst background, this type of objective analysis might be the
right starting point. From there you can drill deeper with more relevance
adding further value.

Finally, your commitment will show, and while it may intangible (at first,
anyway), that too has value.

~~~
pzk1
Appreciate this deeply. You have made me think about doing something unique
and valuable which they are currently struggling with.

~~~
endswapper
Glad to hear it. This is the beauty of Hacker News. I, and others I am sure,
would like to hear how things proceed. If you can update us at some point I'd
appreciate it. I think it would help those in a similar position, and perhaps
managers as well.

~~~
pzk1
Well, it turns out my idea was too farfetched, and someone already did the
groundwork. But I do have an action plan now, just stick to the basics which I
did not do previously, for a number of reasons, namely: 1) being too
overwhelmed and forgetting to merge, 2) forgetting to fix the PR which has
been reviewed, 3) taking tasks which are way above my head and not designing
things beforehand which makes the code subpar and introducing regressions, 4)
not attacking problems as hard as I can which makes tasks longer, 5) not
asking questions a lot sooner

I guess it all boils down to completing the tasks I was assigned, improving
the quality of the code and then finishing on time.

~~~
endswapper
Thanks for the follow-up. I applaud the self-reflection.

It sounds like your manager knows a thing or two in that you may just need a
little more time to settle in and perhaps the word "probationary" lit the
appropriate fire under you. I recommend continuing what you have been doing -
listen, reflect, reach-out, repeat.

------
s3b
I would say don't give up. Use your second probationary period to learn and
improve as much as you can. If things don't work out well, at least you would
have learnt something useful you can use in your next job.

Try asking the seniors for help when you get stuck somewhere. But only ask for
help after trying all the possible solutions you can think of yourself.

Try to come up with 3 or 4 test scenarios for your code and test them before
you submit the code. Thinking up new scenarios will help you reduce the bugs.

Critically review your own code a few days after you've submitted it. Pretend
it was someone else's code and think of all the possible ways to improve it.

If your seniors are willing, ask for a code review. Go through the review
comments carefully and make sure you never get the same review comment again.
Don't ignore any comment, however trivial it may look.

Spend an hour or two extra everyday to improve your knowledge of the system.
Learn something new everyday about the tools, language etc.

~~~
pzk1
Thanks for these actionable tips. Appreciate them. Yes I'm definitely not
giving up yet.

------
nfriedly
Running "lint" tools on your code can be helpful for catching basic things,
[http://eslint.org/](http://eslint.org/) is my favorite one for JS, I know
ones exist for other languages.

After that, ask for code reviews. If you don't understand why the reviewer is
suggesting a change, keep digging until you do.

Also, as partisan said, reading through the code from the other devs will be a
huge win. Even if it doesn't follow "best practices", it will show you what's
acceptable in your company which is arguably more important right now. And,
again, if you come across something you don't understand, ask about it.

Oh, and you need loads of testing to help avoid regressions. Some manual
testing is good, but you really want automated tests covering most things.

~~~
pzk1
Thanks. Excellent point on the "reading other dev's code even though it's not
best practice". Yup you are definitely right, most of the regressions are
because of manual testing. But the team are very comfortable making changes
and doing things "on-the-fly" \+ manual testing here and there, but they get
away with it by being talented coders in the first place, which is the point
of this post anyway. We are doing PR regularly though.

------
maramono
To produce high quality code you need to change your mindset. No tools will
help you if you don't know how to use them. Also you cant simply "pass the
buck" (so to speak) to tools and expect greatness. TANSTAFL.

I wrote a blog post about this not too long ago: [http://ortask.com/why-your-
mindset-might-be-setting-your-sof...](http://ortask.com/why-your-mindset-
might-be-setting-your-software-for-failure/)

~~~
pzk1
Absolutely mind opening article. Thanks.

------
thorin
Been there. Consider whether you want to stay there. If you aren't sure start
looking for other jobs. Even if you want to stay consider other options. If
you're going to have to do a lot of catching up to get where want to be is it
going to benefit you in the long run? It could be an opportunity to learn and
grow in the but don't expect them to do you any favors.

~~~
pzk1
I do want to stay here actually. But definitely a good point about not
expecting them to give me any favours. Thanks!

------
3minus1
Oftentimes when you get assigned a task there is another similar part of the
codebase you can use as an example for what to do. Try to understand what the
code is doing and go from there.

~~~
pzk1
Yup been doing that already but planning to read up the codebase as much as i
can for this last chance to prove myself.

