I’ve been spending a good deal of the last two days preparing mentally for starting a whole new challenge as a developer. New things aren’t new to me, but this is different and big enough really call for some Deep Thoughts ™. For one thing, I’ve made a big move from the world of Python web development to totally other Python work and while web development has never been the only thing I do, it has been the only work that paid the bills.
That transition isn’t one that bothers me or daunts me, though. Instead, I’m thinking about transitioning to the scope of the work I’m getting into. For a long time, I juggled multiple clients and client projects every day, so no single project usually took up most of my time. Every developer juggles time through the day, but exactly how that works in each company and on each project varies a lot. I was looking for a place that I could really focus in a way that I haven’t for a long time. I think I found that, but now I have to deal with the consequences.
What exactly happens when a developer experiences a big shift in working scope and all the temporal expectations around the work we do?
One of my concerns making this change is the way I on-board to all the new work when it is something of a shakeup compared to the work I’ve been used to doing. I don’t want my acclimation to get in the way of the first tasks I’m giving or, worse, to get in the way of other people on my team. So that’s the word of the day: acclimation.
I need to focus my first couple days on maximizing my ability to acclimate to new tools, new projects, new workflows, and new teams. Everything is changing all at once and I’m going to have lots of questions and lots of problems I need to reach out to people for, or that will be answered or solved as a natural part of the on-boarding process. If any of that information slips my mind or has to get drilled into me repeatedly before it sticks then I’m taking up more of my time and someone else’s than I need to, so Transition Strategy #1 is that I will Take All The Notes.
Notes are only as useful as you can get out of reading them. Every day there’s going to be a running log of the things I learn, the things I try to do, everything I observe. That journal is going to get routinely, through the day, rolled into a living outline of the questions, tasks, and understanding I accumulate over the first few weeks. At any time those notes need to be a snapshot of my brain because it is going to be an overwhelmed brain and it needs all the help it can get.
Of course, those notes are going to be far from perfect. I’m going to make mistakes in them and I’m going to understand things wrong when people explain something new to me, so my notes will reflect mistakes as well as understanding. Transition Strategy #2 is going to be failing as fast as a person, not just a rule for software. I’m going to ask someone early before I waste more time than I should. I’m going to take advantage of the experience and knowledge around me to get up to speed and become valuable as soon as possible. I believe my reaching out as a new team member is a good investment for the team and won’t let things like fear of looking dumb to keep me from getting a helping hand.
With notes and with people I’m going to get a ton of information and I’m going to have a lot of knowledge to sift through. That’s inevitably going to take time no matter how much I try to reduce it, be more efficient, or offset my blundering with careful planning. I’m going to decide that’s okay. It is expected, it’s a normal part of a transition, and I’m not going to get held down further by frustrations that I’m not adjusting fast enough or well enough when I’m really just progressing in a totally expected pace with totally expected problems. Transition Strategy #3 will be patience, both for the time this transition takes and for me to figure it out.
That transition isn’t one that bothers me or daunts me, though. Instead, I’m thinking about transitioning to the scope of the work I’m getting into. For a long time, I juggled multiple clients and client projects every day, so no single project usually took up most of my time. Every developer juggles time through the day, but exactly how that works in each company and on each project varies a lot. I was looking for a place that I could really focus in a way that I haven’t for a long time. I think I found that, but now I have to deal with the consequences.
What exactly happens when a developer experiences a big shift in working scope and all the temporal expectations around the work we do?
One of my concerns making this change is the way I on-board to all the new work when it is something of a shakeup compared to the work I’ve been used to doing. I don’t want my acclimation to get in the way of the first tasks I’m giving or, worse, to get in the way of other people on my team. So that’s the word of the day: acclimation.
I need to focus my first couple days on maximizing my ability to acclimate to new tools, new projects, new workflows, and new teams. Everything is changing all at once and I’m going to have lots of questions and lots of problems I need to reach out to people for, or that will be answered or solved as a natural part of the on-boarding process. If any of that information slips my mind or has to get drilled into me repeatedly before it sticks then I’m taking up more of my time and someone else’s than I need to, so Transition Strategy #1 is that I will Take All The Notes.
Notes are only as useful as you can get out of reading them. Every day there’s going to be a running log of the things I learn, the things I try to do, everything I observe. That journal is going to get routinely, through the day, rolled into a living outline of the questions, tasks, and understanding I accumulate over the first few weeks. At any time those notes need to be a snapshot of my brain because it is going to be an overwhelmed brain and it needs all the help it can get.
Of course, those notes are going to be far from perfect. I’m going to make mistakes in them and I’m going to understand things wrong when people explain something new to me, so my notes will reflect mistakes as well as understanding. Transition Strategy #2 is going to be failing as fast as a person, not just a rule for software. I’m going to ask someone early before I waste more time than I should. I’m going to take advantage of the experience and knowledge around me to get up to speed and become valuable as soon as possible. I believe my reaching out as a new team member is a good investment for the team and won’t let things like fear of looking dumb to keep me from getting a helping hand.
With notes and with people I’m going to get a ton of information and I’m going to have a lot of knowledge to sift through. That’s inevitably going to take time no matter how much I try to reduce it, be more efficient, or offset my blundering with careful planning. I’m going to decide that’s okay. It is expected, it’s a normal part of a transition, and I’m not going to get held down further by frustrations that I’m not adjusting fast enough or well enough when I’m really just progressing in a totally expected pace with totally expected problems. Transition Strategy #3 will be patience, both for the time this transition takes and for me to figure it out.
Comments