13 ms·

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 to

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 6y ago
> 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.
- notapenny 6y ago
  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 6y ago
  Pairing, pairing, pairing, and more pairing.
  - spacemanmatt 6y ago
    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.
- foolinaround 6y ago
  interesting... I have never been in an environment where pair-programming was practised.. makes me think how much I could have improved...
  - pavel_lishin 6y ago
    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.
- deleted 6y ago
  [deleted]
- prox 6y ago
  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)
- mattfrommars 6y ago
  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.
  - eyelidlessness 6y ago
    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.
  - pavel_lishin 6y ago
    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.
- bigwavedave 6y ago
  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 6y ago
  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.
aerovistae 6y ago
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 6y ago
  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
mxmpawn 6y ago
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.
- sosuke 6y ago
  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.
- KineticLensman 6y ago
  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 6y ago
    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?"
modzu 6y ago
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.
tdumitrescu 6y ago
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.
vlovich123 6y ago
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.
- jkhdigital 6y ago
  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.
- 0xdeadbeefbabe 6y ago
  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 6y ago
    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.
deleted 6y ago
[deleted]
godshatter 6y ago
>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.
saddington 6y ago
+1 on this. damn.

pavel_lishin 6y ago

> 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.

notapenny 6y ago
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 6y ago
Pairing, pairing, pairing, and more pairing.
- spacemanmatt 6y ago
  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.
foolinaround 6y ago
interesting... I have never been in an environment where pair-programming was practised.. makes me think how much I could have improved...
- pavel_lishin 6y ago
  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.
deleted 6y ago
[deleted]
prox 6y ago
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)
mattfrommars 6y ago
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.
- eyelidlessness 6y ago
  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.
- pavel_lishin 6y ago
  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.
bigwavedave 6y ago
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 6y ago
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.

aerovistae 6y ago

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 6y ago
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

mxmpawn 6y ago

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.

sosuke 6y ago
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.
KineticLensman 6y ago
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 6y ago
  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?"

modzu 6y ago

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.

tdumitrescu 6y ago

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.

vlovich123 6y ago

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.

jkhdigital 6y ago
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.
0xdeadbeefbabe 6y ago
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 6y ago
  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.

deleted 6y ago

[deleted]

godshatter 6y ago

>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.

saddington 6y ago

+1 on this. damn.