Skills of a Successful Software Engineer (Fernando Doglio) (Z-Library)

📄 File Format: PDF

💾 File Size: 8.5 MB

📖 Read Online ⬇️ Download

Registered users can read the full content for free

Register as a Gaohf Library member to read the complete e-book online for free and enjoy a better reading experience.

📄 Page 1

M A N N I N G Fernando Doglio

📄 Page 2

Top non-technical nuggets of wisdom from this book. Advice Section Page number Your code should work first; you can worry about opti- mization later. 2.1 14 Your code needs to run on a machine, but it also needs to be read by a human. 2.2 15 Keep away from boxes; you’re a developer. 2.5 30 Write unit tests for your code! All of chapter 3 41 Knowledge is everywhere; learn how to tap into it and make the most of it. 5.1 87 Side projects are fantastic and should not be a scary thing to tackle. 5.2 91 Avoid companies that are like family. 6.1.2 109 Unlimited time off can be a trap, but it can also be a wonderful perk; make sure you ask the right questions. 6.1.2 112 Trivial perks that only adorn the job offering, such as free food and chill-out zones should be ignored. 6.3.1 119 Flexible hours, paid parental leave, company gear, and other useful perks are what you should look for as part of a job offer. 6.3.2 121 Plan first, code later. That way you have a blueprint to base your work on. 7.1.3 127 Everyone in your team is as important as you, even those who don’t write code. 7.2.1 135 Your ego can be the end of your career; you have to learn to keep it under control. 7.2.2 137 Do not fear code reviews. They’re a perfect learning opportunity; learn to get the most out of them. 7.3.3 147

📄 Page 3

Skills of a Successful Software Engineer FERNANDO DOGLIO M A N N I N G SHELTER ISLAND

📄 Page 4

For online information and ordering of this and other Manning books, please visit www.manning.com. The publisher offers discounts on this book when ordered in quantity. For more information, please contact Special Sales Department Manning Publications Co. 20 Baldwin Road PO Box 761 Shelter Island, NY 11964 Email: orders@manning.com ©2022 by Manning Publications Co. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in the book, and Manning Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps. Recognizing the importance of preserving what has been written, it is Manning’s policy to have the books we publish printed on acid-free paper, and we exert our best efforts to that end. Recognizing also our responsibility to conserve the resources of our planet, Manning books are printed on paper that is at least 15 percent recycled and processed without the use of elemental chlorine. The author and publisher have made every effort to ensure that the information in this book was correct at press time. The author and publisher do not assume and hereby disclaim any liability to any party for any loss, damage, or disruption caused by errors or omissions, whether such errors or omissions result from negligence, accident, or any other cause, or from any usage of the information herein. Manning Publications Co. Development editor: Doug Rudder 20 Baldwin Road Technical development editor: Rasmus Kirkeby Strøbæk PO Box 761 Review editor: Mihaela Batinić Shelter Island, NY 11964 Production editor: Deirdre Hiam Copy editor: Andy Carroll Proofreader: Katie Tennant Technical proofreader: Tim Woolridge Typesetter: Gordan Salinovic Cover designer: Marija Tudor ISBN 9781617299704 Printed in the United States of America

📄 Page 5

To my wife, who’s always supported me on every single decision I’ve made and who’s always been by my side on every adventure: this book, just like everything else I do, is thanks to you. And to my kids, who’ve mastered the art of making me a proud dad every single day: I love you!

📄 Page 6

(This page has no text content)

📄 Page 7

v contents preface ix acknowledgments xi about this book xii about the author xv about the cover illustration xvi 1 Becoming a successful software engineer 1 1.1 What you don’t need 3 Bachelor’s degree in CS or related degree 3 ■ Knowing the software development lifecycle 4 ■ A math, physics, or similar degree 5 Certifications 5 ■ The desire to work in a fast-paced environment 6 ■ Experience 6 1.2 Useful skills to have 7 Patience 7 ■ Determination 7 ■ An eternal student mindset 8 Accepting criticism and learning from it 8 ■ Knowing how to communicate 9 1.3 What about after you get the job? 10 2 Writing code everyone can read 11 2.1 Your code needs to work 12 Good is better than perfect 13 ■ Working, then optimized 14 Sometimes terrible code actually helps 14

📄 Page 8

CONTENTSvi 2.2 Code for people, not for the machine 15 Self-documenting code is a lie 16 ■ Readable code > one-liners 22 2.3 Overengineering: The first capital sin 25 Spotting a case of overengineering 25 2.4 The random bug mystery 27 Performing a root cause analysis (RCA) 28 2.5 You have to aim to be a developer 30 2.6 SOLID, DRY, and other funny terms 32 SOLID: Making your code strong as a rock 32 ■ KISS your code 38 Keep your code DRY 39 ■ YAGNI, another funny word 39 3 Unit testing: delivering code that works 41 3.1 Why unit test your code? 42 What about using unit tests today? 43 3.2 What to test 46 Test one thing at the time 47 ■ Make sure you test a unit of code 47 ■ Only test your own code 48 ■ Don’t test external calls 49 ■ Stick to testing what’s on the rug 50 3.3 How to write your tests 51 Your new best friend: Dependency injection 52 ■ Tame the big four: Mocks, stubs, spies, and dummies 54 ■ Unit tests are not meant to be run manually 58 3.4 When should you write your tests? 59 4 Refactoring existing code (or Refactoring doesn’t mean rewriting code) 61 4.1 What does refactoring mean anyway? 62 4.2 What do you do before you start refactoring? 63 Version control is your friend! 64 ■ Unit tests are all the rage 66 Baselining your code 67 ■ I love it when a plan comes together 67 4.3 What to focus on when refactoring 68 Magic values 68 ■ Everyone’s doing everything 70 ■ You’re too primitive! 70 ■ Obsessive use of switch or if statements 72 Duplicated duplicated code 73 4.4 How to perform code refactoring 75 Common refactoring techniques 75 ■ Tools to reduce human error 79 ■ Refactoring best practices 81 4.5 What if you don’t need to refactor your code? 82

📄 Page 9

CONTENTS vii 5 Tackling the personal side of coding 86 5.1 How are you learning? 87 You’re not supposed to know everything 87 ■ The internet is great, but so is a formal education 90 5.2 Side projects 91 The case for side projects 91 ■ What’s wrong with side projects? 93 ■ What about working on open source projects? 94 5.3 Asking your online friends for help 97 Making mistakes 97 ■ Avoiding the naysayers 98 5.4 Learning to communicate with others 99 6 Interviewing for your place on the team 102 6.1 The tech interview experience 103 What can you expect from a tech interview? 103 ■ Warning signs you should look out for 109 6.2 Things you should never say during a tech interview 113 What do you do here, exactly? 114 ■ I don’t know, I’ve never done that before 114 ■ I hated that place because ... 115 ■ I’ve built multiple SPAs using SSR with MERN 115 ■ Well, nobody uses that anymore 116 ■ It’s listed on my resume 116 ■ No, I don’t have any questions 117 ■ I’m a React developer 117 ■ Oh Linux? I hate Linux, I’m a Windows guy 118 ■ I don’t know what unit tests are 118 6.3 What to expect from the offering after your interview process is over 119 Not everything that shines is gold 119 ■ Actually useful perks 121 7 Working as part of a team 123 7.1 Getting your manager to love you 124 Task-tracking software is not the devil’s tool 124 ■ Meetings! 125 I plan, therefore I code 127 ■ Don’t reinvent the wheel 130 What you should never say to your manager 131 7.2 Being a good teammate 135 Make peace with your testers 135 ■ Leave your ego at the door 137 ■ Learn how to work remotely 139 ■ Be social 142 7.3 Working on your own skills 143 Continuous learning 144 ■ Measuring your learning progress 146 ■ Learning from code reviews 147

📄 Page 10

CONTENTSviii 8 Understanding team leadership 150 8.1 Understanding your leader 151 Key traits of a good leader 151 ■ Hard truths to hear from your leader 153 ■ Constantly asking for status updates 156 Understanding task assignments 157 8.2 The 90-10 rule 158 8.3 Correcting your leader 160 8.4 Dealing with clients 161 Correcting the client 161 ■ Angry clients 163 8.5 Feedback is mandatory 163 Why is feedback so important? 164 ■ Different types of feedback 165 8.6 Thank you 167 index 169

📄 Page 11

ix preface The software development industry has changed, and I’m not talking about a recent change—this happened years ago. Accessing the entry-level knowledge required to start a career in software development is no longer the privilege of a few, but an opportunity for the masses. Knowledge is not the problem—technology has allowed us to make it widespread—but the industry itself hasn’t adapted yet. While most people trying to start a career as a developer focus on the technical side of what to learn (which language and framework to learn, which tutorial is best for understanding design patterns, etc.), they forget about everything else. And through that, they miss out on the most important detail: technical knowledge is read- ily available, and they will be consuming it for many years, if not decades. In contrast, understanding what to expect from your first job, choosing your first company from several job offers, or even figuring out how to work with a team of colleagues with dif- ferent levels of skills than yours is not trivial, and that knowledge is less available. There are plenty of aspects of our profession that don’t involve coding, and even if they do, they don’t rely on code but rather on best practices and teamwork. That’s where this book comes from—the need to fill in that gap in the upbringing of new developers. I strongly believe that anyone can learn how to code if they spend enough time and find the right resources. I honestly believe that is the easiest part of our profession. But the rest? The rest is only learned through experience, and while I can’t force experience into you through a book, I can give you a head start by sharing my own. After almost two decades in this industry, I’ve picked up a tip or two, and I’m more than willing to share them with you.

📄 Page 12

My hope is that by reading this book you’ll either be able to prepare for what’s coming, or if you’re already getting started, you’ll be able to make sense of what you’re experiencing. That’s all. I’m not going to teach the basics of programming— there is the internet for that (and plenty of other books as well). But if you’re inter- ested in knowing what else to expect from the journey you’ve embarked on, then keep on reading!

📄 Page 13

xi acknowledgments While some people would like to think that a book is the work of a single author, the reality is very different. I’d like to acknowledge everyone who’s been involved in the creation of this (and many other titles) within Manning: from the acquisition editor who saw potential in one of my articles on the internet and thought it could become a full-blown book, to the multiple reviewers, editors, and to all the others involved in every single step of the year-long process required to publish the book. I thank my production editor, Deirdre Hiam; my copyeditor, Andy Carroll; my review- ing editor, Mihaela Batinić; and my proofreader, Katie Tennant. I’d also like to thank the reviewers who took the time to read my manuscript at various stages during its devel- opment and who provided invaluable feedback—your suggestions helped make this a better book: Adhir Ramjiawan, Alessandro Puzielli, Brent Boylan, Christopher Villan- ueva, Deepak Raghavan, Dze Richard Fang, Fabian Pietro de Franca Bram, Jeremy Chen, Jessica Daubner, João Marcelo Borovina Josko, Joseph Pereniaj, Krzysztof Hrynczenko, Lobel Strmečki, Matthias Busch, Mattia Antonino Di Gangi, Mikael Dau- trey, Oliver Korten, Owain Williams, Rodney Weis, Samantha Berk, Samvid Mistry, Sim- one Sguazza, Stuart Ellis, Sveta Ashokchandra Natu, and Tim Wooldridge.

📄 Page 14

xii about this book Skills of a Successful Software Engineer was written with the aim of helping newcomers to the industry by sharing my own experience, my own mistakes, and the lessons I’ve learned from them. It’s intended to give you a glimpse into your future and to show you a possible pathway to traverse it. In the end, the way you evolve and move forward is going to be your own. Who should read this book Everyone! At least, that’s my hope, but on a more serious note, I’ve written this book for a very specific type of reader: someone who’s just getting started and has potentially not even worked as a developer yet. That person will get the most out of this book. However, through our review process, we’ve also discovered that many developers with years-long careers already under their belts were able to learn a thing or two from different chapters. Some of them had been working for the same company all this time, and they found chapter 6 about the interview process interesting. Others have been toying around with the idea of working on a side project but didn’t know where to begin, so chapter 5 was great for them. There is something for everyone here, so I encourage you to take a look, even if you’ve been working for a while already. How this book is organized It wasn’t easy, but I tried to organize the content of this book into a logical progres- sion. The eight chapters try to parallel the evolution of your career as a developer:

📄 Page 15

ABOUT THIS BOOK xiii ■ Chapter 1 covers the basis of a software development career: what should be your focus and what are some of the biggest misconceptions people have about the industry. If you’re still on the fence about whether this is the right career choice for you, this chapter should help you answer that question. ■ Chapter 2 will walk you through some of the core concepts you’ll need to understand when tackling code. No, they’re not code-related concepts; I’m not talking about if statements or for loops. This chapter covers ideas such as understanding that there is no perfect code, and that you need to document your logic even if you’re the only one working on it. There are many ways to go about writing code, and this chapter will show you some best practices to keep you sane while doing it. ■ Chapter 3 is the first technical chapter of the book, and it covers unit testing. The concepts covered here are valid for any language you might decide to work with. The few code samples here are either in JavaScript or Python, but they’ll feel more like pseudocode than anything. The point of this chapter is not for you to copy and paste code and get it running, but rather to help you under- stand why unit testing is such a crucial task and to present the core concepts around it. ■ Chapter 4 is the last technical chapter of the book, and it covers another core practice within our industry: refactoring. Again, the focus of this chapter is not the code; instead, it discusses why refactoring is such an integral part of our career and best methods for tackling it. ■ Chapter 5 tackles the personal side of coding, with advice on how to balance your need to code and learn against the fact that you also have a life outside of your computer. Burnout is real in our industry, and sometimes it results from the need to keep on learning, so in this chapter I cover some aspects of what that means and how to move forward without burning out. ■ Chapter 6 focuses on the technical interview process. This can be a very stress- ful process for some, and very scary for others. I’ve gone through plenty of interviews (on both sides) during my career, and here I share some insights into how to best prepare for them as well as to what to expect from the process. ■ Chapter 7 assumes you’ve started working for a company and that you’re part of a team. In this chapter, I cover team dynamics, understanding what your man- ager expects from you, controlling your developer ego, and more. The way you code is influenced by these dynamics, so don’t disregard the importance of this chapter! ■ Chapter 8 finishes the book with an overview of what it means to be a leader. Why? Because it’s the natural progression of most developers: you start as a junior developer and eventually are presented with the opportunity to lead a small team. You might like it or you might hate it—they’re both very valid out- comes. However, often people forget to tell you what it means to actually lead a team, and this chapter tries to present some insights into that role.

📄 Page 16

ABOUT THIS BOOKxiv From understanding what it means to be a developer to getting some insight into what it will mean to lead your first team, this book covers a wide range of topics. This is my view of the process, and you don’t need to follow every piece of advice or perform every action the same way I suggest. However, by getting a glimpse into what’s awaiting you and some analysis of the different options, you’ll be able to make the best deci- sions for your own context and desires. About the code The focus of this book is not on the code. The little snippets you’ll see, especially in chapters 3 and 4, are written in either JavaScript, Python, or plain pseudocode. By themselves, the snippets will not likely work or produce any meaningful results, so don’t focus on getting them to run. They’re there to illustrate the concepts I’m discussing, so just consider them in conjunction with the explanation I give in those sections. liveBook discussion forum Purchase of Skills of a Successful Software Engineer includes free access to liveBook, Man- ning’s online reading platform. Using liveBook’s exclusive discussion features, you can attach comments to the book globally or to specific sections or paragraphs. It’s a snap to make notes for yourself, ask and answer technical questions, and receive help from the author and other users. To access the forum, go to https://livebook .manning.com/book/skills-of-a-successful-software-engineer/discussion. You can also learn more about Manning's forums and the rules of conduct at https://livebook .manning.com/discussion. Manning’s commitment to our readers is to provide a venue where a meaningful dialogue between individual readers and between readers and the author can take place. It is not a commitment to any specific amount of participation on the part of the author, whose contribution to the forum remains voluntary (and unpaid). We sug- gest you try asking the author some challenging questions lest his interest stray! The forum and the archives of previous discussions will be accessible from the publisher’s website as long as the book is in print.

📄 Page 17

xv about the author FERNANDO DOGLIO has been working in the software industry for the past 19 years. He started building websites and working with Java- Script, HTML, and CSS in 2003. Between then and now, Fernando experienced some of the most popular web technologies, such as Ruby, Python, PHP, and Node.js (working with several of its frame- works and creating a set of custom ones as well). He made the jump from web to big data, using his experience with microservices and incorporating the use of big data–related solutions (such as Kafka, Hadoop, NoSQL databases, Spark, and the like) to become a senior architect developing and creating cloud solutions that were both highly available and fault tolerant. He then started transitioning into a leading role, where he dealt with the technical difficulties of different teams, as well as being the technical point of contact for clients. Finally, during the last six years of his career, Fernando has been working as a tech- nical manager, leading multiple high-end projects and overseeing different aspects of the day-to-day work of developers.

📄 Page 18

xvi about the cover illustration The figure on the cover of Skills of a Successful Software Engineer is “Femme de Barabinze,” or “Woman from Barabinze,” taken from a collection by Jacques Grasset de Saint- Sauveur, published in 1797. Each illustration is finely drawn and colored by hand. In those days, it was easy to identify where people lived and what their trade or sta- tion in life was just by their dress. Manning celebrates the inventiveness and initiative of the computer business with book covers based on the rich diversity of regional cul- ture centuries ago, brought back to life by pictures from collections such as this one.

📄 Page 19

1 Becoming a successful software engineer From the outside, the software industry looks very compelling: many countries have no unemployment in the industry, salaries are fair, there is always room to grow, travel is often involved, and there is the option to work from your couch for a Sili- con Valley startup. Why isn’t everyone working on software? The truth is that while the field might seem interesting, getting in is not that simple. I knew I wanted to be a software developer before I owned my first com- puter. I made the choice when I was a kid, based on the value computers were gen- erating even then. But when it was time for me to jump into the real world, it wasn’t just difficult to get in, it was scary and unwelcoming. I had no guide, no map that would help me navigate the maze that was job interviews or even job listings. I This chapter covers  Avoiding misconceptions about initial skill requirements  Focusing on skills that will help you become a better software developer

📄 Page 20

2 CHAPTER 1 Becoming a successful software engineer would spend a few hours every weekend going through the Jobs section of my local newspaper, looking for opportunities for junior developers without experience. Finding your first job as a software developer can be challenging at best; most com- panies looking for entry-level engineers require them to either have experience with some of the latest frameworks and technologies or to understand a lot of advanced concepts such as design patterns, software development best practices, and version control. Then they’ll go into vague requirements, such as having great “interpersonal skills” or knowledge about other IT-related areas. What is that about? I compiled the following junior developer job listing from multiple samples on the internet:  Bachelor’s degree in related areas and a minimum of one year of experience in similar roles  Knowledge of secure software development  Intermediate skills associated with design, development, modifications, and deployment of software, including object-oriented programming  Knowledge of other IT-related areas  Proof of software repository skills  Proof of effective communication and interpersonal skills  Self-motivated and works independently  Proof of problem-solving skills  Intermediate skills in C#, ASP.NET MVC, SQL Server, TypeScript, and React.js  Experience using Git and GitHub Looking at that list, how can anyone trying to get into the industry not feel intimi- dated? Anyone looking at that job posting will assume they need at least two more years of experience before being taken seriously. Having been through the same experience 18 years ago, I still remember the type of questions I had:  Should I even bother applying for the job? I only have 3 of the 10 required skills.  Do I need to stop studying X and switch to Y now? This week everyone’s asking for Y developers.  How can I get experience if I’m looking for my first job? They’re probably the same questions that any new developer looking to start their career has. But here’s the kicker: these questions are normal. You’re not figuring out that you’re not cut out to be a developer—you’re just living through the junior devel- oper experience. That’s why I’m writing this book: to help you find your way into a successful career. I’ve been through the same struggles that any new developer experiences, and I’ve had an underpaid first job because I had no experience. I’ve met some great people who