How to Survive in 2022 as a Software Engineer

Cutting through modern systems architectures and requirements

Photo by Mihály Köles on Unsplash

In the wee hours of the morning, Rakia fired up her MacBook. She opened the browser and looked for something interesting to read. She scrolled past articles about new software releases. She scrolled past articles about machine learning. She scrolled past articles about AWS.

She was about to bounce over to Substack when a headline caught her eye:

Complexity is killing software developers!

After seeing the author’s name, Rakia was sold. It was a new post from Scott Carey. She loves Carey’s engaging style and the insights he gives. Without hesitating, she clicked on the link.

“Complexity kills,” Lotus Notes creator and Microsoft veteran Ray Ozzie famously wrote in a 2005 internal memo. “It sucks the life out of developers; it makes products difficult to plan, build, and test; it introduces security challenges; and it causes user and administrator frustration.”

If Ozzie thought things were complicated back then, you can’t help but wonder what he would make of the complexity software developers face in the cloud-native era. — Carey wrote.

Rakia enjoyed the article and was proud to have stumbled upon it, though Carey looked — in her eyes — to exaggerate a bit when describing developers’ struggle with today’s infrastructure.

With long years of experience as a software engineer, she isn’t a junior in the field, so she has such a struggle phase behind her. She has a diversity of technical skills under my belt. She has worked as an Angular architect, a technical leader, a trainer for her colleagues, a speaker, and even a preacher for an online community along with her role as a developer.

Yes, she still needs to learn more tools and update some of her know-how, but she’s confident her expertise would allow her to move forward in her career smoothly.

“Have you recovered from Friday’s shock?” asked Andrew with a smile on his face.

“Well, mmm…” murmured Rakia. She didn’t know what to answer. The question itself was a confirmation that she has a monster to tame in front of her.

That was her second day joining her new team, and she was not sure how things would work. It was a pleasurable experience to read about the monster months ago in Carey’s post, but she had never expected what she read about would be her reality.

She looked back at all the years she’d spent learning, failing, and succeeding until she became a senior software engineer and an expert, at least in some fields, and thought to herself:

“A decade and a half of experiences didn’t save me. When I see the system architecture, the tons of tools, dozens of repositories, and the diversity of programming languages ​​and frameworks used in my current job, I feel like a junior who is at the beginning of a steep learning curve… I need to survive a lot of struggles in order to recover my ‘expert’ feeling. Yet, should I do any of it?”

Cloud Native Interactive Landscape
Around 1,000 services in the Cloud Native Interactive Landscape (image source: CNCF)

She used to spend the first days of almost every new experience reviewing and analyzing the source code. Yet, even after weeks in her current position, she hasn’t started reviewing the code properly as she used to.

What was she doing then?

Asking Google. Yes, she was literally asking Mr. Google almost all the time:

  • What is Tasklib?
  • What is Terraform?
  • What does Infrastructure as Code mean?
  • What is Axon Server? How could it replace a relational database and why?
  • What is LocalStack?
  • How could Grafana and Cloudwatch play or fit together?
  • Why some of our Lambdas are written in Python while the other ones are written in Java?
  • What’s the difference between a Lambda and a Fargate? And in which cases is Fargate a better choice than a Lambda?
  • What’s Flask? What does it mean to change a Python app from Lambda to Flask?
  • Does AWS have a service for Flask?

And the list goes on.

Her questions were supposed to be: “How is the tool x used in the project?” and “How are the requirements implemented?”

They became: “What is the tool x?” and “What does the term y mean?”

Instead of understanding how the different features are implemented, she was trying to understand the multitude of building blocks of the system.

The architecture of microservices- and serverless-based system
“Infrafree is a higher-level abstraction enabling feature developers to write infrastructure-free, scalable code.” (image credit)

“In one of the teams I worked on, it took on average of several months to get a new developer onboarded and productive on a microservices-based architecture. An SDK team is put into place to simplify the process.”

“Now, it makes sense,” she murmured, remembering this witness from Ala Shiban, Co-Founder at Klotho, ex-Microsoft, and ex-Riot.

She had a meeting with him last year, where he talked about how the current cloud/infra technologies required hard-to-hire FAANG-level engineers with tech-first expertise instead of a user-centric one, which doesn’t speed up feature development.

“The complexity of modern applications requires back-end developers to master a growing array of tools, technologies, and techniques, from the fundamentals of Linux, scripting languages, logging, and monitoring, to cloud-based networking, service meshes, observability, Kubernetes clusters, and the dreaded YAML files.” — Scott Carey

Curious about how much time would it take until she can become productive, she went to the next help door.

“How much time would I need to prepare and get an AWS certification? Is a week enough?” She asked an old friend who is a specialist in the field.

“A week?!!” He replied.

“If not just 2–3 days 😁,” she said.

“Well, I don’t know if this would be enough for you. But for me, I would need at least one month,” he said, trying not to hurt her over-optimism.

In this age of exponentially growing cloud computing, new paradigms, requirements, and architectural patterns are emerging every day, which led to a sheer number of applications, platforms, and tools that developers need to understand and integrate.

“Amazon web services launched in 2006 with a total of 3 products: storage buckets (S3), compute instances (EC2), and a messaging queue (SQS).

Today it offers a mind-numbing 200+ services (across database, storage, analytics, networking, mobile, compute, management tools, IoT, security, developer tools, and enterprise applications). And what’s most confusing is that many of them appear to do almost the exact same thing. It’s like shopping at a big grocery store where you have different aisles of product categories filled with things to buy that meet the needs of virtually every developer on the planet.”

— Fireship

A comparison between AWS services in 2006 and AWS services in 2022
AWS services (image source, edited by author)

This shift, at an incredibly rapid pace, has changed software engineers’ primary concerns and significantly impacted the way they work.

Managing infrastructure is no more a separate task carried out by admins or operators. It has invaded applications’ source code under the name IaC (Infrastructure as Code). Today, developers have to pull together hundreds of microservices, manage fleets of containers, and set the right configuration, which requires knowing each puzzle piece in a huge SCARY… I mean “dynamic” system.

In this new reality, poor Rakia had a false assumption about her competencies and the state of the market. Most importantly, she had no idea about the pain involved in trying to keep up with the zeitgeist and that she may need treatment for PTSD.

Don’t be like Rakia. Don’t lose yourself in the maze of cloud aisles.

Be a brave software engineer. Make your most significant commitment to set yourself ahead and acquire deep domain knowledge.

Check how a cloud compiler like Klotho can decouple application concerns from the infrastructure ones and update the underlying infrastructure based on application requirements. Who knows, you might become the engineer leading the integration of such a tool in your team to mitigate your system complexity.

Encourage your company to adopt a central platform model and build an internal developer platform. Many organizations, such as Spotify, did so to reduce their tech ecosystem fragmentation, ease individual developers’ cognitive load, and empower their journey into production.

“The blessed or recommended tooling should be easily discoverable. The journey through that tooling should be clear. There should be quality user instructions along the way. And, if users get stuck, where to get support should be obvious.” — Spotify

Waiting until you face the monster to start learning how to tame it is a bad idea. And trust me, I will say, “I told you so.”

Leave a Comment