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!

16.
Embrace imperfection

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!

23.
Fight your demons

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

26.
Improve your “search-fu”

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!

32.
The research half-days

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.

39.
The professional
schizophrenia

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