One of the common things I hear from people who are learning AMPscript, is them putting themselves down for always having to look up the syntax or taking so many more steps than someone else. I get it. You see advanced coders and feel like you need to be at that level immediately, or you are a failure. In case you didn’t know, there is no magic character count that you have to come under to be successful. No one who recieves the email is going to know what function you used or how many lines it took. As long as the end result meets your need/design then you were successful.
The thing to remember is that there are lots of different ways to achieve the same result.
The same action might take one person 2 lines of code and another person 15 lines. Neither is inherently better than the other. They each have their pros and cons. The more you try and do in any one step, the harder it is to debug and the more confusing it can be for other admins to decipher. On the other hand, having lots of small lines of code can take more time for the coder to scroll through and can lengthen processing time. And yet, both can produce an email of equal quality and success.
So the next time you feel the urge to beat yourself up, think about when you last learned a new language. Coding Languages are called languages because of all the similarities to spoken languages. You have syntax to follow and vocabulary to learn. Learning it takes time, and mastery only comes after a lot of practice.
When thinking back to learning a language, I have found that most people think of taking classes in high school or college. I think this does real disfavor to people who are brand new to coding. By the time we are learning languages in high school or college, we already understand the concept of language. We understand what language can do. We understand that verbs have tenses. We have an understanding of what things inherently are. As Shakespeare so eloquently wrote, “A rose by any other name would smell as sweet.” But that only makes sense if you understand the concept of what a rose is and that most roses smell sweet.
You can’t approach learning to code the same way you did when learning a foreign language. There is no English-to-code dictionary where you can look up what a rose is called in this new code language. Code does not have the same contextual understanding of what the world looks like or what things inherently are. Coding Languages are not meant to be used to describe or explain something to someone else. Code doesn’t talk to “someone” – it is meant to talk to itself and other code languages within the universe that exists inside our computers. A universe we only get some visibility into.
Don’t get me wrong; coding languages are still a language. There is syntax. There is vocab. There are similar concepts. Coding Languages just live in a different universe, one filled with computed 1s and 0s. The concept of comparison exists in both universes. Take AMPscript functions and Excel functions – you can translate most of what you can do in Excel with formulas into AMPscript and have similarly computed responses. So one could translate Shakespeare’s quote, but you would have to use things that exist in that universe. Maybe “A concatenate function by any other name would still produce a string of strings.” Ok, maybe not.
The hardest part about learning to code isn’t learning the formulas and the syntax. You can look those up. You will eventually learn them by heart, in the same way, that you no longer have to look up how to spell things. The hardest part about learning how to code is understanding WHAT is possible and how to achieve WHAT it is you are trying to do.
Think about what happens when two people meet and don’t speak the same language. As long as both people understand the concept and context, they can usually figure out how to communicate with a mix of hand gestures, pointing at things, and google translate. We know that while the language is different, both people are in the same universe of things. So if you can get over the hurdle of language, there is no reason they can’t understand what you are trying to tell them. In this way, a tourist can point to a picture in their guidebook and ask directions – both parties understand the WHAT and the hurdle is language.
The challenge with code isn’t due to a change in the language; that is only part of it. It is a change of the universe. We have the dictionary at our fingertips, but until you understand the universe that code sits in, you won’t be able to describe the WHAT. This leads us to get frustrated with ourselves, as we know WHAT we want. We just don’t know how to convey that context to the computer. This is where taking a step back to how we first learned the concept of the life around us is helpful.
Take a small child. They are constantly learning the universe of things they share with us. When they get frustrated because we don’t understand what they are asking or telling us about, what do we do? We suggest that they tell the story in the way they know-how. If they don’t know something, they can describe it. And in the end, we can understand what they are saying, even if it takes more words.
What a young child can write a 3-page story about, an adult can usually sum up in a few sentences. This is because we have an understanding of context, complexities, and inferred information. We don’t talk down to our kids as they learn. We know that as they learn, that same story will take fewer and fewer words and use more and more advanced context and vocabulary.
Sound familiar? Seriously, don’t worry if your code is 15 lines longer than someone else’s. As you learn, you will find ways to optimize your code, just like they did. Focus instead on making sure YOU understand what you are asking the computer to do.
Back to learning as a child – Think of a good children’s book. A good children’s story is short and simple to follow. The stories are easy to understand. They often use descriptive words. They are full of simple short sentences. Each sentence covers one thing. And there are lots of pictures.
With can follow the same principles as we learn to code:
- Break up the complicated process into small, simple story blocks.
- Add titles or short summaries of what that chunk is doing by using comments within your code.
- For comments within an AMPscript block use: /* comment copy */
- For comments in HTML use: <!— comment copy —>
- Use easy to understand variable names that clearly state what they are
- Fight the urge is to use shorthands or abbreviations. Quick to understand variable names, even if they are longer, can make it much easier to follow the story both within your AMPscript block, but also later in the context of your email
- Do one thing at a time.
- Avoid nesting your functions until you are confident in what each piece is doing. Don’t just do it because someone else does it that way. Stick to writing it in such a way that you know what is being done at every step. If that means breaking that one step out into 5 steps – err on the side of clarity
- Show your work as you go. Use %%=v(@variablename)=%% to display the value of your variables. It is a lot easier to find where the process breaks down when you can see what is going on behind the curtain. Once you have confidence that it is doing what you want, then remove the variable views and plug it into your email.
Seriously, there are so many ways to accomplish the same thing. HowToSFMC.com recently did a challenge with the song “Baby Shark.” They asked people to use AMPscript to print the words of “Baby Shark” on the screen. The challenge was to do it in the fewest number of characters. They had over 100 different solutions get submitted. There were so many entries that they broke the entries into 3 categories to judge –
- Simplicity – The concentration in this category was how easy it is to pick up and read the code. This includes adding comments, using more ‘basic’ and understandable functions, as well as formatting it in a clear and readable way.
- Innovative – For innovation, the challenge was to come up with the most unique or ‘out of the box’ approach to output the Baby Shark lyrics in the specified format. However, you had to keep in mind that complexity alone does not equal innovation. Efficiency and elegance were also a consideration in this category.
- Efficiency – The efficiency category was based solely on the character count. The challenge to the community was to output the full lyrics in a specific format with as few characters as possible. ‘Hacks’ and abnormal structures that go against best practice were allowed and encouraged – the end result was all that mattered.
At the end of the day, they all did what was asked of them – they got the song stuck in your head. Oh, was that just me? Seriously though – they all published the words of baby shark on the screen. Heck, there were even a few entries that not only published the words of the song on the screen, but they also did so in the shape of a shark. (See below) – To see all the winners check out HowToSFMC.com’s post about “Baby Shark AMPScript Challenge Winning Solutions.”
So take my advice –
- You do You! Be kind to yourself as you learn. You will get faster. The code will get optimized. It just takes time and a lot of practice.
- Don’t fight the syntax – If you aren’t sure – look it up. There is no harm in looking it up – and it will save you lots of frustration. (Trust me on this one) If you find yourself looking up the same thing over and over – write it out on a post-it note. After a while, you’ll find you don’t need that post-it anymore.
- Keep it simple whenever possible and add comments when you can’t
- If you see a code example and don’t know what it does, go through each function and add a comment about what that function does. (This is the fastest way to learn about other things you can do– Remember you have to know WHAT you want it to do before you start trying to write it)
- Keep at it.
- Don’t give up.
- Reach out here or via one of the many options listed on the resource page if you need help.
And most important – be kind to yourself. It’s a whole new universe to explore.