![]()
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 Haskell1 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:
1....
