The Effective Engineer

The effective engineer was a highly recommended book from a coworker available on amazon.

Chapter 1 - An effective engineer is all about accomplishing the most high value things in the least amount of time. The three ways of doing this is doing things faster. Increasing the value of an existing activity. By doing more impactful tasks. The three questions you should be asking yourself when you are working is. How can I do this task faster? How can I make this task be more valuable to the company? Is there something else I could spend my time on that would be a bigger impact for the company/customers etc.

Chapter 2 - All about that growth mindset. It’s basically a chapter dedicated to the benefits of learning. I mostly already knew all the concepts in this chapter but I’ll write about the key points. Learning compounds… so you should always try to be learning and improving everyday. It’s all about the daily 1% improvements that will make you 37x better in a year. You shouldn’t work in an easy chill job because you’re actually getting weaker since you miss out on the compound growth. The author also talks about tangential skills… which I think is extremely true. I use to think that being a good software engineer was all about kicking ass a planning and execution but then now I realize that side unrelated skills may actually make you better. It’s weird. But I think that doing hip hop dancing actually made me a better software developer. /shrug. The author’s specific example was that he use to think that he could never get better at socializing due to his introverted nature… I think I was like this too. But then now I think I’d be fine being dropped into a party where I knew no one. Because I can just jump into random conversations with strangers.

Chapter 3 - prioritization and planning. This chapter was dedicated to organizing and utilizing to do lists and various planning strategies. I already read quite a few books on this topic and I already follow my own schedule. I plan things on a daily basis. I always plan what I want to do tomorrow. I plan for 3 things that I want to get done tomorrow. Between 3 ~ 7 things. And I usually get most of it done and I find that planning the next day makes a huge difference. The other thing I do is plan things on a quarterly / monthly basis. The thing that I haven’t been doing is reviewing on a weekly basis. I think reviewing things on a weekly basis actually helps a lot. I find that when I read my diary entries… even stuff that I’ve written about a week ago feels like ages ago. The other thing is that you need to have contingency planning. If something doesn’t go as planned… what will you do? Priorities also change. Sometimes what was important in the past no longer is as important. Unforeseen events might change your priorities and how you spend your time. I remember a long time ago… I really wanted to work at google. Now I get google recruiter emails all the time and it’s like - bleh I’m not interested in google.

Chapter 4 - invest in iteration speed. Talks about live deploys vs weekly deploys. The faster you can test your code the better. You should invest in tooling. Learn how to script common actions. These things I already do. Like… I usually write a simple bash script instead of building something from scratch. For example… this jekyll blog. I have scripts that auto-generate a template for book reviews, or a weekly entry. I just type weekly “Title of entry” and I’m automatically in the file via vim and I can start typing my blog entry. Also at work… I typically write scripts that help me do stuff. Am example is running unit tests in django. You typically run django test blah. Where blah is like some module and path. Instead I wrote a script that accepts a file name and then auto parses it to r un the test. That way I can do find . grep TestIWantToRun alanTest which then runs the test. :) I feel like such a badass. That I already script everything. I guess that’s why I really like Linux.

Chapter 5 - measure what you want to improve. You want to always keep track of what it is you want to improve and to do that you need to track all changes. You need to have proper analytics and metrics. The metric choice plays a great impact in the final results. The example is the Zappos metric. Typical call centers measure call time as a metric… but Zappos doen’t use that metric because that encourages a poor customer experience. Picking a bad metric can lead you down the wrong path. Having a proper baseline metric also helps determine your actions. If your metric is page load times and your goal is 1 second load time. And your current load time is 5 second… it doesn’t really make sense to go after small wins since your target would necessitate major changes to reach. Also picking a bad metric leads to bad behaviour. If you wanit engineers to fix more bugs and use number of bug fixes as a metric. It encourages engineers to write shitty code so that they have easy bug fixes in the future. Instead you should aim to lower the number of defects in the first place etc. I realize that… some of the metrics in my life aren’t defined… and I’m flying blind in a lot of cases. Gotta apply effective engineering to leading an effective life.

Chapter 6 - validate your ideas early and often. this chapter is dedicated to… kinda the prospect of building a mvp. why a/b testing is important and that you should always approach a problem iteratively vs building a mega program and then praying that it works. the main takeaway from this chapter is that… solo projects are bad because you don’t get feedback. it’s important to get feedback early and often. otherwise you’ll build a mega feature and waste time when someone else could’ve suggested an easier / more time saving solution.

Chapter 7 - improve your estimation skills. Main takeaways is to do the hard / unknown tasks first. You tend to do the easy / properly estimated tasks first and convince yourself that the project is going on schedule. then you get to the hard tasks with a ton of unknowns and you end up taking forever to figure it out. you should buffer for unforeseen events. like members getting sick. and the longer the project the more slippage because there are more time for unexpected events. and lastly… engineering day estimates and schedule day estimates are not the same. something can take one engineering day but take multiple calendar days due to meetings / random / p0 bugfixes etc. and overtime is generally bad. because. overtime is equivalent to sprinting / burnout and for most projects when you need to do overtime / sprint it’s because you don’t know what you don’t know. you’re actually in the middle of a marathon… and sprinting in the middle of the marathon… will just make you tired and in the end reach the finish line slower. there’s basically a list of negative reasons for overtime and why in general overtime is bad.

Chapter 8 - balance quality with pragmatism. Most of this is… stuff I already knew. The only thing of value I guess is how good programming abstractions save you time in the long run vs bad ones which act almost like technical debt. Like. At work with Django… we have this convoluted way of using forms to validate data… which then gets validated again. We have serializers that are used to just return json data… which feels unnecessary since you’re making a serializer for a model… but most of the data isn’t returning just a singular model. So you gotta.. hack around the serializer and inheritance pattern. Urgh. Bad software abstractions is painful. Also automated testing and code reviews are important (duh). And uh… you should watch your technical debt. Since… at some point in time it just gets too expensive and slow. Don’t get stuck paying interest payments like poor people.

Chapter 9 - minimize operational burden. Choose simple and known technologies over fancy new tech that you need to learn or is unproven. Example is Pinterest… which at one point at 7 technologies… before they standardized on memcached, mysql, redis and something that I don’t remember. I already knew this. And yet… at work I’m choosing to build something in Golang. Sometimes it’s just…. too tempting to play with new technology. Go does have proven benefits over python in a sense that it’s more performance but I digress. The other thing is to write code that fails fast. You want the failure to be as close to the actual problem. So if you fail silently… what happens is that the failure bubbles up into another layer and makes debugging it much harder. Makes sense in theory… suprised that I had to learn it via this book. I guess that’s why this book is worth it. Automation is good. Already knew that. Instead of manually running 5 scripts just write a megascript that does all the steps for you. When automating… automate mechanical stuff before decision making since automating decision making is hard. Really hard. That’s why engineers get paid. Aim for idempotence and re-entry. Which means that… if your script fails you should ideally be able to just rerun it. I don’t think I need to define idempotence. More complex is making a script re-entrant such that it can resume from where it blew up. I think aiming for idempotence is much easier since re-entry is tricky. And lastly… chaos monkey via netflix and practicing for fires. A company should load test for the future in advance to see issues before they actually happen in production. In reality… that’s hard because… most engineering teams that I’ve been a part of… the debt there is uh… too high. The present is already broken so project the future is way to scary.

Chapter 10 - invest in your team’s growth. Help the people around you be more successful. To get promoted… you need to be a force multiplier. If you make each engineer 20% better… and there’s 10 engineers. That’s like 2 engineers. Even if each engineer is .5 of your ability. You improved the productivity by 1 whole unit. At worse it’s break even if you didn’t write any code whatsoever. He talks about how as your become more senior… you make a bigger impact. You make your team better, you make your company better… and lastly you make the industry better. Those are the best and most valued engineers. Make hiring a priority. Hiring… makes a huge difference since at every company I was at there is never enough engineers. Each engineer you bring on… is like thouuusands of hours of productivity provided they stay on the team and are good. Onboarding important to making engineers useful faster. Otherwise it makes new engineers stressed out and since ramp up time is lost. Good onboardingg is a huge leverage activity since it brings big gains. Mentoring others is a force multiplier. Shared ownership is important so you don’t get paged on vacation. Also… if you become the guy for some aspect of the tech stack. Sure.. you’re valuable and stuff… but then you get stuck with it. And you can’t work on other projects. Also you don’t become the bottleneck because you’re the only person with knowledge. Debrief and post mortems are important to the team growth. And there should be runbooks for all the previous cases that you’ve run into. That way… when a new engineer oncall has to fix the db… they know what to do. Having a good engineering culture is immensely important because it allows you to attract the best engineers. And it’s also a virtuous feedback loop. The alternative is a shitty engineering culture where all the good people leave and it becomes a death spiral and you’re fucked.

Overall - I think this book was immensely beneficial to me. I learned a lot that I can apply to even my side projects. And the leverage aspect applies to all facets of life. Even in the book he mentions it - you shouldn’t sweat your coffee budget… when negotiating for a better salary would more than cover your coffee expense. So spend time negotiating your salary and investing in stocks or whatever. I think it changed the way I think of approaching problems. I feel like this is the meta of how to be a Software Engineer in Silicon Valley. For me personally I think that an being an effective engineer might not coincide with my personal goals though. It’s true that your contributions are much bigger to an organization if you mentored your peers. My own goal is to become insanely fast and insanely good. To be legitimately orders of magnitude better than regular Software Engineers. I don’t think I’ll be able to reach that level if I spent most of my time mentoring others and not coding. I wonder what the author would say to that.

You can get the book here