3 Non-obvious Skills for Programmers
In this video I'm sharing 3 skills that I believe are not appreciated enough among programmers and which can help a lot in becoming a better developer
In this video I'm sharing 3 skills that I believe are not appreciated enough among programmers and which can help a lot in becoming a better developer:
- good memory
- attention to details
- thinking a few steps ahead
Contact:
✉️ email - gregory@notonlycode.org
🐦 Twitter - @GregoryWitek
📚 Resources
- https://www.hive.co.uk/Product/Joshua-Foer/Moonwalking-with-Einstein--The-Art-and-Science-of-Remembering-Everything/11234581 - "Moonwalking with Einstein - a very interesting book which proves that memory can be trained, and a fun story to read
- https://www.apa.org/science/about/psa/2016/06/learning-memory
- https://www.health.harvard.edu/aging/4-tricks-to-rev-up-your-memory
- https://www.health.harvard.edu/mind-and-mood/regular-exercise-adds-up-to-big-memory-boosts
Notes
Intro
- good memory, attention to details, long-term vision
- 3 things that helped me become a much better programmer
- also curiosity, and writing, and... ok, let's stop at 3 today
- now they also help me to become better manager
Good memory
- I was told memory is not necessary anymore
- memory has a rather bad reputation
- it is related to memorizing, which we all had to do at school and what most of us hated
- as a kid I was told that computers will let us find anything, so good memory is overrated
- Google does not replace memory
- you don't need to memorize all the standard library functions in PHP, remembering the ones you use regularly is enough
- finding something online takes time
- it's not a lot of time
- bet repeated many times might be a lot of time
- sometimes there's no time to search
- during meetings or other conversations
- good memory helps besides coding
- remembering names of people in your company (and how to pronounce them correctly)
- it helps building relations
- remembering past decisions and reasons behind them
- you don't need to remember everything
- remembering algorithms is absolutely useless except for interviewing at companies which rely on remembering algorithms
- you can write stuff down (I take a lot of notes and try to go back to them in the future)
- use git commit messages and documentation to write down notes about the code
Practice
- practicing recall technique
- make notes, review the notes, recall the notes
- learning things that will be used
- e.g. learn and practice a new spoken language
- it's like a muscle, the more you practice, the easier it gets to remember new things
Attention to details
- I think this is one of the things that separate average developers from good developers
- good developers immediately notice things that others miss
- the reason is that in programming even one character, one typo can break everything
- of course there are tests etc, but attention to detail goes way beyond that
- thinking of edge cases is attention to detail
- good developers ask questions like "and what happens when ... ?"
- paying attention to user experience before implementation helps in reducing the time to getting feature done
Thinking ahead
- maybe the most important on the list
- especially important for lead devs and up, but helpful on every level
- often when I see some code that does not look good, I want to change it
- but then I don't have time to do that at once
- so what I do is imagine how this code would look like if I had more time
- then I imagine how to get these
- and then I implement first step and over time I get to the state that I'm happy with
- this helps also with planning projects
- also with strategy for future development
- the questions to ask are
- where do we want to be
- how do we get there one step at a time
- example: I want to move our front-end from Angular to React
- we might use micro front-ends approach
- we might rewrite it all at once
- we might run both apps together and add a layer of communication between them
- each of these will take weeks if not months
- so we need to know what is our goal and define steps to get there
- the same might apply on a lower level
- I have 10 classes that look almost the same
- today I'll extract common part and I'll move 2 out of 10 classes to use the common class
- later I'll be moving remaining classes whenever I have a chance