Skills of a Successful Software Engineer

Skills of a Successful Software Engineer
contents
preface
acknowledgments
about this book
	Who should read this book
	How this book is organized
	About the code
	liveBook discussion forum
about the author
about the cover illustration
Chapter 1: Becoming a successful software engineer
	1.1 What you don’t need
		1.1.1 Bachelor’s degree in CS or related degree
		1.1.2 Knowing the software development lifecycle
		1.1.3 A math, physics, or similar degree
		1.1.4 Certifications
		1.1.5 The desire to work in a fast-paced environment
		1.1.6 Experience
	1.2 Useful skills to have
		1.2.1 Patience
		1.2.2 Determination
		1.2.3 An eternal student mindset
		1.2.4 Accepting criticism and learning from it
		1.2.5 Knowing how to communicate
	1.3 What about after you get the job?
Chapter 2: Writing code everyone can read
	2.1 Your code needs to work
		2.1.1 Good is better than perfect
		2.1.2 Working, then optimized
		2.1.3 Sometimes terrible code actually helps
	2.2 Code for people, not for the machine
		2.2.1 Self-documenting code is a lie
		2.2.2 Readable code > one-liners
	2.3 Overengineering: The first capital sin
		2.3.1 Spotting a case of overengineering
	2.4 The random bug mystery
		2.4.1 Performing a root cause analysis (RCA)
	2.5 You have to aim to be a developer
	2.6 SOLID, DRY, and other funny terms
		2.6.1 SOLID: Making your code strong as a rock
		2.6.2 KISS your code
		2.6.3 Keep your code DRY
		2.6.4 YAGNI, another funny word
Chapter 3: Unit testing: delivering code that works
	3.1 Why unit test your code?
		3.1.1 What about using unit tests today?
	3.2 What to test
		3.2.1 Test one thing at the time
		3.2.2 Make sure you test a unit of code
		3.2.3 Only test your own code
		3.2.4 Don’t test external calls
		3.2.5 Stick to testing what’s on the rug
	3.3 How to write your tests
		3.3.1 Your new best friend: Dependency injection
		3.3.2 Tame the big four: Mocks, stubs, spies, and dummies
		3.3.3 Unit tests are not meant to be run manually
	3.4 When should you write your tests?
Chapter 4: Refactoring existing code (or Refactoring doesn’t mean rewriting code)
	4.1 What does refactoring mean anyway?
	4.2 What do you do before you start refactoring?
		4.2.1 Version control is your friend!
		4.2.2 Unit tests are all the rage
		4.2.3 Baselining your code
		4.2.4 I love it when a plan comes together
	4.3 What to focus on when refactoring
		4.3.1 Magic values
		4.3.2 Everyone’s doing everything
		4.3.3 You’re too primitive!
		4.3.4 Obsessive use of switch or if statements
		4.3.5 Duplicated duplicated code
	4.4 How to perform code refactoring
		4.4.1 Common refactoring techniques
		4.4.2 Tools to reduce human error
		4.4.3 Refactoring best practices
	4.5 What if you don’t need to refactor your code?
Chapter 5: Tackling the personal side of coding
	5.1 How are you learning?
		5.1.1 You’re not supposed to know everything
		5.1.2 The internet is great, but so is a formal education
	5.2 Side projects
		5.2.1 The case for side projects
		5.2.2 What’s wrong with side projects?
		5.2.3 What about working on open source projects?
	5.3 Asking your online friends for help
		5.3.1 Making mistakes
		5.3.2 Avoiding the naysayers
	5.4 Learning to communicate with others
Chapter 6: Interviewing for your place on the team
	6.1 The tech interview experience
		6.1.1 What can you expect from a tech interview?
		6.1.2 Warning signs you should look out for
	6.2 Things you should never say during a tech interview
		6.2.1 What do you do here, exactly?
		6.2.2 I don’t know, I’ve never done that before
		6.2.3 I hated that place because ...
		6.2.4 I’ve built multiple SPAs using SSR with MERN
		6.2.5 Well, nobody uses that anymore
		6.2.6 It’s listed on my resume
		6.2.7 No, I don’t have any questions
		6.2.8 I’m a React developer
		6.2.9 Oh Linux? I hate Linux, I’m a Windows guy
		6.2.10 I don’t know what unit tests are
	6.3 What to expect from the offering after your interview process is over
		6.3.1 Not everything that shines is gold
		6.3.2 Actually useful perks
Chapter 7: Working as part of a team
	7.1 Getting your manager to love you
		7.1.1 Task-tracking software is not the devil’s tool
		7.1.2 Meetings!
		7.1.3 I plan, therefore I code
		7.1.4 Don’t reinvent the wheel
		7.1.5 What you should never say to your manager
	7.2 Being a good teammate
		7.2.1 Make peace with your testers
		7.2.2 Leave your ego at the door
		7.2.3 Learn how to work remotely
		7.2.4 Be social
	7.3 Working on your own skills
		7.3.1 Continuous learning
		7.3.2 Measuring your learning progress
		7.3.3 Learning from code reviews
Chapter 8: Understanding team leadership
	8.1 Understanding your leader
		8.1.1 Key traits of a good leader
		8.1.2 Hard truths to hear from your leader
		8.1.3 Constantly asking for status updates
		8.1.4 Understanding task assignments
	8.2 The 90-10 rule
	8.3 Correcting your leader
	8.4 Dealing with clients
		8.4.1 Correcting the client
		8.4.2 Angry clients
	8.5 Feedback is mandatory
		8.5.1 Why is feedback so important?
		8.5.2 Different types of feedback
	8.6 Thank you
index
	Symbols
	Numerics
	A
	B
	C
	D
	E
	F
	G
	H
	I
	K
	L
	M
	N
	O
	P
	Q
	R
	S
	T
	U
	V
	W
	Y