Shadowgraph
TrendingAbout
Sign in

lambdaclass/lambdaclass_hacking_learning_path

LambdaClass Hobby Club, hacking learning path handbook. The journey starts here!

481

363 commits

updated Jan 12, 2026

See the code

README

LambdaClass Hacking Learning Path

⚠️ If you are applying to LambdaClass' Engineering Residency you've to complete this learning path ⚠️

Table of Contents

Introduction

⚠️ If you are applying to LambdaClass' Engineering Residency you've to complete this learning path ⚠️

You can choose a life of ease and comfort or you can choose a life of service and adventure. When you're 90, which one of those things do you think you'll be more proud of? - Jeff Bezos

My algorithm has always been: You put smart people together, you give them a lot of freedom, create an atmosphere where everyone talks to everyone else. They're not hiding in the corner with their own little thing. They talk to everybody else. And you provide the best infrastructure. The best computers and so on that people can work with and make everyone partners. - Jim Simons

Top-down management leveraging command-and-control hierarchies are for the mahogany boardrooms of yesteryear. We are navigators, adventurers, and explorers of the future. We are married to the sea - Yearn's Blue Pill

A boring codebase doesn't make a bored developer, on the contrary, it frees developers up to think about important stuff and deliver value to the business. Just as I want my language to be boring so I can focus on interesting stuff, I also want my tech stack to be boring - the interesting bits should be in the value added, not the stuff under that. - HN

Welcome!

If you are reading this, you are probably giving your first -or second- steps on the long journey towards being a good developer, but first try to be a good human being and you will see how far that can get you.

This text is a guide intended to aid employees in their first days at the company, it will guide you in setting up expectations and working tools, and includes a whirlwind tour of the background knowledge necessary to work on the kinds of projects common at LambdaClass. This comprises the first part of the path.

The second part is a repository of selected and categorized reference material, exercises and projects for engineers at any stage.

During the initial onboarding of new employees, the first part must be read (end eventually re-read!) by everyone during this process, while the second part can be read on demand.

Part I The Foundation

Our Worldview and Company Culture

Before tackling the technical challenges ahead of us, we realized that the most important things any institution aspiring to greatness must have are clear and shared values and principles. These characteristics, along with several others, define a company's culture.

In these pages, you will find these principles and values, which are expected of anyone who is part of this institution, whether they are a newcomer or a settled employee, an intern or a manager, and how to solve non-technical problems. LambdaClass is a company with high technical content, but this knowledge must be enhanced by cultural values that allow a fast identification of problems, as well as ways to solve them, based on different learnings and heuristics that many have experienced throughout this journey.

While this document aims to be useful, organized, and verified, it is important to note that knowledge and wisdom must be challenged, evaluated, and modified over time. The ideas in these pages are not set in stone but are constantly being assessed and seeking to be refuted or improved.

c.f. The Hacker Manifesto.

Many of the values we elaborate on stem from a central truth: our work only matters if it can be trusted.

We are part of a global effort to build open, secure, and equitable digital infrastructure—systems that may outlast us and serve people we'll never meet. That reach gives us both influence and responsibility: every decision we make must reflect precision, respect, and honesty.

We work on technologies that manage sensitive data, financial transactions, and trustless environments—tools that are redefining how information, value, and identity are handled worldwide. The choices we make ripple far beyond LambdaClass, directly affecting security, privacy, and access to information.

In the fields of blockchain, cryptography, and decentralized systems, maintaing trust is a foundational and non-negotiable principle. A single careless action can erode confidence not just in one project, but in the entire ecosystem that depends on it.

When we ask people to trust the systems we create, we are also asking them to trust us. That trust is earned only when every member of our team acts with integrity, safeguards information, and approaches their work with professionalism.

When we ask people to trust the systems we create, we are also asking them to trust us. That trust is earned only when every member of our team acts with integrity, safeguards information, and approaches their work with professionalism.

One of Lambda's core goals is the betterment of society via technology, and cryptography (and soon AI) are central to these goals.

Attitude

Attitude is how you feel, think, and what you believe regarding something, in other words, these things determine how you approach it.

Although the points we are going to discuss may seem obvious to someone with experience, most of the people who join us are trainees, meaning they have little or no experience in the development industry. Therefore, it becomes necessary to make these clarifications to ensure that everyone understands what we expect.

At Lambda you'll be surrounded by highly skilled professionals. We focus on building a high-performance team, so everyone here excels at what they do. In fact, being exceptional is the standard, which creates a paradox—because in a sense, no one is truly exceptional. Achieving top grades and finishing your degree on time, being passionate about System Programming or Cryptography, or mastering coding skills may have brought you here, but won’t suffice to ensure that you will continue to be a valuable team member. Everyone must continually prove they deserve to be part of this team.

Please don't interpret this point as an invitation to break rules, procedures, or timelines in the pursuit of excellence. While striving for exceptional performance is encouraged, it must be done within the boundaries of established guidelines. For example, completing the Learning Path in a week doesn't demonstrate mastery — it only shows that you rushed through the content without taking the time to truly absorb it. You won’t gain a deeper understanding by rushing through it. Additionally, we explicitly address the importance of ethical conduct, and cutting corners is never acceptable.

There are three key elements we want you to have present at every moment: Communication, Accountability, and Empathy.

  • Communication is a key aspect of every human relationship. If you can measure your words to give a positive clear message, you can achieve anything in life through teamwork. Try labeling your emotions before communicating, since it is likely that people in front of you do not know what is going through your head. Also, be transparent but assertive if you disagree about something, it will help understand your point of view. Finally, try to avoid direct messages, working on channels allows more people to be in the loop and better feedback can be given.
  • Accountability. Everyone makes mistakes, learners do something about them. If you get something wrong, communicate poorly, or even feel overwhelmed about a situation, raise your hand and say it. It's very likely that a process failed, not you. Many people will be there to help you sort out the issue, and you will surely learn something along the way. If you keep quiet and don't say anything you will regret it later when the truth burst through another hole.
  • About empathy, we are all human beings and have complex emotions, if you are feeling great, it doesn't mean your colleague isn't feeling like shit. Perhaps your coworkers don't feel comfortable talking about emotions, so go talk with them and help them. You can talk to them or their manager if you feel something is going on with them. There is a time when everybody feels weak and needs someone else for support. So be a hero, be empathic.

Also remember our core principles are:

  1. We hire fast, fire faster, promote the fastest.
  2. Adhere to the truth and be transparent
  3. Do what is right for the product.

Ego, Learning to fail, and Your relationship with your own work

Those truly exceptional at Lambda are the least likely to believe they are. You may know how to code, but dealing with your own perception and emotions related is a soft skill that appears more rarely in young developers. Trust is earned over time, skills are learned and perfected over time, outliers in one context may not be so in another, and being an excellent team member and understanding one’s role in an organization is more important than standing out.

Excellency is a habit, and no one is above making mistakes. These two facts together lead to a an important conclusion: in order to be exceptional, it's crucial to learn from your mistakes. This starts with acknowledging them. Making mistakes isn’t the same as failing—pretending they didn’t happen is. Mistakes are an essential part of learning; you can’t grow without them. The next step is communicating them. Your work impacts others, so if you make a mistake, it’s important to acknowledge it. This not only makes it easier for others to help, but it also shows accountability.

On the other hand, self-doubt can also become unhelpful and crippling. We can guarantee that almost everyone at Lambda is constantly asking "how can I be better?" of themselves, but believing you don't belong will eventually lead to making it true.

As with most projects making mistakes fast and loudly will make you learn faster, this is why you must work directly on a repository through Pull Requests rather than workshopping in a draft made elsewhere.

  • Avoid google docs. Work directly with Git, it will help get more eyes on your work to get corrections earlier.
  • Default to git. As said earlier, Git snapshots your work and makes it more accessible to the public, more eyes means more people eager to help you.
  • Avoid asking questions in private chats: asking in the project channel is much better, as the question can be answered by anyone, more voices are heard, others with the same questions may also benefit from the answers, and finally the discussion if worthwhile can be captured as documentation.

Much is said about the Dunning-Kruger Effect and Impostor Syndrome, but the important points can be boiled down to:

  • Keep your ego in check
  • Learn to fail, and learn from mistakes
  • Learn from others and help others in need
  • Listen to feedback and do not worry about evaluating your own performance

Some resources on this topic:

Developing equanimity and focusing on the truth revealed by results is The Lambda Way. You’ll come across more lessons on this throughout your learning path.

Principles for success and teamwork philosophy

We follow a code of conduct designed to ensure a safe team environment. You signed it when you entered Lambda and we expect you to follow it. Basically, treat everyone with respect.

Your relationship with others and work hierarchy

At Lambda we won't micromanage you because we don't want to: we give flexibility but ask for responsibility in exchange. Of course, you can have days off to study, or if you feel sick, but you can also have days off if you feel brain fog, nervous, or a bit under the weather; we actually prefer it that way.

If you feel healthy and comfortable, you will be able to solve more efficiently the problems you have in front of you. And even better, you will contribute to a healthier workspace.

Nobody wants to give up, that's a common emotion. The good news is that you are not giving up, you are getting to know yourself better, so you can recharge your energies and keep learning and improving. In turn, when you are working we expect you to hit goals, be proactive, and be a valuable member of the team.

One of the first thing you’ll learn during your onboarding process is that feedback is our most valuable tool, and the ability to give and receive it is something we continuously develop here at Lambda. One quality we all share as collaborators is the ability to take feedback and act on it. Here, feedback is direct and to the point—we’re transparent and clear. If you’re making a mistake or there’s something to improve, you’ll be told as soon as possible. The same goes for positive feedback: if something stands out, we’ll make sure to highlight it.

For us, feedback isn’t a one-way street. It’s not just top-down from managers to team members—we encourage and value feedback in all directions. Two clarifications are in order:

  1. If you receive an instruction you disagree with, you can express your concerns respectfully, offering your reasoning and suggesting an alternative. However, if your Tech Lead still asks you to proceed with the original directive, you must follow it and continue with the assigned task.
  2. Valuing feedback and continuously seeking to improve processes doesn’t mean you can voice any comment or suggestion that crosses your mind, nor that we will implement everything you propose. It’s important to understand that those in charge have likely already considered the same questions or alternatives.

If something is in place, it's because it was determined to be the most effective solution.

When you enter the workforce, giving feedback, especially negative feedback may be one of the most challenging skills you have to build. Here’s the key: It’s not just about what you say — it’s about how you say it.

  1. Be timely - There is a time and place to express your point of view. So, make sure that you aren't catching anyone off-guard. And, above all, read the room.
  2. Before you launch into feedback, ask permission first. Never launch into unsolicited feedback without checking.
  3. Be prepared - Feedback should be specific. You should be able to explain the problem and how it’s impacting you, your team, or the organization.
  4. Be constructive and solution-oriented - Aim to approach the conversation with a helpful attitude rather than pointing out their flaws. Always couch your feedback as an opportunity to improve performance, or to optimize, or to get better outcomes.
  5. Be respectful and be honest - make sure your tone is assertive but it pays appropriate deference to your lead's authority.

Keep in mind that feedback, regardless of which direction it's going in, is affected by this power dynamic. This is why:

  1. Your own performance has to be solid. In other words, you should consistently prove your competence and deliver valuable outcomes.
  2. You have to know what you are talking about. The quickest way to lose credibility is by presenting unthought-out or half-formed opinions.

References:

Working on client projects

Remember you are employed by Lambda even if you work on a client project. It's commonplace in Lambda to work collaboratively with clients in the development of apps and features, so maybe you will have more day to day rapport with them than with your other Lambda coworkers. If you're in that situation you should always remember a few key things:

  • Your work relation is with Lambda, not with the client so expect to get feedback from your Lambda's Tech Lead and Project Manager and not from the client, don't ask for it either.
  • The relationship between Lambda and the client is managed by the Tech Leads and Project Managers. If someone from the client side makes a request to you personally via DM please contact your Tech Lead and Project Manager about it. Make sure your Teach Lead and Project Manager are in the loop for all relevant information.

Professionalism and Ethics

Just reading this subsection title, you can feel your eyes rolling back into your head. What does an attitude of "hack the planet" have to do with the words "professionalism" and "ethics"?

Well, the lone hacker may be romantic, but great things only come from working together. At Lambda, we foster a youthful, relaxed, and collaborative environment to make sure that we can work together, and because of this professionalism and ethics are non-negotiable, whether you're 18 or 40.

We'll elaborate, but a tl;dr boils down to:

  • Work towards making your environment better than the way you found it. This ranges from cleaning tableware used at the office to helping others with your strengths.
  • Deliver high-quality work and taking ownership of responsibilities.
  • Safeguard confidential information — never share or sell it to competitors. If you're unsure whether something can be disclosed, always check with your manager first.
  • Respecting intellectual property, crediting others' contributions, and protecting confidential information—never sharing or selling it to competitors.
  • Stealing, in any way, is explicitly forbidden and is grounds for immediate dismissal. This include stealing software from other projects, open source or not, without attribution or credit.
  • Times are changing fast, and we always encourage trying out new tools, but at Lambda, using code provided by AI or LLMs is stricly forbidden. You can still use LLMs for other purposes, but copilot-style integrations which write code for you are a net loss, as they are not accountable regarding where they get their inspiration from and do not understand code licensing issues.

As all things, this is learned over time, with experience, and from others. If you are ever in doubt, ask your managers, tech leads, and mentors.

So what is professionalism?

Professional behavior is being considerate, formal and focused. In other words, putting constraints on behavior to enable something else. What exactly? A professional attitude makes you trustworthy and reliable. Clients and colleagues prefer to work with people who are polite and dependable. When you are known as somebody who is reliable, you’re more likely to be given added responsibilities and opportunities, and can make faster progress in your career.

Some of the most professional traits:

  • Self-awareness of your behavior: the most important part of creating a professional reputation is showing you behave well when at work. Every workplace has different rules, guidelines and culture, and may be more or less relaxed, but some tips that are universally applicable are:
    • Be aware of others' personal boundaries.
    • Remain calm and unemotional.
    • Be punctual when coming to work, arriving at meetings or joining calls, to respect other's time.
  • Excellent communication: misunderstandings lead to lost productivity, so a professional always makes the effort to be understood.
  • Honesty: Be open and honest, even during difficult conversations. Being able to confront people directly, rather than share your grievances about them with other people, is important in maintaining a professional attitude.
  • Integrity: Always tell the truth. Personal accountability is owning the outcomes of your decisions, and closely related to honesty and integrity. Although you should try to do your best, everyone makes mistakes. When you do, taking responsibility and offering ways to fix errors and prevent them in the future will help colleagues and supervisors maintain their trust in you.
  • Be respectful to others: treating others with respect and kindness is part of getting your ideas across, regardless of who you are interacting with. You don't have to like everyone, or be liked by everyone, but you do have to treat them well, no matter what their role is. Respecting others also includes supporting them when they need it and being generally helpful, since this furthers the group's goals, not individuals'.
  • Be a dependable team player: Come prepared and plan ahead. Build a reputation as someone who keeps their word and can be trusted to deliver on commitments and deadlines. Failing to follow through can have serious consequences for those who depend on your work. When things don’t go as planned, don’t make excuses—take responsibility, do your best to get tasks back on track, and communicate early if you need additional support or resources.
  • Flexibility: Commitment to your role also means being adaptable when circumstances change. As projects move forward, plans, goals, and requirements may shift, and you are expected to maintain professionalism throughout. At times, this may require adjusting your schedule—such as staying late to ensure a task or deadline is met.
  • Competency and a strong work ethic: Being highly skilled may be the first thing one thinks of a professional. To be dependable one first needs to be capable, so as not to leave others picking up the slack or doing more than their share of the work. Over time, keeping knowledge and skill up to date is also expected of a professional. No amount of highly specialized knowledge will compensate for this. Check your work for any errors before submitting it.

Practices at Lambda

Development processes and workflows

  • There is a weekly call with every member of the team to set the most important goals of the week, as well as a daily call to focus on the problems of the daily tasks.
  • When working on projects, the specific tasks to tackle are written in tickets on Github Projects. Some actual Lambda's projects are working on other project management software, but these are legacy.
  • Chapter 1 of The Manager's Path

Design and coding standards

  • The Basics
  • Suggested reading: Coders at work
  • make is the build tool. Consider these notes.
  • Postgresql is the default database.
  • Write tests.
  • Favor integration tests over unit tests. A project's first tests should be end-to-end smoke and sanity tests, and only after that, if ever, should unit tests be written to test API's, system invariants and help pinpoint bug causes and locations.
  • Do not write tests before you have solved the problem, you may waste time writing tests for the wrong implementation.
  • Write for humans: coding for computers is easy, but writing code that is understandable by another person is an art.
  • Code and document in english unless you have a very specific reason not to.
  • Use meaningful, readable names for variables, functions, and files. Don't try to save characters.
  • Documentation is a sign of the quality of an API. It's easier to write it when the design is right.
  • The less code you have the better. Deleted code is debugged code.
  • Aim for simplicity, not performance. The latter is a by-product of the first.
  • Only introduce optimizations if you have benchmarks that prove an improvement and that the improvement is relevant in the context of the program.
  • Only introduce optimizations if they represent a concrete gain (e.g. cost savings, improved user experience).
  • Follow the Zen of Python, regardless of the language you are using at the moment. English also counts as a language.
  • Don't introduce dependencies prematurely. You must evaluate your requirements, maintenance, and integration costs first.
  • If you want to upgrade a dependency, test it first.
  • Always lock your dependencies. Pin a specific version and a commit of a dependency, don't use the version at master.
  • Use git and commit often, even in one-person projects.
  • In general, avoid pining the patch version of dependencies, more info here.

Working on open-source projects

  • Suggested reading: The Architecture of Open Source Applications.
  • Use MIT or Apache 2.0 license.
  • Fill the description field at the top of the repo page.
  • Write a decent README.
  • A good readme starts with a succinct description (one or two sentences) and, when possible, a very short and illustrative example use. The rest of the details go after this header.
  • Use continuous integration, most likely GitHub Actions.
  • Make a good balance of features vs maintenance. Maintenance details usually matter more than adding a lot of features.

Documentation

Group Readings

Software has over the decades, developed a culture and folklore of its own. As trends fade in and out, older tools and practices give way to newer ones, and flame wars rage one, we gather battle stories, wisdom, quotes, bibles, and memes with which we talk about our craft.

We have selected a few articles and posts we consider especially important to be familiar with, because they align with our values and way of working. To ensure everyone has time to be exposed to this material, we set up discussion groups in which someone volunteers to present some material, and the ensuing debate involving everyone, including more senior members, always results in relating the information to concrete experiences.

In addition to the Hacking Learning Path, new employees must participate in these Readings until they cycle out of the contents. You can see the program here.

However, we encourage everyone to continue to embed themselves in this engineering folklore and to continue studying and gainig new skills. For this reason, once the mandatory readings are done with, we invite them to the Book Club, which votes on what research papers, books, posts, or presentations they will study and debate.

Community projects

We organize activities where we share thoughts and interests with anyone who wants to join us.

Learning Projects

The learning path is not just a pile of material to read through, and there is no exam at the end with questions you need to answer. The point of gaining knowledge is to be able to do more things and apply them in problem solving. The only way to learn how to do this is via practice, and since small exercises can only exercise very specific things, there are a few larger projects throughout the learning path which newcomers are expected to complete. These projects are located in the respective section for their language.

When the time comes to start one of the projects please follow these steps:

  • Create a new github repository under your personal account
  • Setup the project skeleton, which will vary depending on the language and tech stack used for the project. In all cases the skeleton should include:
    • A README.md: Create some initial documentation that explains what the repository contains.
    • A Makefile: a Makefile with standard targets (build, run, test) will allow anyone, regardless of familiarity with the commands specific to your language, to run the project.
    • A code skeleton: even a "hello, world!" program will allow exercising the build, running, and testing targets.
    • CI: Part of learning a language or tool includes knowing how to automate the tasks of ensuring that a code change compiles and passes the tests. Since we host these learning projects on Github, the initial PR should include configuration for Github's Continuous Integration platform Actions to run after each change you commit to a PR.
    • Issues: once you understand the project, create issues for the identifiable parts of the implementation solution.
  • Branches:
    • Immediately create a dev branch, in addition to the main one. Learning projects have two separate phases: the first is active development. During this phase your PRs should branch from dev, and once reviewed by other members of the group following the Hacking Learning Path be merged into dev. Once your MVP has been achieved, and all the base functionality is implemented, create another PR from dev into main with the entirety of the code developed during the first phase. This PR will be reviewed by more senior members. Address any corrections that the may give you, and once this PR is merged into main the project can be considered complete.
    • When tackling an issue, immediately create a branch for it, push it and open a PR in draft mode. Having an open PR that is not yet up to review is a good practice because it allows following the work, and provides a venue for discussion and comments even before a review takes place.
    • At Lambda, repositories are automatically configured to delete branches once corresponding PRs are merged. Since learning projects are done under your user account, you must either configure this yourself or delete branches manually after merging. Allowing stale branches to accumulate is generally considered a bad practice.
    • Another requirement is configuring branch protections for main and dev branches. Your CI must have jobs for ensuring that the code is formatted correctly according to the language's formatter, compiles, and passes tests. Each of these should be a separate job and required for merging a PR.
  • For a PR to be eligible for merging, it must at least:
    • Have a good description of its contained changes.
    • Compile, have no failingg tests and pass all CI checks.
    • Have two approvals from other reviewers.
    • Auto-approving is verboten!

The goal of doing all this for a learning project is to allow reviewers to skip the more basic corrections and address more meaningful corrections, and to make you familiar with the basic expectations and workflow of any project at LambdaClass.

Cryptography

One of Lambda's core goals is the betterment of society via technology, and cryptography (and soon AI) are central to these goals.

Technical Foundations

Development Environment

We use a suite of tools to facilitate many tasks, as well as to enforce our security standards for all employees.

Please refer to our Notion document, which aims to provide a simple overview of all of our tools.

Before beginning with this Journey, if you're a macOS user, you may need some tools or utils for a better experience in your learning path, otherwise, you can skip this section.

  • Two-step authentication is mandatory for every login of the company accounts (e.g. Slack, mail, GitHub).
  • Also, the company's GitHub repositories are accessed via SSH
Homebrew

Homebrew is a package manager for macOS. It is a must on any developer machine.

GNU tools

Once you have installed Homebrew in your macOS system, you'll need to install some of the GNU tools/utilities for a better work experience. Just type in your shell the following command lines:

ASDF version manager
  • asdf is a version manager with the idea purpose of generating environmental variables to choose the specific version desired. Remember that to be able to use the environmental variables you need to set their path for the shell to check, you can see how to do it depending on how you installed asdf here.
Code Editors and IDEs

Do's and don'ts about the use of Vertical Whitespace

  • If you'd like to visualize more vertical whitespace than it's established in these Do's and don'ts configure your text editor to show more space.
  • Most of these rules can be enforced automatically in your text editor, configure it to enforce them.
  • Minimize the use of vertical whitespace.
  • Do not end functions with blank lines.
  • Do not start functions with blank lines.
  • Do not use blank lines when you do not have to.
  • Do not put more than one blank line between functions.
  • Blank lines inside a chain of if-else blocks may well help readability.
  • Blank lines at the beginning or end of a function very rarely help readability.
  • Don't leave blank lines at the end of a file.
  • Don't forget to put a single end of the line at the end of a file.

Software Engineering

Complexity and KISS (Do The Simplest Thing That Could Possibly Work)

"Always implement things when you actually need them, never when you just foresee that you need them" - Ron Jeffries

Strive for solving problems in the simplest way possible. To achieve this, you first need to figure out a handful of ways to confront the issue at hand, and only then pick the one you consider will work in the fewest, tiniest steps. Afterwards, refactor. Tomorrow’s code may need to be more complex, so do everything in your power to facilitate tomorrow’s code as simple as possible. Also, while you shouldn't be blind to the future, avoid investing time and effort into developing features that are not currently necessary and might be a waste.

The Unix Philosophy

Worse is Better

Some questions to guide your learning

  • How does complexity relate to modularity?
  • Why is the text-stream interface important in the Unix Philosophy?
  • Why should design for transparency encourage simple interfaces?
  • How does robustness relate to transparency and simplicity?
  • Even now with video processing, why output of programs should be terse?
  • According to the Unix Philosophy, how noisy do errors have to be?
  • How does the economy of programmer time relate to robustness?
  • Why premature local optimization reduces overall performance?
  • There is the approach of doing things in "one true way", how does it affect extensibility?

Linux

If you've already installed GNU-tools, there's no need to install Linux on a VM.

How to try some commands in MacOS with a VM
  1. There are some commands that don't work in MacOS. If you want to try them, you can use a VM to use Linux. For this, we can use UTM. Follow the next steps here.
  2. After the installation is complete, close the VM and press “Stop selected VM”.
  3. Run the VM again.
  4. Now you can use this VM to run the commands.

Some questions to guide your learning

  • What do the following commands do?:
    • ls -l /bin/usr > ls-output.txt 2>&1
    • ls /bin /usr/bin | sort | uniq | less
    • ls /bin /usr/bin | sort | uniq | grep zip
  • How does Linux determine how to interpret the format of a file?
  • What does the sda2 folder represent?
  • What do /root and /usr/bin store?

Networking and SSH

Some questions to guide your learning

  • How are data transmitted over the Internet?
  • What functions do the layers of the OSI model perform?
  • What is the difference between TCP and UDP?
  • What does ARP mean?
  • What range corresponds to private IP addresses?
  • What does IPv6 propose to solve against IPv4?
  • What does IPsec guarantee?
  • What does DNS mean? How does it work?
  • What is the difference between HTTPS and HTTP?
  • What is the difference between asymmetric and symmetric cryptography?

Version Control, Git, and Github

Git

No one should merge his/her own PR without it being reviewed and approved by a co-worker and/or a client.

Note: commit and push every day. Don't expect something perfect, go for the concrete. In one way or another, you will likely have to iterate later about that work done. Also, since that work isn't only stored on your computer, it won't be lost.

Note on Newlines at end of file It is considered good style - and sometimes a necessity - to always end files with a newline (see here and here). Make sure your editor of choice is correctly configured to add them automatically.

Some questions to guide your learning

  • Why is branching necessary?
  • What is the difference between merge and rebase?
  • What is a stash?
  • What does cherry-pick do?
  • What does reflog do?
  • What does git reset --hard HEAD do?
  • How to get back to a previous commit?
  • How to do a pull request?
  • Why are pull requests important?
  • How to clone a repository using SSH?
GitHub and GitLab

Before you continue on your Git journey and learn how to use git together with GitHub, it is important to learn what an SSH Key (Secure Shell Key) is and how to generate one and add it to your GitHub account. This key will allow you to connect and authenticate to remote servers and services using the SSH protocol. With it, you will be able to connect to GitHub without supplying your username and personal access token each time.

Once you have an SSH key associated with your GitHub account, managing it will become a pain. The most basic next step is learning that instead of entering your SSH passphrase every time you have to authenticate, you can tell your operating system's SSH Agent to remember it for you and provide it.

In addition, you can tell 1password to manage it as well: instructions.

Once your system is configured to use the 1password SSH agent with your key, you can configure your local git client to use the SSH key to sign your commits, ensuring that your authorship of the code is verified. You can find the instructions here.

If you have existing commits that you need to push but have not been signed yet you can run the following command:

git rebase -i --exec "git commit --amend --no-edit -S" main
  • Progress in any project must be pushed every day. This must be done within a branch of the master repository and a Pull Request (PR) must be opened for reviewing the code, previous to merging the branch to master.
  • Doc files should always be added via pull request.
    • Be sure those files are written in Markdown.
    • We always use Mermaid for flowcharts, sequence diagrams, graphs, etc.
  • Never push to master directly, and only reviewers can merge branches to master.

Testing

  • Test-driven Design
  • Unit testing
  • Integration testing
  • Property-based testing
  • Fuzzy Testing

Debugging, GDB, DTrace

Docker

Some questions to guide your learning

  • In which scenarios would you use containers and in which you would prefer to use VMs?
  • How do you retrieve and run the latest Ubuntu image?
  • In a Dockerfile, what is the difference between RUN and CMD?
  • Using port 8080, how do you run an image that exposes port 80?

Continuous Integration and GitHub Actions

SQL and PostgreSQL

Reference:

Some questions to guide your learning

  • How to use a wildcard as a character?
  • What does COALESCE do?
  • What does LIKE 'S%' do in a query?

Redis

Some questions to guide your learning

  • What is the difference between PostgreSQL and Redis?
  • What type of databases are the following? PostgreSQL, Redis, MongoDB, MySQL, HBase, Neo4J, DynamoDB.
  • What makes each database type unique?

Part II Specific Topics

⚠️WIP⚠️

JavaScript

Python

  • HTTP server in Python with Flask
  • Automate the Boring Stuff with Python
    • Chapter 11
  • The Zen of Python is your bible.
  • Use Python 3 in greenfield projects.
  • Strive to migrate to Python 3 in non greenfield projects.
  • Read this to understand environment hell in Python.
  • Use pipenv to escape from environment hell in Python. You can even do this locally in projects that are set up to use virtualenv and virtualenvwrapper.
  • If you also need to stick with a specific minor version of Python (e.g. Python 2.7.14) you can use pyenv in combination with pipenv.

Some questions to guide your learning

  • How do you return how many times a certain character appears in a string using Python?
  • How do you handle different routes for your web app in Flask?
  • Using the logging library, how do you log to a file?

The BEAM Ecosystem

In the beginning, the BEAM and Erlang were almost synonymous, there were no other languages that ran on the BEAM virtual machine and ERTS. In fact the core of the platform is the ERTS -- the Erlang Run Time System. In time, others have emerged such as LFE, Elixir, and Gleam. Today, the most common gateway into the ecosystem is learning how to be productive with Elixir, learning the serial (non-concurrent) and functional programming aspects first, and then the support for concurrency, the common concurrency and distribution patterns provided by the OTP. This is usually eventually complemented by learning Erlang to be able to understand and read code from common dependencies (e.g. Cowboy). Lately, Gleam has also matured and is a very interesting possibility.

Elixir

  • Elixir Homepage
  • Read the entire Getting started section starting at the introduction EXCEPT:
    • "Module attributes"
    • "Protocols"
    • "Sigils"
    • "Writing documentation"
    • "Optional syntax cheatsheet"
    • "Erlang Libraries"

In addition, read:

Other useful resources:

Useful libraries, dependencies and tools
  • GenStage Stages are data-exchange steps that send and/or receive data from other stages. When a stage sends data, it acts as a producer. When it receives data, it acts as a consumer. Stages may take both producer and consumer roles at once, acting as consumer producers.
  • Flow Computational flows with stages.
  • Ecto A toolkit for data mapping and language integrated query.
  • Phoenix Phoenix is a web framework for the Elixir programming language
  • Plug Plug is a specification for composing web applications with functions.
  • Guardian An authentication library for use with Elixir applications.
  • Waffle Waffle is a flexible file upload library for Elixir with straightforward integrations for Amazon S3 and ImageMagick.
  • Samly A SAML 2.0 Service Provider Single-Sign-On Authentication library. This Plug library can be used to SAML enable a Plug/Phoenix application.
  • Broadway Broadway is a library for building concurrent and multi-stage data ingestion and data processing pipelines with Elixir. Broadway pipelines are concurrent and robust, thanks to the Erlang VM and its actors.
  • Propcheck PropCheck is a testing library, that provides a wrapper around PropEr, an Erlang based property testing framework in the spirit of QuickCheck.
  • ExMachina ExMachina makes it easy to create test data and associations. It works great with Ecto, but is configurable to work with any persistence library.
  • Faker Faker is a pure Elixir library for generating fake data.
  • Hammer Hammer is a rate-limiter for Elixir with pluggable storage backends. Hammer enables users to set limits on actions performed within specified time intervals, applying per-user or global limits on API requests, file uploads, and more.
  • Oban Oban is a robust background job framework which uses PostgreSQL, MySQL, or SQLite3 for persistence.
  • Quantum Cron-like job scheduler for Elixir.
  • Sage Sage is a dependency-free implementation of the Sagas pattern in pure Elixir and provides a set of additional built-in features.
  • Recon Recon is a library to be dropped into any other Erlang project, to be used to assist DevOps people diagnose problems in production nodes.
  • Tracer Tracer is a tracing framework for Elixir which features an easy to use high level interface, extensibility and safety for using in production.
Presentations
Phoenix
OpenAPI

The OpenAPI Specification (OAS) defines a standard, programming language-agnostic interface description for HTTP APIs, which allows both humans and computers to discover and understand the capabilities of a service without requiring access to source code, additional documentation, or inspection of network traffic.

ExCheck (QuickCheck)

QuickCheck is a testing method (formerly a Haskell library that got adapted to many more languages) that consists of defining expected properties of your program or function, and then testing it extensively against randomly-generated variables automatically. ExCheck is a property-based testing library that resembles QuickCheck.

Project

Check out the project description

Erlang

Useful articles:
Internals:
Useful libraries, dependencies and tools
Some coding guidelines
  • Use rebar3. Include the binary in the repository so it's not an external dependency and the tested version is used. rebar3 is not used directly but through make targets.
  • Support the most recent Erlang version.
  • When building libraries, try to make them both easily usable from the shell and easily configurable via application environment.
  • Indent with two spaces.
  • Avoid using header files (.hrl)
  • Supervised processes provide guarantees in their initialization phase, not a best effort. If you expect failure to happen on an external service, do not make its presence a guarantee of your system.
  • Try to avoid timer:sleep on tests, ktn_task:wait_for_success can be a better option. More on this here.
  • Prefer maps to records.

Exercises

Gleam

Rust

⚠️WIP⚠️

There are now many books on Rust and specific topics within Rust but we consider the following to be of the highest quality/relevance:

Posts:

Other resources:

Exercises

  • Rustlings. To enable rust-analyzer and its features (such as autocomplete and documentation), run this command in the rustlings directory:
rustlings lsp

Exercise - Game of Life

Implement Conway's Game of Life using Rust + Wasm.

We suggest you:

  • Use the macroquad crate
  • Do not follow the tutorial from section 4 of Introduction to Rust+Wasm (read only 4.3 because the rules are better explained there than on Wikipedia)

and here are some sources you might find useful in this journey:

Exercise - Rusty Merkle Tree

Implement a simple Merkle Tree in Rust.

  • A Merkle Tree can be built out of an array.
  • A Merkle Tree can generate a proof that it contains an element.
  • A Merkle Tree can verify that a given hash is contained in it.
  • A Merkle Tree can be dynamic, this means that elements can be added once it is built.

We suggest starting simple, do not optimize prematurely because it's pretty sure that you're not gonna need those optimizations.

Here are some sources that you might find useful:

Julia

Lisp

Although we do not currently use any Lisps at Lambda, we have in the past and there is much to learn from this most venerable family of tools.

Clojure

All distributions are shown on this page, for Mac follow this link.

DevOps and Cloud Environments

AWS and other cloud providers

Amazon Web Services (AWS) is the world’s most comprehensive and broadly adopted cloud platform, offering over 200 fully featured services from data centers globally. Millions of customers—including the fastest-growing startups, largest enterprises, and leading government agencies—are using AWS to lower costs, become more agile, and innovate faster.

AWS tools

  • IAM: It's used for managing users, groups, access policies & roles.
  • EC2: A web service that provides secure, resizable compute capacity in the cloud.
  • AMI: Amazon Machine Images is "An Amazon Machine Image (AMI) provides the information required to launch an instance".
  • ECS: "Amazon Elastic Container Service (Amazon ECS) is a fully managed container orchestration service. Customers such as Duolingo, Samsung, GE, and Cook Pad uses ECS to run their most sensitive and mission-critical applications because of its security, reliability, and scalability." In simpler words, it allows you to launch containers on AWS.

(Optional) To further learn about AWS and its practical uses go here for exercises. These exercises are purely optional and require creating a free tier AWS account, and even then, some of the exercises require a paid account.

Kubernetes

Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.

Functional Programming

Distributed Systems

There are some good books on the general theory and practice of building distributed systems:

  • "Distributed Systems: Concepts and Design" (Colouris)
  • "Distributed Systems Principles and Paradigms" (Tanenbaum)
  • "Introduction to Reliable and Secure Distributed Programming" (Carlos Varela, Cachin)
  • "Distributed Systems for System Architects" (Paulo Veríssimo, Luís Rodrigues)

Some good posts and articles:

Designing Data-Intensive Applications

The book Designing Data-Intensive Applications is an excellent introduction to many topics related to building scalable and fault-tolerant systems. It provides a decent map of the territory and jumping-off points for anyone beginning to understand how systems are architected to provide these characteristics since it provides many references for further reading.

CRDTs

Observability

⚠️WIP⚠️

Performance Engineering

⚠️WIP⚠️

Algorithmics

Data-Oriented Design

Machine Learning

⚠️WIP⚠️

Gaming

⚠️WIP⚠️

General Cryptography

  • crypto101 Crypto 101 is an introductory course on cryptography, freely available for programmers of all ages and skill levels.

Blockchains

Bitcoin

⚠️WIP⚠️

Ethereum

When onboarding to Ethereum-related projects it is important to get a general idea of the high-level components, how they relate, and the general design tradeoffs involved, and then a deeper understanding of some central components. However, understanding everything from the get-go is impossible. Read the Introductory Material, Ecosystem, the selected subsections of the official docs, and the EVM sections. The rest are for reference or reading at your own pace.

Introductory Material

Ecosystem

Official Documentation

This is the official documentation at ethereum.org. Reading through it all in the beginning is not necessary but these highlighted subsections are recommended.

EVM

Account Abstraction

Consensus

Scalability and Rollups

Validium

Provers and zkVMs

zkVMs
SP1

Multi Provers and TEEs

MEV

Based Rollups and Rogue

Ethrex L2 Documentation

Language Engineering

⚠️WIP⚠️

Virtual Machines and Runtimes

Parsing

⚠️WIP⚠️

Hardware

Contributors

(top 30 of 50)

igaray

79 commits

unbalancedparentheses

42 commits

gabrielbosio

38 commits

tvillegas98

26 commits

Similar repos

charlax/professional-programming

A collection of learning resources for curious software engineers

51,566

sdmg15/Best-websites-a-programmer-should-visit

:link: Some useful websites for programmers.

76,260

mtdvio/every-programmer-should-know

A collection of (mostly) technical things every software developer should know about

100,467

kuchin/awesome-cto

A curated and opinionated list of resources for Chief Technology Officers, with the emphasis on…

35,488

fullstack-development/developers-roadmap

How to learn front-end or back-end development

1,223

Dapp-Learning-DAO/Dapp-Learning

Dapp learning project for developers at all stages. Becoming and cultivating sovereign individuals.…

5,834

rebase-network/Dapp-Learning

Dapp learning project for developers at all stages. Becoming and cultivating sovereign individuals.…

5,834

SansGuidon/bookmarks

:warning: Mirrored from https://gitea.zoemp.be/sansguidon/bookmarks ! :bookmark: +5K awesome…

552

lambdaclass/lambdaclass_hacking_learning_path

LambdaClass Hobby Club, hacking learning path handbook. The journey starts here!

481

363 commits

updated Jan 12, 2026

See the code

README

LambdaClass Hacking Learning Path

⚠️ If you are applying to LambdaClass' Engineering Residency you've to complete this learning path ⚠️

Table of Contents

Introduction

⚠️ If you are applying to LambdaClass' Engineering Residency you've to complete this learning path ⚠️

You can choose a life of ease and comfort or you can choose a life of service and adventure. When you're 90, which one of those things do you think you'll be more proud of? - Jeff Bezos

My algorithm has always been: You put smart people together, you give them a lot of freedom, create an atmosphere where everyone talks to everyone else. They're not hiding in the corner with their own little thing. They talk to everybody else. And you provide the best infrastructure. The best computers and so on that people can work with and make everyone partners. - Jim Simons

Top-down management leveraging command-and-control hierarchies are for the mahogany boardrooms of yesteryear. We are navigators, adventurers, and explorers of the future. We are married to the sea - Yearn's Blue Pill

A boring codebase doesn't make a bored developer, on the contrary, it frees developers up to think about important stuff and deliver value to the business. Just as I want my language to be boring so I can focus on interesting stuff, I also want my tech stack to be boring - the interesting bits should be in the value added, not the stuff under that. - HN

Welcome!

If you are reading this, you are probably giving your first -or second- steps on the long journey towards being a good developer, but first try to be a good human being and you will see how far that can get you.

This text is a guide intended to aid employees in their first days at the company, it will guide you in setting up expectations and working tools, and includes a whirlwind tour of the background knowledge necessary to work on the kinds of projects common at LambdaClass. This comprises the first part of the path.

The second part is a repository of selected and categorized reference material, exercises and projects for engineers at any stage.

During the initial onboarding of new employees, the first part must be read (end eventually re-read!) by everyone during this process, while the second part can be read on demand.

Part I The Foundation

Our Worldview and Company Culture

Before tackling the technical challenges ahead of us, we realized that the most important things any institution aspiring to greatness must have are clear and shared values and principles. These characteristics, along with several others, define a company's culture.

In these pages, you will find these principles and values, which are expected of anyone who is part of this institution, whether they are a newcomer or a settled employee, an intern or a manager, and how to solve non-technical problems. LambdaClass is a company with high technical content, but this knowledge must be enhanced by cultural values that allow a fast identification of problems, as well as ways to solve them, based on different learnings and heuristics that many have experienced throughout this journey.

While this document aims to be useful, organized, and verified, it is important to note that knowledge and wisdom must be challenged, evaluated, and modified over time. The ideas in these pages are not set in stone but are constantly being assessed and seeking to be refuted or improved.

c.f. The Hacker Manifesto.

Many of the values we elaborate on stem from a central truth: our work only matters if it can be trusted.

We are part of a global effort to build open, secure, and equitable digital infrastructure—systems that may outlast us and serve people we'll never meet. That reach gives us both influence and responsibility: every decision we make must reflect precision, respect, and honesty.

We work on technologies that manage sensitive data, financial transactions, and trustless environments—tools that are redefining how information, value, and identity are handled worldwide. The choices we make ripple far beyond LambdaClass, directly affecting security, privacy, and access to information.

In the fields of blockchain, cryptography, and decentralized systems, maintaing trust is a foundational and non-negotiable principle. A single careless action can erode confidence not just in one project, but in the entire ecosystem that depends on it.

When we ask people to trust the systems we create, we are also asking them to trust us. That trust is earned only when every member of our team acts with integrity, safeguards information, and approaches their work with professionalism.

When we ask people to trust the systems we create, we are also asking them to trust us. That trust is earned only when every member of our team acts with integrity, safeguards information, and approaches their work with professionalism.

One of Lambda's core goals is the betterment of society via technology, and cryptography (and soon AI) are central to these goals.

Attitude

Attitude is how you feel, think, and what you believe regarding something, in other words, these things determine how you approach it.

Although the points we are going to discuss may seem obvious to someone with experience, most of the people who join us are trainees, meaning they have little or no experience in the development industry. Therefore, it becomes necessary to make these clarifications to ensure that everyone understands what we expect.

At Lambda you'll be surrounded by highly skilled professionals. We focus on building a high-performance team, so everyone here excels at what they do. In fact, being exceptional is the standard, which creates a paradox—because in a sense, no one is truly exceptional. Achieving top grades and finishing your degree on time, being passionate about System Programming or Cryptography, or mastering coding skills may have brought you here, but won’t suffice to ensure that you will continue to be a valuable team member. Everyone must continually prove they deserve to be part of this team.

Please don't interpret this point as an invitation to break rules, procedures, or timelines in the pursuit of excellence. While striving for exceptional performance is encouraged, it must be done within the boundaries of established guidelines. For example, completing the Learning Path in a week doesn't demonstrate mastery — it only shows that you rushed through the content without taking the time to truly absorb it. You won’t gain a deeper understanding by rushing through it. Additionally, we explicitly address the importance of ethical conduct, and cutting corners is never acceptable.

There are three key elements we want you to have present at every moment: Communication, Accountability, and Empathy.

  • Communication is a key aspect of every human relationship. If you can measure your words to give a positive clear message, you can achieve anything in life through teamwork. Try labeling your emotions before communicating, since it is likely that people in front of you do not know what is going through your head. Also, be transparent but assertive if you disagree about something, it will help understand your point of view. Finally, try to avoid direct messages, working on channels allows more people to be in the loop and better feedback can be given.
  • Accountability. Everyone makes mistakes, learners do something about them. If you get something wrong, communicate poorly, or even feel overwhelmed about a situation, raise your hand and say it. It's very likely that a process failed, not you. Many people will be there to help you sort out the issue, and you will surely learn something along the way. If you keep quiet and don't say anything you will regret it later when the truth burst through another hole.
  • About empathy, we are all human beings and have complex emotions, if you are feeling great, it doesn't mean your colleague isn't feeling like shit. Perhaps your coworkers don't feel comfortable talking about emotions, so go talk with them and help them. You can talk to them or their manager if you feel something is going on with them. There is a time when everybody feels weak and needs someone else for support. So be a hero, be empathic.

Also remember our core principles are:

  1. We hire fast, fire faster, promote the fastest.
  2. Adhere to the truth and be transparent
  3. Do what is right for the product.

Ego, Learning to fail, and Your relationship with your own work

Those truly exceptional at Lambda are the least likely to believe they are. You may know how to code, but dealing with your own perception and emotions related is a soft skill that appears more rarely in young developers. Trust is earned over time, skills are learned and perfected over time, outliers in one context may not be so in another, and being an excellent team member and understanding one’s role in an organization is more important than standing out.

Excellency is a habit, and no one is above making mistakes. These two facts together lead to a an important conclusion: in order to be exceptional, it's crucial to learn from your mistakes. This starts with acknowledging them. Making mistakes isn’t the same as failing—pretending they didn’t happen is. Mistakes are an essential part of learning; you can’t grow without them. The next step is communicating them. Your work impacts others, so if you make a mistake, it’s important to acknowledge it. This not only makes it easier for others to help, but it also shows accountability.

On the other hand, self-doubt can also become unhelpful and crippling. We can guarantee that almost everyone at Lambda is constantly asking "how can I be better?" of themselves, but believing you don't belong will eventually lead to making it true.

As with most projects making mistakes fast and loudly will make you learn faster, this is why you must work directly on a repository through Pull Requests rather than workshopping in a draft made elsewhere.

  • Avoid google docs. Work directly with Git, it will help get more eyes on your work to get corrections earlier.
  • Default to git. As said earlier, Git snapshots your work and makes it more accessible to the public, more eyes means more people eager to help you.
  • Avoid asking questions in private chats: asking in the project channel is much better, as the question can be answered by anyone, more voices are heard, others with the same questions may also benefit from the answers, and finally the discussion if worthwhile can be captured as documentation.

Much is said about the Dunning-Kruger Effect and Impostor Syndrome, but the important points can be boiled down to:

  • Keep your ego in check
  • Learn to fail, and learn from mistakes
  • Learn from others and help others in need
  • Listen to feedback and do not worry about evaluating your own performance

Some resources on this topic:

Developing equanimity and focusing on the truth revealed by results is The Lambda Way. You’ll come across more lessons on this throughout your learning path.

Principles for success and teamwork philosophy

We follow a code of conduct designed to ensure a safe team environment. You signed it when you entered Lambda and we expect you to follow it. Basically, treat everyone with respect.

Your relationship with others and work hierarchy

At Lambda we won't micromanage you because we don't want to: we give flexibility but ask for responsibility in exchange. Of course, you can have days off to study, or if you feel sick, but you can also have days off if you feel brain fog, nervous, or a bit under the weather; we actually prefer it that way.

If you feel healthy and comfortable, you will be able to solve more efficiently the problems you have in front of you. And even better, you will contribute to a healthier workspace.

Nobody wants to give up, that's a common emotion. The good news is that you are not giving up, you are getting to know yourself better, so you can recharge your energies and keep learning and improving. In turn, when you are working we expect you to hit goals, be proactive, and be a valuable member of the team.

One of the first thing you’ll learn during your onboarding process is that feedback is our most valuable tool, and the ability to give and receive it is something we continuously develop here at Lambda. One quality we all share as collaborators is the ability to take feedback and act on it. Here, feedback is direct and to the point—we’re transparent and clear. If you’re making a mistake or there’s something to improve, you’ll be told as soon as possible. The same goes for positive feedback: if something stands out, we’ll make sure to highlight it.

For us, feedback isn’t a one-way street. It’s not just top-down from managers to team members—we encourage and value feedback in all directions. Two clarifications are in order:

  1. If you receive an instruction you disagree with, you can express your concerns respectfully, offering your reasoning and suggesting an alternative. However, if your Tech Lead still asks you to proceed with the original directive, you must follow it and continue with the assigned task.
  2. Valuing feedback and continuously seeking to improve processes doesn’t mean you can voice any comment or suggestion that crosses your mind, nor that we will implement everything you propose. It’s important to understand that those in charge have likely already considered the same questions or alternatives.

If something is in place, it's because it was determined to be the most effective solution.

When you enter the workforce, giving feedback, especially negative feedback may be one of the most challenging skills you have to build. Here’s the key: It’s not just about what you say — it’s about how you say it.

  1. Be timely - There is a time and place to express your point of view. So, make sure that you aren't catching anyone off-guard. And, above all, read the room.
  2. Before you launch into feedback, ask permission first. Never launch into unsolicited feedback without checking.
  3. Be prepared - Feedback should be specific. You should be able to explain the problem and how it’s impacting you, your team, or the organization.
  4. Be constructive and solution-oriented - Aim to approach the conversation with a helpful attitude rather than pointing out their flaws. Always couch your feedback as an opportunity to improve performance, or to optimize, or to get better outcomes.
  5. Be respectful and be honest - make sure your tone is assertive but it pays appropriate deference to your lead's authority.

Keep in mind that feedback, regardless of which direction it's going in, is affected by this power dynamic. This is why:

  1. Your own performance has to be solid. In other words, you should consistently prove your competence and deliver valuable outcomes.
  2. You have to know what you are talking about. The quickest way to lose credibility is by presenting unthought-out or half-formed opinions.

References:

Working on client projects

Remember you are employed by Lambda even if you work on a client project. It's commonplace in Lambda to work collaboratively with clients in the development of apps and features, so maybe you will have more day to day rapport with them than with your other Lambda coworkers. If you're in that situation you should always remember a few key things:

  • Your work relation is with Lambda, not with the client so expect to get feedback from your Lambda's Tech Lead and Project Manager and not from the client, don't ask for it either.
  • The relationship between Lambda and the client is managed by the Tech Leads and Project Managers. If someone from the client side makes a request to you personally via DM please contact your Tech Lead and Project Manager about it. Make sure your Teach Lead and Project Manager are in the loop for all relevant information.

Professionalism and Ethics

Just reading this subsection title, you can feel your eyes rolling back into your head. What does an attitude of "hack the planet" have to do with the words "professionalism" and "ethics"?

Well, the lone hacker may be romantic, but great things only come from working together. At Lambda, we foster a youthful, relaxed, and collaborative environment to make sure that we can work together, and because of this professionalism and ethics are non-negotiable, whether you're 18 or 40.

We'll elaborate, but a tl;dr boils down to:

  • Work towards making your environment better than the way you found it. This ranges from cleaning tableware used at the office to helping others with your strengths.
  • Deliver high-quality work and taking ownership of responsibilities.
  • Safeguard confidential information — never share or sell it to competitors. If you're unsure whether something can be disclosed, always check with your manager first.
  • Respecting intellectual property, crediting others' contributions, and protecting confidential information—never sharing or selling it to competitors.
  • Stealing, in any way, is explicitly forbidden and is grounds for immediate dismissal. This include stealing software from other projects, open source or not, without attribution or credit.
  • Times are changing fast, and we always encourage trying out new tools, but at Lambda, using code provided by AI or LLMs is stricly forbidden. You can still use LLMs for other purposes, but copilot-style integrations which write code for you are a net loss, as they are not accountable regarding where they get their inspiration from and do not understand code licensing issues.

As all things, this is learned over time, with experience, and from others. If you are ever in doubt, ask your managers, tech leads, and mentors.

So what is professionalism?

Professional behavior is being considerate, formal and focused. In other words, putting constraints on behavior to enable something else. What exactly? A professional attitude makes you trustworthy and reliable. Clients and colleagues prefer to work with people who are polite and dependable. When you are known as somebody who is reliable, you’re more likely to be given added responsibilities and opportunities, and can make faster progress in your career.

Some of the most professional traits:

  • Self-awareness of your behavior: the most important part of creating a professional reputation is showing you behave well when at work. Every workplace has different rules, guidelines and culture, and may be more or less relaxed, but some tips that are universally applicable are:
    • Be aware of others' personal boundaries.
    • Remain calm and unemotional.
    • Be punctual when coming to work, arriving at meetings or joining calls, to respect other's time.
  • Excellent communication: misunderstandings lead to lost productivity, so a professional always makes the effort to be understood.
  • Honesty: Be open and honest, even during difficult conversations. Being able to confront people directly, rather than share your grievances about them with other people, is important in maintaining a professional attitude.
  • Integrity: Always tell the truth. Personal accountability is owning the outcomes of your decisions, and closely related to honesty and integrity. Although you should try to do your best, everyone makes mistakes. When you do, taking responsibility and offering ways to fix errors and prevent them in the future will help colleagues and supervisors maintain their trust in you.
  • Be respectful to others: treating others with respect and kindness is part of getting your ideas across, regardless of who you are interacting with. You don't have to like everyone, or be liked by everyone, but you do have to treat them well, no matter what their role is. Respecting others also includes supporting them when they need it and being generally helpful, since this furthers the group's goals, not individuals'.
  • Be a dependable team player: Come prepared and plan ahead. Build a reputation as someone who keeps their word and can be trusted to deliver on commitments and deadlines. Failing to follow through can have serious consequences for those who depend on your work. When things don’t go as planned, don’t make excuses—take responsibility, do your best to get tasks back on track, and communicate early if you need additional support or resources.
  • Flexibility: Commitment to your role also means being adaptable when circumstances change. As projects move forward, plans, goals, and requirements may shift, and you are expected to maintain professionalism throughout. At times, this may require adjusting your schedule—such as staying late to ensure a task or deadline is met.
  • Competency and a strong work ethic: Being highly skilled may be the first thing one thinks of a professional. To be dependable one first needs to be capable, so as not to leave others picking up the slack or doing more than their share of the work. Over time, keeping knowledge and skill up to date is also expected of a professional. No amount of highly specialized knowledge will compensate for this. Check your work for any errors before submitting it.

Practices at Lambda

Development processes and workflows

  • There is a weekly call with every member of the team to set the most important goals of the week, as well as a daily call to focus on the problems of the daily tasks.
  • When working on projects, the specific tasks to tackle are written in tickets on Github Projects. Some actual Lambda's projects are working on other project management software, but these are legacy.
  • Chapter 1 of The Manager's Path

Design and coding standards

  • The Basics
  • Suggested reading: Coders at work
  • make is the build tool. Consider these notes.
  • Postgresql is the default database.
  • Write tests.
  • Favor integration tests over unit tests. A project's first tests should be end-to-end smoke and sanity tests, and only after that, if ever, should unit tests be written to test API's, system invariants and help pinpoint bug causes and locations.
  • Do not write tests before you have solved the problem, you may waste time writing tests for the wrong implementation.
  • Write for humans: coding for computers is easy, but writing code that is understandable by another person is an art.
  • Code and document in english unless you have a very specific reason not to.
  • Use meaningful, readable names for variables, functions, and files. Don't try to save characters.
  • Documentation is a sign of the quality of an API. It's easier to write it when the design is right.
  • The less code you have the better. Deleted code is debugged code.
  • Aim for simplicity, not performance. The latter is a by-product of the first.
  • Only introduce optimizations if you have benchmarks that prove an improvement and that the improvement is relevant in the context of the program.
  • Only introduce optimizations if they represent a concrete gain (e.g. cost savings, improved user experience).
  • Follow the Zen of Python, regardless of the language you are using at the moment. English also counts as a language.
  • Don't introduce dependencies prematurely. You must evaluate your requirements, maintenance, and integration costs first.
  • If you want to upgrade a dependency, test it first.
  • Always lock your dependencies. Pin a specific version and a commit of a dependency, don't use the version at master.
  • Use git and commit often, even in one-person projects.
  • In general, avoid pining the patch version of dependencies, more info here.

Working on open-source projects

  • Suggested reading: The Architecture of Open Source Applications.
  • Use MIT or Apache 2.0 license.
  • Fill the description field at the top of the repo page.
  • Write a decent README.
  • A good readme starts with a succinct description (one or two sentences) and, when possible, a very short and illustrative example use. The rest of the details go after this header.
  • Use continuous integration, most likely GitHub Actions.
  • Make a good balance of features vs maintenance. Maintenance details usually matter more than adding a lot of features.

Documentation

Group Readings

Software has over the decades, developed a culture and folklore of its own. As trends fade in and out, older tools and practices give way to newer ones, and flame wars rage one, we gather battle stories, wisdom, quotes, bibles, and memes with which we talk about our craft.

We have selected a few articles and posts we consider especially important to be familiar with, because they align with our values and way of working. To ensure everyone has time to be exposed to this material, we set up discussion groups in which someone volunteers to present some material, and the ensuing debate involving everyone, including more senior members, always results in relating the information to concrete experiences.

In addition to the Hacking Learning Path, new employees must participate in these Readings until they cycle out of the contents. You can see the program here.

However, we encourage everyone to continue to embed themselves in this engineering folklore and to continue studying and gainig new skills. For this reason, once the mandatory readings are done with, we invite them to the Book Club, which votes on what research papers, books, posts, or presentations they will study and debate.

Community projects

We organize activities where we share thoughts and interests with anyone who wants to join us.

Learning Projects

The learning path is not just a pile of material to read through, and there is no exam at the end with questions you need to answer. The point of gaining knowledge is to be able to do more things and apply them in problem solving. The only way to learn how to do this is via practice, and since small exercises can only exercise very specific things, there are a few larger projects throughout the learning path which newcomers are expected to complete. These projects are located in the respective section for their language.

When the time comes to start one of the projects please follow these steps:

  • Create a new github repository under your personal account
  • Setup the project skeleton, which will vary depending on the language and tech stack used for the project. In all cases the skeleton should include:
    • A README.md: Create some initial documentation that explains what the repository contains.
    • A Makefile: a Makefile with standard targets (build, run, test) will allow anyone, regardless of familiarity with the commands specific to your language, to run the project.
    • A code skeleton: even a "hello, world!" program will allow exercising the build, running, and testing targets.
    • CI: Part of learning a language or tool includes knowing how to automate the tasks of ensuring that a code change compiles and passes the tests. Since we host these learning projects on Github, the initial PR should include configuration for Github's Continuous Integration platform Actions to run after each change you commit to a PR.
    • Issues: once you understand the project, create issues for the identifiable parts of the implementation solution.
  • Branches:
    • Immediately create a dev branch, in addition to the main one. Learning projects have two separate phases: the first is active development. During this phase your PRs should branch from dev, and once reviewed by other members of the group following the Hacking Learning Path be merged into dev. Once your MVP has been achieved, and all the base functionality is implemented, create another PR from dev into main with the entirety of the code developed during the first phase. This PR will be reviewed by more senior members. Address any corrections that the may give you, and once this PR is merged into main the project can be considered complete.
    • When tackling an issue, immediately create a branch for it, push it and open a PR in draft mode. Having an open PR that is not yet up to review is a good practice because it allows following the work, and provides a venue for discussion and comments even before a review takes place.
    • At Lambda, repositories are automatically configured to delete branches once corresponding PRs are merged. Since learning projects are done under your user account, you must either configure this yourself or delete branches manually after merging. Allowing stale branches to accumulate is generally considered a bad practice.
    • Another requirement is configuring branch protections for main and dev branches. Your CI must have jobs for ensuring that the code is formatted correctly according to the language's formatter, compiles, and passes tests. Each of these should be a separate job and required for merging a PR.
  • For a PR to be eligible for merging, it must at least:
    • Have a good description of its contained changes.
    • Compile, have no failingg tests and pass all CI checks.
    • Have two approvals from other reviewers.
    • Auto-approving is verboten!

The goal of doing all this for a learning project is to allow reviewers to skip the more basic corrections and address more meaningful corrections, and to make you familiar with the basic expectations and workflow of any project at LambdaClass.

Cryptography

One of Lambda's core goals is the betterment of society via technology, and cryptography (and soon AI) are central to these goals.

Technical Foundations

Development Environment

We use a suite of tools to facilitate many tasks, as well as to enforce our security standards for all employees.

Please refer to our Notion document, which aims to provide a simple overview of all of our tools.

Before beginning with this Journey, if you're a macOS user, you may need some tools or utils for a better experience in your learning path, otherwise, you can skip this section.

  • Two-step authentication is mandatory for every login of the company accounts (e.g. Slack, mail, GitHub).
  • Also, the company's GitHub repositories are accessed via SSH
Homebrew

Homebrew is a package manager for macOS. It is a must on any developer machine.

GNU tools

Once you have installed Homebrew in your macOS system, you'll need to install some of the GNU tools/utilities for a better work experience. Just type in your shell the following command lines:

ASDF version manager
  • asdf is a version manager with the idea purpose of generating environmental variables to choose the specific version desired. Remember that to be able to use the environmental variables you need to set their path for the shell to check, you can see how to do it depending on how you installed asdf here.
Code Editors and IDEs

Do's and don'ts about the use of Vertical Whitespace

  • If you'd like to visualize more vertical whitespace than it's established in these Do's and don'ts configure your text editor to show more space.
  • Most of these rules can be enforced automatically in your text editor, configure it to enforce them.
  • Minimize the use of vertical whitespace.
  • Do not end functions with blank lines.
  • Do not start functions with blank lines.
  • Do not use blank lines when you do not have to.
  • Do not put more than one blank line between functions.
  • Blank lines inside a chain of if-else blocks may well help readability.
  • Blank lines at the beginning or end of a function very rarely help readability.
  • Don't leave blank lines at the end of a file.
  • Don't forget to put a single end of the line at the end of a file.

Software Engineering

Complexity and KISS (Do The Simplest Thing That Could Possibly Work)

"Always implement things when you actually need them, never when you just foresee that you need them" - Ron Jeffries

Strive for solving problems in the simplest way possible. To achieve this, you first need to figure out a handful of ways to confront the issue at hand, and only then pick the one you consider will work in the fewest, tiniest steps. Afterwards, refactor. Tomorrow’s code may need to be more complex, so do everything in your power to facilitate tomorrow’s code as simple as possible. Also, while you shouldn't be blind to the future, avoid investing time and effort into developing features that are not currently necessary and might be a waste.

The Unix Philosophy

Worse is Better

Some questions to guide your learning

  • How does complexity relate to modularity?
  • Why is the text-stream interface important in the Unix Philosophy?
  • Why should design for transparency encourage simple interfaces?
  • How does robustness relate to transparency and simplicity?
  • Even now with video processing, why output of programs should be terse?
  • According to the Unix Philosophy, how noisy do errors have to be?
  • How does the economy of programmer time relate to robustness?
  • Why premature local optimization reduces overall performance?
  • There is the approach of doing things in "one true way", how does it affect extensibility?

Linux

If you've already installed GNU-tools, there's no need to install Linux on a VM.

How to try some commands in MacOS with a VM
  1. There are some commands that don't work in MacOS. If you want to try them, you can use a VM to use Linux. For this, we can use UTM. Follow the next steps here.
  2. After the installation is complete, close the VM and press “Stop selected VM”.
  3. Run the VM again.
  4. Now you can use this VM to run the commands.

Some questions to guide your learning

  • What do the following commands do?:
    • ls -l /bin/usr > ls-output.txt 2>&1
    • ls /bin /usr/bin | sort | uniq | less
    • ls /bin /usr/bin | sort | uniq | grep zip
  • How does Linux determine how to interpret the format of a file?
  • What does the sda2 folder represent?
  • What do /root and /usr/bin store?

Networking and SSH

Some questions to guide your learning

  • How are data transmitted over the Internet?
  • What functions do the layers of the OSI model perform?
  • What is the difference between TCP and UDP?
  • What does ARP mean?
  • What range corresponds to private IP addresses?
  • What does IPv6 propose to solve against IPv4?
  • What does IPsec guarantee?
  • What does DNS mean? How does it work?
  • What is the difference between HTTPS and HTTP?
  • What is the difference between asymmetric and symmetric cryptography?

Version Control, Git, and Github

Git

No one should merge his/her own PR without it being reviewed and approved by a co-worker and/or a client.

Note: commit and push every day. Don't expect something perfect, go for the concrete. In one way or another, you will likely have to iterate later about that work done. Also, since that work isn't only stored on your computer, it won't be lost.

Note on Newlines at end of file It is considered good style - and sometimes a necessity - to always end files with a newline (see here and here). Make sure your editor of choice is correctly configured to add them automatically.

Some questions to guide your learning

  • Why is branching necessary?
  • What is the difference between merge and rebase?
  • What is a stash?
  • What does cherry-pick do?
  • What does reflog do?
  • What does git reset --hard HEAD do?
  • How to get back to a previous commit?
  • How to do a pull request?
  • Why are pull requests important?
  • How to clone a repository using SSH?
GitHub and GitLab

Before you continue on your Git journey and learn how to use git together with GitHub, it is important to learn what an SSH Key (Secure Shell Key) is and how to generate one and add it to your GitHub account. This key will allow you to connect and authenticate to remote servers and services using the SSH protocol. With it, you will be able to connect to GitHub without supplying your username and personal access token each time.

Once you have an SSH key associated with your GitHub account, managing it will become a pain. The most basic next step is learning that instead of entering your SSH passphrase every time you have to authenticate, you can tell your operating system's SSH Agent to remember it for you and provide it.

In addition, you can tell 1password to manage it as well: instructions.

Once your system is configured to use the 1password SSH agent with your key, you can configure your local git client to use the SSH key to sign your commits, ensuring that your authorship of the code is verified. You can find the instructions here.

If you have existing commits that you need to push but have not been signed yet you can run the following command:

git rebase -i --exec "git commit --amend --no-edit -S" main
  • Progress in any project must be pushed every day. This must be done within a branch of the master repository and a Pull Request (PR) must be opened for reviewing the code, previous to merging the branch to master.
  • Doc files should always be added via pull request.
    • Be sure those files are written in Markdown.
    • We always use Mermaid for flowcharts, sequence diagrams, graphs, etc.
  • Never push to master directly, and only reviewers can merge branches to master.

Testing

  • Test-driven Design
  • Unit testing
  • Integration testing
  • Property-based testing
  • Fuzzy Testing

Debugging, GDB, DTrace

Docker

Some questions to guide your learning

  • In which scenarios would you use containers and in which you would prefer to use VMs?
  • How do you retrieve and run the latest Ubuntu image?
  • In a Dockerfile, what is the difference between RUN and CMD?
  • Using port 8080, how do you run an image that exposes port 80?

Continuous Integration and GitHub Actions

SQL and PostgreSQL

Reference:

Some questions to guide your learning

  • How to use a wildcard as a character?
  • What does COALESCE do?
  • What does LIKE 'S%' do in a query?

Redis

Some questions to guide your learning

  • What is the difference between PostgreSQL and Redis?
  • What type of databases are the following? PostgreSQL, Redis, MongoDB, MySQL, HBase, Neo4J, DynamoDB.
  • What makes each database type unique?

Part II Specific Topics

⚠️WIP⚠️

JavaScript

Python

  • HTTP server in Python with Flask
  • Automate the Boring Stuff with Python
    • Chapter 11
  • The Zen of Python is your bible.
  • Use Python 3 in greenfield projects.
  • Strive to migrate to Python 3 in non greenfield projects.
  • Read this to understand environment hell in Python.
  • Use pipenv to escape from environment hell in Python. You can even do this locally in projects that are set up to use virtualenv and virtualenvwrapper.
  • If you also need to stick with a specific minor version of Python (e.g. Python 2.7.14) you can use pyenv in combination with pipenv.

Some questions to guide your learning

  • How do you return how many times a certain character appears in a string using Python?
  • How do you handle different routes for your web app in Flask?
  • Using the logging library, how do you log to a file?

The BEAM Ecosystem

In the beginning, the BEAM and Erlang were almost synonymous, there were no other languages that ran on the BEAM virtual machine and ERTS. In fact the core of the platform is the ERTS -- the Erlang Run Time System. In time, others have emerged such as LFE, Elixir, and Gleam. Today, the most common gateway into the ecosystem is learning how to be productive with Elixir, learning the serial (non-concurrent) and functional programming aspects first, and then the support for concurrency, the common concurrency and distribution patterns provided by the OTP. This is usually eventually complemented by learning Erlang to be able to understand and read code from common dependencies (e.g. Cowboy). Lately, Gleam has also matured and is a very interesting possibility.

Elixir

  • Elixir Homepage
  • Read the entire Getting started section starting at the introduction EXCEPT:
    • "Module attributes"
    • "Protocols"
    • "Sigils"
    • "Writing documentation"
    • "Optional syntax cheatsheet"
    • "Erlang Libraries"

In addition, read:

Other useful resources:

Useful libraries, dependencies and tools
  • GenStage Stages are data-exchange steps that send and/or receive data from other stages. When a stage sends data, it acts as a producer. When it receives data, it acts as a consumer. Stages may take both producer and consumer roles at once, acting as consumer producers.
  • Flow Computational flows with stages.
  • Ecto A toolkit for data mapping and language integrated query.
  • Phoenix Phoenix is a web framework for the Elixir programming language
  • Plug Plug is a specification for composing web applications with functions.
  • Guardian An authentication library for use with Elixir applications.
  • Waffle Waffle is a flexible file upload library for Elixir with straightforward integrations for Amazon S3 and ImageMagick.
  • Samly A SAML 2.0 Service Provider Single-Sign-On Authentication library. This Plug library can be used to SAML enable a Plug/Phoenix application.
  • Broadway Broadway is a library for building concurrent and multi-stage data ingestion and data processing pipelines with Elixir. Broadway pipelines are concurrent and robust, thanks to the Erlang VM and its actors.
  • Propcheck PropCheck is a testing library, that provides a wrapper around PropEr, an Erlang based property testing framework in the spirit of QuickCheck.
  • ExMachina ExMachina makes it easy to create test data and associations. It works great with Ecto, but is configurable to work with any persistence library.
  • Faker Faker is a pure Elixir library for generating fake data.
  • Hammer Hammer is a rate-limiter for Elixir with pluggable storage backends. Hammer enables users to set limits on actions performed within specified time intervals, applying per-user or global limits on API requests, file uploads, and more.
  • Oban Oban is a robust background job framework which uses PostgreSQL, MySQL, or SQLite3 for persistence.
  • Quantum Cron-like job scheduler for Elixir.
  • Sage Sage is a dependency-free implementation of the Sagas pattern in pure Elixir and provides a set of additional built-in features.
  • Recon Recon is a library to be dropped into any other Erlang project, to be used to assist DevOps people diagnose problems in production nodes.
  • Tracer Tracer is a tracing framework for Elixir which features an easy to use high level interface, extensibility and safety for using in production.
Presentations
Phoenix
OpenAPI

The OpenAPI Specification (OAS) defines a standard, programming language-agnostic interface description for HTTP APIs, which allows both humans and computers to discover and understand the capabilities of a service without requiring access to source code, additional documentation, or inspection of network traffic.

ExCheck (QuickCheck)

QuickCheck is a testing method (formerly a Haskell library that got adapted to many more languages) that consists of defining expected properties of your program or function, and then testing it extensively against randomly-generated variables automatically. ExCheck is a property-based testing library that resembles QuickCheck.

Project

Check out the project description

Erlang

Useful articles:
Internals:
Useful libraries, dependencies and tools
Some coding guidelines
  • Use rebar3. Include the binary in the repository so it's not an external dependency and the tested version is used. rebar3 is not used directly but through make targets.
  • Support the most recent Erlang version.
  • When building libraries, try to make them both easily usable from the shell and easily configurable via application environment.
  • Indent with two spaces.
  • Avoid using header files (.hrl)
  • Supervised processes provide guarantees in their initialization phase, not a best effort. If you expect failure to happen on an external service, do not make its presence a guarantee of your system.
  • Try to avoid timer:sleep on tests, ktn_task:wait_for_success can be a better option. More on this here.
  • Prefer maps to records.

Exercises

Gleam

Rust

⚠️WIP⚠️

There are now many books on Rust and specific topics within Rust but we consider the following to be of the highest quality/relevance:

Posts:

Other resources:

Exercises

  • Rustlings. To enable rust-analyzer and its features (such as autocomplete and documentation), run this command in the rustlings directory:
rustlings lsp

Exercise - Game of Life

Implement Conway's Game of Life using Rust + Wasm.

We suggest you:

  • Use the macroquad crate
  • Do not follow the tutorial from section 4 of Introduction to Rust+Wasm (read only 4.3 because the rules are better explained there than on Wikipedia)

and here are some sources you might find useful in this journey:

Exercise - Rusty Merkle Tree

Implement a simple Merkle Tree in Rust.

  • A Merkle Tree can be built out of an array.
  • A Merkle Tree can generate a proof that it contains an element.
  • A Merkle Tree can verify that a given hash is contained in it.
  • A Merkle Tree can be dynamic, this means that elements can be added once it is built.

We suggest starting simple, do not optimize prematurely because it's pretty sure that you're not gonna need those optimizations.

Here are some sources that you might find useful:

Julia

Lisp

Although we do not currently use any Lisps at Lambda, we have in the past and there is much to learn from this most venerable family of tools.

Clojure

All distributions are shown on this page, for Mac follow this link.

DevOps and Cloud Environments

AWS and other cloud providers

Amazon Web Services (AWS) is the world’s most comprehensive and broadly adopted cloud platform, offering over 200 fully featured services from data centers globally. Millions of customers—including the fastest-growing startups, largest enterprises, and leading government agencies—are using AWS to lower costs, become more agile, and innovate faster.

AWS tools

  • IAM: It's used for managing users, groups, access policies & roles.
  • EC2: A web service that provides secure, resizable compute capacity in the cloud.
  • AMI: Amazon Machine Images is "An Amazon Machine Image (AMI) provides the information required to launch an instance".
  • ECS: "Amazon Elastic Container Service (Amazon ECS) is a fully managed container orchestration service. Customers such as Duolingo, Samsung, GE, and Cook Pad uses ECS to run their most sensitive and mission-critical applications because of its security, reliability, and scalability." In simpler words, it allows you to launch containers on AWS.

(Optional) To further learn about AWS and its practical uses go here for exercises. These exercises are purely optional and require creating a free tier AWS account, and even then, some of the exercises require a paid account.

Kubernetes

Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.

Functional Programming

Distributed Systems

There are some good books on the general theory and practice of building distributed systems:

  • "Distributed Systems: Concepts and Design" (Colouris)
  • "Distributed Systems Principles and Paradigms" (Tanenbaum)
  • "Introduction to Reliable and Secure Distributed Programming" (Carlos Varela, Cachin)
  • "Distributed Systems for System Architects" (Paulo Veríssimo, Luís Rodrigues)

Some good posts and articles:

Designing Data-Intensive Applications

The book Designing Data-Intensive Applications is an excellent introduction to many topics related to building scalable and fault-tolerant systems. It provides a decent map of the territory and jumping-off points for anyone beginning to understand how systems are architected to provide these characteristics since it provides many references for further reading.

CRDTs

Observability

⚠️WIP⚠️

Performance Engineering

⚠️WIP⚠️

Algorithmics

Data-Oriented Design

Machine Learning

⚠️WIP⚠️

Gaming

⚠️WIP⚠️

General Cryptography

  • crypto101 Crypto 101 is an introductory course on cryptography, freely available for programmers of all ages and skill levels.

Blockchains

Bitcoin

⚠️WIP⚠️

Ethereum

When onboarding to Ethereum-related projects it is important to get a general idea of the high-level components, how they relate, and the general design tradeoffs involved, and then a deeper understanding of some central components. However, understanding everything from the get-go is impossible. Read the Introductory Material, Ecosystem, the selected subsections of the official docs, and the EVM sections. The rest are for reference or reading at your own pace.

Introductory Material

Ecosystem

Official Documentation

This is the official documentation at ethereum.org. Reading through it all in the beginning is not necessary but these highlighted subsections are recommended.

EVM

Account Abstraction

Consensus

Scalability and Rollups

Validium

Provers and zkVMs

zkVMs
SP1

Multi Provers and TEEs

MEV

Based Rollups and Rogue

Ethrex L2 Documentation

Language Engineering

⚠️WIP⚠️

Virtual Machines and Runtimes

Parsing

⚠️WIP⚠️

Hardware

Similar repos

charlax/professional-programming

A collection of learning resources for curious software engineers

51,566

sdmg15/Best-websites-a-programmer-should-visit

:link: Some useful websites for programmers.

76,260

mtdvio/every-programmer-should-know

A collection of (mostly) technical things every software developer should know about

100,467

kuchin/awesome-cto

A curated and opinionated list of resources for Chief Technology Officers, with the emphasis on…

35,488

fullstack-development/developers-roadmap

How to learn front-end or back-end development

1,223

Dapp-Learning-DAO/Dapp-Learning

Dapp learning project for developers at all stages. Becoming and cultivating sovereign individuals.…

5,834

rebase-network/Dapp-Learning

Dapp learning project for developers at all stages. Becoming and cultivating sovereign individuals.…

5,834

SansGuidon/bookmarks

:warning: Mirrored from https://gitea.zoemp.be/sansguidon/bookmarks ! :bookmark: +5K awesome…

552

Contributors

(top 30 of 50)

igaray

79 commits

unbalancedparentheses

42 commits

gabrielbosio

38 commits

tvillegas98

26 commits