If you’re really into something, you’re bound to get asked Why do you love X? all the time. This question seems straightforward at first. If you do something all day, how can you not know why?!? However, it’s often surprisingly hard to articulate. When you really love something, you don’t often think about — you just . why do If you know anything about me, you know that I write a and . When I get this question, I often take the easy way out and reply with something along the lines of lot of about code I can use code to build whatever I want! Most people are fascinated by this. Woah! I can’t do that. Sounds cool. Is it cool? Yes. Is it rewarding? Definitely. … But, is it really why I love ? Meh. programming After many years, I’ve finally cracked the code — I love programming because I love . It’s the same reason I love , , and more recently, studying number theory. abstractions analyzing code reading about startups Abstractions, huh? Don’t you just build apps? Believe it or not — the job of a good “software engineer” is not just to slam keys and output code but also to manage (and eliminate) complexity. Managing Complexity A common method of limiting complexity is cutting scope, but what if scope has already been cut, and things really are complex? Depends on who you’re talking to. The average developer will likely tell you that’s why they’re there to solve the hard problems and then, produce a convoluted, unmaintainable solution. However, the adept “software engineer” knows that an increasingly complex system is not an excuse for increasingly complicated code, and that the correct approach is to abstract. What’s in an abstraction? The concept of an abstraction is simple. You take complicated stuff, simplify it, isolate it, build a human-friendly, generic interface around it, name it something cool, and reference it elsewhere. Though not purely technical, here are some real-world examples of abstractions you may reason about frequently without even realizing: When you multiply and , do you think about summing Y sets of X? Nope. That’s why multiplication exists, right? X Y When we charge a customer at , do we think about how that money gets from their bank to ours? Nope. Our friend, , does. Segment Stripe When you buy something on Amazon, do you think about how it ends up at your door in 2 days? Nope. Their friend, UPS, does. It turns out that there are a number of ways these abstractions could have been architected, and it takes a lot of planning to get them right… or even wrong for that matter. The greatest challenge of abstractions is that they’re rarely static. The requirements of customers and thus, systems are constantly evolving, and abstractions need to adapt to this. For example, due to the rise of on-the-go purchases, payment processors like have been forced to not only support debit and credit cards in addition to banks but now, mobile services like Apple Pay, too. Fortunately, the engineering team at Stripe didn’t have to rewrite their entire system to implement these major changes. Instead, they’ve developed an interface that each implements to execute common operations like “charge customer X $Y”. Stripe payment source A good abstraction is . An abstraction should be able to adapt or be easily adapted to an ever-changing set of needs. Flexible . Remember, the point of an abstraction is to reduce complexity. Simple . Is it easy to use the abstraction without worrying about implementation details? Is it easy to figure out how it works? Readable On the contrary, a bad abstraction violates at least one of the above. Finally, the worst type of abstraction is one that , as they harm productivity by introducing unnecessary indirection. shouldn’t exist at all Conclusion Evidently, there are lots of concerns in creating abstractions, but managing these is inevitable, as abstractions are crucial to . In a nutshell, programming is both the art and science of crafting better abstractions. That’s what makes it so challenging. That’s what feeds my brain. productivity As per usual, I’ll conclude with the idea that sparked this post— Technology will definitely solve all our problems, but in the process it will create brand new ones. But that’s O.K. because the most you can expect from life is to get to solve better and better problems. — , Author of Scott Adams Dilbert
