This Contrarian View Can Make You the Highest Paid Software Engineer in Your Company

Many interesting case studies on the internet show the complex architecture of large companies like Netflix or Slack. You can see on those diagrams many components handling a lot of traffic and serving millions of users.

But beware of that complicated architecture, it is a trap. These companies are massive and have 100s or 1000s of software engineers working and maintaining that infrastructure. This scale does not apply to 99% of companies.

This means it probably doesn’t apply to your company.

This contrarian view will make you stand out. As you must have figured out now, becoming a highly-paid software engineer is not about how much code you can write. It is about how much you understand the business goals and the technical implications of those goals.

The latest and greatest is not usually the best for the product and not for you. Don't be the one recommending the latest fancy tech. 99% of companies operate in very different environments. They need to move fast and change fast. The large infrastructure will stop their progress.

Buzzwords Will Not Get You Far

Many young developers want to work with cutting-edge technology and new tools because they think they can put interesting buzzwords in their CVs. And that doesn't impress the senior managers who understand how to get things done.

This is not the correct way to look at things and is not about buzzwords. It is about successful projects. If you can demonstrate that you use any technology to build a successful application, every potential employer will gladly hire you.

This is usually your ego speaking. You do not have to showcase every technology you have learned. Leave your ego at the door.

An overcomplicated infrastructure is the quickest route to a software meltdown.

The future is lean architecture and streamlining, not cluttering. Overengineering is the silent killer of many promising products.

Overcomplicated Project

Once, I worked on a relatively modest project. The product was designed to serve 10000s of users per day. The company already prepared architecture for the product. It consisted of several application services working with a database, API gateway, authorization component, full-text search engine, and others.

The application services were not optimally designed, so there was much copying back and forth between them.

Another complication was that the infrastructure was self-hosted and was not stable. There were a lot of problems with resources. We had to upgrade machines to allow this complicated architecture function.

The basic requirements for the application were gathered upfront, but a lot was unknown, and the team had to upgrade different parts of the architecture during development.

The team had to adjust some components to work in our scenario - they had to develop special solutions for them.

The idea originally was that the project was new, so it had to be built from scratch “the right way". That's why the architecture was designed to be robust. Or at least that was the intention.

However, the number of users who would use the application was not that large. So, the infrastructure was way too complicated for that load.

In this project, we experienced many anti-patterns of overcomplicated architecture.

Preemptive Complication

The main problem with designing complicated architecture at the beginning is that we don't know the full scope of the problem. When you are building an application from scratch, even if you have collected requirements upfront, you don't know what will come next.

During an iterative application build-up, you will not uncover other requirements that may greatly impact the existing architecture.

When the product is deployed for public use, users use it extensively, and you will see the bottlenecks more clearly. Only at that time will you know what to optimize.

Measurement

The goal is to measure and then optimize the important part of the application.

You should first design and use application performance measurement tools. That will show you what parts of the applications are not responding on time and should be optimized.

Work on calibrating the performance of the application based on data. Until you have some data, it's not your top priority.

New VS Time-tested

It is important to balance between cutting-edge technology and the maintainability and cost-effectiveness of the solution. Use primary, well-tested approaches. Adopting a pragmatic approach can lead to manageable and cost-effective solutions.

Yes, we want to use the best technology, but it can't eliminate business priorities.

Yes, we want to innovate, but don't do that at the expense of the product. Concentrate on the innovation of the product and use tested, boring tech to build that product.

Components that Click Together

I'm a big proponent of using existing tools or solutions to help us build new applications. For example, you should always use existing solutions for authorizations - you don't have to build it yourself.

See what is working and what is not working. You can put various components together, and minute leads to desired results. Here also comes this rule into play. Use whatever is tested and already running in production.

Software engineers from big companies are used to working with big infrastructure projects and want to use the setup from previous jobs. This is not viable for a small company. A small company or startup can build and innovate much faster than a large enterprise.

A small company needs a fast, simple infrastructure to deploy and iterate faster. It cannot be slowed by bloated architecture and complicated integrations.

One of the signs that your architecture is easy to work with is that every developer can run the whole application on their computer.

This way, every developer can test and build and test quickly. They can test multiple components and multiple versions. It is also good for testers because they can run their test environment locally on their computer and test everything extensively.

Ensure you have a setup that is a pleasure to work with and easy to run on your computer. This will lead to faster development and progress with no headaches.

How to Optimize

Simply put - build for the number of users you currently have, not the number of users you wish you had. Be a bit optimistic, maybe, but do not dream about millions of users when you don't have any.

A simple setup is a pleasure to work with and is easy to run on your computer. This will lead to faster development and progress with no headaches. This will help a company address business goals faster and make the product more stable, predictable, and maintainable.

Summary

• Use simple infrastructure

• Measure applications' performance

• Optimize later, but plan for optimal infrastructure early

• Simplify so you can build and deploy faster

• Focus on successful products, not tech buzzwords

Focus on delivering a successful product, not complicated tools and architecture. This is the kind of contribution you should be making to your team.

Initially, you might be the black sheep. But trust me, someone is paying attention. When the time comes for a review, you will be valued better and paid higher because you understand these things. And yes, speak up in meetings.