Ask HN: How do I perform given a 1 month probation period?

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.

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.

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

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.

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.

Running "lint" tools on your code can be helpful for catching basic things, 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.

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

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.

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.