Here is another highly recommended(controversial) and eye-opening presentation that can help you get better at coding.
https://www.infoq.com/presentations/7-ineffective-coding-habits/
I’m leaving here just 2 screenshots that were important to me and that I identify with them.
1. About Comments
2. About TDD
Also I like the phrase, “OOP Assembly”… that is we write procedural code in OOP
You won’t always be on top of your game, it is then when your Team’s spirit come into play.
– It is possible to always come up with the best solution
– It is possible to always use the best Design Pattern (or even to know it)
– to use the best/simplest API
– You won’t be always up to date with the latest Library/Technology
Sometimes you will be in doubt, or even stuck, you won’t like the solution you produce
you will not have the inspiration, or the knowledge
THAT IS WHY
– we work in a TEAM
– we have code reviews
– we ask for help/opinions
– it takes a TEAM to produce a project
That is WHY we work in a Team and you should trust your team
you should FEEL SAFE to ask for help and ask for feedback
It is impossible to get everything right, to know and to understand everything, and to always use the right solution
In the last couple of months I have beaten myself into learning a lot, shoving/forcing a lot of courses into my brain,
because I didn’t feel good enough, I didn’t feel worthy
It is better to use the correct approach to producing software,
– Yes, you should have a good knowledge, a very strong technical knowledge
{ you should know patterns, you should know what the language can do for you
you should have the correct mental model about how things work
}
– But equally important is your Methodology/your approach to writing code
– you should really care about the code you’re about to write and really understand the requirements and it’s intent
– you should aim to produce the (‘perfect’)/Clean code, TDD, Testable, SOLID, DRY
– you should feel like you’re part of a team, working in a team, and ask for code reviews,
– you should feel safe in your team and should be ok asking for help and asking ‘stupid questions’
– you will not always be on top of your technical challenge, sometimes you will need help
Into Java 