Software engineering 101 - The basics you should hear about at least once
96
Software Engineering 101 The basics you should hear about at least once
-
Upload
alexey-migutsky -
Category
Technology
-
view
2.371 -
download
0
description
The facts about Engineering Culture. These are the things I wish I were told about at the beginning of my career.
Transcript of Software engineering 101 - The basics you should hear about at least once
Software Engineering 101
The basics you should hear about at least once
Engineering is all about
constraints
Know your context
Know your resources
How can you do this?
Know your goals
What are you doing?
Why are you doing this?
Know your reason
There is always “it depends”
argument
Be proactive to find those limitations
Listen and ask to get the whole context
Be passionate
Technologies do
NOT matter
No, it does not really matter
“ Is Ruby better than Python? ”
Yeah, that’s a good argument
“But I like Python more!”
Good software is done by good software engineers
Project success has NO correlation
with technologies used
Pick any technology pragmatically
Pragmatic arguments logically fit
your context
Pragmatic: “Team is proficient with it“
Pragmatic: “People are excited by the technology”
Pragmatic: “Easy to find new people”
Pragmatic: “Helps do things right”
Hardest challenges
Problems Context Focus
1. How do you communicate?
Divide and Conquer Structure
Conventions
2. How do we manage complexity?
3. How do I name this thing?
Never trust names by default Look in the source code
Read more
Manage complexity Communicate
Measure React
4. How to evolve this system?
There are no silver bullets
Be pragmatic not religious
about how you solve problems
Code is for humans!
It’s all about people
Not easy !
See this: http://www.infoq.com/presentations/Simple-Made-Easy
Use simple
technologies
More time spent reading and debugging then actual writing code
Always think about maintenance
Readability and simplicity is always better
than no duplications and following best practices
–John Woods
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.
Know what
you are doing
Never be lazy about knowing
what's going on under the hood
This is not really scary
Ask
Tell
Show
Keep on learning
Be a sponge for information
Experiments
Always write code
Do not only learn and analyse Get your hands dirty
Try new things
Success is a side-effect
Failure is the only
source of experience
Experience is the only
source of intuition
Recipe may vary !
See this: http://en.wikipedia.org/wiki/Cynefin
Think Act
Measure Decide
Be responsible
Good practices
Routine automation
Do not let bugs live
OSS Open new issues
Make contributions
Hotkeys Snippets
Live templates
Pet projects
https://signalvnoise.com/posts/3124-give-it-five-minutes
Give it 5 minutes
Know your tools
Git
rebase, add patch, bisect
Gitflow
Vim, Sublime, Nano
IDE + Text editor
CI / CD / QA / Operations
Know what others do and how you can help
Guerilla Refactoring
The only one working
refactoring method
Refactoring has no
direct business value
Refactoring should not
be a part of backlog
Add time for refactoring
in your estimates
Boy Scout rule: “Always leave the code behind
in a better state than you found it”
Uncle Bob
Task estimation
Include all phases in estimates
30% testing 30% implementation 10% logging and metrics 30% refactoring
30% testing 30% implementation 10% logging and metrics 30% refactoring
This is what you REALLY can estimate
Real estimate = 3 * implementation estimate
Multiplication Factor will vary based on experience
Project estimation
Create epics and stories
Divide stories in tasks
Make optimistic task estimation
Illness Fuck ups
Bus factors Holidays
Design mistakes
Include all risks
Optimistic path with estimated risks included
Realistic path
Realistic path =
3.14 * Optimistic path + 2 weeks
The time needed for senior engineer to make something working
if everything else failed
2 weeks is an emergency interval
Productivity
Pomodoro GTD
Productivity techniques
Always Be Coding https://medium.com/@davidbyttow/abc-always-be-coding-d5f8051afce2
ABC
Keep mind sharp
Eat well
Sleep well
Exercise well
Make breaks
Meditate
Intentionally left blank
The Ultimate Goal
It’s not about coding
It’s not about design
It’s not about joy
It’s not about making money
It’s all about value
All other things included!
When your coding skills will be smooth, you will start thinking about the value
automatically
Takeawayshttp://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.pdfhttp://www.targetprocess.com/articles/speed-in-software-development.htmlhttp://simpleprogrammer.com/2014/02/17/secret-ridiculous-productivity-im-using-now/
https://signalvnoise.com/posts/3124-give-it-five-minuteshttps://medium.com/@davidbyttow/abc-always-be-coding-d5f8051afce2
