David from Kodaps

David from Kodaps

/kodaps

David from Kodaps

A neuro-spicy Parisian Brit who writes about software engineering, tech communication, entrepreneurial journeys & data. I help understand code, why it is fun, & how devs think.

Youtube Channel (EN)Newsletter (EN)Youtube Channel (FR)
User Avatar

David from Kodaps

1y ago

Top 3 Quotes On How To Learn To Code
David from Kodaps

Quote 0: 'Code is like humour. When you have to explain it, it’s bad.' – Cory House

Code is consumed by computers and by humans.

Your code needs to be readable because it needs to be maintained. Gone are the days when you write a line of code and never return to it. Software evolves because software is a service.

Write readable code; your future self will thank you.

Quote 1: 'Programming isn’t about what you know; it’s about what you can figure out.' – Chris Pine

Programming is a journey of discovery.

AI copilots can solve known problems. The fun of code lies in formulating a strategy to solve new, unknown problems. And then failing and trying again.

Quote 2: 'The only way to learn a new programming language is by writing programs in it.' – Dennis Ritchie

In programming, you can only truly learn by doing. By failing. And by overcoming the difficulties of working out what is going wrong.

And then succeeding.

User Avatar

David from Kodaps

1y ago

The 3 elements of an effective short-form video hook (to drive retention)
David from Kodaps

To ensure people stay and watch your short-form video content, a hook should provide 3 things within 3-5 seconds

  • Curiosity: What is the question the viewer wants to know the answer to? (what is the payoff you will provide?)

  • Clarity: What is the value you are providing ? (Why is the payoff important?)

  • Context : Who is this about? Who is this for?

And this should be provided in a short a time frame as possible

User Avatar

David from Kodaps

1y ago

4 Principles of Software Development To Make Your Code Shine
David from Kodaps

Here are 4 principles of good code to help your code shine.

  • KISS - Keep it simple : You will not recognise your own code six months from now. Keep it simple, keep it readable. Keep it clear. Don't be clever. Your future self will thank you.

  • DRY - Don't repeat yourself Copy-pasting is a sure sign that things have gone wrong somewhere.

  • YAGNI - You ain't gonna need it. User needs and software specifications are fluid. Don't optimise too early. Don't away abstract concepts on the off chance another similar use case might arise one day.

  • TDA - Tell don't Ask (a.k.a Separation of Concerns) Business logic should be in one place. "Bits" of code should do one thing only. Keep things separate.

What do you think, are there any more that are worth mentioning and focusing on?

User Avatar

David from Kodaps

1y ago

The Reason Why TypeScript Made Me Like JavaScript
David from Kodaps

In 2010 I started using JavaScript professionally for the first time, and it was a mess.

Prior to that I had been coding in C++, which is very structured. But the JavaScript codebase I was trying to understand was a hodge-podge of intertwined callbacks, and I hated it from the start.

Learning and using TypeScript changed all that for me.

Because it adds structure and constraints.

Like anyone, I like my freedom. I like doing what I want. But JavaScript has too much freedom. That freedom made the codebase unreadable.

It's probably possible to document JavaScript code correctly to the point where TypeScript is not necessary - i.e. if you follow another constraint.

TypeScript provides a common structure for that constraint. It makes documentation a prerequisite for the code to function.

That constraint, that stricture, is what make JavaScript fun for me.

It's why I am where I am now.

User Avatar

David from Kodaps

1y ago

This Is The Best Book I’ve Ever Read On Motivation
David from Kodaps

There are a lot of books about management and motivation.

And I've read a lot of them.

But the best book on motivation I've found is Drive by Daniel Pink. As a (former) game designer I find it fascinating. Daniel talks about how traditional reward schemes (if you reach this target, you will get this reward) are often counter productive.

Why?

External rewards means external motivation.

Performing a task in order to earn a reward focuses you on the reward. But in the right conditions, work-like activity has its' own inherent satisfaction and pleasure.

For example I code for my 9-5, but I also code for fun in my leisure time. In the same way, artists create for the sake of creating. They find more pleasure in the act of creation than when they take a paid commission to create a specific piece. Why?

Internal motivation requires autonomy

Commissioned work enforces guidelines and expectations. It limits artists' freedom to express themselves. And reduces motivation.

Working towards an external reward masks a tasks' inherent reward. It reduces autonomy because the outcome is external.

Outside of repetitive mechanical tasks, rewards that diminish autonomy lead to decreased job satisfaction and higher turnover rates.

Conversely, in jobs requiring creativity, employees who feel more autonomous are more likely to be engaged, satisfied, and productive.


If you are at all interested in motivation and management, I can't recommend this book enough.

(And if you've read it, do you agree? What other book would you recommend for beginners?)

User Avatar

David from Kodaps

1y ago

4 Essential Software Process Tools I Use To Manage a 7-Figure e-Com Website
David from Kodaps

For the last 5 years, I've managed an e-commerce website grossing 7 figures yearly. Here are the tools I've set up to ensure everything runs smoothly:

Build via Bash

The scripts automate the build sequence: pulling all the code updates and translations, checking code quality, running automated tests and then handing over to GitHub actions for CI/CD.

Deploy using GitHub actions / AWS

Github actions then also run automated tests, set the environment variables, zip the code and push it to AWS to deploy it.

Observe via Sentry

Sentry is a lifesaver: any crashes (either frontend or backend) are logged to Sentry, which allows us to 1/ quickly find the cause when users report an error and 2/ do triage based on which errors are the most common

Alerts via Slack

All the tools (except for the initial build scripts) let us know via Slack when something is going on / going wrong. (And internal users can also trigger reports via Slack)


All these tools help me sleep at night - because they automate all the boring bits and let me know when there is anything I need to take a look at.

User Avatar

David from Kodaps

1y ago

4 Reasons Why Coding is Fun
David from Kodaps

Code is fun.

When I was 7, my grandad gave me a ZX81. It was one of the first mass-market personal computers, with 1 kilobyte of memory. It could only hold one page of code.

But boy, did I have fun coding with it.

That was when I experienced the four reasons why coding is fun.

Reason #0: Code Is a Game Of Exploration & Discovery

Coding is all about exploring what is possible and learning how things work. It's about discovering new possibilities, tools, and concepts. And then combining them to discover even more possibilities.

Learning is fun.

Reason #1: Code Is A Construction Game

Coding a program is like building something out of thin air and electrons. My first programs were simple games I spent hours playing on. I'm not much of a DIY person in real life, but I love building things with code.

Building is fun

Reason #2: Code Is A Strategy Game

Code is about formulating and implementing a method to overcome an obstacle: i.e. implementing a feature, solving a technical hurdle. It's about marshalling your resources, and devising different strategies of attacking the problem.

And strategy is fun.

Reason #3: Code Is A Puzzle Game

Coding is about solving mysteries. The mystery of why the code is not working, or the darker mystery of why it is working when it should not be. Following the clues and laying traps until the bug is fixed.

Solving mysteries is fun.

Code is my 9-5 AND my side hustle

Jane McGonigal says in Reality is Broken: "Games make us happy because they are hard work that we choose for ourselves, and it turns out that almost nothing makes us happier than good, hard work."

Why is code fun? Coding is a game. It is good hard work with a visible outcome. It provides a sense of achievement when you finally reach your destination.

And the nature of software means that journey is always beckoning.

User Avatar

David from Kodaps

1y ago

5 Daily Habits I Use to Ensure Consistency for My YouTube Channels (While Working a 9-5)
David from Kodaps

Every content creation course/guru hammers away at one thing: consistency.

But consistency is hard. Especially when you have a full-time job.

Here are five daily habits I've set up to stay consistent. These have helped me grow 2 channels to 15k+ subscribers each:

Habit 1: I Track Every Idea (= use a second brain)

I use Notion on my phone to jot down every content idea. The exact tech stack doesn't matter; what matters is being able to enter and retrieve an idea with minimal friction.

Relying on my memory doesn't work.

Habit 2: I Set Aside A Specific Time Each Day

I'm a morning person, so I dedicate time every morning to work on my youtube channels, when I'm at my brightest and when I have the least amount of distractions. The time of day your choose isn't important. What is important is to stick to it.

Habit 3: I Review Medium-Term Analytics

Darrel Eves recommends looking at your 28 day views recap, filtering out recent videos, and determining what subjects are generating views.

And then to double down on those

Habit 4: I Repurpose, Repurpose, Repurpose

I'm bilingual (in French & English). My two channels contain the same content, but translated. The additional work for a translated piece of content is minimal compared to the original.

0 to 1 is hard. 1 to 2 is a lot easier. Repurpose everything you can.

Habit 5: Hit Publish

It's tempting to spend time polishing content for it to be just right. When you've already validated the subject matter's traction, that makes sense.

But when you're testing ideas, speed of iteration is more important.

Done is better than perfect

And Then Refine & Improve

Once you have the habit going, think about how you can bring incremental adjustments to improve the content & streamline production,

User Avatar

David from Kodaps

1y ago

A Question I’ve Been Asking Myself Lately (And Why)
David from Kodaps

I've been spending a lot of my time thinking about the Lean Methodology - how you test a low(er) effort version of an idea before pushing it into the wild. In Ship30for30, we learn to apply this to writing.

But lately, one question I've been asking myself is this:

How can I apply the Lean Methodology to tech educational video content?

For a few reasons:

  • Scripting & Editing a longer-length video is time-consuming.

  • I often don't know what video ideas will perform well or not (obviously, packaging & the hook play a big role, too, but the subject matter is key). But is the subject matter (the core idea) important in short-form video? Or is it all hook & curiosity loops?

  • Short form has more reach since it requires less commitment from the viewer, and I'm not using it yet. Can I use it to test ideas, or is the format too different?

To solve this question, I'm :

  • building up a writing habit via the Ship30 course,

  • repurposing this kind of format to a short-form video.

But I think it'll be a while before I come to any sort of solid conclusion.

(And if you have a clear answer to this question, I'd love to hear from you.)

User Avatar

David from Kodaps

1y ago

5 Small (But Easily Fixable) Mistakes Most People Make Working in Software Development
David from Kodaps

Getting promoted isn't about being "the best."

It's far more about being reliable—and people being able to trust that you won't make little mistakes.

For anyone working in Software Development, here are 5 small (but easily fixable) mistakes most people make—and why, if you can avoid these, your career is going to accelerate exponentially:

Mistake #1: Not Testing

Last Friday, I moved a script higher up an HTML page. I didn't bother checking this innocuous change. And it broke the website.

Always test your work. You never know what the side effects might be.

Add automatic tests if you can.

Mistake #2: Not Explaining Your Difficulties

The most effective ways to solve a (logical) problem is to explain your difficulties out loud.

Not because the person you're talking to will provide insights. But verbalising an issue seems to activate a different part of the brain (verbal and creative, as opposed to logical) than coding. I've often had the solution pop into my brain as soon as I started speaking.

Some developers have a plastic duck for just this purpose.

Mistake #3: Not Asking the End User

Building a complex feature can be fun, but if it doesn't fit the end user's needs it will be a wasted effort.

Make sure you fully understand the need.

Empathy is a software developer's secret weapon.

Mistake #4: Not Showing Your Work

Confront your ideas (in terms of design, architecture, features...) as early as possible with your end user(s) / target audience.

Be brave. Confront what you are building with the real world.

Don't wait till your work is perfect. By then it is too late.

Mistake #5: Not Mentoring Other

One of the best ways to really understand a concept is to explain it to someone who does not understand it.

Help others. It will make you grow.

User Avatar

David from Kodaps

1y ago

I'm Trying Payload as my NextJS CMS. Here's Why. (and How)
David from Kodaps

I've decided to switch my (non-static) NextJS projects to Payload CMS. Because there are three things the solution does well. Here's why I'm making the switch.

I use Markdown (& ContentLayer)

I don't want my content to be locked in to a specific provider, e.g. a SaaS

Markdown is portable and can be tracked with git. For now I use Notion to store my content and export it to Markdown. This allows me to have a custom front matter database.

And I use ContentLayer to convert the front matter to Typescript.

BUT Markdown is basically only good for rich text. It's great for blog posts, but not for anything more complex on page.

I tried MDX

MDX is an interesting concept to augment Markdown.

It allows you to add React components to your Markdown content.

BUT if you want any substantial content, you're basically writing code in a text editor. I've not found a good way to write MDX content in Notion.

Why I'm Trying Payload....

1/ Payload is open-source and NextJS native. So no SaaS lock in.

It provides an administration UI for your content, but you define your content types in code (TypeScript).

2/ Payload has good internationalisation (i18n) support out of the box

But more importantly,

3/ It allows you to create items containing a collection of blocks, each with its own type. For example a page with different section.

BUT surely that means my content is locked in to which ever database I'm using?

So next step: I'm building an MDX import / export to be able to edit my content in Payload and use my existing content.

User Avatar

David from Kodaps

1y ago

Here are 6 JavaScript concepts you should understand in order to be fully proficient in React.

1/ Falsiness

Falsiness means values that are "as if" they were false. i.e. They don't trigger "if" statements.

Falsy values includes 0, null, undefined, the empty string and NaN.

=> Falsy values are used in conditional rendering

2/ Object mutation

Let's create an object : let a = {}

Then copy to another variables : let b = a

Finally, we change a's shape : a.id = 42

What does 'a == b' evaluate to? To "true".

=> Changes to a are not detected by comparing a to b. Generally speaking it is best not to store React state in an object

React change detection checks how variables change, just changing a member doesn't trigger the change detection.

3/ Destructuring

We can extract values from an object or an array. For example, if we pick from our previous example, and write :

let { id } = a;

This amounts to: let id = a.id;

In the same way, if we have an array stored in a variable called arr,

let [ c] = arr;

amounts to let c = arr[0];

=> Destructuring allows us to extract values from an object or array

(For example, the useState hook returns and array with the current state and a function to set a new state.)

4/ The spread operator

The spread operator (...) "explodes" an array or an object in to its component values.

So if we write : let b = { ...a}, b has the same values as a (i.e. it contains the same data) but a is not equal to b.

=> If we do store state inside an object (for example with useContect), we can use the spread operator to create new objects to store in the state and to ensure changes are detected.

5/ Boolean operators

Boolean operators are && and ||

They don't quite work as you would expect, in that they don't (necessarily) return true or false. Instead, if a is falsy, a || b evaluates to b. And if a is truthy, a && b evaluates to b.

=> This means that if you have a condition, and you only want to return a <Component> if it is true, you can write condition && <Component>

Be careful with falsiness though: most falsy values don't provoke any render, but 0 will be displayed, even if it is falsy. So if in our code above condition is 0, you're getting a 0 in your UI. (you're fine with false, null, undefined and the empty string though)

6/ array function : Map & Filter

a/ Map allows you to transform an array using a function :

arr.map((item) => f(item))

=> This allows you for example a different component for each item in a list of values

b/ filter allows you to filter an array of all the values where a condition is false

arr.filter((item) => isValid(item))

Used with map this allows for powerful interface updates

In summary, you need to understand:

1/ Falsiness

2/ Object mutation

3/ Destructuring

4/ The spread operator

5/ Boolean operators

6/ The map & filter array functions

Make sure you follow for more insights from the frontlines of web development :)

User Avatar

David from Kodaps

1y ago

4 Tips for Making Technical Concepts Relatable to Non-Technical Stakeholders
David from Kodaps

Explaining technical challenges or features to a non-developer is often frustrating, but done right it is rewarding.

We use condensed jargon like "race condition" or "side effect" to express complex concepts. However for most people, those terms have no meaning. Which means explaining them out into non-technical terms.

Here are four tips to help you do just that

Tip 0: Determine the common ground

Start by defining the known common ground.

Ask questions like "What is your understanding of" whatever core concept you are trying to explain. This show you where the gap lies. And how to fill it.

And it means you don't waste the time of the people you are communicating with.

Tip 1: Use analogies to connect complex ideas to familiar concepts

Technical concepts have physical world equivalents people can relate to.

A database is a library of ledgers. A network message is an address. A program is a recipe. A commit is a record of which lines in the code were changed.

Once you have your analogy, tell a story with it. With diagrams if need be!

Tip 2: Simplify language and avoid jargon

Jargon permeates our language.

Among people who understand it, it speeds up communication. With a non-speaker, it kills it.

Use everyday words.

Tip 3: Highlight the business value and relevance

How does what you are doing translate in terms of time and money for the business?

How will it help have time, or make money? How does it help better meet the end-user's needs?

How can it benefit the people you are communicating with?


And remember: one of the better ways to ensure you understand a concept fully is to explain it to someone who is new to it. In other words: You too can benefit from the exercise.

User Avatar

David from Kodaps

1y ago

3 Ways in Which Software Developers Think Differently And How To Better Communicate With Them
David from Kodaps

Communicating with software developers can be frustrating, but it doesn't have to be that way.

For 20+ years I've functioned as the primary interface between software teams and non-developers. As such, I've seen my share of miscommunication.

We software developers live in a different world -- one with different challenges, rules and outcomes. This colours our way of thinking.

Here are three ways in which developers "think different" (to steal a slogan), and how best to communicate with us:

1 - We make the implicit explicit

Computers deal in 1s and 0.

They needs to be told exactly what to do in every single situation. Software development is about translating implicit fuzzy needs into explicit rules.

Our understanding of the context needs to be as extensive and precise as possible.

When communicating with a developer, explain the "why".

2 - We think in systems and abstractions

Given a set of feature requests, my natural tendency is to imagine which overarching system will allow me to implement as many of the features as possible. In other words, to determine the commonalities between tasks.

When talking to a software developer, state both the current need, and what other similar needs exist now and in the near future.

Provide the larger picture.

3 - We focus on what could go wrong

Part of the difficulty in software development is that the "nominal" case (the one where everything works!) is only one of many possible situations.

But each possible failure scenario also needs to be managed (i.e. coded) for the systems to work. For example, what should happen when a payment first succeeds, but then fails?

When communicating with a developer, explain what should happen when things go wrong.

To summarise: The first step in improving communication between devs and non devs is to recognise that, despite a common language, we have different mindsets, cultures and world views.

User Avatar

David from Kodaps

1y ago

The 6-Step Viral Framework Revealed by Urban Legends
David from Kodaps

In 2007, Chip and Dan Heath released "Made to Stick", a book that changed how I think about communicating.

It explores what ingredients make urban legends "stick" in people's minds and repeat them.

In short, what makes them viral?

They discovered six common traits of effective marketing campaigns and urban legends and gave them a six-letter acronym: SUCCES (yes, there's a missing S).

Trait 1: S is for Simple

Simple is easier on the brain.

The mind struggles to remember several "bits" of information. How can you condense what you are trying to communicate into one core idea?

Trait 2: U is for Unexpected

The mind is made to recognise patterns. And then ignore them. To stand out, an idea needs to break the pattern of what is already known - to surprise and entertain the mind.

Highlight what is counter-intuitive in the core idea. Create a mystery.

Curiosity gaps drive your story forwards.

Trait 3: C is for Concrete

Our brains remember concrete stories and details better than they remember abstract concepts. How can you help your audience visualise your idea?

Show, don't tell.

Trait 4: C is for Credible

An idea will only spread if people believe in it. What is the reason you believe this idea? Why should your audience believe it?

Trait 5: E is for Emotional

Why should your audience care? Not because of an abstract statistic, but because how it impacts people. Or how it impacts them.

Trait 6: S is for Stories

Our brains are made for stories. If you want an idea to stick, structure it as a story.

It's not always possible to use all 6 traits. But leverage as many as you can to make your communication more effective - be it a corporate presentation, a short-form video, or anything in between.

User Avatar

David from Kodaps

1y ago

4 Essential Skills for Success In Learning To Code
Davd from Kodaps

I've been coding for over 4 decades - because I started when I was 7. And I've been learning to code ever since, because coding is not something you learn once. It's a permanent process. The software landscape is constantly evolving moving target.

To learn a programming language, and to keep learning and growing once you have the fundamentals, you need these four skills.

Skill 1 : Problem solving abilities

A core strategy of software engineering is "divide and conquer". It takes many shapes, but it comes down to this: break down a problem into smaller parts, and solve those.

When learning a coding concept, break down what you are trying to grasps into smaller concepts. A website like Exercism does this for you, by creating a learning journey. (checkout exercism.org).

Skill 2: Learning Mindset

The first step is to recognise that you have a problem. That is to say, you need to start by realising that you need to learn. This is not just the starting point. It is the prerequisite for every step of the way: having the humility to recognise there is more to learn.

That the road is never finished.

That there is always more to learn - and that the journey is rewarding.

Skill 3: Attention to detail

Computers deal in absolutes and cold hard facts - in 1s & 0s as opposed to us more fluid and messy humans.

That means mistakes sometimes hide in the mundane - in a misspelt word, in missing punctuation.

Coding is an exacting exercise. But it is fun.

Skill 4: Patience and Perseverance

Finding those mistakes is an exercise in tenacity. In grit. In trying, again and again and again.

But there is no feeling like felling a bug that I've been tracking down for days. It's like killing the boss of a particularly hard level in a video game.

That rush of dopamine is why I program.

User Avatar

David from Kodaps

1y ago

How I Maintain Focus Instead of Scrolling (Even Though I have ADHD)
David from Kodaps

Everyone struggles with distractions to a certain extent.

For those of us with ADHD, it's worse. The slightest distraction can send me careening down a rabbit hole. Countless times, I've looked up from my computer or walked out of a room and wondered: "What did I come here for initially?"

But making progress on any task requires dedication, regularity, and consistency.

And one day, it all clicked. I realised I could lean into my neuro-spiciness and use it as a strength instead of battling it constantly. And as soon as that penny dropped, I started to understand that overcoming my wandering attention wasn't that hard—I was simply doing the wrong thing, wasting energy fighting my brain.

Here's what I should have done instead:

Choose my distractions

My mind is going to wander when I need to concentrate. But if I provide my own distractions, I can make sure they don't lead me where I don't want to go.

It's a simple fix really: I occupy my senses.

  • I pipe sound into my ears that has no discernible structure or words.

  • I set up a counter in the corner of my eye for the time I have left

The music has enough variation and change to filter out distractions, but not enough to hold my attention fully. The counter catches my eye but redirects me to the task.

And then I let my mind do its thing.