Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Working the right way, by knowing all the wrong ways


Published on

Software development is a strange mixture of work and art. We do not only write code, but we make art as writers create their masterpieces. Your habits reflect on your daily work and shape how you approach new tasks. The main problem of bad habits, aside of wasting your time and lowering your motivation, is that rather often you don’t even know about them. I will talk about bad habits by sharing with you all of the bad practices that I remember from my past and current projects. I will talk about what helps me write better, what motivates me and what prevents me from doing so. I will tell you how I started with Delphi, PHP and JAVA, how I hated JavaScript and how I love it now. We will even briefly talk about DevOPS and how I had to develop a torrent client in Python. I’ll share how I manage to learn new things, despite my uncanny laziness for reading.

Published in: Software
  • Login to see the comments

  • Be the first to like this

Working the right way, by knowing all the wrong ways

  1. 1. Working the right way, by knowing all the wrong ways Boyan Djumakov @djumaka
  2. 2. The purpose of this talk
  3. 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. 4. The purpose ■ Improvement through errors ■ There is no right way! ■ Even machines work, by identifying the unacceptable states.
  5. 5. Roadmap ■ The reasoning ■ The Philosophy ■ The Toolset ■ It’s all about the code ■ The professional schizophrenia
  6. 6. Who am I
  7. 7. Who am I ■ A father ■ A bad developer ■ An even worst team lead ■ Constantly bored person ■ Constantly lazy person
  8. 8. Why do we need to work the right way?
  9. 9. The right way ■ Writing code is an art ■ Writing code is a craft ■ The habits and “feeling” for good work
  10. 10. Why bother if “it works anyways”?
  11. 11. The philosophy
  12. 12. You are half the reason for all the problems in your company
  13. 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. 14. The “Are we there yet” driven development
  15. 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!
  16. 16. Embrace imperfection
  17. 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. 18. Be frank with yourself and your goals
  19. 19. The time may have not come yet?
  20. 20. The negative feedback and the cost of a compromise
  21. 21. The toolset
  22. 22. For Christ’s sake, Improve your language!
  23. 23. Fight your demons
  24. 24. You don’t need an excuse not to work - You don’t need a reason to work
  25. 25. Lazines and scatterbrain as a way of life
  26. 26. Improve your “search-fu”
  27. 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. 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. 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. 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. 31. Don’t blindly follow the fassion!
  32. 32. The research half-days
  33. 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. 34. Overthinking "Premature optimization is the root of all evil." Donald Knuth
  35. 35. Always estimate your work
  36. 36. It’s all about the code
  37. 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. 38. Handle errors ● Don’t overlook errors ● Empty “catch” is not a solution ● Log everything, help your future self.
  39. 39. The professional schizophrenia
  40. 40. Don’t be stubborn on development. - We’re just a means to solve a problem!
  41. 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. 42. Walk in the QA shoes!
  43. 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. 44. Lifehacks
  45. 45. Rest until you’re bored to death
  46. 46. Reorganize your day to develop better habbits
  47. 47. Always be with the feeling, that someone else is better and you have to catch up.
  48. 48. Never meet your Gods!
  49. 49. ● Read the medium or ● Read “The clean code” ● Read “Refactoring”
  50. 50. QA