How I Prompt
Joel Spolsky wrote he wouldn’t hire an engineer that couldn’t write1. That seems more pertinent today than ever! Of course, the industry has argued for a long time that communication is important for a software engineer, for everything from code comments to code review, documentation and demos. That is, communication with people, but prose is clearly turning into communication with machines too.
So, as a programmer, how do I make the most of the GPTs?
My personal tips:
- Learn your stuff. You have to know your stuff better than ever if you are going to hand-hold a GPT. That’s high-level stuff it struggles with, and low-level stuff it will get wrong on occasion, even though the same model got it right on several prior occasions.
- Pay attention to scope. This is still a core skill in software development! What goes in is what comes out. Too much and it will loose you in verbosity even if it manages to stay on track. Too little and you won’t get anything helpful if it doesn’t miss the mark completely.
- You can not count on a GPT to give you the right answer. You can count on them to generate text. So count on them to do just that. Need the right answer on your code-base? Don’t ask directly. Ask for code that’ll give you what you need.
- Go step by step: prompt, edit, and repeat. Better hand-hold than try to do most of it at once.
- Use absolute, not relative, references. Name the thing don’t use “it”, “this”, or “that”.
If you understand the tech under a GPT, you’re better placed to play to its strengths, and circumvent its weaknesses. You’ll be able to diagnose issues with how you’re using it and really leverage the tech.
To put things into perspective, too much of my social media is about people surprised at the novelty of writing prose to produce an artifact 2, more than its technical abilities or deficiencies 3. A while back, Paul Graham was interviewing two founders about their “learn to code by making games” start-up, when he asserted 4:
Why do they need to learn all that fundamental programming stuff? These days you can pull in a package to do this or that and just glue it all together.
The point then, and now, is that you need the fundamentals or precursors to take advantage of any industry development be it package management or GPTs in their early stages. At the time you had to choose packages, or decide when to write your own, and glue them together. You couldn’t do that blindly with no experience. Today you have to instruct a GPT step by step. At least for the time being. It’s changed day to day software development from solving some smaller problems to solving some bigger ones.
There was a generation that had to look up everything in a printed manual. Then there was Google, StackOverflow, and YouTube. Now we’ve got Generative AI, LLMs, and GPTs. Here’s the thing. I once had a colleague who knew our APIs inside out. Never had to look them up. Not via Google and not via the documentation. He could just get on with work. Random access into his own memory. Code straight out of his fingertips 5. They say recent generations can Google better than older generations, but that kind of thing aside, who do you think is better equipped to use a GPT; Someone who knows their craft inside-out or someone who doesn’t even want to?
-
↩
It might have been in The Guerrilla Guide To Interviewing.
-
↩
In a sense code is just an intermediate representation.
-
↩
Prose is not always going to be the best way to talk to a machine, even as this tech advances, we have code for a reason. Just try explaining a sorting algorithm or data-structure, writing an essay on them, or better still ask a GPT. It’s verbose in prose, several paragraphs of text worth might distill into several lines of code, as I discovered long time ago. There is ambiguity, as is widely noted, with natural language. That is not to say the current programming languages or mathematics notation are optimal.
-
↩
I paraphrase from memory but you can look it up on YouTube.
-
↩
He could type fast.