Teresa Coleman, IT Architect, IBM, discusses how IT professionals can adapt to a changing workplace demanding coding skills.

Those of us whose background is in IT infrastructure probably learned basic coding in college or university but used it very little, except, in my case for example, to write some basic S/370 Assembler exits, and later, to do some korn shell scripting and to write some simple HTML.

In fact, for many years I lived in a world where we all believed that writing lots of code to do clever stuff with the infrastructure just created unsustainable needs to maintain that code.

In addition, the ‘development and test’ environments were for the real Developers, not for the System Admins, so we rarely had good ways to test any significant code that we wrote.

And, it was almost a given that whatever we wrote would wither and die when we left a team as nobody would understand it and/or maintain it properly when we were gone.

So we didn’t write much code.

We plugged infrastructure products together as best we could, using the available built-in integrations and we lived with the gaps.

If we did write code it was to do very simple things like checking if the backups worked and sending an email if not, and eventually the products started doing that for us.

Then cloud happened, and following it came concepts such as infrastructure-as-code, software defined networking and DevOps.

This has opened up a whole new universe of possibilities for innovation.

And now it seems that everybody is supposed to write code.

Are we?

And if we are, for the generation of IT professionals out there who have spent their careers NOT writing code, where do we start?

The simple answer is probably: “Create a BlueMix account, pick a language and start writing”.

This may be the right first step, but what are the second and third steps?

If we are all going to write code, it needs to be good code. We need to learn good code design, development and test practices, ideally without going back to full-time education to do it.

How can we do this quickly, while leveraging the skills and experience we already have? Is there one book or one course we can do?

Getting started

I scratched my head over these questions for a while until I realised that the answers are really in the questions.

As experienced SysAdmins, we are not really starting from scratch. We know quite a bit about design, implementation and testing. We know a lot about change management, problem determination and non-functional requirements and we know about starting small and growing things.

We need to apply this knowledge in a new area in much the same way as we do with a new product or a new operating system – by leveraging all of those skills that we have developed already.

And we start with the ‘Getting started’ guide, and then we copy a few examples and modify them and we go from there.

We start with small steps and we use what we know already to minimise the risks.

So, as SysAdmins or former SysAdmins even, we too can write real code.

But before you do write real code and put it into production, there are a few other things worth doing too:

• Talk to the ‘real’ Developers. Listen to what they have to say about coding standards and good practices. Adapt what they say to the scale of your development.
• Avoid reinventing the wheel by using their stuff where possible including their code repositories, their development and testing tools and even their code.
• Be prepared to throw your code away and start again when you learn a bit more, even to switch languages if you discover that the one you picked doesn’t really suit your needs.
• Try to do a course in the programming language you choose if your development takes off – it can save a lot of time in the long run.
• Implement version control from the start.
• Do some design and document it. Consider using IBM Design Thinking – the Field Guide is only 29 pages long.
• Document your code too.
• Share your documentation – not just with the Systems Admin teams – share it with the Developers too. Deal with the feedback.
• Think about the amount of maintenance effort you are creating for yourself – be realistic about this.
• Be prepared to hand your work over to the Development team if it turns into a major piece of code development and long term maintenance which has become an integral part of your Service.

Above all, enjoy learning some new skills and putting them to use.

Note: Opinions expressed here are my own and don’t necessarily represent IBM’s positions, strategies or opinions.

This article was originally published on LinkedIn, and edited for web by Cecilia Rehn.