The design of code requires insight into what a system does, how a language works, the performance characteristics of a runtime, and features offered by libraries. Languages which are Turing Complete are able to compute any logic, yet different languages have different specialisms. A company will use a language based on the labour available, and the niche they operate in. A low power device like a Remarkable uses C++, a low level language which has a fast runtime, but a slow compile time. The software engineer's familiarity with the language and tools affects the readability. When a software engineer is unfamiliar with the language, codebase, architecture, and the tools, they are less able to identify problems with the code.

Each language has different properties - different ways of writing code. Code is not magic, it is highly structured. Every line of code has significance, unless it is a comment or a blank line. Every line does something. Therefore, the easiest way to write reviewable code is to keep it short. Short does not mean to use variable names like "a" or "b" instead of "userEmail" or "fileName", but rather to write the minimal amount of code to solve a specific problem. Each language has a different way of solving this problem - a high level language like Python makes it easy to manage collections of data, which makes the code needed to add data to a list minimal.

Every line of code adds to the maintainable overhead of a project, increases the risk of bugs, security issues, and reduces the ability to understand what the program does.

Companies tend to standardise on the languages their developers know, even when a niche language may suit the problem space better. Using the same language as the rest of the company will give a far wider range of experts who are familiar with the best practices rather than other languages.

But then before we get into these practices, let’s dive into the foundation of programming languages: the syntax. Every language has a different syntax, sometimes very similar, sometimes completely different. Much like animals, programming languages have taxonomy. But in a very human way, branches of programming language families often borrow ideas from completely unrelated languages.

Designing a programming language

To demonstrate, let’s design our own programming language. Every example here is part of the Mojie language, a language I created specifically for this blog post (with human brain and hands!)1. Mojie has a playground here, which I suggest you try out as you read the article. There’s a link for each example, and the playground actually parses and compiles Mojie into JavaScript, Python, and English so you can compare to languages you’re familiar to2. No AI involved, just regular human “I”.

Relationship between syntax

A programming language has rules that define how logic is expressed. Where does a + symbol go? When are () required? Each piece of syntax has a relation between every other piece: either other syntax is expected, or other syntax is not allowed. The restriction of possible syntax makes it easier for a software engineer to communicate their intended logic to both the computer, and other software engineers.

Think of it this way: in theory, books could use Wh.aaatEVER GRAMMArrrr they want. But that gets obnoxious, right? In a computer program, it’s not just obnoxious: it leads to bugs.

More on that later, but first let’s dive into our emoji programming language, Mojie.

Strings and numbers

The fundamentals first: strings. A string is a representation of text. Each character in the string is a visual representation of a number. For example, in ASCII, A is 65. Most people who have studied computer science will remember this, though day-to-day usage is very low. In order to separate strings from the rest of code, languages often use something that looks like quotes: ‘ “ `.

We’re going to use 🧵, with our text between two just like quotes. Like this:

🧵Hello world🧵

Playground link

If we want to use two strings together (concatenation), let’s use a paperclip:

📎🧵Hello🧵🧵world🧵

Playground link

Numbers are foundational to most programming languages, so let’s add them. Numbers are often simply expressed as digits, e.g:

123

Playground link

No fancy wrapping. But there are some important differences between number types. The above example is an integer (a whole number). A floating number has a decimal place, like so:

123.99

Different languages handle these differently - in ours, we’re only going to support integers.

Printing and statements

Next, we want to be able to output data somehow. Different languages have different ways of doing that, like print, or console.log. We’re going to make ours use 📠. Anything you write after 📠 will be put on the screen somehow, depending on the runtime. E.g if it’s in terminal, it will show up there. in the browser, it will show up in the console.

We can use ours like this:

📠🧵Hello world🧵

To let the parser know that we’ve finished statement, we’re going to use 🛑. Many programming languages use a semi-colon for this. Let’s add it to our print example:

📠🧵Hello world🧵🛑

Now the compiler will know that once it reaches 🛑, it should start a new statement.

Playground link

Variables

In order to refer to different bits of data, we need to be able to use a name a human can understand. JavaScript uses let, const, and var for this, but in our language, we’re going to use 🔖.

🔖 x 🔖10 🛑

We need a way to then use those variables. In most languages, you can just use the name you gave. In ours, we’re going to use 🔈. When the code runs, 🔈 will tell the computer to look up the value that a variable points to.

Like this:

📠🔈 x 🔈 🛑

will print 10, as we set the variable name x to point to the value 10.

Playground link

Conditionals, ifs, thens, and elses

Next, we need to be able to compare two values and do different branches of logic if they are the same, or if they are different. These are called conditionals, and normally use if and else.

In our language, it looks like this:

🔖 x 🔖10 🛑
❓ 🔈 x 🔈 5
    👍📠🧵x is equal to  5🧵
    👎📠🧵x is not equal to 5🧵
🛑

Playground link

Notice that each branch in the conditional doesn’t end with a 🛑, only the entire conditional. In our language, a conditional is an expression - a set of logic that returns a value. Therefore we think of the entire conditional block as a single statement, so we only need a 🛑 after the conditional has finished. One side effect of this is that every conditional statement must have both a 👍 and a 👎 - a then and an else.

To visually group logic, we use indentation to make it easier to read. In our conditionals, we indent before the then (👍) and the else (👎). But in our language, whitespace is optional. The above is the same as

🔖 x 🔖10 🛑❓ 🔈 x 🔈 5 👍📠🧵x is equal to  5🧵 👎📠🧵x is not equal to 5🧵🛑

But since we want other people (or generative AI) to read our code, we don’t write code like this. Be nice to your colleagues!

Functions

Often, we want to group together bits of logic. We call these functions, routines, methods, or procedures. To make functions reusable, they often take arguments or parameters - bits of data that can be used in that function.

For example, in our language, we’ll take an argument called name, and say hi to the name we’re given.

🔧say hi🔧
    📋 name 📋
    📠📎 🧵Hi there 🧵 🔈 name 🔈
🛑

Now we need a way to use this function - otherwise known as calling the function, or invoking the function. We need to separate the arguments, which we’ll use 🦜 before every argument.. We’ll use 🧰 to look up the function we want to call:

🧰say hi🧰🦜🧵noah🧵 🛑
🧰say hi🧰🦜🧵tom🧵 🛑

Playground link

Which prints:

Hi there noah
Hi there tom

Runtimes often include a minimal set of functions. In our language, we include some basic mathematics operations like add, sub, div, multi, and mod.

We can combine several of these ideas together, like this which combines a function definition with a conditional:

🔧check if noah🔧
    📋 name 📋
    ❓ 🔈 name 🔈 🧵noah🧵
        👍📠🧵Hi Noah!🧵
        👎📠🧵You're not Noah🧵
🛑

🧰check if noah🧰🦜🧵noah🧵 🛑
🧰check if noah🧰🦜🧵tom🧵 🛑

which prints:

Hi Noah!
You're not Noah

Playground link

Loops, for, while, and recursion

What if we want to repeat something multiple times? In most languages, there’s three ways to do so: 1) for loops, 2) while loops, 3) recursion.

For-loops are used when you know how many times you might want to run a piece of logic. A variable is used to keep track of how many loops have happened, normally starting at 0. The for loop states how much to increase the variable by each loop, and when to stop.

This for loop names the variable x, which goes from 0 up to 10, increased by 1.

🔁 x 🔁 🎬 0 🎬 ✋ 10 ✋ 🔼 1 🔼
    📠🔈 x 🔈
🛑

which prints:

0
1
2
3
4
5
6
7
8
9

Playground link

Notice that it didn’t print 10 - usually for loops will use x < 10 , because when x starts at 0, that would be 10 iterations of the loop.

What if we want to stop the loop early? Sometimes we want to stop the loop before the variable has reached the number. We’ll use ⛔ to do that - often known as break , as it breaks the loop.

🔁 x 🔁 🎬 0 🎬 ✋ 10 ✋ 🔼 1 🔼
    ❓ 🔈 x 🔈 5
        👍⛔
        👎📠🔈 x 🔈
🛑

📠📎 🧵Exited the loop when x was 🧵 🔈 x 🔈 🛑

will print:

0
1
2
3
4
Exited the loop when x was 5

Playground link

When x was 5, the condition was true, leading to the for-loop breaking.

while loops are often used when there is not a specific end to a loop. We’ll make our while loop infinitely loop, and call it :loop:. In this case, we’ll want to break the loop when we reach 10, so we’ll need to keep track of the variables ourselves. In this case, add is a runtime-defined function which will return the sum of two arguments. Like this:

🔖 x 🔖0 🛑

➿
    ❓ 🔈 x 🔈 10
        👍⛔
        👎🔖 x 🔖🧰add🧰🦜🔈 x 🔈🦜1
🛑

📠📎 🧵The loop finished when x was: 🧵 🔈 x 🔈 🛑

which prints:

The loop finished when x was: 10

Playground link

So far, all our functions and loops have done one thing. What if we want to do multiple things in a single function? In our language, we’ll use 🪜 to say “there is another thing to do on the next line”, like this:

🔧check if noah🔧
    📋 name 📋
    ❓ 🔈 name 🔈 🧵noah🧵
        👍📠🧵Hi Noah!🧵
        👎📠🧵You're not Noah🧵🪜
    📠🧵Yay🧵
🛑

🧰check if noah🧰🦜🧵noah🧵 🛑
🧰check if noah🧰🦜🧵tom🧵 🛑

which prints:

Hi Noah!
Yay
You're not Noah
Yay

Playground link

FizzBuzz

A very basic typical test that programmers are given is known as FizzBuzz3. It’s simple: for the numbers 0 to 100:

• If a number is divisble by 3, print “Fizz”

• If a number is divisble by 5, print “Buzz”

• If a number is divisble by both 3 and 5, print “FizzBuzz”

• Otherwise, print the number

In our language, Mojie, we can implement that with the aid of a helper function that returns a value by 📩 - this is similar to a break, where it will end the function and return whatever value is given to 📩.

🔧print message🔧
    📋 x 📋
    🔖 remainder when divided by 3 🔖🧰mod🧰🦜🔈 x 🔈🦜3🪜
    🔖 remainder when divided by 5 🔖🧰mod🧰🦜🔈 x 🔈🦜5🪜
    🔖 remainder when divided by 15 🔖🧰mod🧰🦜🔈 x 🔈🦜15🪜
    ❓ 🔈 remainder when divided by 15 🔈 0
        👍📩 🧵FizzBuzz🧵
        👎🧵do nothing🧵🪜
    ❓ 🔈 remainder when divided by 3 🔈 0
        👍📩 🧵Fizz🧵
        👎🧵do nothing🧵🪜
    ❓ 🔈 remainder when divided by 5 🔈 0
        👍📩 🧵Buzz🧵
        👎🧵do nothing🧵🪜
    📩 🔈 x 🔈
🛑


🔁 x 🔁 🎬 1 🎬 ✋ 101 ✋ 🔼 1 🔼
    📠🧰print message🧰🦜🔈 x 🔈
🛑

which prints:

Playground link

Finally, recursion: a loop made by a function optionally calling itself:

🔧check if noah🔧
    📋 x 📋
    🔖 next x 🔖🧰add🧰🦜🔈 x 🔈🦜1🪜
    ❓ 🔈 next x 🔈 10
        👍📠🧵Finished at 10🧵
        👎🧰check if noah🧰🦜🔈 next x 🔈
🛑

🧰check if noah🧰🦜0 🛑

Which prints:

Finished at 10

Playground link

Overall

All the emojis in Mojie are part of the syntax. While many languages use English keywords, like for, if, or while, many also use symbols like {, (, ?. The English keywords are there to make it easier for a human reader to understand, but there’s no requirement for the keywords to be English. Emojis are just as feasible, though not everything that is feasible is wise. Generative AI has a much smaller training base on emoji-based languages, so it’s not very good at writing Mojie.

For example:

The point: code is not the same as human language. Generative AI does not understand code, it merely searches and returns code that looks similar to the surrounding code. Whereas I’d expect most human software engineers to be able to write small Mojie programs within a day. Keep this in mind when vibe coding - don’t put too much trust into the artificial intelligence. You, the human, are responsible for the code you produce, regardless of the tool you use!

Syntax makes languages deterministic

When code runs, it is always the same. Given the same set of data, it will perform the same operations. It is deterministic. There are some languages which allow for undefined behaviour, but on the whole every time code is run, it performs in the same way. Uncertainty or confusion in behaviour leads to bugs, often security bugs. Mojie’s parser is deterministic. The syntax of programming languages makes them deterministic, in the way the language was designed.

Generative AI (LLMs) are not deterministic, they are probabilistic. It’s very rare to get the same output twice, given the same inputs. There is an element of inherent randomness. This is not very easy for debugging or tracing. It’s hard (or impossible) to be accountable for unpredictable content. However, you, the human, are always accountable regardless which tool you use.

It’s important to keep this in mind when you talk to software engineers: code is inherently more predictable than generative AI output. The unpredictable nature of generative AI has an impact on operations. The code it generates might be low risk some percentage of times, but the remaining percent might be high risk.

Whereas the code generated by Mojie complies with a forced structure: it will be consistent. Consistency is crucial in technical systems. If a bug is consistent, we can fix it. If a bug is inconsistent, it becomes exponentially more difficult to fix. Simply reproducing an inconsistent bug will take more time. It is the role of software engineering to make systems consistent. Even small inconsistencies can lead to severe damage to a system.

What I hope you learned

1. What language syntax is, and the role each piece of syntax contributes to both the feel, and the form and function of a language.

2. That code is not actually the same as written human languages, it just happens to look similar.

3. Deterministic vs probabilistic impact on software bugs.

I’d recommend for you to ask your software engineering colleagues:

1. What programming languages does your workplace use?

2. What is the syntax it uses?

Share

Imagine you're building a house: it's not enough to say “I want brown things connected by shiny things”. There needs to be precision: I need 12x4 beams of wood and 6cm nails. It not only helps others understand your goals, but it avoids any confusion when a delivery company drops off brown paper joined by a paperclip instead of the wood and nails you wanted.

Generative AI tools are pretty good at eventually figuring out what you want, but you save tokens by being direct. Plus, when you want to tell other humans what you made, the more accurate your terminology, the better they’ll understand. Especially if they're experts!

Broadly, you probably want to do one of four things:

1. Create a new and separate website or product.

2. Take inspiration from a website or product that already exists, but do it differently.

3. Modifying something that already exists.

4. Automate a process.

Of these, the easiest are 1 and 2. I'll touch on in the future 3 and 4. But let's imagine you start with no code, and no systems. The world is your oyster. You want to make something new.

The first questions questions you should ask yourself: what do you want to build? Who do you want to use it? Why do you want it? The better you can answer these questions, the better you’ll know what to prompt AI. Humans go through the same process1.

So, to give you the right terminology: this article is all about the different categories of software projects. To make it simpler, I’ve grouped them into frontend, backend, and mobile.

Each has a different benefit, a different reason why you might want to build them. A human software engineer normally specializes in a subset of these, but not all. A chef could adapt to any cuisine, but if they work day to day with Peruvian cuisine, they’re more likely to know how to cook lomo saltado brilliantly rather than lasagna.

Generally speaking, frontend is the cheapest to both create and maintain, while also being the least complex to vibe code2. I’d recommend to anyone vibe coding to begin with frontend.

Frontend

aka: client-side, browser code, JavaScript, web apps

Frontend code has several different meanings, but it usually refers to the code loaded in your browser. Servers send this code to your device, and your device runs it in the browser. The fundamental languages involved in frontend are HTML, CSS, and JavaScript3.

When making a frontend project, there’s some some specific concerns to think about. For example, do you want to use it on a computer? Or do you want to use the website on mobile? Probably both, and modern websites are designed with both in mind. Websites are known as “responsive” if they are built to handle multiple different screen sizes. They respond to the screen size.

Frontend code is intentionally restricted. Since browsers run someone else’s code, your browser needs to act as a safe way to run code with restrictions. These restrictions are good: it makes browsing the web safer. Imagine if visiting a random website had the power to use your camera, microphone, or access files on your device. These require permissions.

There are additional restrictions that you might not think about, too. For example, a modern browser runs multiple tabs. Each tab has code from a different source, and can run them at the same time safely. We call this sandboxing - each tab is effectively given no information about the other tabs, and therefore can’t modify code or access data in other tabs. They are able to play in their own sandbox, but not get into their neighbour’s sandboxes. There are some exceptions, like Chrome Extensions, but generally tabs can’t interfere with each other.

Because of the browser restrictions, frontend-only code is typically much safer to create or deliver to users than other types of apps. Frontend code is considerably more straightforward from a software engineering perspective, too. There are still concerns, but they’re minimized.

An important thing to keep in mind: since frontend code is sent to the browser, it is possible for anyone to read the source code. For example, if your frontend JavaScript has something like:

const veryImportantPassword = "password123";

Every user of your site will be able to see password123. If your idea requires any kind of password or sensitive data (like user emails), you’ll probably need a backend to prevent this scenario. Backend code isn’t accessible by your users.

Backends and frontends fit naturally together. The majority of websites have both. Frontend code without a backend is often referred to as “static site”. Static because the content is always the same.

Backend

aka server code, infrastructure, hosted code

Backend code refers to code that runs on a server, which talks to either other servers, frontends, or mobile and native apps. If the waiters in a restaurant are “front of house” (frontend), then the kitchen staff are “back of house” (backend). Customers (your users) interact with the waiters, and waiters talk to the kitchen staff. Rarely will a chef come to talk directly to customers without the waiter. It does happen, but it’s very rare.

Backend code runs on servers. Servers are powerful computers dedicated to running code all day.

Many interactions on the frontend of a modern website communicate with a backend. For example, login involves a backend. Writing in Google Docs involves a backend. Messaging a friend involves a backend.

Storing of data is usually done in a database, which is usually on a backend server. If you use tools like Supabase in the frontend code, there’s still a backend: it’s just someone else’s backend4. A database is a collection of data, normally in a structured format so that it’s easy to find the data you need. Think of it like a well cared for library: the librarian knows how to find a book very effectively. Once you’ve got the book, you can read it, you could throw it away, or you could write into it. Databases do the same, and they’re very very fast. Most big companies will have servers entirely just for databases.

Servers are very good at serving static files (like HTML, JavaScript, or CSS) to many users at the same time. Since they are static, the same code can be sent to every device. Think of it this way: if you print 100 copies of the same poster and hand them out on the street, it takes a lot less time than making 100 slightly similar posters and handing them out on the street. The time to hand out remains the same (i.e sending data between the two devices), but the time to create and print each separate poster makes the process much slower. But if you’re trying to give out personalized posters, you’ll want to take the lower route because it fits your needs.

A service is considered scalable if it can handle a change in the number of users. Scaling up involves starting more servers. Scaling down turns down servers which are no longer needed. In the case where we need to create, print, and hand out many different posters, scaling up would involve having more people to make the posters, more printers to print the posters, or more people to handle out the posters. While scaling down would involve using less people, or less printers.

Mobile

aka apps, mobile apps, native apps

In some cases, you might want to make a mobile app. Mobile apps come in two different flavours: native apps and webview-based apps. Webview apps are simple to explain: imagine you took a browser (like Chrome or Safari), and turned it into a dedicated app for just one website. That app has some more privileges than a normal website, like storing data on the user’s device, sending notifications, or deeper integrations with the device, but is otherwise similar to frontend web code. Native apps are written in the native programming languages of either Android or iOS. Native apps are able to use lower level functionality than webviews, often leading to better performance or a better user experience.

Android and iOS are similar but different. Often, a software engineer would specialize in one, but not both. While many practices are shared, the typical languages and libraries are quite different. There are ways to share code between each, though it’s done infrequently. iOS talks German, and Android talks Norwegian. While they share a Germanic origin, the culture is different. But a German speaker will typically learn Norwegian quite quickly, and vice versa.

The complexity involved with mobile apps is higher than browser only code, and getting mobile apps to your users has several steps. I’ll go into mobile apps in-depth in future, along with native apps.

Overall

• Frontend: when you want to make a website users can interact with

• Backend: when you want to store data, secrets, or give users different data

• Mobile: when you want an app you can install on your phone.

Example prompts

Here’s some template prompt examples you might use for each:

Frontend

Make me a static website where a user can calculate the cost of a monthly ticket on Berlin’s public transport.

Backend

Make me an API that allows a user to search a database of receipes.

Frontend and backend

Make a website where users can login and store pictures so they can access or share their photo gallery with others.

Mobile

Make me a native mobile app that allows me to take notes on Android.

What I hoped you learned from this post

1. The different places you’d use frontend, backend, and mobile apps.

2. The different concerns and costs involved in each.

3. What type of app to begin with (hint: frontend is easiest!)

In the next article, I’ll be going into what exactly code is. How does it work, why does it matter, and how are programming languages different?

Share

Computer Science and software creation

Computer Science degrees touch a wide range of topics, and only some of them are particularly relevant to vibe coders using Generative AI to create software. Think about it in terms of mathematics and accounting: while mathematics applies to a wide range of STEM, accounting only needs some very specific parts of maths.

While computer science is the foundation of software engineering, software engineering itself can be considered the processes and practices used to implement software. These processes and practices have been built up over the recent decades, though there is always constant change in technology. Generative AI is the most recent big change, but there’s always been changes, often quite big ones. Experienced software engineers have likely gone through multiple big, industry defining changes.

Vibe coding introduces a distinct change in the industry, but not in terms of technology. The ability to create software has always been available to anyone, but now a larger portion of non-software engineers have the ability to produce code without knowing what it does or how it works.

Software engineering is there to apply a methodological approach to computer science theory and software delivery, If someone is shipping software via vibe coding, it’s important they understand the practices enough to avoid risks or negative impact. That’s the whole premise of this blog series: leveling up knowledge to ensure that we, as a society, mitigate as many possible concerns from vibe coding while helping you achieve your goals.

How do people get into software engineering?

Historically, there’s been two routes into software engineering: the academic route and the self-taught route. The academic route typically would set the foundations through computer science theory, while the self-taught route tended to be more hands-on. I myself am self-taught, though I also went into academia. Those using vibe coding tools are actually quite similar to the self-taught category.

Software engineers who started in academia typically start at the foundations, learning abstract theories. Code is used to reinforce and teach those theories. Meanwhile those who are self taught typically start with code, and they learn abstract theories to reinforce the knowledge they need to unlock more code-based skills. In both cases: code is a means to an end. There is rarely a right or wrong path to take, but they require a different mindset to gain the skills and experience needed to provide value to businesses or academic research.

I’ve mapped some of the paths software engineers follow to learn in the image below:

While it might seem like Academia and Self-Taught are entirely different paths, they overlap substantially. At about 3 years into the job, the path taken to become a software engineer largely becomes irrelevant. Not completely irrelevant, but nearly unnoticeable in day-to-day work. I expect my software engineers to be able to learn any concept they need to get the job done. The number one skill I see in the most senior software engineers: the ability to learn and adapt to changing needs.

Vibe coders I’ve talked to tend to start in a couple of places:

1. Their company has told them to try out vibe coding

2. They feel curious to try out vibe coding independently, whether for career growth or for interest.

Like most tools, vibe coding is there to fit a use case. Understanding your end goals is vital to developing the skills you need to get there. Ask yourself: why are you curious about vibe coding? What do you want to get out of it? Is there something specific you want to do? What’s your preferred learning style: hands-on, or theoretical?

These are the first questions I ask anyone who approaches me about vibe coding, because the answers completely change in which direction I think you should go. If you’re just curious, the answer is different from if you have a specific goal in mind. To set yourself up for success, you need to reflect on what you want to achieve.

Why software engineering?

Like most digital industries, computer science has become a fundamental part of our daily lives. On the base level: when was the last time you interacted with a business that didn’t have a website? Beyond research, software engineering is there to provide business value. The scale of digital infrastructure provides a broader reach than traditional products, for a smaller cost. In the simplest terms: the creation, delivery, and maintenance of software provides businesses value at a lower cost than traditional, non-digital industries. A small team of developers can reach millions of people.

However, these smaller teams come with risks. The fewer people to maintain a service, the bigger the dependency on core individuals. Establishing healthy software engineering practices help minimize the risk, while providing the team the ability to deliver on business goals. Companies without healthy software engineering practices in place fall into a loop - short term practices risk the long term delivery of software. We call this technical debt. Every software project will have technical debt. Companies trade off short term wins with the long term impact of technical debt.

Think of it like keeping an apartment clean and maintained. It’s okay if the apartment has a couple of trash bags prepared and ready to be thrown anyway. But if more trash bags fill up, it affects the quality of life for those living there. It may even attract rodents or insects, which requires substantial remediation.

Software engineering principles have been established to reduce this impact. Instead of waiting to throw out the trash once there are several bags, throwing away the trash once one bag is filled makes it easier to maintain.

In other words, following software engineering practices are illustrated by the happy green person with 2 trash bags on the left, vs the unhappy person the right plagued by too much trash, rats, and flies.

While it may seem like software engineering might slow down development in the short term, it actually speeds up development in the long term, along with minimizing risk. As we walk through different concepts together, I’ll be highlighting the practices, theory, and guidelines that particularly apply to vibe coding, so that the vibes you produce ✨ sparkle ✨ rather than seem 🕵️ sus 🕵️.

What I hoped you learned from this post

1. The relationship between computer science and software engineering

2. Why software engineering practices are important

3. How vibe coding fits in with education styles software engineers have followed in the past

4. Self-reflection: why are you interested in vibe coding? What do you want to do with it?

If this left you thinking “okay, I get it - let’s get into the juicy stuff”, then subscribe. The next article will be on Thursday!

Subscribe now

Share

A short intro to me, for those that don’t know me: I’m Noah, I work in the biggest news media company in the Nordics. In my day job, I’m a “tech enabler”. In my volunteer roles, I’m involved with unions and open source. In my hobby projects, I design and build programming languages. I’ve been coding for over 20 years, and professionally for about 15 years. I’ve lectured at universities, I’ve spoken at many conferences, and I’m an avid writer. My biggest passion is helping people, and helping the world, to the small extent that I can. The topics in this blog series are all ones I’m deeply passionate about, since it combines my love of helping people with technology. None of these posts use AI anywhere: I hope you enjoy the human approach

Subscribe now

There’s a drastic increase in people without software engineering backgrounds getting into software development via AI tools. At work, I’ve been sharing weekly computer science lessons specifically for that new growing group of people. This blog will share similar lessons, with the goal of getting wider feedback from what you want to hear about or learn.

Each lesson will come out on Thursday, and I’ll probably mirror them to LinkedIn for reach. Long term, I’m planning to create some tests and examinations related to each article.

Why is computer science important?

When two groups of people meet for the first time, it’s important to set the context. What does each group want, what do they need, and what do they know? Beyond that, developing a shared glossary makes it easier to understand each other.

What does “production” actually mean? How do we build products? How do we measure the success of a code change? How do we prevent things going wrong?

All of these are part of the upcoming curriculum.

Curriculum

I already have posts on:

• Intro: what exactly is software engineering, computer science, and how do they relate?

• Building: how do we build good codebases and products?

• Performance

• Security

• Source control (e.g git)

• Programming language theory

• Metrics

• Workflow management

The curriculum will evolve as the ecosystem around vibe coding changes, and I’ll try to prioritize lessons that I think will be most valuable.

Please subscribe, and I’m really hoping to get feedback on the posts as I go. Here’s a little drawing from where I’ll be starting, but I’m gonna need a bigger piece of paper soon.

No AI will be used in any of the articles, and each article will be based on my experience as a software engineer of all kinds of levels.