I'm a lazy developer. Here's how Amazon Q is enabling me

I'm always on the hunt for ways to improve my productivity as a developer. I've spent the better part of the last two weeks diving head first into using Amazon Q Developer, experimenting with how it might work in my development flow, learning the ins and outs, and chatting with coworkers about how they are using it. Today, I want to share what I've learned so far, how I'm tweaking my productivity and staying in the flow.

When I'm writing code, I want to get in the flow and stay in the flow. Context switching -- flipping between apps, back and forth between browser tabs, a google search here, and StackOverflow search there, the ding of an email, a bleep of a Slack notification (oops, I'm late for a meeting) -- all of this comes with a cost.

I'm finding that Amazon Q Developer keeps me in my IDE. Instead of hopping over to a browser to do a google search or to read through documentation for my programming language, the framework I'm using, or the AWS docs, I can use this tool to do this digging for me.

I can ask how to get started with a new project. Here, I started with the prompt What are the steps to creating a python Flask app? Amazon Q Developer outlines the steps I need to take to get started, providing me with both code snippets and explanations.

I can never remember the steps to create a python virtual environment so I ask it questions like How do I initialize a python virtual environment?

And if I want to go deeper, I'm even presented with external references backing up the responses.

All of this allows me to stay in my IDE, reducing my context switching, and stay in the flow. Check out how my colleague stays in the flow with Amazon Q.

According to the creator of the Perl programming language, Larry Wall, laziness is one of the virtues of a good programmer. For a programmer to be effective and efficient, they must also be lazy. But not in the traditional, lounge on your couch and watch TV all day and be lazy sense. Instead, a lazy developer is interested in saving time, automating tasks, especially the boring, time consuming, or brittle ones, documenting work for others.

That's me. I'm a lazy developer.

I don't remember all the properties for an HTML text area. So I ask Amazon Q to do the research for me and propose examples for boilerplate code like HTML elements and unit tests.

I ask it to explain a block of code by selecting it and then using the "Send to Amazon Q" menu option:

And the response I get back:

And then I wanted more detail on the json.loads line:

In a previous life, I often worked as a team of one, inheriting someone else's codebase. I would come into a new codebase with no other teammates to help me figure out what was going on. This is where Amazon Q can help you get up to speed quickly, summarizing blocks of code, functions, or even whole files.

One challenging task for developers is debugging hairy bugs. It's hard because you end up having to shove a bunch of info into your short term memory in order to trace through layers and layers of code, some of which you may not even be familiar with. Then... BAM! Slack notification, time for a meeting! You drop everything for an hour and come back to debugging and have to start that trace over again. Or you're chasing through multiple API docs trying to figure out whether you've correctly understood how to make a call and which parameters to send and how to handle the response.

That's exactly what just happened to me as I was trying to make a call to Amazon Bedrock's invoke_model API.

I messed it up! So I asked Amazon Q for an assist:

I had also messed up the format of the response body, so I used Amazon Q to help me debug through that as well:

It's important to recognize that LLMs are backing Amazon Q, which means it will experience hallucinations just like any other model. I did have some extra debugging because of this as the example code proposed using ModelId and Body when calling invoke_model when they should have been lower-case modelId and body.

Want to see more complex debugging scenarios with Amazon Q? Check out my colleagues' experiences solving a data serialization problem and finding and fixing a concurrency bug.

I am an avid tester, so when I'm writing code, I'm often pairing it up with unit tests at a minimum. I have not had much experience using mocks in Python tests, so I asked Q How would you write a test for the send_prompt_to_bedrock function using mocks? and got this response:

It gets me a lot closer than had I started with a google search, dug through some documentation, and started by writing the boilerplate code myself. This response is an example customized to what I am doing, so I don't have to try to translate what one blog post author was trying to do in their situation to what I'm trying to do in my situation. I didn't spend much time getting this test to pass, most of my time was making sure the request/response objects were prepared correctly.

Read more about how my colleagues' are using Amazon Q for writing tests earlier and for test driven development.

Hopefully the only thing you took away from this article wasn't that I'm a lazy developer! Here, I covered four different ways I'm tweaking my productivity as a developer so I can stay in the flow:

Are you ready to get started with Amazon Q Developer in your IDE? Check out how to set it up for VS Code or JetBrains IDEs or even the command line. Or take a look at how others are using Amazon Q Developer in the Community.aws space. Amazon Q Developer just left Preview on April 30th and is continuously being improved based on your feedback. If something isn't working as you expect, you find a bug, or even have suggestions to improve how it works in your development flow, let me know in the comments!