โ€ข

newsletter

My top 3 skills to learn as a software developer

Some skills will pay more for your time than others. Principles and practices that sit at the core of your daily struggle to make a complex system stand on its own. These are my top 3 picks for you (and why).


Sandro Maglione

Sandro Maglione

Software development

Not all skills are created equal.

I am of the opinion that knowing everything is generally preferable (guess you agree?). Yet some skills have objectively more valuable, the ones that are cross-technology and more frequently used.

Let me save you some time and give you my top 3 picks ๐Ÿ‘‡


(1) SQL and relational databases

Now that the trend of NoSQL is waning, we can come back to origins with SQL.

No matter if you do frontend, backend, data science, or even design (that's right), SQL is for you. SQL and relational databases in general:

  • Backend: Database management, data modeling, querying (obvious ๐Ÿซก)
  • Data science: I mean, databases are kind of your job, right?
  • Frontend: Knowing how to query and manipulate data is a must

Note for frontend folks (and I guess everyone else): a new wave of local-first is coming. This moves the database to the client, and the database is going to be SQL (postgres/sqlite).

SQL is about to become even more mission-critical โšก๏ธ

Don't shy away from the basics, SQL is a required skill in your toolbox ๐Ÿ™Œ

(2) Domain modeling and data structures

An app is as good (and safe) as it's data model.

Your domain model sits at the heart of your app. It's the first thing you design and the hardest to change.

Ever heard of the "Onion Architecture"? Keep external dependencies as far outward as possible, and domain entities at the core.

Better not mess up that core then, right? ๐Ÿ’๐Ÿผโ€โ™‚๏ธ

Everything is coupled with your domain, better make sure it works then!Everything is coupled with your domain, better make sure it works then!

In TypeScript a solid domain model starts with schemas. Some rules of thumb:

  • Add annotations and branded types whenever possible
  • Implement strict validation rules (e.g. NonEmptyString better than just String)
  • Make impossible states unrepresentable
  • Use meaningful and consistent naming conventions (arguably the hardest part ๐Ÿซ )
  • Use enums (Literal) for fixed sets of values
  • Choose the right data structure for the job (e.g. HashMap instead of Record)

Below an example of schema for a course on Typeonce:

  • Use Literal instead of String for the category
  • TemplateLiteral for strings with a known pattern
  • NonEmptyString title
  • DateFromString so that the UI gets the right date format
const CourseCategory = Schema.Literal("full-course", "project");
export const PackageJsonLink = Schema.TemplateLiteral(
  Schema.String,
  "package.json"
);

export class MetadataCourse extends Schema.Class<MetadataCourse>(
  "MetadataCourse"
)({
  preview: Schema.Boolean.pipe(Schema.optionalWith({ default: () => false })),
  title: Schema.NonEmptyString,
  description: Schema.String,
  githubUrl: Schema.TemplateLiteral("https://github.com/", Schema.String),
  githubPackageJson: Schema.optional(Schema.Array(PackageJsonLink)),
  icon: Schema.TemplateLiteral("/static/images/course/icon/", Schema.String),
  updatedAt: Schema.DateFromString,
  category: CourseCategory,
}) {}

The code above uses Schema from effect.

(3) Functional programming

I waited too long to learn this (well, I didn't even know it was a thing ๐Ÿฅฒ).

I don't mean functional programming in the sense of "learn Haskell" (of course). Functional programming principles are the real gold.

Start from here:

  • Pattern matching (a blessing when the language supports it (well))
  • Immutability
  • Pure functions
  • Dependency injection (Function composition)
  • Types over classes (First-Class and Higher-Order functions)

Every paradigm has something to teach. I got started with Lisp, Scheme (Racket), and Haskell.

Learn the building blocks, and then use them in your daily language.

Bonus: State machines

I'm surprised that many people don't know about state machines. As such, I often preach out loud about their importance and benefits.

Every app deals with data, every data change is a state change, and state changes are modeled as a state machine.

So, yeah, don't be afraid of state machines.


I am cooki.., erm, coding my next project. You are always the first to know about new things. It's in active development but already open source on Github.

A local-only calories tracker app made with TanStack Router, PGlite, Effect, XState and drizzle.

The app is all client-side, fast, private, and reactive using a local postgres database โšก๏ธ

Meanwhile new snippets popping up on Typeonce: Stripe payments React client with XState and Effect.

See you next ๐Ÿ‘‹

Start here.

Timeless coding principles, practices, and tools that make a difference, regardless of your language or framework, delivered in your inbox every week.