20 subscribers
התחל במצב לא מקוון עם האפליקציה Player FM !
Episode 452: Consulting refactor and extra work, extra scrutiny
Manage episode 471853335 series 1414955
In this episode, Dave and Jamison answer these questions:
I’ve been a developer for about 1.5 years. I work for a large consultancy. we provide services to big clients. I’m working on a front-end codebase that has been through three consulting companies already.
Tired of just moving tickets and fixing bugs, I decided to refactor the front end of the entire application we support. Touching the codebase to add features gave me a pit in my stomach. No integration tests, no staging environment, huge functions with tons of parameters, etc.
The client provided technical guidelines that were pretty solid, but the code just didn’t follow them at all. In the time left on the contract, I refactored the codebase to fix the biggest problems to align with the client’s technical guidelines. I did all this without my manager/PO/PM asking me to.
But now, how do I communicate what I’ve done to the client and my manager? Can I get any recognition for it?
A listener named Mike asks,
I’ve been in my role for about 1.5 years in a dev team of 7. I really like the job, it has a good culture and I’m learning. Sometimes I channel my desire to learn into improving our projects with small, self directed changes on my own time. I these changes are useful but aren’t high enough priority to make it into planned sprint work. I don’t inundate the team with these requests, it happens maybe 1-2 times a month.
We make a point of working in small steps, usually submitting several PRs per day each. I really like this approach, and I also keep my occasional self-directed bits of work small in scale. However, I’ve noticed these PRs receive more scrutiny and more “whataboutism” that our regular on-the-books PRs.
For example, for regular sprint tickets there’s an understanding that we’re making progressive improvements or building small pieces of features that exist within the constraints of our systems. We might flag broader improvements to consider, but there’s no expectation to re-boil the ocean every time we want to merge code.
When I submit a self initiated piece of work there can be a long back and forth of suggestions that can involve changing other dependent code, changing internal APIs which may have side- effects, and generally a level of defensiveness in the code that we never normally expect. I understand that by submitting off the books PRs I am requiring some work-time from reviewers, but there is more pushback than I’d expect. It feels like because I get the ball rolling on my own time the normal cost-benefit constraints go out the window, and the code purists come out to play.
Could I be annoying the team with these submissions? Have you experienced team members doing the same thing? Is there a way I can scratch my own itch by learning against our systems without creating this resistance?
461 פרקים
Manage episode 471853335 series 1414955
In this episode, Dave and Jamison answer these questions:
I’ve been a developer for about 1.5 years. I work for a large consultancy. we provide services to big clients. I’m working on a front-end codebase that has been through three consulting companies already.
Tired of just moving tickets and fixing bugs, I decided to refactor the front end of the entire application we support. Touching the codebase to add features gave me a pit in my stomach. No integration tests, no staging environment, huge functions with tons of parameters, etc.
The client provided technical guidelines that were pretty solid, but the code just didn’t follow them at all. In the time left on the contract, I refactored the codebase to fix the biggest problems to align with the client’s technical guidelines. I did all this without my manager/PO/PM asking me to.
But now, how do I communicate what I’ve done to the client and my manager? Can I get any recognition for it?
A listener named Mike asks,
I’ve been in my role for about 1.5 years in a dev team of 7. I really like the job, it has a good culture and I’m learning. Sometimes I channel my desire to learn into improving our projects with small, self directed changes on my own time. I these changes are useful but aren’t high enough priority to make it into planned sprint work. I don’t inundate the team with these requests, it happens maybe 1-2 times a month.
We make a point of working in small steps, usually submitting several PRs per day each. I really like this approach, and I also keep my occasional self-directed bits of work small in scale. However, I’ve noticed these PRs receive more scrutiny and more “whataboutism” that our regular on-the-books PRs.
For example, for regular sprint tickets there’s an understanding that we’re making progressive improvements or building small pieces of features that exist within the constraints of our systems. We might flag broader improvements to consider, but there’s no expectation to re-boil the ocean every time we want to merge code.
When I submit a self initiated piece of work there can be a long back and forth of suggestions that can involve changing other dependent code, changing internal APIs which may have side- effects, and generally a level of defensiveness in the code that we never normally expect. I understand that by submitting off the books PRs I am requiring some work-time from reviewers, but there is more pushback than I’d expect. It feels like because I get the ball rolling on my own time the normal cost-benefit constraints go out the window, and the code purists come out to play.
Could I be annoying the team with these submissions? Have you experienced team members doing the same thing? Is there a way I can scratch my own itch by learning against our systems without creating this resistance?
461 פרקים
כל הפרקים
×
1 Episode 460: Losing autonomy and I got skipped for a promotion even though I'm awesome 33:07

1 Episode 459: Am I cutting edge and how to compliment someone who went from super jerk to super nice 22:44

1 Episode 458: Infinite tech debt hack and figuring out what is going on 34:00

1 Episode 457: How do I get off the on-call rotation and "big tech" == "big leagues"? 27:25

1 Episode 456: Will I look bad on the job market if I'm a crypto developer and struggling to go from management back to dev work 31:39

1 Episode 455: UX designer without a mentor and I get bored too easily and stressed too easily 33:00

1 Episode 454: Tracking productivity? and my CTO is ChatGPT 28:11

1 Episode 453: Why did my company build an internal LinkedIn and how do I not get stagnant in my skills? 31:34

1 Episode 452: Consulting refactor and extra work, extra scrutiny 25:12

1 Episode 451: Un-collaborative architect and who is my boss? 32:47

1 Episode 450: I'm terrible at behavioral interviews and time zonessssssss 34:04

1 Episode 449: My tech lead ignored my warnings and I don't know what my leadership style is 29:54

1 Episode 448: Title over salary and from figure skater to software developer 28:01

1 Episode 447: Overleveled at FAANG and accidental draft feedback 30:11

1 Episode 446: Wading through AI slop and they don't get git 33:19
ברוכים הבאים אל Player FM!
Player FM סורק את האינטרנט עבור פודקאסטים באיכות גבוהה בשבילכם כדי שתהנו מהם כרגע. זה יישום הפודקאסט הטוב ביותר והוא עובד על אנדרואיד, iPhone ואינטרנט. הירשמו לסנכרון מנויים במכשירים שונים.