[pavel_lishin]

> Now that you're at the medium software company, seek mentorship and coaching from others.

Agreed. My abilities as a developer increased tremendously at one of my jobs, and I can attribute 90% of that to a single person at that company who mentored me and helped me grow. (Hi, René, you probably don't read this.)

You can read all the articles and books you want, but actively pairing with someone on tasks and getting personalized feedback has a much greater pay-off.

[bigwavedave]

Absolutely- getting a mentor who will make time for pair programming is invaluable. Early in my career as a self-taught dev (my degree was in a different area), I landed a job as an associate dev and was assigned a "mentor" who wouldn't give me the time of day. While I'm sure he was very busy, it was also very frustrating to be told every time I reached out: "Give me one sec, I've gotta finish something up, I'll message you when I'm done" only for them to ghost me for days even after I'd reach out again (I couldn't even drop by their desk since we were both remote devs). So I made different connections, got to know my other coworkers better, and found a person who wasn't just willing to mentor me and pair with me, but was excited about it and glad I would reach out! I learned more from him in a week than three months with my former "mentor".

Moral of the story: find someone who's happy to mentor you, willing to pair program, and wants to see you grow and succeed. I can't promise that you'll never feel like a fraud again, but I can promise that you'll feel more confident about the work you do. The sooner you can do this, the sooner you'll find your "muchness" and become "much more muchier" (to quote Tim Burton's adaptation of the Mad Hatter).

[prewett]

At my first company, in order to commit anything we had to get someone else on the team to sit down with us and we'd have to go over the diffs with them and walk them through the changes and why. Incredibly annoying, but a great way to learn. I still rewrite "if (!condition)" to "if (positive_condition)" to this day based one guy's feedback that negative logic is hard to read and reason about. It was also really humbling to not remember why I did things, so I'd have to prepare for the code review so I'd have something besides "um, I don't remember" to say.

I have also realized that there are some categories of problems that I really don't know how to solve well. So if I find myself struggling, I try to ask someone for ideas.

[notapenny]

Totally agree with this. If you see someone who's better at something than you are, go up to them and ask if they are willing to spend some time with you working on a topic. You'd be surprised how many people would love to help out. Depending on the company they may even have decent learning/pairing programs for this.

Can share that experience as well, my first job there were 2 devs who were great programmers, highly educated. At every chance I tried to get as much knowledge from them as possible. They were happy to share and equally happy when they saw me improving.

[etothepii]

Pairing, pairing, pairing, and more pairing.

[spacemanmatt]

This. Suggest and attend stand-ups. Treat them like professors' office hours. Encourage and nurture people who are very good to give you things you can do, maybe with some help, but which are real tasks that are useful in the end.

[mattfrommars]

Do you have tips or things you did to get more effective mentor ship? My company has assigned me a mentor but I always thing I am not using it to the fullest extent.

The `only` time I speak with my mentor is when I get stuck with a bug and need help getting started. I have asked frequently on how to do better code reviews or how did she get so good at programming - she always said it takes time. To get better with the code base - it takes time.

[pavel_lishin]

Ideally, this person should be on your team, or otherwise someone you work with regularly. But asking your mentor when you run into bugs is a good start! Pairing on those helps.

I guess in terms of concrete advice:

1. Put time on a calendar to work with this person; don't just slack back and forth about some specific issue for a bit.

2. If you're looking to become a better programmer, actually pair with them - take turns driving and writing code. If she's doing the driving, it would help to hear out her rationale for what she's doing - probably even before she starts writing. If you're driving, try to do the same.

3. Ask for code reviews on as many of your pull requests as she can provide; this is going to be pretty workplace specific, and is going to depend on how much code you end up putting up for review and how much time she has. It's a good way to get async feedback.

And yeah, it takes time and practice.

[eyelidlessness]

It is true that it takes time. And to some extent just observing others’ work is a lot of the benefit of time. But if you’re looking for your mentor to be more involved and she’s not engaging that, try asking more specific questions. Like “oh this bit of code is interesting and it wouldn’t occur to me to do it that way, what was your reasoning/thought process? Where can I learn more about this approach?”

You can also find others on your team whose work you admire and ask them similar questions. Lots of people are happy to talk about their work when asked.

[foolinaround]

interesting... I have never been in an environment where pair-programming was practised..

makes me think how much I could have improved...

[pavel_lishin]

I don't think pair programming should be done for every line of code written, but it's a really good way to transfer knowledge and mentor folks.

[prox]

Also try to identify on three levels : how is your understanding of structure, how is your understanding on the functional level and how is the understanding on the syntax level (in the context of the company you are working for)