ChatGPT as a mid-level developer

Robert Sweetman
Version 1
Published in
5 min readJul 14, 2023

As a mid-level developer you know how to do some things, you know what should be possible but sometimes getting there can be slow as you’ll be looking almost EVERYTHING up.

AI hype is absolutely off the charts and might instinctively turn some people away from taking a deeper look at what’s going on.

This sort of knee-jerk reaction is a trap, but why?

If nothing else, ChatGPT is a force multiplier when it comes to getting things done, if you keep the following in mind:

  • Ask well-structured questions that are limited in scope.
  • Enquire about the smallest part of what you’re trying to do.
  • Concentrate on understanding the explanation.
  • Don’t paste your work/company code into the box. Go for concepts and understanding over fixing your specific issue, you’ll learn faster this way.
  • Test what you write

As a mid-level developer, you can:

  • Recognise nonsense and course correct.
  • Iterate quickly through possibilities
  • Understand the code examples
  • Test what you implement

I might have mentioned testing a few times… 🤷‍♂ 😆

So by way of proving my point and encouraging you to get some experience with these tools, here’s an actual DevOps scenario I went through recently.

Shout-out to all my DevOps colleagues who’ll know that every day throws up something absolutely new that they’ve never seen before… 👍

So I want to pass IP address and port pairs (as tags on EC2 instances) which ansible is going to pick up and make available to a bash script via Jinja2 templating and that script is going to check whether these (1 or more) ip:port pairs are accessible from the instance with the tag using netcat.

This check forms part of a metric which records a fail if all Netcat attempts fail. So if there are three ip:port pairs then all the reviews have to fail for the metric to start shouting about a connection failure.

In summary, the steps are…

  1. What’s the format of the tag string?
  2. Ansible parses the tag
  3. Pass the values to Jinja2 templating

Some immediate problems came to mind, others arrived when I began testing.

Step 1 — What’s the format of the tag string?

I would have loved to have specified the tag contents in a sensible way but had to come back to this… "192.168.1.2 8080 192.168.1.10 3389"

The terraform tags parser would crash if I tried to separate the ip address from the port with a colon(:) or something else like a comma(,) and I couldn’t successfully format this information as JSON for the same reason.

So we’re stuck with a string where it’s “IP-address port ip-address port ip-address port” and so on. I knew (as a mid-level dev) that this wasn’t great but didn’t run into a better solution…

Steps 2 + 3 — Getting Ansible to Parse the tag info & handing it off

I don’t really know how to get Ansible to do the heavy lifting so I’ll ask ChatGPT…

There’s clearly a LOT going on here and I’m not going to attempt to break it all down line by line. However, it’s certainly worth pointing out all the info that you can immediately use.

  1. Creating the pairs using .split(‘ ‘) and batch(2)… I’ve not seen batch before so it’s worth looking this up.
  2. How to do the for loop in Jinja2, another thing I now don’t have to look up independently.
  3. Using loop.index to create a function per ip/port pair that can be called lower down if I need to.

In this small example, I’ve condensed having to look up 3 things independently (or hoping I stumble across a blog post where someone’s done exactly the same thing) into one question.

ONE IMPORTANT THING TO NOTE…

I absolutely can’t guarantee that this will work, although I can eyeball it (mid-level remember) and go from there.

Also, how does it behave if there’s only one ip/port pair like “192.168.2.4 3389”? Can the initial ansible parsing of .split(‘ ‘) and batch(2) cope?

What I actually ended up doing this was to check first if the list length was > 2 then parse it one way, if it wasn’t then I went about it a different way.

It’s not the main point I’m trying to make, but yes, test whatever you’re about to implement!

The main thing is this… For developers, Google (& search generally) became our primary way of asking questions, backed up by sites like Stack-overflow and blogs. Maybe also actually reading the documentation?

We’ve been doing that for > 10 years and while it’s been pretty successful by comparison it’s not efficient. Comparing the time it would have taken me to look up those three steps and piece them together against asking one question… it’s 5 to 10 times faster.

I’m not even getting into the scenario where you try ‘x’ and can go back to the conversation thread with results, fine-tuning or a different take on the same problem.

Now, with a little bit of our own context and some (mid-level) experience, we have a vastly more powerful tool for information retrieval. We’ve all suddenly been given the ability to ask questions and receive answers in an accelerated fashion.

I would estimate I’m at least twice as productive as I was compared to back when I had to hunt across the internet for answers. Still, don’t forget to check your fast food for bugs. It’s still on you to test your code!

About the Author:
Robert Sweetman is a Consulting Engineer here at Version 1.

--

--