Skip to main content

My Software Job Transition Strategies?

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.

Comments

Popular posts from this blog

CARDIAC: The Cardboard Computer

I am just so excited about this. CARDIAC. The Cardboard Computer. How cool is that? This piece of history is amazing and better than that: it is extremely accessible. This fantastic design was built in 1969 by David Hagelbarger at Bell Labs to explain what computers were to those who would otherwise have no exposure to them. Miraculously, the CARDIAC (CARDboard Interactive Aid to Computation) was able to actually function as a slow and rudimentary computer.  One of the most fascinating aspects of this gem is that at the time of its publication the scope it was able to demonstrate was actually useful in explaining what a computer was. Could you imagine trying to explain computers today with anything close to the CARDIAC? It had 100 memory locations and only ten instructions. The memory held signed 3-digit numbers (-999 through 999) and instructions could be encoded such that the first digit was the instruction and the second two digits were the address of memory to operate on

The Range of Content on Planet Python

I've gotten a number of requests lately to contribute only Python related material to the Planet Python feeds and to be honest these requests have both surprised and insulted me, but they've continued. I am pretty sure they've come from a very small number of people, but they have become consistent. This is probably because of my current habit of writing about NaNoWriMo every day and those who aren't interested not looking forward to having the rest of the month reading about my novel. Planet Python will be getting a feed of only relevant posts in the future, but I'm going to be honest: I am kind of upset about it. I don't care if anyone thinks it is unreasonable of me to be upset about it, because the truth is Planet Python means something to me. It was probably the first thing I did that I considered "being part of the community" when I submitted my meager RSS feed to be added some seven years ago. My blog and my name on the list of authors at Plan

Pythonic Defined

Introduction Losing is Good Strings Dictionaries Conclusion Introduction Veterans and novices alike of Python will hear the term "pythonic" thrown around, and even a number of the veterans don't know what it means. There are times I do not know what it means, but that doesn't mean I can define a pretty good idea of what "pythonic" really means. Now, it has been defined at times as being whatever the BDFL decides, but we'll pull that out of the picture. I want to talk about what the word means for us today, and how it applied to what we do in the real world. Languages have their strengths and their idioms (ways of doing things), and when you exploit those you embrace the heart of that language. You can often tell when a programmer writing in one language is actually more comfortable with another, because the code they right is telltale of the other language. Java developers are notorious for writing Java in every language they get their hands on. Ho