The developer's way
Hey! I hope you have a nice day 🙂 I want to share some thoughts that help me to enjoy my daily life as a developer.
Imposter syndrome
It is a psychological pattern in which an individual doubts their skills, talents or accomplishments -- Wikipedia
The amount of what "we don't know" and "don't know what we don't know" to be a developer is massive. We often feel like a fraud knowing nothing at all. With this point of view, any accomplishment or success are attributed to others or luck because if you are doing things right without knowing its just "luck", right?
The software space is evolving at a fast pace so it's impossible to keep it up and know everything. What do you think you are missing to be a better developer? Hard skills? Soft skills? Pieces of knowledge?
If you know what, it's fantastic! You can go to the learn chapter.
Reminders :
- Not knowing is ok
- You can ask for help
- Tell yourself everyone deals with this (you are not alone)
The Dunning-Kruger effect
It is a cognitive bias where people who perform poorly on a certain task tend to overestimate their own performance -- Wikipedia
It's the reverse of imposter syndrome. It happens when we know a little bit of something and be overconfident. Having some successes can lead us to think you know some secret weapon to defeat all projects easily.
When you feel confident on a topic, share what you know! If people recognise you, you can be a legitimate expert. If you realize you are not an expert and accept it, you can pass the Dunning-Kruger effect.
Reminders :
- The ego can get in the way
- Share what you think can help
- Being an expert is a long pathway
Inspirations for this chapter :
Learn
Learning is the process of acquiring new understanding, knowledge, behaviours, skills, values, attitudes, and preferences. -- Wikipedia
Some people will grasp it just with a visual picture and others just by reading a book. When it's time to learn we have to find the more effective way. Do you know your preferred learning style?
Learning styles
Visual. if you are a visual learner you can watch live coding exercises, slides, diagrams, maps, sketches. I like simple and concise diagrams from Lucca Rossi.
Aural. if you are an aural learner you can follow podcasts, lecture format learning, read out loud. Find some podcast or youtube channel and focus on listening.
Print. if you are a print learner you can write a lot of notes or blog on the topic. Brain dump all your ideas somewhere (in your phone?) and take time to write on it later.
Tactile. if you are a tactile learner, you learn it by doing it. Exercise with a code kata, tutorial step by step or create a pet project. Exercise can be found at Code Kata
Interactive. if you are an Interactive learner, you can participate in hands-on workshop and discussions, brainstorming, Q&A sessions on the topics. It's typical activities of communities on Meetup.com.
Kinesthetic. if you are a kinesthetic learner, your learning is connected with your emotion and body. Engage in debate, try an exciting experiment, try to work out and learn at the same time.
Reminders :
- We are multiple styles learner
- Try to learn one thing at a time
- Have breaks, when doing nothing you infuse your learning.
Inspirations for this chapter :
Experiment
Disclaimer: remember the Dunning-Kruger effect? I think I only scratch the surface of how to conduct an experiment. You can have good insights with John Cutlefish.
Have you ever think how to design and conduct an experiment?
For example, in software development experiment often emerge from retrospective, the team reflect on past events and suggest an action in order to be a better version of themself.
It goes the same way for a product. We study the user behaviour, get feedback on what should change and explore new ways to satisfy our users.
Design your experiment
Experimentations should have a timebox and a measurable goal otherwise we can not confirm or infirm it.
I often use an empirical experiment, I call it the "self+1+n" approach. I start by experimenting alone. If I see a positive result I redo it with someone. If it works well I suggest an experiment with my team. It can be long but if I can't convince myself, I will find it hard to convince someone or my team to run an experiment.
John gives us some thoughts :
Example
Let's make an assumption: "Limit our work in progress, will reduce the cognitive load of our team and make us faster"
The design metrics :
- My level of tiredness at the end of the day. (1-exhausted, 5-i'm fine)
- Number of tasks done & Business value-added
The scope and timebox :
- It starts with a limit of 5 work in progress for one week.
- then with a limit of 3 work in progress for one week
- then with a limit of 1 work in progress for one week.
Reminders :
- Infirming is as important as confirming
- Start with small experimentation
- Mind the sunk cost fallacy, stop an experiment can be the right decision.
Enjoy it
It makes me think of the second ideal of Gene Kim's Five ideals.
THE SECOND IDEAL: FOCUS, FLOW, AND JOY The Second Ideal is all about how our daily work feels. Is our work marked by boredom and waiting for other people to get things done on our behalf? Do we blindly work on small pieces of the whole, only seeing the outcomes of our work during deployment when everything blows up, leading to firefighting, punishment, and burnout? Or do we work in small batches, ideally single-piece flow, getting fast and continual feedback on our work? These are the conditions that allow for focus and flow, challenge, learning, discovery, mastering our domain, and even joy. This is what being a developer means. -- Gene Kim
Nobody love burn-out / bore-out / brown-out, to find some satisfaction we need to evolve between them by not accepting an impossible/unclear task, not laying too long in our comfort zone and staying energized by what we do.
It's not that simple because the company culture is an important factor in this equation. One of the most remarkable actions I can control is to choose who I want to work with and try to be the co-worker I want to work with.
What you enjoy as a developer is really personal, here my main source of satisfaction :
(re)Write quality software step by step.
Deploy often.
Get feedback.
Because writing software that can change easily and be deploy make me feel safe for the future.
Find people I want to work with.
Grow together to become a great team.
Try, fail and succeed.
Retry.
Because build software is like a team sport and I want to be in a great team.
Finishing days with a high-energy level.
Enjoy my free time after.
Because I wish I can do it in the long term.
Gratitude.
Because gratitude disrupts frustration.
Reminders:
- You can only change yourself
- Mind symptoms of Burn/Bore/Brown-out
- Taking a decision and commit to it is key
Inspiration for this chapter :
- The-eight-factors-of-happiness-for-developers/
- gratitude-and-a-growth-mindset-the-key-ingredients-to-a-successful-agile-retrospective
Thanks for reading!