Software Developer Life
Page 14
31: Places You Can Work [Career]
Everyone’s career path is unique. Whether you’re an entrepreneur, gig freelancer, pig farmer, or full-time developer, the paths and milestones that comprise each career are vastly different. For some, a career is synonymous with life; for others, the delineation between business and pleasure is cut and dried. Whatever it may be, all of us have aspirations, at varying levels, for our professional lives.
This chapter is dedicated to a specific group of people—anyone looking for employment as a software developer. This group does not include starving founders, one-man consultant services, elite hackers, or professional gamers. Even though we’ve narrowed down the career options, employment as a software developer is still extremely broad and can be an intimidating maze of what-ifs.
For some, a career is synonymous with life; for others, the delineation between business and pleasure is cut and dried.
One of the most crucial decisions you’ll need to make is the seemingly simple choice of where to work. You already know the factors: life responsibilities, what tech you’re trying to learn, how much money you’re trying to make, or what group of people you’re trying to help. All of the above will be resolved by your own internalization. The finishing touch to your decision will revolve around a significant factor that’s outside your control—the software job types that are out there.
Information Technology Vs. Software Development
Before getting started, let’s discuss how IT is different than software development. It’s an important distinction, but it confused me for many years. Every company needs an IT department, but not every company needs a software development department. I’ll put money down on the claim that every company—every single company—uses computers. Goldman Sachs uses IT to set up floors and floors of computers for their stock traders. Your grandma’s basement business uses a special family-plan IT—AKA you and your computer expertise—to get her dusty computer online and upgraded out of Windows 95. If your company uses computers, you need Information Technology!
Every company needs IT, but not every company needs software development.
The local high school, nursing home, and construction company all need computers. They need someone to set them up, create logins, secure networks, check licenses, and deploy the software needed for people to do their jobs. A gross over-simplification, yes, but it’s essentially what IT provides. Their goal is to set up the computer and network infrastructure, so the company can operate. They also write software on top of all of this, but it’s purposeful and enables their primary operational goals.
Now, how is software development different? The purpose of a software development team is not for internal infrastructure. The goal of a software team is to create a unique technical product, or service, for the company. Google has thousands of software teams working on fancy products like Google Plus, but they still have a dedicated IT team to handle their internals. Compare that to your local college; they probably don’t need a software development team, but they definitely need someone to maintain all the student email accounts.
When you think about IT, think about infrastructure and plumbing. When you think about software development, think about applications and services. Software development is building something novel, iterating on it, and selling it for money. You can even build software that helps facilitate IT—Google Apps for example. Every company needs IT, but not every company needs software development.
Startups
In my humble opinion, there are only three categories of startups. They don’t fall into industry or sector groups, but are singled out for the experience offered.
The first experience available comes to those starting their own company as founders. Founding a company is an enormous undertaking and responsibility, a topic that is far beyond the scope of this book and my own personal career path. If it interests you, there are countless testimonials, interviews, and books from founders kind enough to share their journeys with the world, and I wholeheartedly encourage you to seek out their stories.
The second experience is becoming a developer for a tiny startup. At this stage in the game, the startup is very high-risk and has much to prove. You’ll be pumping out code to make that first splash onto the scene or hustling door-to-door to make those first dollars. These developer roles are primed for cowboy types who love green pastures and writing code from the bottom up. This level of startup is optimized for a jack-of-all-trades experience and can make for great, accelerated learning venues. For some, this environment is something to dabble in, just to see how wild the ride is. For others, it’s something to avoid at all costs. And for a small minority, it’s an addictive experience they’ll want repeat many times over.
The term “startup” represent two things—finding the mysterious product-market fit and being able to successfully repeat it at a non-trivial scale.
Finally, the third experience is working at a growing startup. At this stage of the game, the product or service has been vetted and the obstacle is now replication and execution. The startup has raised a healthy chunk of capital that has been earmarked for growth and expansion.
This experience is optimized for those who want to be part of a budding engineering department—this is not a pristine green pasture for cowboys. Process must be established, management becomes a real thing, drama escalates, and technical specialties start becoming delineated.
Anything beyond this level I do not consider a startup. The term “startup” represent two things—finding the mysterious product-market fit and being able to successfully repeat it at a non-trivial scale. Anything after that is a private company.
Private Company
A private company is what startups aspire to be. At the time of writing, some examples include Airbnb, Uber, and Patagonia. These companies are not startups; they are operating companies that aren’t traded on the public stock market.
This stage of a company’s life cycle is defined by many unique circumstances. If a company wants to liquidate, or is strapped for cash, it might file for an Initial Public Offering (IPO) to go public. Some private companies might plan for an acquisition. Other companies like Patagonia—a very successful outdoor clothing company—may choose to stay private indefinitely for personal reasons. The company’s finances, execution aptitude, the energy of its founders, and various other circumstances will influence how long it stays private.
When a company has reached this point in its growth, the engineering experience has been formalized. You will be assigned to a team, have a well-documented workflow, and be a part of the machine. Your task load will be lighter than what you’d expect at a startup. The work assigned to you comes after much deliberation, and there is zero room for cowboys. Many developers who enjoy the do-it-all lifestyle of pumping out two thousand lines of code a day will become bored at this level. The cowboys usually leave to find their next green pasture, moving away from the “official” engineering process.
Big Tech Company
These are the big players you already know about. They are billion-dollar publicly traded companies that have become household names—Amazon, Microsoft, Facebook, Google, Apple. You’ll have a brand to put on your résumé, a huge networking pool, and access to all the world’s resources. Three-hundred-thousand-dollar yearly license for a single piece of software, just because you feel like it? No problem. You’ll be surrounded by smart people, achieve steady career advancement, see your bank account grow, and live a very comfortable life. You’ll become a cog in the machine, but the machine can be an enjoyable place.
While the company might be known for working on cutting-edge technologies, you might be working on maintaining a couple of buttons.
Join a big company when you understand exactly what it will provide you. While the company might be known for working on cutting-edge technologies, you might be working on maintaining a couple of buttons. If your only job was to make sure the Facebook settings page stayed up to date, would you be
satisfied with that work? Huge companies are not places for the extremely ambitious. They are places for brand, networking, comfort, and cash. These are all great things—just make sure you know what you’re getting into.
Big Company / Enterprise
These are gigantic, publicly traded companies that are not primarily tech. As a catch-all phrase, I’ll represent them with the term “enterprise.” Examples include Avis Car Rental, Walmart, Marriot Hotels, and Mount Sinai Hospitals. These companies provide products and services that aren’t technical in nature, but that doesn’t mean they don’t need technical expertise; I guarantee a hospital needs serious IT and programming to service all its patients! These billion-dollar entities need software developers, but their goal isn’t to build rocket ships to land on Mars.
Enterprises carry many of the same characteristics as the big tech players. You’ll have brand recognition, resources, and a cozy life; you just won’t be associated with the tech world. For the true tech companies—Tesla, SpaceX, Akamai—working as an engineer there will automatically label you as extremely technical. Programming for Nike won’t exude the same impression. In reality, the Nike developer could easily be just as skillful, if not more so, than the Tesla developer. However, we shouldn’t dismiss the general perception with regards to the companies you have worked for—the branding is important.
Finally, another major benefit of enterprise employment is the exposure to various non-technical business aspects. Working at Walmart exposes you to supply-chain management. Working at Marriot Hotels exposes you to the hospitality industry. Working at Goldman Sachs exposes you to finance. There is a lot to be learned outside tech, but you won’t be exposed to these parts of life inside a research lab. Whether you’re a technical purist or a jack-of-all-trades polyglot, pick and choose based on your personal preference.
Consulting
Consulting covers a broad spectrum that is tied to the idea of established experts lending out their knowledge. I’ve bucketed consulting firms into two major categories: those who implement, and those who do not.
If no implementation is involved, there will be little need for actual coding. These consultants operate at a high level and employ experienced technologists to give a bird’s-eye view of strategy. This can range from system design, to architecture review, to formulating a technical grand vision.
If you work for a consulting company whose staff advertise themselves as “implementers,” on the other hand, you’ll need to engage in heavy amounts of building. Clients will come and go, and you will provide both expertise and solutions. Once you’re done, the clients own what you’ve developed.
I recommend this avenue to anyone who is technically seasoned and confident providing a high level of expertise to others. I will issue a warning to those who are considering consulting and are still early in their careers. Many of my peers found jobs at large consulting firms, but due to their inexperience, they merely offered pre-meditated solutions that were handed to them by the company. There wasn’t much thinking involved.
Agencies
Agencies are similar to consulting firms, but with a subtle twist—they are not expected to transfer knowledge or deliver abstract solution-building. The client relationship is extremely clear—we are hiring you to build something very specific, for a price, by a certain date.
Agencies often specialize in specific platforms or frameworks. There are agencies that specialize in mobile development and others that specialize in desktop software, for example.
Join an agency if you enjoy sprinting. You will spend six months building a new iOS application for Starbucks, then quickly move on to the next big thing. It might feel empowering to be writing an application for Starbucks, but don’t feel too special—Starbucks employs many agencies to build different versions of their apps.
Join an agency if you don’t mind rapid turnover. You must feel no attachment to your code, because in the end, you own none of it. Top-line revenue dollars will always take priority over code quality; there is no refactoring and there is no cleaning up the technical debt.
Finally, join an agency if you don’t mind inconsistency. The lifestyle of agency employment is highly preferential to the people who bring in the cash. If you’re lucky enough to be on the team that lands the big Disney contract, you’ll be treated like a rock star and get the expensive standing desk you requested. If your department is running on a dry spell and isn’t working on the big-ticket items, then your work—and the way you are treated—will quickly become dull.
Government
Another popular place for software developers to work is in the government. When I was eighteen, I remember the NSA and FBI had booths at our school’s job fair. I applied for an internship with the NSA, and they asked me to fill out a ten-year background check—just in case I was doing anything sinister at age eight!
The gist of government work is simple. It’s highly technical, but agonizingly slow.
The gist of government work is simple. It’s highly technical, but agonizingly slow. You will be working on jets, missiles, and radar. You will be writing real-time, high-performant, meticulously-tested software to make sure the government can do whatever the government wants to do.
There are two main avenues for this line of work. You either work directly for the government, or you work for companies that land huge government contracts. In the U.S., some examples include Boeing, Raytheon, and Lockheed Martin. These are publicly traded companies which receive most of their work and cash from the government. The contracts usually read something like this: “Please build us a next-generation fighter jet and drone in the next five years. Here’s five-hundred million dollars.”
In the United States, a commitment to the government is no laughing matter. I know many people who’ve gotten Top Secret clearance in their twenties—think of Edward Snowden. Though Snowden is an extreme example of life taking some huge unexpected pivots, it serves as a reminder of how serious a government job can be. If you’re suddenly handed top-secret information, what happens when you feel like looking for another job? I don’t want to scare you, but just gently remind you of the gravity of these government positions. For these kind of jobs, there are many aspects to consider outside the technical.
Academic and Research & Development
Another job type for a select few is the highly academic ivory tower. These jobs exist in universities and research and development (R&D) centers within large corporations. You might be a professor pushing the limits of quantum computing or a computer science PhD working on new routing algorithms for Amazon.
The premise of an academic position is a special one. You and your team are inventors tasked with creating tomorrow’s tech. Many of the technologies we take for granted today—desktop interfaces, LTE cellular, C—all came from R&D environments. Big tech companies invest a chunk of their capital into research, in hopes that their engineers will produce something that can eventually make the big bucks. Academic environments aren’t bound by sprints, agile development, or definitive product cycles. They are slow, experimental, and have a degree of expected failure.
Academic positions will also vary widely between universities and huge companies. Working with a professor might entail fundraising, publishing stress, and frequent conference trips. I don’t think there will be any cash problems if you work for Google X’s research department.
The academic position is perfect for someone looking to tinker and shift their attention back and forth between new challenges. It is not for anyone yearning for operational execution. If you love shipping product and getting in front of customers, R&D won’t fit. If you don’t mind banging your head on tables and not thinking twice when your code gets scrapped, then R&D might be the perfect fit.
By Industry
Last, but not least, let’s talk about the job type that isn’t actually a job type. Unique experiences follow unique industries, and a software developer can be employed by any industry. Every industry you can think of—e
ducation, gaming, weddings, real estate, marine biology, clothing, partying, traveling—all need some form of code.
Considering the industry makes a significant difference when you have an affinity towards something particular. What do you love? Let’s say you’ve been a serious gamer for the past fifteen years and you finally decide you can no longer spend every day, from dawn till dusk, wired on Red Bull. It might behoove you to follow the path of gaming and pursue the role of game developer—wouldn’t working at Blizzard be a dream? Work touching our personal interests is extremely rare; take advantage of it if you can.
32: Simplicity [Coding]
In code and in life, we are told to “keep things simple.” This little directive seems obvious, easy even, but fully ingraining it into your skills takes conscious effort.
Software systems are notorious for turning into complex behemoths. Give an innocent project five years, and it will make the bravest of developers cry a little inside. This aspect of software is undeniable, and it’s one of the reasons classical-thinking engineers don’t consider software to be pure engineering. A purist view of engineering will point you to bridges, cars, and skyscrapers. A design is established, the implementation steps are well-defined, and we end up with a well-oiled eight-cylinder engine. Software is not like this. Every aspect of software development lends itself to subjectivity and complexity—a million ways to do one thing, a constant churn of developers in and out of projects, perpetually changing business requirements, tight deadlines, third-party libraries becoming deprecated. The list is endless.
Give an innocent project five years, and it will make the bravest of developers cry a little inside.
It is what it is—the nature of software-building will always be dynamic. To combat this flux, developers must make a consistent and sincere effort to simplify their code. This takes many forms, from periodic refactoring tasks to practical challenges to the status quo, but at the end of the day, every developer must value simplicity.