> I was really worried that I wasn't producing like I should at my seniority. This has since gone away though.
Absolutely had this in my new role, I'm about to hit a year on and have an excellent performance review which has since assuaged my concerns of imposter syndrome or having lost my touch after spending two years in a public-sector hellhole. Went from "Star QB" in an MS shop to "Holy Shit WTF is this Kubernetes shit even doing and how do I get my job done." Stressed as I may have been, it was temporal and I've gotten good lessons from it.
If I have any takeaways from this past year:
For Managers:
Add in some amount of check-in one-on-ones to keep folks aware of their performance and standing. As good a manager as my supervisor is, ours were oriented towards ensuring I was happy with the role and not wanting to leave quickly and waste the 30K recruiter fee. For that matter, I'm not one[0] to go seek validation from others and especially not when they're already over burdened with "real" meetings.
For Engineers:
Even if you're not "Senior" in terms of $TECHNOLOGY, you're (hopefully) Senior in terms of your soft-skills. If you're left scratching your head wondering "how the fuck do I get this deployed" or "what the fuck is the development cycle" or "why the fuck is there an 11 step baby-sitting process for the local development workflow" - these are opportunities to add in documentation, scripts, or process changes to the firm. If you've done your shopping right, they're probably amenable to these changes.
Personally, I scripted our local Docker Compose development workflow such that one has a clean-slate environment with one script, and can build and patch any project's Docker image / Docker Compose service with one script as well. Somehow we lacked this, but everyone had their cotdamn minds blown when I put that out there for feedback - and here I was thinking it was some silly scripts they'd likely turn their nose up at.
New job, lots of, to me, low hanging fruit ripe for automation and documentation. The team has been adrift for a long time and all the juniors just accepted broken processes as facts of life.
Every time I have someone walk me through the completely undocumented process for x, I take notes and mark the best candidates for automation.
I then go through the process a second time, adding all the api calls and semi-automate the process so instead of logging into four different consoles in the browser hunting for values and setting minor things in different places, you can up front declare seven variables, and just copy/paste chucks of code that will perform all the steps for you. You are still acting as the error handler.
For low frequency tasks, it usually ends there. For high frequency tasks, I take the time to add error handling so it can just be part of a pipeline.
It's crazy to me that the team has put up with these processes for so long, I've been turning tasks that used to take 4-12hours and highly error prone and turning them into well documented code copy/paste jobs that takes about 15 minutes from start to finish, the vast majority of which is waiting for a build pipeline to finish.
Absolutely had this in my new role, I'm about to hit a year on and have an excellent performance review which has since assuaged my concerns of imposter syndrome or having lost my touch after spending two years in a public-sector hellhole. Went from "Star QB" in an MS shop to "Holy Shit WTF is this Kubernetes shit even doing and how do I get my job done." Stressed as I may have been, it was temporal and I've gotten good lessons from it.
If I have any takeaways from this past year:
For Managers:
Add in some amount of check-in one-on-ones to keep folks aware of their performance and standing. As good a manager as my supervisor is, ours were oriented towards ensuring I was happy with the role and not wanting to leave quickly and waste the 30K recruiter fee. For that matter, I'm not one[0] to go seek validation from others and especially not when they're already over burdened with "real" meetings.
For Engineers:
Even if you're not "Senior" in terms of $TECHNOLOGY, you're (hopefully) Senior in terms of your soft-skills. If you're left scratching your head wondering "how the fuck do I get this deployed" or "what the fuck is the development cycle" or "why the fuck is there an 11 step baby-sitting process for the local development workflow" - these are opportunities to add in documentation, scripts, or process changes to the firm. If you've done your shopping right, they're probably amenable to these changes.
Personally, I scripted our local Docker Compose development workflow such that one has a clean-slate environment with one script, and can build and patch any project's Docker image / Docker Compose service with one script as well. Somehow we lacked this, but everyone had their cotdamn minds blown when I put that out there for feedback - and here I was thinking it was some silly scripts they'd likely turn their nose up at.