As I reflect over my time as a developer for a variety of teams and companies, I see three major themes on how I sought to curate my time at work.
Learning the Language
In each company I have joined, I have had to learn something new. I went to a bootcamp that focused on Ruby and JavaScript, and then my first job after school was in Java and Spring(and about 20 different other skills). Next, it was Java and JavaLite. The next role was in Python. My current role is in Ruby, Elixir, and JavaScript.
At my last company, I was truly settling into this idea that maybe I've context switched too much. The frustration of having to learn a new language again felt daunting on top of a demanding codebase. I reflected deeply on this idea and found I love the spice of life to learning new things. I deliberately switched to working at a consultancy for that opportunity. Some people vibe with either style of working (finding a thriving niche and taking it to the moon or floating around to wherever the wind takes them).
This skill path requires constant tending. At the beginning of a role, your Plant Self will be bulking up on whatever content and learning style fits you best to skill up to understand what the codebase is detailing. Ask for suggestions from your new coworkers. Start to understand that new language's culture and community. Take an open interest in what this new language will require. Giving yourself plenty of opportunities in the first 90 days to learn the language will greatly help yourself in the long term of the team.
This is where junior developers thrive best. Seeing everything from a new perspective to the veteran team can shed valuable light on new versions of the language along with performant optimizations and improvement to the codebase's documentation.
Learning the Codebase
If you're on a greenfield project, congratulations you don't have to worry about this step!
For everyone else, you got some legacy code to learn. It's like reading through the diary log of a married couple. There are their nascent honeymoon days, the ups and downs, the tenuous years, and the recent present good ol' days. And depending on the length of how long this company or code has been written, there will be a lot to learn and understand.
I think one of the best ways to dive headfirst into a codebase is to pair with a coworker for some amount of onboarding.
It could be for the first 1-2 months for smaller codebases,
Or maybe for 6 months for larger codebases. (Yes, I'm serious)
If you've got a massive monorepo that's divided into an ever-increasing amount of teams with around 200 total engineers... There needs to be more support for onboarding engineers than a pat on the back and a high five after two low priority bugs are merged.
Maintaining a healthy Plant Self in this area is crucial. I think this is the area where folks may get down on themselves the most while being a programmer. Interacting with a company's codebase can be daunting and highly complex, and factor that to day by day, negative intrusive thoughts may creep in to say "You're not good enough to do this."
So take time for self-care. Meditate, journal, exercise. Do the things that help your mental health the most.
Have a mentor on your team or company who will support you.
You need to know the codebase to be successful at your job. If you don't know the codebase, you will struggle with being a satisfactory engineer for the company.
Learning the Business
This skill is closely coupled with Learning the Codebase. Reading the aforementioned diary log of a married couple can reveal strange compromises and weird conventions that you personally wouldn't imagine affecting your life.
Why do we check for this strange logic? Oh, that's because of the company's 5 outdated models for subscription and we still have clients using them.
Wait, we check twice for this user input? Oh yeah, that's because it's being pushed by two competing department's API within the company and they refuse to merge data.
Wait, why do we take 3 weeks to roll a production release? ..... The odd questions go on and on. And it's all impacted by the mechanisms of the business!
You'd think, that can't be-- technology is supposed to be void of our human quips and quirks. Well, I hate to tell you, but no. Far from it. You being a successful engineer are navigating the business logic that influences your codebase. It's psychological and political. It's the flirting skirt that Technology overall continues to linger on to the ethical ramifications of how our world operates and evolves.
Your Plant Self may find little to thrive off by Learning the Business. Perhaps you're sensing the soil not optimal, the nutrients minimal, and the sun too harsh. Learning the Business is a skill that can be quite ethereal. It's the atmosphere of your workplace. The misty haze that floats amid the meetings, interactions, and initiatives that occur within a company.
Conclusion
Atrophy to either branch leads to stagnant professional growth, or maybe even death (jk, but you may get fired)
If they are challenging, that's okay! You're the judge of what allows your Plant Self to thrive. If the proximal zone of success is just too toxic and reachable, it is up to you to remove yourself from that situation.
Staying longer-term at a company can lead to a strong and healthy Plant Self that has deep roots established in a place. You're the definition of thriving! What do you do with all that gorgeous Plant goodness?
These three skills are individually powerful and well worth it to learn and understand but are also connected in how each scenario lends to the developer’s experience, like a vine growing incrementally node by node leaf by leaf. Now imagine with me, if we cut off that vine at any point (learning the language, learning the codebase, learning the business), you outright curtail the growth of that plant. This is what context switching is like. It grows less debilitating the longer you stay on that project/team/job.
To keep with this plant analogy, while it gets easier to context switch over time, there’s also a health improvement to this little vine. Constant clipping of its vines will lead to new branches of growth, or a stronger stalk to weather the velocity.