[epm7384]

I'd argue differently. Congrats for having the courage to recognize your problem.

The analogy that comes to mind is I've been playing basketball in my local town, and now I've gotten promoted to play in the big city. I now feel like a small fish in a big pond.

If you enjoy software engineering, I'd say, double down. Now that you're at the medium software company, seek mentorship and coaching from others.

In addition, there might be more homework (hitting the gym sort of), things you also have to do on your own.

It isn't going to feel good being humbled and I've been there myself. But if you think about the goal as "learning to get better" than "prove to others I am better", you'll have a better time walking through this challenge. This all comes from a person who is a PM.

So some tactical thoughts of possible advice: 1. Face the issues head on -> take all the negative feedback on the code and rework the medium complexity task 2. Learn to unlearn bad habits. Yes, it's harder, but it comes with practice. 3. Commit to maybe taking a course work online (maybe seek advice from others on what are good ones to address weaknesses you have)

Hope this helps.

BTW, you don't need to be able to code things the right way to be a PM. Coding is only one specific skill and not always necessary for a PM.

[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)

[aerovistae]

Totally agreed! My first thought on reading this was "this doesn't sound like a bad engineer, this sounds like an engineer with potential who's just been exposed to some good practices they hadn't encountered before."

Just set your mind to doing better and in as little as a year it'll be a different story.

[milesvp]

Seriously. The bad engineers are the ones who accomplish nothing. I’d be concerned if he said the codebase was too hard for him make any significant changes.

About the only

[tdumitrescu]

Agreed with everyone else here that it's great that you've recognized areas of improvement for yourself. That's an important step, and in your position I would validate by chatting with your coworkers about it. Every time a colleague has asked me for my opinion on what they can improve upon or work on, I've always tried to give a straightforward critique; see if your colleagues independently bring up the same issues you think you have.

More generally, without having worked at a company that size yet, you can't be expected to come in with all the domain knowledge that dev team veterans have. Forget about titles like "senior" and what that means. Doing mostly-solo dev work for a long time is just a very different kind of work than writing code in a shared codebase with a team of coworkers of varying experience and skill levels. There will be aspects of maintainability and clarity which simply aren't a big concern in your solo projects but make a big difference when you have dozens or more developers working on the same code. Communication with coworkers becomes an important skill, collaborative project management etc. These are things which you can't just study and learn on your own, you ramp up on them over the course of working in that kind of environment. So yes, you might be pretty "junior" at some of these medium-sized-company aspects of software development, but that's fine and only to be expected at this stage. Keep at it, gain experience, level up by doing.

[mxmpawn]

I really appreciate your (and everyone) help. I've always knew I was behind some things but this real world experience slapped me in the face and now I'm trying to readjust.

My manager has already been aware of my lack of knowledge but I'll talk to him to know if they still want me there. If I keep my job I for sure will be asking for more help at the start of a new project.

[KineticLensman]

Crucially, don't start the discussion with "do you still want me" but with "I'm concerned that I might run into problems and wanted to discuss how we can avoid them" (or something like that).

Some managers would welcome this discussion. It shows that you are aware that you have limitations and that you would like to improve. If nothing else it helps keep the manager / company from placing you on a task that you wouldn't be able to complete successfully, which would ultimately hit their bottom line. If the company / management are sufficiently enlightened (such companies do exist), they may be able to find additional training or development opportunities to enhance your skills

FWIW, when I was a manager, I ALWAYS liked to find things out before they created a problem, when there was time to fix them, rather than in the middle of some critical task.

Good luck!

[michaelbuckbee]

An even better starting point would be: "Hey Manager, I'm dissatisfied with the quality of my work on medium_complexity_project and want to make sure that I'm improving going forward. Here are the steps I'm taking (list steps) do you have any other suggestions on what I can do to improve here?"

[KineticLensman]

Yes. In fact this is an interesting topic in its own right - how do you approach management when you have found a problem. In my experience, there is a sort of scale here, along the lines of:

* do nothing and keep quiet (almost always the wrong thing)

* say "help"

* say "I've found this specific problem, but I don't know what to do"

* say "I've found this specific problem, here are some options for fixing it - what do you think?"

* say ""I've found this specific problem, doing X will fix it - what do you think?"

This will vary a lot in practice and depending on circumstances, but I think as people increase in experience and knowledge they tend to approach management with solutions rather than just problems.

[patrickthebold]

I agree with the sibling, but let me be more explicit: It's going to be hard to take time off, "level up" and then come back and get another job. Your best bet is to stay where you are and keep your job. The company has already invested in you and your manager has every incentive to help you improve rather than finding someone else.

You should go to you manager with a look to the future: come with some specific things you can do differently on the next project, and perhaps also some general 'goals' for improving your skill.

Then, most importantly, do what you said, and get better.

All this assumes you are happy and want to stay in engineering, if you do think you'll be happier doing something else, then by all means go ahead and do that.

[sosuke]

Don't phrase the conversation like that. If you want to get better start there. Say you'd like to improve. That your first attempt here was rough and didn't work out but pairing up with a more experienced developer would give you some rails to keep you on the right path.

Either way. Keep your head up! Asking for help is the first step of an endless journey.

[jrumbut]

Make sure to really listen to what your manager says is the real problem. Sometimes in these situations we get flustered and jump to solving the wrong thing.

Maybe the real issue here isn't engineering ability but communication, that you didn't let anyone know you were having challenges, didn't set expectations about how the project was going.

There could be more or less going on here than just code quality, so like I said, really listen and ask questions and keep an open mind.

Also to reiterate what others are saying, don't go asking about being fired because it can come off like you want to leave or have given up. You've been humbled but it doesn't take away the good parts of what you do, you're a pragmatic, independent, get stuff out the door type adjusting to a larger team. This is normal growing pains.

[yowlingcat]

> I'll talk to him to know if they still want me there.

Why would you think they don't want you there? This is not a helpful mindset to have. Here are the facts:

1) You passed the interview process.

2) They made you an offer.

3) They've continued to invest in you as an engineer by giving you feedback on your weak spots and where you can improve.

If you were really that far behind, they would have realized that in the hiring process and you would /not/ have received an offer. So let's start there. They definitely still want you there. That is why they hired you.

Second, let's talk about your "lack of knowledge," "being behind some things" and "real world experience" that "slapped [you] in the face" -- based on your mindset it looks like you are viewing this as a negative, or as proof of failure. Why is that the case?

You have 10 years of experience solving problems and getting paid for it. Now, you are solving different kinds of problems, so you're developing new muscles. It's expected on their end (and should be expected on yours) that there is some kind of /ramp up/. Talk about what ramp up means. Figure out your manager's expectations, and figure out what resources you have available to engage in ramp up. I guarantee you this, there's ramp up at any new medium-big company anywhere you go. There's tribal knowledge, spinning up on the industry vertical, etc -- all of this is incompressible, doesn't matter how good of an engineer your are.

If your manager is any good, they likely know about this and will appreciate you being aware of this problem as a logistics problem, not a moral problem. So think about it that way. Stop thinking about "whether they want you there" -- start thinking about "what blockers are in your way towards being productive" and start building a game plan with your manager. Worst case scenario, you're not able to accomplish it, but at least you gave it an effort and approached it the right way. That's a much more mature, proactive and effective approach than self-sabotaging yourself with feelings of inadequacy. I have a hunch that you won't fail if you do this, though. Just thinking about what you want to get accomplished and the nitty gritty details of how you get there and collaborating with your manager to get to a plan you're both happy with is /a lot/ of work -- once you've done that, if you work at a functional organization, the chances of you succeeding are very high!

Give yourself a pat on the back, while you're at it. Getting to a point where you're still being challenged after 10 years of experience is a /good/ thing! It reflects well on you and indicates your desire for growth. In all likelihood, your company saw this motivation in you and that's why they hired you. Look at the positives and opportunities here, and I'm sure you'll do amazing.

Good luck!

[rramadass]

Much needed shot in the arm !

[marton78]

This is excellent advice. Take this to the heart, OP!

[godshatter]

>So some tactical thoughts of possible advice: 1. Face the issues head on -> take all the negative feedback on the code and rework the medium complexity task 2. Learn to unlearn bad habits. Yes, it's harder, but it comes with practice. 3. Commit to maybe taking a course work online (maybe seek advice from others on what are good ones to address weaknesses you have)

I'd also add to this: learn the why as well as the what. There are reasons why hardcoded values shouldn't be used, why OP's structure was bad, and so on. Learning why will help build those habits and make them stick.

[vlovich123]

I don't think I've come across coursework that's intended to level up coding ability itself (i.e. good software engineering/design) rather than teaching basic knowledge things. I'm curious if anyone has come across anything of that nature.

[0xdeadbeefbabe]

I've come across the book Clean Code, which presumes to improve your craftsmanship. It has been improving craftsmanship for 12 years, and everyone has noticed of course.

Have you seen a shortage in people who dress up their preferences as facts? Maybe a better question is, who is producing the good software? Oh, and software ought to include malware (personal preference).

[vlovich123]

I don't know, but some of the people I consider to be really good software developers seem to reference "The Pragmatic Programmer" (perhaps even more than I realize do since I never read the book but have heard of "rubber duck debugging" & "DRY").

Generally, good software would have to be first defined and there's no universal definition. In most projects, I require it to have the following properties: * New developers find it easy to ramp up on * A handle on the defect rate (usually through adoption of best-practices like unit tests, fuzzers, automated tools, CI/CD, reproducible builds, etc). * "Fires" infrequently enough relative to team size that it's manageable to accomplish your business goals. * No "surprises" in adding new features/fix bugs where you didn't expect them. * Meets business requirements today & can meet them tomorrow.

However, in other cases, like prototyping, "good software" means, "explores the problem space as quickly & cheaply as possible without worrying about any of those other things". Some of those other things can be useful in accomplishing this, especially if you plan to pivot from prototyping to the above definition. If you don't use them effectively then throw away your prototype before productionizing & start from scratch.

[jkhdigital]

For me this knowledge has always come from working on a variety of projects and seeing the effects of various architectural and design decisions on the result. Hard to imagine how such things could be taught otherwise, honestly.

[modzu]

id argue acquiring the skills and experience to be a good pm is on par with doing the same to become a better engineer. good pms have very different skills to software engineers - communication, communication, more communication. obviously software experience lends itself to managing software projects well so youre half way there, but i wouldnt underestimate it. it sounds to me, that if you recognize and have identified your weaknesses as an engjneer, youre also half way there to learning from them and getting better at it. the question is what do you enjoy and what will you be motivated to work at? do that.

[saddington]

+1 on this. damn.