Hi, everyone. I'm Nicole Van Der Hooven. I'm a developer advocate at K six dot IO and I've been a performance tester for several years. Being a deve developer advocate means being able to write code and also being able to talk about it.So this topic is of personal interest to me. Code and speech are often seen as being positioned at different ends of the spectrum. However, I think that they have more in common than is immediately obvious. We're gonna go quickly through how code has been changing, then how speech has been changing and then we'll talk about what we can do to adapt to these changes. And by the way these slides are public and I'll share the URL at the end so you don't have to take notes. So on the one hand, there's code code comes in many forms, but this is the first program ever, an algorithm for an analytical engine that was created by the first ever computer programmer, a woman named Ada Lovelace. The interesting thing is that this is pure mathematics code is terse strictly logical and limited. It has a vocabulary all of its own and its syntax is pretty unforgiving code has traditionally been in the domain of computer science.

And the stereotype is that it's incomprehensible to those outside of the know. And when we look at this precursor of code, we may be inclined to agree. This is binary code, binary code consists of zeros and ones and is used to encode data into a simple on off or a yes or no pattern. By the way, it's not so important to understand all of this. But I just want to take us through a bit of the history of code. So each zero or one is a binary digit or bit. And then when we string together eight of them, we get unique representations of characters. And we call that a byte already. We can see here a form of abstraction. Abstraction just means grouping things together to give them a collective name so that we can understand them better. Uh And it's easier to refer to them and it's something that humans are great at. This is machine code. Machine code interprets binary code in hexadecimal form. It's used to send instructions directly to a computer CPU and this is assembly code specifically for a Motorola 68,000 microprocessor assembly code makes machine code more functional, adding special keywords. So this is a huge jump in abstraction as programmers at this level can already use words instead of just numbers or math. And the next layer is compiled languages.

This is a snippet of a A go go code at this point, the code is starting to become more intelligible, more human readable. Let me just scroll here. There's still a structure there, but there's a distinct shift away from numbers and towards readable English words go is a compiled language which means that all of this code is still translated into machine code before it's run. But it's a lot easier to understand at this level.

And this is an interpreted language specifically react js javascript. We can see that this is much more abstracted again. Uh Now we're talking about account balances states, buttons and clicking things that we already understand yet javascript is still translated to machine code at run time.

So this is what we've got so far, you can call it a code abstraction cake of sorts. So we start with a layer of mathematics and physics and we work our way up to interpreted languages coded each layer exists today. So it's less a chronological progression than just different ways to do the same thing. And each new layer gets more and more abstract that is closer and closer to human speech. So code is moving towards speech. But what about speech? Speech is actually moving the opposite way towards coding. So take the phrase large snorting ancient red dragon in this phase. The phrase the dragon is a noun, the thing and all the other words are adjectives. So they describe that noun that the dragon in some way. But why don't we say, you know, red, large, ancient snorting dragon English speakers will probably say it sounds off. But what does that actually mean? And why is it that it sounds off? It turns out that there's this weird thing in English that when there are multiple adjectives in a row that refer to the same noun, they're always ordered according to the characteristic that they describe so large is a dragon size. The fact that it's snorting is a physical quality.

Ancient refers to age and red is its color. In fact, adjectives in English are always written in this order. This is the full one from uh CC the Cambridge dictionary. When there's more than one adjective for a noun. This is an incredibly complex syntax. If we had a programming language that enforced this kind of complexity, it likely never again be used. But native speakers of English just do this without even noticing without having to memorize this list. So we often think of speech as unbounded and forgiving in syntax. But that's not always the case while literary speech often breaks grammatical rules and is celebrated for it. Technical speech sticks to the rules to be able to compare speech with code. Let's look at layers of written speech that we use to describe new product features in software.

When we first start conceiving of a feature, we start with the most abstract level. A feature usually starts with some sort of project plan, sometimes called a theme. And a project plan is usually a pages long document uh describing in prose, the reason for a feature or a group of features and giving a rough overview of how it might be implemented. And then the next level of abstraction down is Epics. Epics are still not at the nitty gritty level, but at this level, we're already starting to see some structure in agile methodologies. Epics answer a standard set of prompts. We're breaking up those pages into smaller sentences that are more actionable. Next level down is user stories and they're typically included in Epics. They zoom in a little bit more on a feature. So here's a standard formula for a user story as an account owner, I want to deposit and withdraw money from my account so that I can save and spend my money, the phrases as A I want to. And so that are important here. A likely offshoot of a user story is a behavioral specification. This is an example of one written in Gherkin, a business readable language. The goal of Gherkin is to translate business requirements into a more logical structure that can serve as the basis for both tests and code.

Gherkin structure is less ambiguous, making it easier for developers to interpret what those requirements mean into programming languages. The words feature scenario when and then are still prompts, but they're also keywords kind of like the logical keywords if then when else that we see in code and as speech goes, it's way less abstract than project plans. So this speech abstraction cake is upside down and it starts with the most abstract layer which is project plans. And as we go down through the layer, speech gets more structured, shorter in length and more specific in short, it's getting more and more like code. So here's one example is this code or speech, a button that says add $3 and a button that says withdraw $5 then show me my balance. This is an example that exists in the intersection of code and speech. It has the syntax of code, but it's human readable like speech. So it's pretty easy to understand even though we don't have any context. So here's the context. This is an app created by the company DBU. It's based on artificial intelligence called GP T three by the company open A PA I you type text that describes an app that you'd like to build and GP T three builds a functioning React Js app. So this is it being used and the buttons are being clicked.

And if you see down below the code has been generated, that's actual javascript and pretty smart javascript at that all by an artificial intelligence. So code or speech, we've just gone from the description above to the functioning interface below. Is that not what code does?

So code is moving towards speech, I would argue that the sentences above our code, a new code, a kind of code that's written in natural language, but still code with a vocabulary and a syntax all its own. And at the same time, speech is moving towards code because those sentences are speech too, they're immediately understandable, follow the rules of grammar. They're even punctuated for like emphasis. So on the right side, the code side, artificial intelligence is getting increasingly smarter and we're building types of code of higher and higher levels of abstraction. And because of this, we're able to give computers instructions that are closer to writing than the algorithm. Ada Lovelace began with.

And then on the left side, the speech side, we're starting from a place of high abstraction already. But working in tech and building software has caused us to be more and more precise with our language to the point where our descriptions of code may just become code themselves.

So what can we do to remain competitive and relevant in the face of these changes? Here are some concrete tools techniques and areas of study that we can focus on to adapt to this new paradigm. If you're a coder, write expressive code, this meme pokes fun at the fact that actual programming takes up such a small slice of a coder's pie of work. It's an intentionally exaggerated example. But I think that there is a bit of truth in it and the truth is that it's becoming way more important that your code be understandable by others than that you make it work in the first place. Because if you're the only one who understands how it works, then it's only a short term success, it only lasts as long as you stay on the project. And after that, all bets are off as coders, we can pay more attention to the way the variables are named. Yes, but also comments that we leave in our code, not mixing levels of abstraction, keeping functions atomic. This is why peer reviews are so important. If you give your code to someone else and they can't follow your train of thought. There's a problem, it might not be a problem you have to solve now, but someone's going to have to do it at some point. The second thing is document your work. Many things can't be explained by just comments and code.

And for those you need to accompany your code with a more detailed explanation. So the company that I work for maintains an open source load testing tool and our develops, our developers are great at taking responsibility for explaining their own work. So at K six, they write documentation as part of a release, developers write documentation for every new feature that they build. They also answer questions in our public community forum. They just treat it as part of their job because it is if you're a coder, make it part of your job to describe what you've done and why write a change log and release notes. Even if they're just bullet points, write, read mes for repose, write contribution guidelines. It's your work. After all, you should be proud of it. Learn how to write by reading what others have written and doing a lot of practice. Here's a book that I found personally useful and it's called Everybody Writes by Anne Hadley. It's a good book to start with. And I also use tools like grammarly uh which check, not just spelling or grammar, but also tone and consistency and whether or not words I'm choosing are ambiguous. So if you're a writer, try using tools that developers use even for your writing another book recommendation. Modern technical writing by Andrew Ether, it ta it talks about tools for writing that bring writing more in line with code with a goal of streamlining processes. For both.

For example, we could store our writing on version control systems like get write an XML via lightweight markup language like markdown and use static websites like Hugo, which is my personal pick using the tools that developers use, makes the transition to code much easier. And you might actually start to see it creeping naturally into your writing. Programmers rarely believe that they have to get it right the first time. But for some reason, we writers do, we should treat our work like a digital garden that's constantly growing. And changing and refactor it like code. We should get into the habit of updating blog posts when we learn something new and think of writing as a perpetual work in progress rather than a once off project with a clear end, learn to code. Or if you already know how to code, get better at it. Learning code doesn't mean you have to be a programmer. It just means knowing how to use it to make your work as a writer better. I always recommend starting with something that you'll actually use because just like human languages, you'll forget any programming language you don't use regularly. I'm a big fan of Coursera for learning a variety of subjects and I highly recommend them if they're free. Uh You can also pay to get certified there and here are some courses I've found useful on other sites and all of them are free for both of them for both writers and coders. Here are two takeaways.

The first is learn in public talk about what you're learning and especially if you're not an expert yet, share it, whether it's on social media or a blog post or a video or a conference or on your own website. Not because we're self centered and we want to show off. But we, because we just want to have a record of everything that we've done. Why should we throw away all that career capital? Here are three of my favorite public learners, Christian has hundreds of videos on youtube documenting his journey into software development as a complete beginner. Josh branch show has a github repository called Til It that stands for today. I learned where he just posts posts one thing a day that he's learned every day. And years later, he has a repository of over 1000 little snippets, Shan Wang blogged for a developer enough that he found he had enough to write a book called the Coding Career handbook. In my personal experience, learning in public helps you learn faster because people chime in and help you along while helping others who may be struggling with the same thing and leaving a record of where you've been for future employers or for yourself. Secondly, build and maintain a personal knowledge management system. This is a big one and it applies to everyone.

If you're working in tech, you're a knowledge worker, you make your living based on the things that you know, and the skills that you've mastered to keep up with this pace of technology. I strongly believe that taking notes is an essential skill, take notes on your daily activities on things you're learning as if you're talking to a version of yourself that has forgotten everything because I guarantee that you will forget things e ears down the track. I've personally used tools like Obsidian Room research and notion to remember and think deeply about topics that interest me. Or once I'm learning this on the left is a graph view of my notes on Obsidian. You can check it out. I've published it at N Notes dot Nicole V dh.com. It's messy. So don't expect something polished, but it just helps me make sense of this crazy world of tech. The thing with change is that everyone wants it, but nobody wants to change the convergence of code and speech can be daunting and is causing many of us to rethink the way that we work. I hope that the tools and concepts I've mentioned today will help some of you prepare for this convergence and look at it with excitement rather than fear. Thanks for hearing me out.

And if you want to check out any of the resources that I mentioned as promised, here are my slides. You can find a copy of them on slides dot Nicole V dh.com. And if you go there, you can also, here's a tip, you can click s on your keyboard and you'll see the speaker notes just so you can hear the little nickel in your head going through these slides. Feel free to reach out to me on all these social channels as well. And thanks again for listening.