Working the right way, by knowing all the wrong ways
Download as PPTX, PDF0 likes219 views
The talk emphasizes that mistakes are a normal and essential part of the development process, encouraging a mindset of continuous improvement. It advocates for clear communication, embracing imperfection, and taking responsibility for one's work, while also stressing the importance of good coding practices and organization. Additionally, it highlights the collaborative nature of software development and the need for mutual support among team members.
Working the right way, by knowing all the wrong ways
- 1. Working the right way, by knowing all the wrong ways Boyan Djumakov @djumaka
- 2. The purpose of this talk
- 3. The purpose ■ To show you that mistakes are normal. ■ To show you that mistakes are essential ■ To show you that you make the same mistakes.
- 4. The purpose ■ Improvement through errors ■ There is no right way! ■ Even machines work, by identifying the unacceptable states.
- 5. Roadmap ■ The reasoning ■ The Philosophy ■ The Toolset ■ It’s all about the code ■ The professional schizophrenia
- 6. Who am I
- 7. Who am I ■ A father ■ A bad developer ■ An even worst team lead ■ Constantly bored person ■ Constantly lazy person
- 8. Why do we need to work the right way?
- 9. The right way ■ Writing code is an art ■ Writing code is a craft ■ The habits and “feeling” for good work
- 10. Why bother if “it works anyways”?
- 11. The philosophy
- 12. You are half the reason for all the problems in your company
- 13. Open environment ■ You can help the others imrpove ■ Others WILL help you improve ■ You can’t see all the mistakes, that you make ■ Share your thoughts out loud. Telepathy is a fiction.
- 14. The “Are we there yet” driven development
- 15. “Are we there yet” ■ Report regularly and clearly. ■ Think for the other non-tech members of the crew. ■ They will twist the system, to get the info!
- 17. Embrace imperfection ■ You want to work hard ■ You’re not perfect ■ You have bad habits ■ Create a healthy daily routine ■ An example of how the kitchen kills it all
- 18. Be frank with yourself and your goals
- 19. The time may have not come yet?
- 20. The negative feedback and the cost of a compromise
- 21. The toolset
- 22. For Christ’s sake, Improve your language!
- 24. You don’t need an excuse not to work - You don’t need a reason to work
- 25. Lazines and scatterbrain as a way of life
- 27. ■ You’re not always the one with the good idea ■ You’re not better than the others ■ The era of “your framework” is gone Don’t feed your ego
- 28. ■ Respect yourself and the others ■ Clean and neat code ■ Dirty fixes are disgrace but sometimes it’s OK ■ Don’t promise, just because somebody needs it. They took you for quality! Respect
- 29. ■ It’s your project ■ It’s your promise ■ It’s your code ■ It’s not a “hit and run” job. You have to support it. Be responsible
- 30. ■ Be confident about what you do ■ Organize things to guarantee stable flow ■ You can debug better if you know, that “this works!” Be solid
- 31. Don’t blindly follow the fassion!
- 33. ■ JIRA is for tasks, not for showing off how good you are! ■ IDE vs Editor - Noone cares ■ How quickly do you do code refactoring? ■ Are you so proud that you know the project by heart? ■ Don’t remember! Recreate! Know your tools
- 34. Overthinking "Premature optimization is the root of all evil." Donald Knuth
- 35. Always estimate your work
- 36. It’s all about the code
- 37. ■ The code is for logic, not for data ■ The code should tell a story ■ Apply Code style. Any! ■ Do Code Reviews! Do them immediately! ■ Refactor like crazy! Embrace imperfection! The Code
- 38. Handle errors ● Don’t overlook errors ● Empty “catch” is not a solution ● Log everything, help your future self.
- 40. Don’t be stubborn on development. - We’re just a means to solve a problem!
- 41. A manager for a day ● Helps you know when info is scarce ● Know if details were missed or they can’t be defined ● Know if you’re on a “poor” task or you’re prototyping.
- 42. Walk in the QA shoes!
- 43. Walk in the QA shoes ● The fact that there is a separate QA team, indicates that "you don't care", leading you away from craftsmanship. ● QA team just helps you with an extra POV ● Some companies deliver to production within the working day ?!?!?!
- 44. Lifehacks
- 45. Rest until you’re bored to death
- 46. Reorganize your day to develop better habbits
- 47. Always be with the feeling, that someone else is better and you have to catch up.
- 48. Never meet your Gods!
- 49. ● Read the medium or dev.to ● Read “The clean code” ● Read “Refactoring”
- 50. QA
Editor's Notes
- #3: An introduction to the opennes about mistakes.
- #5: Example of the line-tracking robots
- #8: Example of the line-tracking robots
- #10: Example of the line-tracking robots
- #17: Organize things around your perks, don’t fight them
- #19: Don't aim to get a senior software architect unless you are ready to deal with several technological stacks at the same time, write stupid product specs and write no code for months. Know what you want - it is ok to change your goals.
- #21: Compromises are only useful if it is one-time and on the right spot. Otherwise you rob them from the precious resource for improvement - the bad example.
- #36: Пример с Пресли/Траян и как естимейтите те карат да помислиш
- #38: Code Style saved a lot of GIT log review time * Refactoring is natural * Refactoring clarity
- #47: Примера от по-горе с кухнята