Welcome! This is a guide intended to aid employees in their first days in the company.
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
"With great power, comes great responsibility" probably Uncle Ben, but who knows
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 are 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 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.
There are three key elements we want you to have present at every moment: Communication, Accountability and Empathy.
- Communication is a key aspect for 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 on 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 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 to 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.
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.
We follow a code of conduct that must be followed to ensure a safe space in the team. You signed it when you entered Lambda and we expect you to follow it. Basically, treat everyone with respect.
- Principles for succes by Ray Dalio.
- Charity Majors - The Sociotechnical Path to High-Performing Teams.
Note: Reading order is from top to bottom.
This section is meant to guide you during your learning period.
Estimate time: 53-57 hours
Estimate reading time: 4-5 hours
- The Linux Command Line
- Chapters [1-7], [9-10], 14, [16-17]
- Linux Basics for Hackers
- Chapters [8-10]
Estimate reading time: 2 hours
Reference:
Estimate reading time: 2-3 hours
Estimate reading time: 3-4 hours
- Datacamp Python Fundamentals
- HTTP server in Python with Flask
- Automate the Boring Stuff with Python
- Chapter 11
Estimate reading time: 5-6 hours
- How the Internet Really Works
- Chapters [2-5]
- Practical Packet Analysis with Wireshark
- Chapters 1, [3-4], [6-8]
- Burp
Estimate reading time: 7-8 hours
- Introduction to GitHub
- Learning Git Branching
- Pro Git
- Pages [10-106]
- Git Exercises
- The Git Parable
- How to write a Git Commit message
- Merging vs Rebasing
Estimate reading time: 5-6 hours
a.k.a "The way we do things around here"
- Antifragile: Things That Gain from Disorder
- Chapters 1, 15
- Data science in Julia for hackers
- Chapter 1
- How to Make Your Code Reviewer Fall in Love with You
Estimate reading time: 9-10 hours
- SQL: Practical Guide for Developers
- Chapters [10-11]
- SQL Bolt
- Mystery solver with SQL
- Seven Databases in Seven Weeks
- Introduction, chapters 2 and 8
- An introduction to Redis data types and abstractions
- Redis Transactions
Reference:
Estimate reading time: 2-3 hours
Estimate reading time: 1 hour
- The Manager's Path
- Chapter 1
Estimate reading time: 2 hours
Estimate reading time: 15 minutes
- Join the reading club
Estimate time: 46-56 hours (assuming you read either 'Elixir in Action' or 'Phoenix in Action')
Estimate reading time: 1-2 hours
Estimate reading time: 4-5 hours
Reference:
Estimate reading time: 40 hours
Estimate reading time: 40 hours
- Phoenix in Action
- All chapters except 2 and 12
- Phoenix Chat Example
Estimate reading time: 1-2 hours
Estimate time: 6-7 hours The idea is to apply everything learned.
Estimate reading time: 7-8 hours
- A half-hour to learn Rust
- I am a Java, C#, C or C++ developer, time to do some Rust
- Three Kinds of Polymorphism in Rust
- Learning Rust
- 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
- If you are new to GitHub, you can put your hands on with this course
- 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.
- Never push to master directly, and only reviewers can merge branches to master.
- 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 clickup.
- 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, but do write unit tests when the functions merit them.
- Do not write tests before you have solved the problem, you may waste time writing tests for the wrong implementation.
- Start with the simplest thing that could possibly work.
- Don't try to foresee future uses of your program: You aren't gonna need it.
- 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 no 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 proof 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.
- Suggested reading: The Architecture of Open Source Applications.
- Use MIT license.
- Fill the description field at the top of the repo page.
- Write a decent README.
- A good readme starts with a succint 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 travis.org.
- Make a good balance of features vs maintenance. Maintenance details usually matter more than adding a lot of features.
We organize activities where we share thoughts and interests with anyone who want to join us.
- BuzzConf A conference for developers, by developers. Past talks here.
- Zruput Digital Communications Conference.
- This is not a monad tutorial Writings, reviews and interviews about programming.
- Papers We Love Buenos Aires Once a month we organize a meeting where we discuss scientific papers we love. Join us on Telegram.
- 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.
- Julia Koans that will give you some short but effective understanding.
- Julia Academy for getting your hands dirty with some great tutorials.
- Read the book Learn you some Erlang for great good! if you want to learn some Erlang.
- 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) [TODO ELABORATE].
- 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.
This is a list of interesting projects to read code and learn:
Some of us at Lambda have formed a reading club, where we propose, vote, select, read, and discuss books, papers, posts, videos, or any material we feel is interesting or advances our skills as developers and humans.
Please visit the following document for adding reading suggestions:
The group gathers on Tuesdays at 17:00. Ping someone to get added to the calendar event.
A Pipeline Made of Airbags
Fred Hebert https://ferd.ca/a-pipeline-made-of-airbags.html
Complexity Has to Live Somewhere
Fred Hebert https://ferd.ca/complexity-has-to-live-somewhere.html
The Mythical Man-Month + The Tar Pit
Frederick Brooks We read the first 2 chapters.
You can Change Your Organization or Change Your Organization
James Shore
We read all the entries from this autobiographic diary about how to tackle organizational change.
https://www.jamesshore.com/v2/projects/change-diary
Understanding, detecting and localizing partial failures in large system software
(Talk & PDF) The Morning Paper's post about the paper
Designing Data-Intensive Applications
Martin Kleppmann We discussed every chapter of the book.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent
