Skip to content

Commit

Permalink
developer pride ai tooling
Browse files Browse the repository at this point in the history
  • Loading branch information
klausbreyer committed Jun 13, 2024
1 parent 627dcc9 commit b466009
Show file tree
Hide file tree
Showing 2 changed files with 86 additions and 85 deletions.
83 changes: 38 additions & 45 deletions content/posts/2024-all-the-requests/index.md
Original file line number Diff line number Diff line change
@@ -1,63 +1,56 @@
---
title: "A Rant About Neglected AI Tooling and Developer Pride"
title: "All The Requests"
date: 2024-06-11
categories: ["Code"]
categories: ["Open Source"]
draft: true
---

I am currently hiring senior developers, and I assumed that AI would be used to "cheat" during coding tests. So, I made it part of the task that they should explain afterward how and for what they used AI.
I've just released a new open-source project called [All The Requests](https://github.com/klausbreyer/all-the-requests). It's a simple HTTP server built in Go that logs every incoming request. This tool captures details like timestamp, path, headers, and payload, making it great for debugging callbacks and webhooks.

I am a coder at heart, and I feel developers should use AI tooling at every opportunity. And I mean it quite literally. They should use every opportunity to determine how the current AI tooling performs on their problems.
![Example](example.png)

However, I was astounded by the low rate of usage. [I was assuming the centaurs were waiting around the next corner](https://www.v01.io/posts/2024-centaur-programmers-shrinking-team-sizes/). And somehow, I always hear the same arguments.
## Why Use It?

## Root Causes
- **Comprehensive Logging:** It logs request paths, headers, and bodies.
- **Timestamping:** Each request log includes a timestamp.
- **Customizable Ports:** You can set the port via command-line arguments.

Ultimately, it's a variation of one of the following causes.
## Example Usage

### Ignorance
Start the server on port 9090:

Many may have tried an early version and been dissatisfied with the results.
```sh
./all-the-requests -port=9090
```

But AI tools are constantly evolving, so it's essential to try them out continually. Most have a slight learning curve and are constantly changing.
The server output:

### Laziness
```sh
Starting server on :9090
Server is ready to handle requests and display all details.
```

Yes, understanding how to groove with AI takes a moment, but it pays off multiple times.
Send a POST request:

You can write and understand every program in an unknown language or framework with almost no prior knowledge and even get the best instructions on how to get it up and running, including debugging help.
```sh
curl -X POST http://localhost:9090 -d "test payload" -H "Content-Type: text/plain"
```

### Cumbersome
Logged request details:

This is the argument I accept the most.
```sh
--------------------------------------------------
Timestamp: 2024-06-11T13:52:33+02:00
Method: POST
Path: /
Headers:
User-Agent: curl/8.6.0
Accept: */*
Content-Type: text/plain
Content-Length: 12
--------------------------------------------------
Payload: test payload
--------------------------------------------------
```

Experienced coders, in particular, fall into this trap. They find it too cumbersome. The code that GitHub Copilot suggests doesn't exactly match the next steps that are already in their heads.

In principle, this concerns both points made before. The tooling constantly evolves (for example, at one point, Copilot introduced Quick Chat to use it selectively), and you must understand how to groove with the AI.

## Dear Developers, Please, Please, Jump Over Your Pride.

Please don't be so vain and place value on your code being hand-written. Think about how much time you spend writing code. It's probably 10-30 %.

What about the rest of the time? Quite a lot of it is thinking - between typing, researching, and reading documentation. Also not to be underestimated is collaboration with other programmers and the people on your team responsible for usability and customer value.

Writing code is not the only thing that you are hired for.

Now, you can also turn my argument around and say - if I spend so little time writing code anyway, why should I do it with AI?

- AI allows you to try out other patterns. `I have a bit of code here that feels cumbersome to me. Give me 3 different ways I can refactor it, my goals are...`
- AI takes the shitty work off your hands and gives you more time for actual thinking. `Replace my German texts with i18n strings and give me an JSON with English default translations under my component.`
- You no longer have to read so much in the documentation: `Please write me an ESLint config that spits out a warning when the following module is imported.`
- Suddenly, you can do things that otherwise seem like arcane knowledge from super experienced colleagues: `Write me a one-liner for this given Pipeline YAML with jq that does the following...`

To repeat myself: AI can write code, but you are responsible for the more important thing - the context and solving problems.

Over time, you recognize more and more GPT-sized holes that you can quickly fill. This makes you more efficient at writing code, giving you more time to solve real problems.

Frameworks will change. The skills of how to groove with AI will not.

To avoid being replaced like last year's JavaScript framework, you better learn AI. You also need to keep up with it, but this is more universally applicable knowledge than knowing exactly how to do things in, let's say, NextJS 14—before everything changes with NextJS 15.

In the end, [AI Won't Replace Humans — But Humans With AI Will Replace Humans Without AI](https://hbr.org/2023/08/ai-wont-replace-humans-but-humans-with-ai-will-replace-humans-without-ai).

Having AI infuse the very thing that I love most—writing code—is the most magical experience I have had since using a computer for the first time at the age of six, magnified by its capabilities.
For technical details, downloads, and getting started instructions, visit the [GitHub repository](https://github.com/klausbreyer/all-the-requests).
88 changes: 48 additions & 40 deletions content/posts/2024-developer-pride-ai-tooling/index.md
Original file line number Diff line number Diff line change
@@ -1,56 +1,64 @@
---
title: "All The Requests"
date: 2024-06-11
categories: ["Open Source"]
draft: true
title: "A Rant About Neglected AI Tooling and Developer Pride"
date: 2024-06-13
categories: ["Code"]
---

I've just released a new open-source project called [All The Requests](https://github.com/klausbreyer/all-the-requests). It's a simple HTTP server built in Go that logs every incoming request. This tool captures details like timestamp, path, headers, and payload, making it great for debugging callbacks and webhooks.
I am currently hiring senior developers, and I assumed that AI would be used to "cheat" during coding tests. So, I made it part of the task that they should explain afterward how and for what they used AI.

![Example](example.png)
I am a coder at heart, and I feel developers should use AI tooling at every opportunity. And I mean it quite literally. They should use every opportunity to determine how the current AI tooling performs on their problems.

## Why Use It?
However, I was astounded by the low rate of usage. [I was assuming the centaurs were waiting around the next corner](https://www.v01.io/posts/2024-centaur-programmers-shrinking-team-sizes/). And somehow, I always hear the same arguments.

- **Comprehensive Logging:** It logs request paths, headers, and bodies.
- **Timestamping:** Each request log includes a timestamp.
- **Customizable Ports:** You can set the port via command-line arguments.
## Root Causes

## Example Usage
Ultimately, it's a variation of one of the following causes.

Start the server on port 9090:
### Ignorance

```sh
./all-the-requests -port=9090
```
Many may have tried an early version and been dissatisfied with the results.

The server output:
But AI tools are constantly evolving, so it's essential to try them out continually. Most have a slight learning curve and are constantly changing.

```sh
Starting server on :9090
Server is ready to handle requests and display all details.
```
### Laziness

Send a POST request:
Yes, understanding how to groove with AI takes a moment, but it pays off multiple times.

```sh
curl -X POST http://localhost:9090 -d "test payload" -H "Content-Type: text/plain"
```
You can write and understand every program in an unknown language or framework with almost no prior knowledge and even get the best instructions on how to get it up and running, including debugging help.

Logged request details:
### Cumbersome

```sh
--------------------------------------------------
Timestamp: 2024-06-11T13:52:33+02:00
Method: POST
Path: /
Headers:
User-Agent: curl/8.6.0
Accept: */*
Content-Type: text/plain
Content-Length: 12
--------------------------------------------------
Payload: test payload
--------------------------------------------------
```
This is the argument I accept the most.

For technical details, downloads, and getting started instructions, visit the [GitHub repository](https://github.com/klausbreyer/all-the-requests).
Experienced coders, in particular, fall into this trap. They find it too cumbersome. The code that GitHub Copilot suggests doesn't exactly match the next steps that are already in their heads.

In principle, this concerns both points made before. The tooling constantly evolves (for example, at one point, Copilot introduced Quick Chat to use it selectively), and you must understand how to groove with the AI.

## Dear Developers, Please, Please, Jump Over Your Pride.

Please don't be so vain and place value on your code being hand-written. Think about how much time you spend writing code. It's probably 10-30 %.

What about the rest of the time? Quite a lot of it is thinking - between typing, researching, and reading documentation. Also not to be underestimated is collaboration with other programmers and the people on your team responsible for usability and customer value.

Writing code is not the only thing that you are hired for.

Now, you can also turn my argument around and say - if I spend so little time writing code anyway, why should I do it with AI?

- AI allows you to try out other patterns. `I have a bit of code here that feels cumbersome to me. Give me 3 different ways I can refactor it, my goals are...`
- AI takes the shitty work off your hands and gives you more time for actual thinking. `Replace my German texts with i18n strings and give me an JSON with English default translations under my component.`
- You no longer have to read so much in the documentation: `Please write me an ESLint config that spits out a warning when the following module is imported.`
- Suddenly, you can do things that otherwise seem like arcane knowledge from super experienced colleagues: `Write me a one-liner for this given Pipeline YAML with jq that does the following...`

To repeat myself: AI can write code, but you are responsible for the more important thing - the context and solving problems.

Over time, you recognize more and more GPT-sized holes that you can quickly fill. This makes you more efficient at writing code, giving you more time to solve real problems.

Frameworks will change. The skills of how to groove with AI will not.

To avoid being replaced like last year's JavaScript framework, you better learn AI. You also need to keep up with it, but this is more universally applicable knowledge than knowing exactly how to do things in, let's say, NextJS 14—before everything changes with NextJS 15.

In the end, [AI Won't Replace Humans — But Humans With AI Will Replace Humans Without AI](https://hbr.org/2023/08/ai-wont-replace-humans-but-humans-with-ai-will-replace-humans-without-ai).

Having AI infuse the very thing that I love most — writing code — is the most magical experience I have had since using a computer for the first time at the age of six, magnified by its capabilities.

And I just don't get it why so many developers resist embracing this transformative technology.

0 comments on commit b466009

Please sign in to comment.