Comment by calebkaiser | Hacker News Reader

Comment by calebkaiser | Hacker News Reader

I'm sorry you're experiencing this level of stress. The situation you're in is one that many (I might even say most) junior, and even senior, engineers find themselves in. If I can give you one piece of advice that was critical for me, which I share with every new engineer, it is this:

Be radically transparent with your team when you struggle. Tell people when you're stuck, when something is new to you, when you're uncertain of where to go next. And tell them soon.

In my first jobs, I constantly felt like I was "interviewing" for my position even after I started. I thought that if I couldn't do something simple, I wasn't living up to the skill level I had promised them when they hired me. So I would hide the fact that I was struggling. Worse, after 2 days of being stuck on something "simple," I'd feel like I couldn't possibly tell the team--they'd think I'd wasted their time for two days!

The key for me was to simply be transparent. If I was assigned a task that used some technology I'd never seen, I simply told the team upfront "Hey I've never used Vue before. I'm going to read the docs and familiarize myself with the framework, but if this is particularly time-sensitive, should someone else take this ticket or can anyone recommend a better approach than learning Vue from scratch?"

Then, whenever I hit a confusing bit of Vue code that I couldn't decipher in 20 minutes, I'd simply post a link in Slack and ask "Can anyone help me understand what's going on here?" and explain where I was getting confused.

If your team hired a junior, they don't expect you to be a senior. If they see you working, see where you're getting stuck, and see where they can help, things will go much more smoothly. Where conflict occurs is when a junior disappears for 3 days, then shows up with a PR that needs to be redone (speaking as a person who has been that very junior).

Please listen to this advice! I’ve managed hundreds of developers and i can tell you the difference between someone junior that we keep and someone we exit is substantially defined by how good they are at communicating their circumstances and allowing others to help. People make the mistake of assuming others are too busy or will be annoyed, it may seem that way but they would much rather you ask than not be productive.

Ask questions. Tell people where you’re at. Advocate for your own success and by all means, do not ever hide problems or the challenges you’re facing. If the team cannot support you when all you’re doing is being honest, that’s a problem I’d solve by finding a new team to work with.

100% - The #1 developer mistake is not knowing when to ask a co-worker for help. Juniors make this mistake more often, but I've observed the same pattern in developers with lots of experience too.

When to ask a co-worker for help: domain specific problems, open ended questions, subjective questions that would be hard to input into a search engine, etc.

Ask questions when you would spend a lot of time tracking down the answer. Don't ask a co-worker a question that a web-search could answer quickly.

Also, if you do go ask for help, tell them what you already tried (and you know, actually try some things, even if that ends up being a waste of time).

I love helping people that have put in the effort to try doing something themselves, but I hate helping people that just dump their work in my lap.

The “I tried nothing, and I’m all out of ideas.” trope.

The guideline I always tell to juniors (and I can't remember where I read it) is that if you don't spend 15 mins on it yourself you're wasting others time, if you spend more you are wasting your own time. After a few times of breaking that rule both ways they usually stop asking before trying to find the answer themselves but also sometimes feel more free to spend more time on something if they want (since it's your time).

Of course 15 mins is meant as a loose time, as a sort of benchmark for "give it an actual try yourself, but don't spend a day stressing out yourself without help".

Thank you sir, I read this and thought what I did all the time. If I was more transparent, maybe I felt better and could think without stress.

This means to me that talk with my project managers and colleagues more make more comments/updates on Asana :)

so leetcode grinding doesn’t work and maybe experience is more important then, after all?

I thought leetcode grinding was just for passing the interview, not the actual job?

experience seems to be far less important than leetcode BS in getting hired. experience is really all that should matter.

I imagine it's patently obvious to everybody that leetcode grinding tells you nothing of value. I question the actual experience of anybody that didn't find that out yet.

I believe people put it in interviews because they need some metric, and hey, it's a metric. Quite like the constant attempt on estimating the work done on some software.

yeah, i guess that implies that management are a bunch of incompetent idiots.

Personally, I'd be happy to see a single place where management doesn't do the "we need a metric, this is a metric" dance in some context.

Anyway, it's hard to say somebody is an incompetent idiot when literally everybody does the same thing. It's certainly caused by some structural feature of companies.

Reply on news.ycombinator.com