| marp | true |
|---|---|
| theme | gaia |
| <!-- size | 4:3 --> |
| <!-- width | 1920 --> |
| <!-- height | 1080 --> |
<style scoped> { background-color: #3b86cb; } a { color: white } </style>
Steve Jobs
<style scoped> { background-color: #3b86cb; } a { color: white } </style>
Code for now, not for the future. Refactor often.
<style scoped> { background-color: #3b86cb; } a { color: white } </style>
!= WET :
Write Everything Twice
<style scoped> { background-color: #3b86cb; } a { color: white } </style>
by Mihály Csíkszentmihályi
<style scoped> { background-color: #3b86cb; } a { color: white } </style>
TODO ;)
- OK to fail
"Die and retry"➡️ Code and refactor
- Decompose into micro actions
- Github issues + tags ("easy", "good first issue", etc.)
- Start just for 5 minutes
- identify easy issue
- fix it to get the ball rolling
- Adjust skills and difficulty to stay in the zone
<style scoped> { background-color: #3b86cb; } a { color: white } </style>
<style scoped> { background-color: #3b86cb; } a { color: white } </style>
<style scoped> { background-color: #3b86cb; } a { color: white } </style>
<style scoped> table { height: 80%; width: 100%; } th { background-color: #3b86cb; } </style>
| SUBJECTIVE | OBJECTIVE |
|---|---|
| EFFICIENT: FAST, ERROR PROOF | |
| SIMPLE | |
| PRECISE |
- button 🎹
- door knob 🚪
- hammer 🔨
- user guesses right
_04.png)
-
action continuity
-
smoother experience (TWEEN / lerp)
-
user satisfaction 🤩
- reward mechanism
-
⚠️ avoid bad juice- distracting, unexpected
- How long does the user take to reach the target?
- How many mistakes are made before succeeding at a task?
- How accurate is the result vs a reference?
<style scoped> { background-color: #3b86cb; } a { color: white } </style>
- Builder, Observer, State can be interesting
⚠️ avoid Singletons!- adapt the pattern to your code, don't use as-is!
Entity Component System
<style scoped> { background-color: #3b86cb; } a { color: white } </style>
- document the "why?"
- at high-level
- if needed
- avoid documentation altogether
- write tests, examples, tutorials instead
- write code as documentation
- BAD ❌
const float a = 9.81; //gravitational force
float b = 5; //time in seconds
float c = (1/2)*a*(b^2) //multiply the time and gravity together to get displacement.- GOOD ✅
float computeDisplacement(float time_s) {
const float g = 9.81;
float displacement = (1 / 2) * g * (time_s ^ 2);
return displacement;
}
- "What is this object? What does it do?"
- Object, variable ➡️ noun
user,accountNumber,customerEmail
- Function, method ➡️ verb
user.login(),shutDown()
- Boolean ➡️ adjective
allowed,disableduser.active()❌user.isActive()✅
- convey intention
var d // elapsed time in days❌ vsvar elapsedTime_days✅ - name arguments too!
void copyChars(char a1[], char a2[])❌void copyChars(char source[], char destination[])✅ - pronunciation (avoid abbreviations)
genymdms❌ vsgenerationTimestamp✅ - no magic numbers (keep your code searchable and maintainable)
s / 5❌ vstask / WORK_DAYS_PER_WEEK✅ - use camelCase
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
Martin Fowler
<style scoped> { background-color: #3b86cb; } * { color: white } </style>