Ask HN: How do I perform given a 1 month probation period?
A bit of background. Dev exp 3 years of on/off .Net, no git, a bit of Java in college, previous role is closer to an analyst for IT projects in reality.
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.
Then life hits -- daily scrums, JIRA, talented full stack devs, Some tasks I did well but some didn't, e.g too long to finish, have to be redo by the CTO due to regressions and poor code quality.
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.
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.
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? 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. Spot on i would say. I guess it's just due to "ego" or lazy to spend a few minutes understanding. 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. 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. 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?" 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. I deeply sympathize. Things will get better! 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. Appreciate this deeply. You have made me think about doing something unique and valuable which they are currently struggling with. 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. 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. 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. 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. Thanks for these actionable tips. Appreciate them. Yes I'm definitely not giving up yet. 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. 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. 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... Absolutely mind opening article. Thanks. 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. I do want to stay here actually. But definitely a good point about not expecting them to give me any favours. Thanks! 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. Yup been doing that already but planning to read up the codebase as much as i can for this last chance to prove myself.