The document provides an overview of essential software engineering principles, emphasizing the importance of context, communication, and simplicity over technology preferences. It recommends practices like ongoing learning, thoughtful code maintenance, and responsible task estimation to enhance project success. Ultimately, it asserts that the ultimate goal of software engineering is creating value rather than just focusing on coding or design.

1. Software
Engineering 101
The basics you should hear about at least once

2. Engineering is all
about
constraints

3. Know your context

4. Know your resources
How can you do this?

5. Know your goals
What are you doing?

6. Know your reason
Why are you doing this?

7. There is always
“it depends”
argument

8. Listen and ask to get the whole context
Be proactive to find those limitations

9. Be passionate

10. Technologies
do
NOT
matter

11. “ Is Ruby better than Python? ”
No, it does not really matter

12. “But I like Python more!”
Yeah, that’s a good argument

13. Good software is done
by good software engineers

14. Project success has
NO correlation
with technologies used

15. Pick any technology pragmatically

16. Pragmatic arguments
logically fit
your context

17. Pragmatic: “Team is proficient with it“

18. Pragmatic: “People are excited by the
technology”

19. Pragmatic: “Easy to find new people”

20. Pragmatic: “Helps do things right”

21. Hardest challenges

22. 1. How do you communicate?
Problems
Context
Focus

23. 2. How do we manage complexity?
Divide and Conquer
Structure
Conventions

24. 3. How do I name this thing?
Never trust names by default
Look in the source code
Read more

25. 4. How to evolve this system?
Manage complexity
Communicate
Measure
React

26. Be pragmatic
not religious
about how you solve problems
There are no silver bullets

27. Code is for humans!

28. It’s all about people

29. Use
simple
technologies
Not easy
!
See this:
http://www.infoq.com/presentations/Simple-Made-Easy

30. Always think about maintenance
More time spent reading and debugging
then actual writing code

31. Readability and simplicity
is always better
than no duplications
and following best practices

32. Always code as if the guy who ends up
maintaining your code will be
a violent psychopath
who knows where you live.
!
Code for readability.
–John Woods

33. Know
what
you are doing

34. Never be lazy about
knowing
what's going on under the hood

35. Ask
This is not really scary

36. Tell

37. Show

38. Keep on learning
Be a sponge for information

39. Experiments

40. Always write code
Do not only learn and analyse
Get your hands dirty

41. Try new things

42. Failure is
the only
source of experience
Success is a side-effect

43. Experience is
the only
source of intuition

44. Think
Act
Measure
Decide
Recipe may vary
!
See this:
http://en.wikipedia.org/wiki/Cynefin

45. Be responsible

46. Good practices

47. Routine automation

48. OSS
Open new issues
Make contributions
Do not let bugs live

49. Hotkeys
Snippets
Live templates

50. Pet projects

51. Give it
5 minutes
https://signalvnoise.com/posts/3124-give-it-five-minutes

52. Know your tools

53. Git
rebase, add patch, bisect

54. Gitflow

55. IDE + Text editor
Vim, Sublime, Nano

56. CI / CD / QA / Operations
Know what others do
and how you can help

57. Guerilla
Refactoring

58. The only one
working
refactoring method

59. Refactoring
has no
direct business value

60. Refactoring
should not
be a part of backlog

61. Add time
for refactoring
in your estimates

62. Boy Scout rule:
“Always leave the code behind
in a better state
than you found it”
Uncle Bob

63. Task estimation

64. Include all phases in estimates

65. 30% testing
30% implementation
10% logging and metrics
30% refactoring

66. 30% testing
30% implementation
10% logging and metrics
30% refactoring
This is what you REALLY can estimate

67. Real estimate = 3 * implementation estimate
Multiplication Factor will vary based on experience

68. Project estimation

69. Create epics and stories

70. Divide stories in tasks

71. Make optimistic task estimation

72. Include all risks
Illness
Fuck ups
Bus factors
Holidays
Design mistakes

73. Optimistic path with
estimated risks included

74. Realistic path

75. Realistic path
=
3.14 * Optimistic path + 2 weeks

76. 2 weeks is an
emergency interval
The time needed for senior engineer
to make something working
if everything else failed

77. Productivity

78. Productivity techniques
Pomodoro
GTD

79. White noise
Scientifically proved
http://focusatwill.com/

80. ABC
Always Be Coding
https://medium.com/@davidbyttow/abc-always-be-coding-d5f8051afce2

81. Keep mind sharp

82. Eat well

83. Sleep well

84. Exercise well

85. Make breaks

86. Meditate

87. Intentionally left blank

88. The Ultimate Goal

89. It’s not about coding

90. It’s not about design

91. It’s not about joy

92. It’s not about making money

93. It’s all about value
All other things included!

94. When your coding skills will be smooth,
you will start thinking about the value
automatically

95. Takeaways
http://martinfowler.com/bliki/OpportunisticRefactoring.html
http://www.quora.com/Computer-Programming/What-insights-do-expert-hackers-have-for-
novice-programmers
http://www.quora.com/Computer-Programming/What-are-some-essays-all-programmers-
should-read
http://michaelochurch.wordpress.com/2012/01/26/the-trajectory-of-a-software-engineer-
and-where-it-all-goes-wrong/
http://pomodorotechnique.com/
http://www.infoq.com/presentations/Simple-Made-Easy
http://vlsicad.ucsd.edu/Research/Advice/star_engineer.pdf
http://www.targetprocess.com/articles/speed-in-software-development.html
http://simpleprogrammer.com/2014/02/17/secret-ridiculous-productivity-im-using-now/
https://signalvnoise.com/posts/3124-give-it-five-minutes
https://medium.com/@davidbyttow/abc-always-be-coding-d5f8051afce2

96. Brought to you by Alex
mr_mig_by