mirror of
https://github.com/theoludwig/theoludwig.git
synced 2024-11-05 04:51:30 +01:00
45 lines
2.3 KiB
Plaintext
45 lines
2.3 KiB
Plaintext
|
---
|
||
|
|
title: '❌ Mistakes I made as a junior developer'
|
||
|
|
description: 'Here are mistakes I made when I started, to prevent you from making the same mistakes.'
|
||
|
|
isPublished: false
|
||
|
|
publishedOn: '2021-12-06T22:06:33.818Z'
|
||
|
|
---
|
||
|
|
|
||
|
|
Hello! 👋
|
||
|
|
|
||
|
|
I will explain some of my mistakes I made as a junior developer, so you can avoid doing them.
|
||
|
|
|
||
|
|
## 1. Skipped learning how to do automated tests
|
||
|
|
|
||
|
|
Probably one of the most common error junior developers do.
|
||
|
|
|
||
|
|
When you begin in programming, you learn a programming language, so you learn variables, conditions, loops, functions, etc.
|
||
|
|
|
||
|
|
With these concepts, you might start a new project, thinking that you will be able to do everything.
|
||
|
|
|
||
|
|
But as the project grows, you will end up using functions at multiple places in code, so if you change the behavior of a function, it will affect the whole project.
|
||
|
|
|
||
|
|
And because the code grows, you might do some refactoring, but because we are humans, we make mistakes, you could accidentally break the whole project even with a tiny change you thought was safe to do.
|
||
|
|
|
||
|
|
If you would have automated tests, you would have a way to know if you made a mistake even before deploying to production.
|
||
|
|
|
||
|
|
Depending on the programming language you are using, and what is the project you are working on, writing tests will be different.
|
||
|
|
|
||
|
|
Be aware that there are 3 main testing strategy:
|
||
|
|
|
||
|
|
- [Unit testing](https://en.wikipedia.org/wiki/Unit_testing)
|
||
|
|
- [Integration testing](https://en.wikipedia.org/wiki/Integration_testing)
|
||
|
|
- [End-to-end testing](https://en.wikipedia.org/wiki/End-to-end_testing)
|
||
|
|
|
||
|
|
After you learnt the basic of programming, learn how to write automated tests, it will save you a lot of time and debugging.
|
||
|
|
|
||
|
|
## 2. Thinking too big, with too much abstraction
|
||
|
|
|
||
|
|
Abstraction is great, but it can be harder to understand what is going on if actally don't need this abstraction.
|
||
|
|
|
||
|
|
Find the right balance, between abstraction and implementation, start simple, and then gradually improve and add more features.
|
||
|
|
|
||
|
|
When you start a new project, you should focus on the core of the project, not on the details, to release as soon as possible, a working usable version of your project also called a [**Minimum Viable Product** (MVP)](https://en.wikipedia.org/wiki/Minimum_viable_product).
|
||
|
|
|
||
|
|
## 3. Focusing on the thing that don't add value to a project
|