Ask HN: I started a new job and I'm scared

You know what I love when someone new starts? When they tell me they feel like they’re moving too slow. It indicates introspection and a desire to improve. I you’re on a healthy team they should be expecting a ramp up period anyway, especially for someone learning both the domain and the tech stack.<p>You should really discuss with your manager. They should be able to set expectations and likely put you at ease. And if your manager <i>isn’t</i> encouraging and supportive, then it’s likely going to be a bad fit and you’ll be happier elsewhere.

Discuss most of this with your manager (or mentor.) (Everything except the quitting part.)<p>Chances are, it&#x27;s normal and expected.<p>&gt; I&#x27;m working on a ticket that should take me a day to finish but it has taken me almost a week<p>20 years into my career, that also happens to me when I start a new job. You&#x27;re working with an unfamiliar codebase. It takes time to learn; especially if your assumptions are different than the assumptions made in the code.

What’s your title? If you’re junior then there should be a reasonable expectation that you will be learning a lot on the job. Without more context it’s impossible to say you if you are actually incompetent. I’d say treat this as a fire under your ass. Invest money into courses and books that fill in gaps of your knowledge. And it’s likely that your company would start a discussion about performance before any talks about layoff. And if those talks ever happen, you can explain that you are investing in learning xyz with books&#x2F;courses. Most likely, the company hired you knowing your skill level, and having a slow start is not too surprising. Don’t be afraid of asking stupid questions - because when you get afraid of asking stupid questions then you get completely paralyzed.. and then it becomes a vicious cycle.<p>Also.. the fact what’s it’s just the processes that are new to you is really quite minor! That’s all learnable with time!

Sounds like an adventure - What would a career be without an emotional rollercoaster!<p>Just wait it out, keep up the hard work and face the fear head on. The fact that you’re thinking about it is a good sign.<p>I work as a PM, and I’m far less technical and I’m more soft skill oriented than the engineers around me. I notice that engineers have a tendency to have a lower tolerance for failure, and they worry when things don’t go exactly according to plan. I like this quality - keeps everything grounded (including me!).<p>Don’t let these thoughts cloud your judgement. As long as you keep your cool, and show that you’re making progress, it is probably more worthwhile to wait until you catch up than it is to recruit someone to replace you. If anything goes wrong, it could just be a “bad job experience” to be put behind you anyways. Also, others here are giving great actionable advice.

This is a nice crash course &#x2F; intro to the basics that you can play with at your own pace and with your own throwaway repos: <a href="https:&#x2F;&#x2F;docs.github.com&#x2F;en&#x2F;get-started&#x2F;quickstart" rel="nofollow">https:&#x2F;&#x2F;docs.github.com&#x2F;en&#x2F;get-started&#x2F;quickstart</a><p>With that out of the way, if your bosses want to fire you a week after you&#x27;ve consistently and proactively been trying to learn workflows that are new to you in your new job, you&#x27;d actually be dodging a bullet.<p>&gt; I hate that I am always asking people for help<p>You only need to do this for &quot;tribal&quot; knowledge, for which you should have (or start) an internal wiki. For the rest, you kinda have to plumb the depths of the public internet...<p>&gt; like today I asked for help to rebase my branch since I have never done it before<p>Yeah, I still remember my first rebase very well, thinking I would just lose everything if it went wrong. I tried a bunch of things on a throwaway repo to figure out what exactly happens, which turned out to be very helpful. I particularly enjoyed this talk once I&#x27;d found it: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=1ffBJ4sVUb4" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=1ffBJ4sVUb4</a><p>&gt; At my old job I was the guy that got things done, gathering requirements, designing and developing new features &lt;...&gt; did anyone else ever feel this way and if so how did you over come, did anyone get fired because they are incompetent?<p>That is still your skill set, and not knowing something does not make you incompetent; though not wanting to learn new workflows and tribal knowledge <i>does</i>.<p>I have always had pride in being a newbie to a new team - I get to learn another set of ways someone has thought about working through problems, and more often than not - my new team benefits from the fresh perspective I bring to the table when I start asking questions on why something is the way it is, and to mull over whether there could be a better way to do it before you get crusty. Win-win.<p>See if anyone on the new team is willing to volunteer to mentor you. That looks nice on yearly reviews for both of you as well. Cheers!

I&#x27;ve been working professionally for eight years and it&#x27;s only been in the last few months that I&#x27;ve learned to use git properly beyond the barest basics. I&#x27;ve had git rebase explained to me half a dozen times over the years because I just wasn&#x27;t using it often enough for it to stick (and because frankly, git&#x27;s UX and conceptual model are garbage)<p>More broadly: this industry is all about never fully knowing what you&#x27;re doing, especially when you start at a new company. Just keep learning as you go. Also keep in mind that probably more than half of your coworkers have impostor-syndrome too. It&#x27;s pervasive and it never fully goes away.<p>I&#x27;ve only known one person in my whole career who was let go based on their abilities, and it wasn&#x27;t because they didn&#x27;t already know a technology or didn&#x27;t learn it fast enough, it was because they had no instinct whatsoever for how to write decent code. And despite that, they landed another job almost immediately.<p>So I wouldn&#x27;t worry about it too much. I&#x27;m sure you&#x27;re doing fine.

I have felt this every single time I&#x27;ve switched jobs, and I&#x27;ve been at this for over a decade. It&#x27;s normal to be scared, and to worry about doing a good job. It&#x27;s normal to be slower when you ramp up at a brand new company. It sounds like you are introspective and proactive in analyzing your own progress and improving, which is a great sign. For me, there was no &quot;overcoming&quot; of this feeling. It abates over time and eventually you relax into the role as you get a handle on things.<p>In practice, for me those first months of stress always result in a lot of reading&#x2F;brushing up quickly on new tech, a lot of digging around the code, debugging, late nights to finish tasks I feel I&#x27;m behind on, asking teammates about tools and processes, etc. But while all of that might help, in the end it&#x27;s usually just a matter of waiting it out and knowing that this is a mental pattern I&#x27;ve dealt with before. Meditation sometimes helps.<p>Good luck! I really think you&#x27;ll be just fine.

I wouldn’t think twice if it took a new teammate longer than expected on their first few tickets as long as they are communicating what is blocking them to the relevant stakeholders.<p>However a lack of basic Git skills (or struggling to quickly ramp up) for anyone above an entry-level engineering role would be a bit of a red flag. I’d fix that right away, but that may be my personal bias.

Oh boy, I&#x27;ve felt this way a lot in my career.<p>The key mistake that I would make was to curl up instead of reach out.<p>When you are worried or afraid, it can be hard to reach out. But I always got far better feedback whenever I presented my work, and showed the parts that were blocking my progress, and asked a lot of questions.<p>Often, I was trying to solve a problem that the team had simply not considered.<p>The problem might be out of scope for the task I was expected to address, and my perspective was due to my lack of context that was considered natural for any new hire.<p>Or I was unfamiliar with their tools and workflow. This is where it might be best to work through a task in tandem with someone who has been working there for a while. It doesn&#x27;t have to be a big thing, just something to go through the whole cycle.<p>You are already asking good questions. On HN. Keep it up, ask your new team. It might be scary but the fear usually goes away very quickly.

I’ve certainly felt this way - overwhelmed. It sounds like you’re proactive and diligent and in my opinion many people recognise this and it’s much easier to teach you how to rebase your branch than to teach you to care about doing a good job!<p>I too went from small to big and had to learn the frameworks and processes of bigger places, coming from having to do everything myself. I’ve also changed types of roles which is just another set of “out of comfort level” issues.<p>In the first few months I’d say ask all the dumb questions …they’re not gonna fire you for being new in a place different to where you’ve been. Thinkabout the time and money wasted if they fire you before they give you a chance, they should definitely try to help you for months before that happens. No one wants to be out hiring again if they can fix simple learning problems.<p>And write things down so you don’t have to ask twice.<p>You’ll get there.

As others mentioned you&#x27;re not incompetent, ramp up on git in your downtime and the rest of the knowledge will come through work. The official git docs are actually pretty good.<p><a href="https:&#x2F;&#x2F;git-scm.com&#x2F;book&#x2F;en&#x2F;v2" rel="nofollow">https:&#x2F;&#x2F;git-scm.com&#x2F;book&#x2F;en&#x2F;v2</a>

&quot;it takes 10,000 hours of intensive practice to achieve mastery of complex skills&quot; - Malcolm Gladwell<p>That&#x27;s 5 years of full time. I estimate that it often takes 6-12 months for a new hire just to even become positive in terms of net impact to the team, let alone mastery. This will vary depending on complexity. In other words, when does that extra set of hands contribute more than it costs in terms of extra communication, training, mistakes, etc.<p>Be honest, ask for help when appropriate, be a good listener, take notes, learn. Be the one ready to take on any job. God gave you two ears and one mouth, so listen twice as much as you speak.<p>In a year or so, you&#x27;ll be the journeyman helping the next crop of newbies.

They hired you and have to take responsibility for training you. Don’t let they’re Byzantine development practices scare you. In all places that I’ve worked in like that - Jira sweat shops - the product was a tinderbox of disaster code waiting to burst into flames and nobody noticed. Everyone is chained to their Jira tickets - including the whole management hierarchy - and nobody bothers to look up to take a fresh look at the big picture. You have out-of-the box, novel experience and can help them far more than I think you realize… They need you. “Hey guys, do you really think this is a good idea..?”

Why do you think it should take you a day? Set the bar lower. Under promise and over deliver. Don&#x27;t say &quot;it&#x27;ll take me a day&quot; when you aren&#x27;t sure.

&gt; I&#x27;m working on a ticket that should take me a day to finish but it has taken me almost a week<p>Check with your TL or Manager for the expectations.

I feel this way every time I start a new job!

Try to not ask questions that you don&#x27;t need them to answer specifically. Rather, find answers on your own.