Street Coder

The rules to break and how to break them

Sedat Kapanoglu

• Publisher: Manning
• Year: 2022
• Print ISBN: 9781617298370
• eBook ISBN: 9781638357148
• Topic: Computer Science
• Subtopic: Object Oriented Programming
• Index: Computer Science

Computer science theory quickly collides with the harsh reality of professional software development. This wickedly smart and devilishly funny beginner's guide shows you how to get the job done by prioritizing tasks, making quick decisions, and knowing which rules to break. In Street Coder you will learn: Data types, algorithms, and data structures for speedy software development
Putting "bad" practices to good use
Learn to love testing
Embrace code breaks and become friends with failure
Beginner-friendly insight on code optimization, asynchronous programming, parallelization, and refactoring Street Coder: Rules to break and how to break them is a programmer's survival guide, full of tips, tricks, and hacks that will make you a more efficient programmer. It takes the best practices you learn in a computer science class and deconstructs them to show when they're beneficial—and when they aren't! This book's rebel mindset challenges status quo thinking and exposes the important skills you need on the job. You'll learn the crucial importance of algorithms and data structures, turn programming chores into programming pleasures, and shatter dogmatic principles keeping you from your full potential. Welcome to the streets! About the technology
Fresh-faced CS grads, bootcampers, and other junior developers lack a vital quality: the "street smarts" of experience. To succeed in software, you need the skills and discipline to put theory into action. You also need to know when to go rogue and break the unbreakable rules. Th is book is your survival guide. About the book
Street Coder teaches you how to handle the realities of day-to-day coding as a software developer. Self-taught guru Sedat Kapanoglu shares down-and-dirty advice that's rooted in his personal hands-on experience, not abstract theory or ivory-tower ideology. You'll learn how to adapt what you've learned from books and classes to the challenges you'll face on the job. As you go, you'll get tips on everything from technical implementations to handling a paranoid manager. What's inside Beginner-friendly insights on code optimization, parallelization, and refactoring
Put "bad" practices to good use
Learn to love testing
Embrace code breaks and become friends with failure About the reader
For new programmers. Examples in C#. About the author
Sedat Kapanoglu is a self-taught programmer with more than 25 years of experience, including a stint at Microsoft. Table of Contents
1 To the streets
2 Practical theory
3 Useful anti-patterns
4 Tasty testing
5 Rewarding refactoring
6 Security by scrutiny
7 Opinionated optimization
8 Palatable scalability
9 Living with bugs

1 To the streets

This chapter covers

• The realities of the streets
• Who is a street coder?
• The problems of modern software development
• How to solve your problems with street lore

I am lucky. I wrote my first program in the 1980s. It only required me to turn on the computer, which took less than a second, write 2 lines of code, type RUN, and voila! The screen was suddenly filled with my name. I was immediately awestruck by the possibilities. If I could do this with 2 lines, imagine what I could do with 6 lines, or even 20 lines! My nine-year-old brain was flooded with so much dopamine that I was addicted to programming at that instant.

Today, software development is immensely more complex. It’s nowhere close to the simplicity of the 1980s, when user interactions only consisted of “press any key to continue,” although users occasionally struggled to find an “any” key on their keyboard. There were no windows, no mice, no web pages, no UI elements, no libraries, no frameworks, no runtimes, no mobile devices. All you had was a set of commands and a static hardware configuration.

There is a reason for every level of abstraction we now have, and it’s not that we are masochists, with the exception of Haskell¹ programmers. Those abstractions are in place because they’re the only way to catch up with current software standards. Programming isn’t about filling the screen with your name anymore. Your name must be in the correct font, and it must be in a window so you can drag it around and resize it. Your program must look good. It should support copy and paste. It must support different names for configurability as well. Perhaps it should store the names in a database, even in the cloud. Filling the screen with your name isn’t so much fun anymore.

Fortunately, we have resources to contend with the complexity: universities, hackathons, boot camps, online courses, and rubber ducks.

TIP Rubber duck debugging is an esoteric method for finding solutions to programming problems. It involves talking to a yellow plastic bird. I’ll tell you more about it in the debugging chapter.

We should be well equipped with all the resources we have, but the foundation we build for ourselves may not always be sufficient in a high-competition, high-demanding career of software development, the streets.

1.1 What matters in the streets

The world of professional software development is quite mysterious. Some customers swear that they will pay you in a couple of days every time you call them for months on end. Some employers don’t pay you any salary at all, but they insist they will pay you “once they make money.” The chaotic randomness of the universe decides who gets the window office. Some bugs disappear when you use a debugger. Some teams don’t use any source control at all. Yes, it’s frightening. But you must face the realities.

One thing is clear in the streets: your throughput is what matters most. Nobody cares about your elegant design, your knowledge of algorithms, or your high-quality code. All they care about is how much you can deliver in a given time. Counterintuitively, good design, good use of algorithms, and good quality code can impact your throughput significantly, and that’s what many programmers miss. Such matters are usually thought of as hindrances, frictions between a programmer and the deadline. That kind of thinking can turn you into a zombie with a ball and chain attached to your foot.

In fact, some people do care about the quality of your code: your colleagues. They don’t want to babysit your code. They want your code to work and be easily understandable and maintainable. This is something you owe them because once you commit your code to the repository, it’s everybody’s code. In a team, the team’s throughput is more important than that of each member. If you are writing bad code, you are slowing your colleagues down. Your code’s lack of quality hurts the team, and a slowed-down team hurts the product, and an unreleased product hurts your career.

The easiest thing you can write from scratch is the idea, and the next easiest thing is the design. That’s why good design matters. Good design isn’t something that looks good on paper. You can have a design in your mind that works. You will encounter people who don’t believe in designing and just improvise the code. Those people don’t value their time.

Similarly, a good design pattern or a good algorithm can increase your throughput. If it doesn’t help your throughput, it’s not useful. Because almost everything can be given a monetary value, everything you do can be measured in terms of throughput.

You can have high throughput with bad code too, but only in the first iteration. The moment the customer requests a change, you are stuck with maintaining terrible code. Throughout this book, I’ll be talking about cases in which you can realize that you are digging yourself into a hole and get yourself out of it before you lose your mind.

1.2 Who’s a street coder?

Microsoft considers two distinct categories of candidates when hiring: new graduates of a computer science department and industry experts who have substantial experience in software development.

Be it a self-taught programmer or someone who studied computer science, they are missing a common piece at the beginning of their career: street lore, which is the expertise to know what matters most. A self-taught programmer has many trials and errors under their belt but can lack knowledge of formal theory and how it applies to everyday programming. A university graduate, on the other hand, knows a lot about theory but lacks practicality and, sometimes, a questioning attitude toward what they learned. See figure 1.1.

Figure 1.1 Starting a career through different paths

The corpus you learn at school doesn’t have priority associated with it. You learn in the order of the learning path, not in the order of importance. You have no idea how useful certain subjects might be in the streets, where competition is relentless. Timelines are unrealistic. Coffee is cold. The best framework in the world has that single bug that renders a week of your work worthless. Your perfectly designed abstraction crumbles under pressure from the customer who constantly changes their requirements. You manage to quickly refactor your code with some copy-paste, but now you must edit 15 separate places just to change one configuration value.

Over the years, you develop new skills to tackle ambiguity and complexity. Self-taught programmers learn some algorithms that help them, and university graduates eventually understand that the best theory isn’t always the most practical.

A street coder is anyone with software development experience in the industry who has had their beliefs and theories shaped by the realities of an unreasonable boss who wanted a week’s worth of work done in the morning. They have learned to back up everything on multiple media after they lose thousands of lines of code and have to rewrite it all from scratch. They have seen C-beams glitter in the server room from burning hard drives and have fought with the systems administrator at the doors of the server room just to get access to production because someone has just deployed an untested piece of code. They have tested their software-compression code on its own source code, only to discover that it’s compressed everything into one byte and the value of that byte is 255. The decompression algorithm is yet to be invented.

You’ve just graduated and are looking for a job, or you’ve been fascinated by programming but have no idea what awaits you. You’ve gotten out that boot camp and are looking for job opportunities, but you’re not sure about the knowledge gap you have. You’ve taught yourself a programming language, but you’re not sure what is missing from your skills tool belt. Welcome to the streets.

1.3 Great street coders

In addition to street cred, honor, and loyalty, a street coder ideally possesses these qualities:

• Questioning
• Results-driven (aka, “results-oriented” in HR-speak)
• High-throughput
• Embracing complexity and ambiguity

Great software developers are not just great coders

Being a great work colleague involves many more skills than just putting bits and bytes into a computer. You need to be good at communication, provide constructive feedback, and accept criticism like a champion. Even Linus Torvalds² admitted that he needed to work on his communication skills. However, such skills are outside the scope of this book. You will have to make friends.

1....

Table of contents

• inside front cover
• Street Coder
• Copyright
• dedication
• contents
• front matter
• 1 To the streets
• 2 Practical theory
• 3 Useful anti-patterns
• 4 Tasty testing
• 5 Rewarding refactoring
• 6 Security by scrutiny
• 7 Opinionated optimization
• 8 Palatable scalability
• 9 Living with bugs
• index
• inside back cover