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.

Software engineering 101 - The basics you should hear about at least once

12,231 views

Published on

The facts about Engineering Culture.

These are the things I wish I were told about at the beginning of my career.

Published in: Technology, Self Improvement
  • Hey guys! Who wants to chat with me? More photos with me here 👉 http://www.bit.ly/katekoxx
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Software engineering 101 - The basics you should hear about at least once

  1. 1. Software Engineering 101 The basics you should hear about at least once
  2. 2. Engineering is all about constraints
  3. 3. Know your context
  4. 4. Know your resources How can you do this?
  5. 5. Know your goals What are you doing?
  6. 6. Know your reason Why are you doing this?
  7. 7. There is always “it depends” argument
  8. 8. Listen and ask to get the whole context Be proactive to find those limitations
  9. 9. Be passionate
  10. 10. Technologies do NOT matter
  11. 11. “ Is Ruby better than Python? ” No, it does not really matter
  12. 12. “But I like Python more!” Yeah, that’s a good argument
  13. 13. Good software is done by good software engineers
  14. 14. Project success has NO correlation with technologies used
  15. 15. Pick any technology pragmatically
  16. 16. Pragmatic arguments logically fit your context
  17. 17. Pragmatic: “Team is proficient with it“
  18. 18. Pragmatic: “People are excited by the technology”
  19. 19. Pragmatic: “Easy to find new people”
  20. 20. Pragmatic: “Helps do things right”
  21. 21. Hardest challenges
  22. 22. 1. How do you communicate? Problems Context Focus
  23. 23. 2. How do we manage complexity? Divide and Conquer Structure Conventions
  24. 24. 3. How do I name this thing? Never trust names by default Look in the source code Read more
  25. 25. 4. How to evolve this system? Manage complexity Communicate Measure React
  26. 26. Be pragmatic not religious about how you solve problems There are no silver bullets
  27. 27. Code is for humans!
  28. 28. It’s all about people
  29. 29. Use simple technologies Not easy ! See this: http://www.infoq.com/presentations/Simple-Made-Easy
  30. 30. Always think about maintenance More time spent reading and debugging then actual writing code
  31. 31. Readability and simplicity is always better than no duplications and following best practices
  32. 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. 33. Know what you are doing
  34. 34. Never be lazy about knowing what's going on under the hood
  35. 35. Ask This is not really scary
  36. 36. Tell
  37. 37. Show
  38. 38. Keep on learning Be a sponge for information
  39. 39. Experiments
  40. 40. Always write code Do not only learn and analyse Get your hands dirty
  41. 41. Try new things
  42. 42. Failure is the only source of experience Success is a side-effect
  43. 43. Experience is the only source of intuition
  44. 44. Think Act Measure Decide Recipe may vary ! See this: http://en.wikipedia.org/wiki/Cynefin
  45. 45. Be responsible
  46. 46. Good practices
  47. 47. Routine automation
  48. 48. OSS Open new issues Make contributions Do not let bugs live
  49. 49. Hotkeys Snippets Live templates
  50. 50. Pet projects
  51. 51. Give it 5 minutes https://signalvnoise.com/posts/3124-give-it-five-minutes
  52. 52. Know your tools
  53. 53. Git rebase, add patch, bisect
  54. 54. Gitflow
  55. 55. IDE + Text editor Vim, Sublime, Nano
  56. 56. CI / CD / QA / Operations Know what others do and how you can help
  57. 57. Guerilla Refactoring
  58. 58. The only one working refactoring method
  59. 59. Refactoring has no direct business value
  60. 60. Refactoring should not be a part of backlog
  61. 61. Add time for refactoring in your estimates
  62. 62. Boy Scout rule: “Always leave the code behind in a better state than you found it” Uncle Bob
  63. 63. Task estimation
  64. 64. Include all phases in estimates
  65. 65. 30% testing 30% implementation 10% logging and metrics 30% refactoring
  66. 66. 30% testing 30% implementation 10% logging and metrics 30% refactoring This is what you REALLY can estimate
  67. 67. Real estimate = 3 * implementation estimate Multiplication Factor will vary based on experience
  68. 68. Project estimation
  69. 69. Create epics and stories
  70. 70. Divide stories in tasks
  71. 71. Make optimistic task estimation
  72. 72. Include all risks Illness Fuck ups Bus factors Holidays Design mistakes
  73. 73. Optimistic path with estimated risks included
  74. 74. Realistic path
  75. 75. Realistic path = 3.14 * Optimistic path + 2 weeks
  76. 76. 2 weeks is an emergency interval The time needed for senior engineer to make something working if everything else failed
  77. 77. Productivity
  78. 78. Productivity techniques Pomodoro GTD
  79. 79. White noise Scientifically proved http://focusatwill.com/
  80. 80. ABC Always Be Coding https://medium.com/@davidbyttow/abc-always-be-coding-d5f8051afce2
  81. 81. Keep mind sharp
  82. 82. Eat well
  83. 83. Sleep well
  84. 84. Exercise well
  85. 85. Make breaks
  86. 86. Meditate
  87. 87. Intentionally left blank
  88. 88. The Ultimate Goal
  89. 89. It’s not about coding
  90. 90. It’s not about design
  91. 91. It’s not about joy
  92. 92. It’s not about making money
  93. 93. It’s all about value All other things included!
  94. 94. When your coding skills will be smooth, you will start thinking about the value automatically
  95. 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. 96. Brought to you by Alex mr_mig_by

×