dnlgrv

Keeping up with change

Working in software is to be surrounded by constant change. It can be really difficult to figure out:

  • Do you like the change?
  • Is the change is even any good?
  • What will happen if you don’t go with it?

That last point is probably the one that will keep you up at night the most. It does for me anyway.

In software development at least, change can be a number of things:

  • A new library is becoming popular in your current programming language
  • Your company is starting to switch from waterfall project planning to Agile
  • Designers you admire are starting to use Figma instead of Photoshop
  • A different programming language is faster than your current one
  • This AI stuff seems to be taking off, should I be working in that industry?

We can be going about our daily work, shipping software and planning what’s next, and the world continues to move on and make us question what we’re doing.

It can be extremely difficult, impossible even, to analyse the change itself. For example, if you could come to the conclusion and knew that switching programming languages to the new one would be best for your career, you’d do it in a heartbeat. You’d also probably want to invest in companies surrounding it. It’s basically like predicting the stock market - you have no idea what’s going to be successful or long lasting and what isn’t.

Unless you are forced to make this change for other reasons, like your current role requires you to switch (someone else made the decision), you can’t be rational about any of this.

If you look at to the bullet list at the top of this post, I think the first one is the most important here: do you like it?

I explained a bit of this in Checking if the grass is greener, but if you’re noticing a change is happening, go and try it first! There’s very little risk and if you realise you don’t like the change then you probably shouldn’t go with it anyway.

When you already have an established way of working, and a job doing it, it can be extremely difficult to generate the enthusiam and desire to learn something new. This is why I think you have to like what the change is brining more than anything. If you like it, you’re going to want to do it more, and eventually you might be able to get paid to do it as well.

An important aspect of trying out something new is not to forget what you are already doing. Due to the way software evolves over time, old systems get left behind but still need people to work on them. So if you used to use Ruby and have since moved on to doing TypeScript development, you should still consider yourself a Ruby developer who could pick that skill back up at any point.

Lastly, try not to hop on the change train too fast either. It can take a while for the change to really show its true colours. Maybe it doesn’t end up being all it’s cracked up to be, or it doesn’t take off as you might have expected. If you do though, at least the very least I hope you’ve learned a new skill that you can apply in the future.

It definitely wouldn’t be a waste of time, but it just might not be the golden ticket you were hoping it to be.