Anti-patterns from Big Tech that smaller companies should avoid?

1. It is impossible to be, at the same time, a "good engineer" and "difficult to work with". FAANG can hire 30 people to work next to one toxic person so their impact can be 1/30th the pain.

2. Interviewing. FAANG can waste 30+ engineering hours on each candidate because of how much money they can burn. Don't do leetcode interviews. Find someone who you think is good, hire them, if they're not good let them go. Don't make a soul crushing interview process.

3. Open office / an office. It's a complete waste for most startups (unless you're a hardware company and can't send the hardware units to each dev). It's a sunk cost and "back in my day"-ism in FAANG.

In my company actually developing the product features is a low status activity. Everyone strives to be someone who influences how the features are developed - by making platforms, by writing standards, by leading meetings - but it’s understood that you’ll never be promoted or paid well if you’re the one actually coding end-user functionality.

Don’t do that. Center and value the actual software construction; make sure you treat the “meta” as an unfortunately necessary cost rather than the goal.

I would say the biggest practice that smaller companies should not emulate is "rolling your own" otherwise known as "not invented here". For a large FAANG company creating your own versions of things can potentially pay off and if they don't those companies can eat the investment cost with out too much trouble.

Smaller companies should focus on the business problems though instead of rolling their own database, orchestration, or programming language. At a large enough size doing any of those things may pay off but when you are smaller they are just a distraction from your core business.

There is a snarky saying at one of the large tech companies that goes something like "I don't know how to count that low."

When you're facing off against large companies as a smaller player this is one of the tricks you can use for leverage. You can serve the markets that larger companies feel safe ignoring because they are currently small.

They should however be markets that you expect to grow over time.

Paul Graham talks about this in some detail in his essay "do things that don't scale".

http://paulgraham.com/ds.html

Don't try to be a large company.

Large companies suck. They obsess over processes and demand formality.

The best thing about working at a startup is that it's a startup!

At a startup, you can be informal. You can do work that wasn't assigned to you. You can communicate with everyone on the team directly. You can change your planned design and get right to working on those changes.

People think that companies are big because of the convoluted processes they use. It's the other way around.

If you have 100 people to do 95 things, then it makes sense to give every person a specific structured role. Else, why have 100 people at all?

When you only have 30 people to do those 95 things, then your structure not only has to be, but can be much more organic and fluid.

Microservices should be avoided in my humble opinion. The maintenance cost is just too high for small and medium companies.

Don't interview like FAANG unless you're offering the same compensation - otherwise you're going to get a lot of people dropping out of your funnel because the BS isn't worth it for what you're offering.

Kubernetes isn't the be-all and end-all of how to run your applications.

Microservices is an solution to an organisational problem.

Make sure you use it when you need it. Not because others do it.

Developer chapter leads as managers. I believe this is a model from Netflix. It's absolute garbage at my company. I want to say it's because we have IT as a cost center, but it might run deeper than that. Who honesty thinks that making a senuor developer split their time between managing people who aren't on their team and coding for their own team is a good idea?

Off the top of my head:

CI/CD is two processes, not one.

You cannot put code in prod and say you regressed it unless you drop everything in an instrumented environment, and ran everything against it.

Just because you hired a bunch of software engineers, you are not obviated from keeping around someone who knows what they are doing.

There are two faces to Quality: 1-I will negate this suffering 2-I will replace one form of suffering with another, to buy time, and exploit the human tolerance/blindspot for churn and novelty to keep my revenue coming in.

1 is incredibly difficult, expensive, and full of work you just cannot avoid or get around. 2 is easy, modus operandi, and actually synergizes with multiple other business cycles, and is thus considered the "No one ever got fired for buying IBM" route.

If you are not doing 1 you are doing 2 by default.

corporate process - more of a problem in mid size companies, but: installing execs / VPs from large tech companies. they replace all the managers down the chain and stir a bunch of crap up, and usually only the poor performing ICs are left at the end.

using java spring framework