magnify
Home coding So You Want To Be A Coder
formats

So You Want To Be A Coder

Published on October 2, 2011 by in coding

Self-Directed Job Enlargement

This article is dedicated to my friends and colleagues working in non-coding technical roles that wish to make a transition or at least increase the amount of coding in their work.

The Dilemma

In software development teams above a certain size, there are often software engineers and systems engineers (including testing, support, sales, and technical marketing engineers). On some of the teams I have been a part of, a number of systems engineers have wanted to become software engineers / coders but face a dilemma. The issue is that if they have not been hired on as a developer, are valued in their current systems role and have not proven themselves able coders, how can they start coding? The situation is often something like this:

  1. A systems engineer wants programming assignments but is not getting any
  2. The development manager realizes the engineer wants to move into coding but does not see enough ability or demonstrable interest to assign coding tasks in lieu of tasks that need to be performed from a business perspective
  3. Without coding tasks, the systems engineer feels he cannot demonstrate ability and thus become a coder

So it seems we have a catch-22 where the systems engineer wants, but cannot find a way, to become a software developer which can lead to decreased job satisfaction.

So what can a systems engineer do? Beyond coding on the side and taking classes which may not impact work at the company, how can one get recognized for coding by your coding peers at the company?

The Do It Yourself (DIY) Approach

While I have never desired to become a full-time coder when I wasn’t hired on as one, I have had my code recognized at some companies and the ways I’ve done it may give you a leg up.

First of all, I don’t view coding as special discipline that only people specifically assigned to code do the coding, after all, most technology companies are not unionized. My view is that code is a tool, much like a spreadsheet is a tool. When you have a task that can use a spreadsheet, use a spreadsheet and when you have a task that can use some code, write some code.

One of the best ways to get started is to write some code to make your work more efficient. This way the code can be easily justified as one way to implement a work task and you’ll get used to coding as a natural part of how you work. If you are in an “Ops” role, you can also view this as a natural extension to “DevOps“. Once you can help yourself, you can move on to helping others and even entire teams. As people see your tools become useful, you will get more recognition as a coder and may formally move into a coding role once you are recognized as such.

As a firm believer in the Do As I Do and Not As I Say approach, here are some situations where I have written programs on the job where it wasn’t my formal responsibility and received recognition:

  1. Be Pro-active

    The first part of coding for yourself is to take initiative and not wait until someone gives you a coding task, since you may be waiting a very long time. If you see something that might be interesting, roll up your sleeves and see what happens.

    A while back, I would work with our customers on acceptance testing of our product. In this situation, our expertise and value was primarily in the C++ back-end; however our front-end code was available for inspection as it was coded a in dynamic, interpreted language. I thought the code could be a bit tighter here and since I was the one representing my firm on the front line, on my own time, I refactored our front end code. When I showed it to our development manager, it was recognized as good work, and I had a software developer assigned to integrate my code.

  2. Help yourself

    The great thing about coding is it can automate and improve consistency for repetitive tasks, making time-consuming tasks manageable and otherwise impossible tasks time-consuming. If you are faced with a task like this, write a program to help yourself out. Creating tools for yourself can have positive spill-over effects as well.

    In one situation, we had not yet build an automated installer and I needed to run multiple installations / upgrades of our software on 6 servers. To streamline the then-manual process, I wrote an automated, “one click,” installation / configuration / upgrade script. Not only did others notice I had a one click installation for an otherwise-lengthy task via my installs and upgrades, it gave me some insight that I was able to contribute to our dev team when we did create a formal installer.

  3. Help a Colleague

    Once you can help yourself, you can move on to helping others. This requires additional skills as you’ll need to do requirements gathering and push multiple releases if your tool / program is successful. However, the rewards are much greater because now your skills are making an impact on the people around you.

    While acting as a product manager ahead of a release, we had to update the localization of our product for a double-byte language where we had significant customers. We were facing significant schedule risk with our process so I worked with our translation and build engineers to create a tool to speed up the translation. We finished on time and the tool was useful enough that I updated it for several releases. Additionally, the colored, graphical status pages made the tool more usable by the translator and more noticeable by others from afar.

  4. Help an entire team and get the buzz out

    Finally, when you are ready, you can build an app that is used by many people internally. If successful, your app will go viral inside your organization and people will start creating a buzz about your code for you. The additional challenge from working closely with a few colleagues is that people you don’t normally work with will suddenly start asking you for your app and even have new product requirements you will need to manage.

    In this case, the app I built is most likely still in use to derive competitive advantage so I’ll leave out the details. Our team was was working with a Fortune-50 account and I ended up building an app that was used by our team and presented to the client. We successfully closed the account due to many factors; however, it was recognized that this was a significant contribution. Eventually the app became important enough that it was actively requested by our staff (and escalated to higher management when I was otherwise too busy), mentioned by the CEO in all-hands staff meetings and attracted the attention of the CTO who took a personal interest in the app.

In all of these situations, coding was not my responsibility but I took it upon myself to make my life and that of my colleages easier by coding. In the process, my code was recognized by peers including software engineers, systems engineers, salesmen and my CTO. It was also easy to justify spending my time on these coding projects because they improved the work we already needed to do.

While it was not my desire to become a coder in any of these situations, my projects received enough recognition that I believe it would be much easier for a development manager to justify a formal switch or assignments for someone if desired.

Summary

If you are in a situation where you want to code and need to get some recognition for coding before getting a formal role or task, find a project to make your life easier and more effective. If these projects impact the bottom line and if you can get your colleagues using and creating buzz about your apps, you’ll have gone a long way to showing your coding chops.

Have you made the transition from a non-coding role to a coding one? If so, how did you do it? What worked and what didn’t work?

 
 Share on Facebook Share on Twitter Share on Reddit Share on LinkedIn
No Comments  comments