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

Interrupting Coders Isn’t So Bad

Here’s a hot take: disrupting coders isn’t all that bad.

Some disruptions are certainly bad but they usually aren’t. The coder community has overblown the impact. A disruption can be a good thing. How harmful disruption might be a symptom of other problems.

There are different kinds of disruptions. They are caused by other coders on your team, managers and other non-coders, or meetings throughout the day.

The easiest example to debunk is a question from a fellow developer. Imagine someone walks over to your desk or they ping you on Slack, because they have “one quick question.” Do you get annoyed at the interruption when you were in the middle of something important? You help out your teammate quickly and get back to work, trying to pick up where you left off. That’s a kind of interruption we complain about frequently, but I’m not convinced this is all that bad.

You are being disrupted but your team, of which you are only one member of the whole unit, is working smoothly. You unstuck …

Announcing Feet, a Python Runner

I've been working on a problem that's bugged me for about as long as I've used Python and I want to announce my stab at a solution, finally!

I've been working on the problem of "How do i get this little thing I made to my friend so they can try it out?" Python is great. Python is especially a great language to get started in, when you
don't know a lot about software development, and probably don't even know a lot about computers in general.

Yes, Python has a lot of options for tackling some of these distribution problems for games and apps. Py2EXE was an early option, PyInstaller is very popular now, and PyOxide is an interesting recent entry. These can be great options, but they didn't fit the kind of use case and experience that made sense to me. I'd never really been about to put my finger on it, until earlier this year:

Python needs LÖVE.

LÖVE, also known as "Love 2D", is a game engine that makes it super easy to build small Lua…

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 only re…