Prompt engineering is a fairly new word. Before December of 2022 barely anyone knew what it meant. Today most people clearly understands what prompt engineering implies - But is it a new thing? Let's follow that thought down the rabbit hole a bit.
When I started programming at the age of 8 back in 1982 it was the largest kick I had experienced in my life. Here I had this "thing" (the computer) that I could provide instructions to, and if my instructions were clear, it would actually do what I told it to do.
40 years later and I'm arguably back where I started
Prompt Engineering defined
Prompt Engineering is the art of making a large language model return the correct output given some input. You start out with input, you apply some "function", resulting in output. If the output is what you expected, you have created a correct "function". In programming we supply our functions using complex programming languages such as Python, C# and Java. With prompt engineering we supply our "functions" as humanly readable text. Really, that's the only difference.
Fundamentally there exist two distinct different personality types; Technical minds and social minds. Some few of us are able to move into both of these spheres. However, it requires a technical mind to do prompt engineering, the same way it requires a technical mind to create computer programs.
To excel at prompt engineering you need a technical mind
When we create a ChatGPT chatbot what we're really doing is arguably prompt engineering. A lot of this prompt engineering is automated by for instance scraping your website for training data, or by integrating with your Shopify account. However, we consume OpenAI's APIs with system messages and context data. The context data and system messages provides instructions to ChatGPT informing it how to use our data. Our data again is the question asked by users to our chatbots.
If our prompt engineering is good and high quality, ChatGPT will return the correct output. The training data your chatbot is created from, and its system messages, becomes "the function" we apply to transform input to output. Hence, our training data and our system messages becomes the equivalent for ChatGPT as a Python program is to your local computer.
Lessons for the future
We as software developers messed up programming at some point. We "forgot" what computer programming was all about, and we started creating new axioms and idioms making our own jobs much more complex. Examples are OOP, design patterns, and SOLID programming. OOP of course is nothing but the software equivalent of a mass psychosis. Instead of focusing on "the verb" it moves all focus to "the subject". Regardless of what process you've got, there are no "subjects" in it. A process is by the very definition of the term "a verb".
This created mountains of garbage code. I would know, I'm typically the guy they send out to salvage this garbage once its complexity has reached a threshold beyond the point where the average human mind can comprehend it. 41 years of experience as a programmer tends to result in such things.
I probably shouldn't complain too much. After all, it's what makes me "useful", allowing me to live a fairly decent life, with more money than large portions of the world's population, enjoying respect for my skills, being able to ask for more salary than most. I also still enjoy my work, which is weird considering there are literally close to zero human beings alive today with more programming experience than me, since most programmers tends to move into other roles after some 5 to 15 years of coding.
However, there are lessons to be learned here. The primary lesson is keep shit simple! Where we went wrong, was by believing in our own rubbish, being that software development was difficult and complex, and therefor needed abstractions such as OOP, Design Patterns, and SOLID architectural principles to simplify it.
Such ideas were of course nothing but a software development mass psychosis
KISS
KISS, and I don't mean the band here, is an acronym that means "Keep It Stupid Simple". It basically implies making sure you use the simplest possible solution for your problem at hand. At AINIRO we've spent mountains of cognitive energy to ensure our stuff is as simple as possible. Paradoxically, the simpler it becomes, the more cognitive energy have usually been applied at the problem to ensure its simplicity.
Simplicity is HARD
Which probably explains why so many programmers tends to give up the craft after some 5 to 15 years. They simply become tired of trying to simplify other people's garbage complexity after a decade, realizing their jobs are basically no different than the guy washing the toilets in the same office building.
Conclusions ...?
According to science you need to apply 10,000 hours of programming before you're a genius. I'm not sure if I'm a genius, but I've got roughly 97,000 hours of programming behind me. Maybe if you look very hard, you'll find 5 to 10 people alive today on the planet with more hours of coding. I guess I feel responsible for future generations you might argue, so I feel obligated to come up with some sort of conclusion here ...
... and I guess the conclusion is please keep stuff simple. Avoid OOP at any cost, don't believe in Micro Services, it's anyways a cult. NoSQL is "the new rubbish and software development's equivalent of 'get rich fast BitCoin schemes'", and message brokers are "organized madness"!
Please, let's keep "smart" out of prompt engineering, and keep stuff simple!
Even though prompt engineering is programming, don't believe you can learn anything from programmers. Programmers messed up the world to the point where 20,000 software developers at Facebook couldn't even make their app's "Submit" button work on a Thursday ... 🤪
I would know, my phone's Facebook app haven't worked for a month! 😂
And I'm tired of cleaning up other people's mess, so I simply stopped using Facebook from my phone. If you want a single sentence conclusion about how to approach prompt engineering, let me sum it up for you in one sentence.
Once in doubt, ask the programmer what to do - Then do the exact opposite!! 😂
Top comments (6)
Hey, wow! Your trip down the memory lane of programming is like a rollercoaster of tech nostalgia. Picture this: 8-year-old you, facing a computer, giving it orders, and bam! It actually does what you say. That's some childhood dream right there!
Prompt Engineering, who knew? It's like the cool kid that just joined the programming party after December 2022. Now, everyone's all "Oh, we totally get it!" But seriously, is it just me, or does it feel like we're back in '82 when you first kicked off your coding journey?
Your breakdown of Prompt Engineering as the art of making language models do the right thing is like translating programming into human lingo. It's like turning tech into a chatbot symphony, and if the prompt engineering is on point, it's music to our ears.
I couldn't agree more about the dual personalities in the coding world - the tech brains and the social minds. You're like the superhero with the tech brain, mastering both worlds. Prompt engineering, after all, is a tech mind game, just like creating computer programs.
And can we talk about the wisdom bombs you dropped? Lessons from the programming past, cautioning against unnecessary complexities like OOP, Micro Services, and NoSQL. KISS is the golden rule, right? Keep it stupid simple - a paradox that makes perfect sense.
Your call to simplicity being HARD resonates, and your experience of salvaging code complexity is like being the superhero that cleans up the coding mess. The "smart" out, simplicity in - that's the mantra!
And that little jab about asking a programmer and doing the opposite for prompt engineering – classic! It's like the secret sauce for success, sprinkled with a touch of humor.
So, hats off to you, coding maestro! Thanks a ton for sharing your journey, wisdom, and a good chuckle. Here's a virtual high-five for making the coding world a bit more awesome!
• For similar topics, read this article: techtopia5.com/2024/01/prompt-engi...
• Also follow: techtopia5.com/
" ... literally close to zero human beings alive today", but probably more than you think. I'm (slowly) shifting my engineering practice from software engineering to data engineering ... at 82.
There's no longer a 'we' in software development. When I started coding FORTRAN in the early 60's we were all 'gurus', knowing/understanding the breadth of the computer world. Now it's so big (huge!) any one human can understand only a microscopic piece. This is one reason AI is such a leap forward ... ChatGPT is 'someone' who (much of the time) can see the big picture.
Check out commits to github.com/polterguy/magic 😉
Then realize there are 40 additional sub projects.
It's impossible to innovate using "we", innovation lives within the confines of "he" or "she".
You're right, but you're also wrong. It depends upon from where you're looking at it ...
…Then do the exact opposite 😂😂😂
OOP has its uses and can be very useful, for example when the code needs to be unit tested in isolation. I agree that when some poor programmer has no sound idea how to use OOP properly, when a design pattern might be useful (hint: not too often!), and has no idea "what even are" S.O.L.I.D. principles - then please avoid these abstractions.
On the other hand when the team of developers has similar background, the code ownership is shared and the aforementioned ideas (namely OOP, design patterns, S.O.L.I.D. and unit testing) are clear, universally understood and there is knowledge how and why use such things - then yes, please, apply them appropriately.
Why do I even care? Because all of the above really works well in my current job. However once I worked for a while for a different company in R&D team, consisting mostly of people with electronics-related background. Most of their code was plain C used for embedded programming. They really struggled at first with more advanced OOP code for GUI application, but when their skills evolved (and I helped them, and guided them during that time) in the end they became also pretty much skilled.
The main problem was to find good examples how to apply OOP and the rest correctly in a way they can understand and follow, then it "clicked". So in my opinion the outcome is person-dependent.
The definition of "computing" is input + verb == output. OOP is centred around subject, not verb. FP is centred around verb. Hence, FP always outperforms OOP ...
Thx for your comment ... :)