[charred_patina]

I don't want to be negative, but this post reads like a list of things that I want to avoid in my career. I did a brief stint in cloud stuff at a FAANG and I don't care to go back to it.

Right now I'm engineer No. 1 at a current startup just doing DDD with a Django monolith. I'm still pretty Jr. and I'm wondering if there's a way to scale without needing to get into all of the things the author of this article mentions. Is it possible to get to a $100M valuation without needing all of this extra stuff? I realize it varies from business to business, but if anyone has examples of successes where people just used simple architecture's I'd appreciate it.

[extr]

You can scale to any valuation with any architecture. Whether or not you need sophisticated scaling solutions depends on the characteristics of your product, mostly how pure of a software play it is. Pure software means you will run into scaling challenges quicker, since likely part of your value add is in fact managing the complexity of scaling.

If you are running a marketplace app and collect fees you're going to be able go much further on simpler architectures than if you're trying to generate 10,000 AI images per second.

[daxfohl]

Don't need any of it. Start simple. Some may be useful though. The list makes good points. Keep it around and if you find yourself suffering from the lack of something, look through the list and see if anything there would be good ROI. But don't adopt something just because this list says you should.

One thing though, I'd start with go. It's no more complex than python, more efficient, and most importantly IMO since it compiles down to binary it's easier to build, deploy, share, etc. And there's less divergence in the ecosystem; generally one simple way to do things like building and packaging, etc. I've not had to deal with versions or tooling or environmental stuff nearly as much since switching.

[singron]

You don't need this many tools, especially really early. It also depends on the particulars of your business. E.g. if you are B2B SaaS, then you need a ton of stuff automatically to get SOC2 and generally appease the security requirements of your customers.

That said, anything that's set-and-forget is great to start with. Anything that requires it's own care and feeding can wait unless it's really critical. I think we have a project each quarter to optimize our datadog costs and renegotiate our contract.

Also if you make microservices, you are going to need a ton of tools.

[segfaltnh]

Also don't make microservices if you don't have teams that will independently own them.

[krmboya]

I bet you can get pretty far with just ec2 and autoscaling, or comparable tech in other cloud platforms. With a managed database service.

[charred_patina]

That I'd be comfortable with.

[movpasd]

I'm currently early in my career and "the software guy" in a non-software team and role, but I'm looking to move into a more engineering direction. You've pretty much got my dream next job at the moment — if you don't mind me asking, how did you manage to find your role, especially being "still pretty Jr."?

[charred_patina]

What a coincidence! I've got my dream job too!

The things I did to get here are honestly kind of stupid. I started out at a defense contractor after graduating and left in the first six months because all the software devs were jumping ship. Went to a small business defense contractor (yep that's a thing) and learned to build web apps with React and Django. Then the pace of business slowed so after about 18 months I got on the Leetcode grind and got into a FAANG. Realized I hated it, so I quit after about 9 months with no job lined up.

While unemployed I convinced myself I was going to get a job in robotics (I actually got pretty close, I had 3 final level interviews with robotics companies), but the job market went to shit pretty much the exact day I quit my job lol. I spent about 6 months just learning ROS, Inverse Kinematics, math for robotics, gradient descent and optimization, localization, path planning, mapping etc. I taught at a game development summer camp for a month and a half, that was awesome. Working with kids is always a blast. Also learned Rust and built a prototype for a multiplayer browser-based coding game I had been thinking about for a while. It was an excuse to make a full stack application with some fun infrastructure stuff.

https://ai-arena.com/#/multiplayer

The backend is no longer running, but originally users could see their territory on the galaxy grow as their code won battles for them.

For the current role, I really just got lucky. The previous engineer was on his way out for non-job related reasons. He had read a lot of the books I had (Code Complete, Domain Driven Design) and I think we just connected over shared interests and intellectual curiosity.

I think that in the modern day, so many people are really just in this space for the paycheck-- and that's okay! Everyone needs to make a living. But I think that if you have that intellectual curiosity and like making stuff, people will see that and get excited. It ends up being a blessing and a curse.

I have failed interviews because of honesty "I would Google the names of books and read up on that subject" or "I think if I was doing CSS then I would be in the wrong role" (I realize how douchey that sounds but I just was not meant to design things, I have tried). But I have also gone further in interviews than I should have because I was really engrossed in a particular problem like path planning or inverse kinematics and I was able to talk about things in plain terms.

I think it's easier to learn things quickly if they are something you're actually interested in, it becomes effortless. Basically I just try to do that so I can learn optimally, then I try to get lucky.

EDIT: Oh I just thought of more good advice. Find senior devs to learn from. They can be kind of grumpy in their online presence, but they help you avoid so many tar pits. I am in a Discord channel with a handful of senior engineers. The best way to get feedback is to naively say "I'm going to do X", they will immediately let you know why X is a bad idea. A lot of their advice boils down to KISS and use languages with strong typing.

[daxfohl]

I did this myself for a good 15 years or so, but eventually with a family, money became a bit more of a priority, and it's hard to get a good job if all you've worked at is small shops. Any next role in a larger tech company will likely be a downgrade until you can prove yourself out, which of course you may not be able to because things are so different, and motivation will run low because you're being tasked with all the stuff that caused you to leave big tech in the first place. It can be quite miserable to be grouped with a bunch of kids with 3-5 YOE that have no idea how to build something from scratch, and they're outperforming you because they know the system.

In my case it took a good five years and a couple job hops to rebalance. But eventually you get back to a reasonable tech leadership role and back to making some of the bigger decisions to help make the junior devs' lives less miserable.

No regrets, but the five years it takes to rebalance can be pretty hard.

[charred_patina]

I think that my work is honestly the most important factor in my happiness. I spend 8 hours a day (probably for the rest of my life) at work so it's going to be the thing that impacts me the most psychologically in my life.

After realizing that, I decided I'd try as hard as I possibly could to never have to work at a job that I didn't like. I already didn't want kids so that part is easy. The other part of the equation is saving lots of money. I'm not an ascetic by any means, but I live well below my means on a SWE salary which means I can save quite a bit of money each year.

I also recognize that not wanting to go corporate severely limits my options down the line. But capitalism is all about making money for other people. If I can make someone a lot of money, they're not going to care about if I have the chops to stand up a Kubernetes cluster or write a Next.js app or whatever (I hope).

I don't think I'm super smart, I'd say I'm pretty average for this line of work. But I reckon that most SWEs are focused on learning new technologies to get to their next job, or are overly concerned with technical problems. I like to think that I am pragmatic enough about only doing things that are going to deliver business value to make up for being average in smarts.

Anyways, there's not really a point to this rant. These are just some thoughts I have had about optimizing my career for my own happiness, and how I hope I can stay a hot commodity even though I hate working in the cloud and my software skills aren't bleeding edge.

[daxfohl]

Sounds like a good approach to me. I think you'll do fine. Best of luck!

[Arbortheus]

Currently working at a $100M valuation tech company that fundamentally is built on a Django monolith with some other fluffy stuff lying around it. You can go far with a Django monolith and some load balancing.

[AznHisoka]

I bet Craigslist runs on much simpler infrastructure. Not sure how much they’re worth though

[mixmastamyk]

Stackoverflow famously grew huge for a long time on a single Windows box. I don’t recommend that but yeah KISS rule definitely. Floss version: supabase, open telemetry, etc.

[kevinqi]

I work at a startup and most of the stuff in the article covers things we use and solve real world problems.

If you're looking for successful businesses, indie hackers like levelsio show you how far you can get with very simple architectures. But that's solo dev work - once you have a team and are dealing with larger-scale data, things like infrastructure as code, orchestration, and observability become important. Kubernetes may or may not be essential depending on what you're building; it seems good for AI companies, though.

[charred_patina]

How many people if I may ask? And how many TPS for your services? I am hoping I can get away with a simple monolith for a very long time.

[kevinqi]

30-40 people; not much TPS but we're not primarily building a web app; we have event-driven data pipelines and microservices for ML data.

If you're primarily building a web app, a monolith is fine for quite a while, I think. But a lot of the stuff in the post is still relevant even for monoliths - RDS, Redis, ECR, terraform, pagerduty, monitoring/observability.