What projects actually force senior-level engineering thinking?
Posted by BowlerPretend4090@reddit | ExperiencedDevs | View on Reddit | 112 comments
\~5 YOE full-stack. Built a CRM with VoIP (calls, tasks, deals, etc.), but most of my work still looks like CRUD from the outside.
I’m trying to close the gap to senior-level engineering.
Looking for 2–3 project ideas that force:
- real system design trade-offs
- failure modes / reliability thinking
- async or distributed patterns
Not interested in features — interested in problems.
What projects would you suggest, and what actually makes them hard?
Also: what’s the difference between a mid-level vs senior implementation of the same system?I’m considering things like event-driven systems or real-time collaboration, but not sure what actually stretches you the most.
Basic-Kale3169@reddit
As someone who has managed and promoted people from intern to staff, here is the quickest path to become a true good engineer. It’s also the hardest and the least rewarding.
Work on any tickets with bugs on production, whether it’s in the infrastructure, the codebase, the pipeline.
It’s a pain in the ass, but there is nothing that will make you grow faster.
If all you care about is to polish your CV and become a paper senior, disregard this advice.
programmerman9000@reddit
I’m trying to close the same gap.
What I’ve noticed in my team is that what makes the senior engineers seniors isn’t really about what they are working on or what they have worked on. It’s something about how they think. Their mind goes to places where mine often doesn’t.
A lot of it feels like asking “why”, but thoughtfully. The seniors are better at avoiding complexity, or more like, better at seeing complexity from a mile away. They also seem to have put a lot of effort into understanding both the code base and the business, and they actively draw from a larger reservoir of information and contribute to it.
They are good engineers with plenty of experience who can speak knowledgeably about the technical side of things but I don’t feel like that’s what makes them seniors. It’s about paying attention to detail more than anything else.
RandomPantsAppear@reddit
It’s trauma. Years and years of watching systems, businesses, and products get fucked up and then being the dude who had to unfuck it.
You start to pick up on the little whispers in the wind that feel every so slightly similar to the fuckery that fucked you before.
Then you take a deep breath, convert that situation into your present situation, remove all the cuss words and make it professional, and like magic: you’re talking like a senior engineer
captcrax@reddit
This is a dirtier and more poetic version of the answer I've been giving people for years. Thank you.
stingraycharles@reddit
Oh this hits the nail on the head. So much trauma from overcomplicated systems. And it’s often a death by a thousand cuts; all these abstractions that only have a single implementation, and/or where just duplicating the code twice would be more than sufficient.
To be clear: all of us seniors went through these phases in life before, we just learned that it’s pure aesthetics that actually increase complexity, make it harder for others to understand the code, and in the end don’t serve any business goals.
B-Con@reddit
This is why YOE is a soft requirement for having senior level judgement. It's hard to simulate.
I've seen folks with senior level projects on paper but little experience and they make very questionable real world decisions.
RandomlyMethodical@reddit
It requires a variety of experience as well. I worked almost 5 years at one place and got less experience than I did in one year at an another.
I’d also say it’s easier to get more experience at a fast growing company (doesn’t need to be a startup either).
minusfive@reddit
This is correct. And like any trauma it means that detection happens unconsciously, and your brain just follows that guttural feeling. Technical experience helps navigating around those icebergs sometimes, but it’s not guaranteed. The instinct helps you detect them earlier.
RandomPantsAppear@reddit
Yes! A joke I used to tell, is about the buttcheek rule.
To find your most experienced engineers a room, start talking about home rolling a billing system. Take note of everyone who just grew 2-4 inches from their buttcheeks clenching together, and you have found your senior engineers.
namenotpicked@reddit
Lol. This is how I felt when I was told we needed to move our Fortune 500 company billing/invoicing processes internally and I'll only get under 6-8 months to do it with just me full time and 2 very part time guys assisting.
RandomPantsAppear@reddit
Just vibe code it, it will be fine 😂
namenotpicked@reddit
"Recreate. No mistakes."
hundo3d@reddit
I was gonna say “don’t forget to say ‘no mistakes’”. But you got it, so no feedback. This is the answer!
Forsaken-Promise-269@reddit
Yes the great irony is that the tech world is full on ageist and regards graybeards or those over 40 with scorn - you’d think those who have experienced the last 5 Re platforms or new tech sweeps would have some memory of the last time it was attempted..
CandidateNo2580@reddit
This is funny to me. It's the classic "What's the difference between a proof of concept and a production system?" There is no difference. So that PoC better be extensible in the right way if you think it'll get mass adopted and there's no way to fully understand the pros and cons of that until you've had to scale one too many un-scalable designs.
Of course it doesn't need to scale now because that would be a waste of time. I think the application of nuance and delicate planning from that kind of experience is what creates invaluable engineers.
Soft-Stress-4827@reddit
yeah here is an example. A newer engineer was going to deploy a new instance of railway for each of our customers to give them all a 'novel' subapp experience. I asked him why he didnt just make one app and 'multiplex it' with an architecture, similar to how MySpace did it 18 years ago.
He rethought it and saved us probably 50 hours of devops and headaches
shlock2000@reddit
This is it. Watch a product evolve long enough and you see what worked, what didn't and what was a colossal mistake. You'll automatically start asking questions that make sense lol.
aj0413@reddit
Yes. I’m working my way towards staff/principal and people constantly are surprised on how I troubleshoot or seem to immediately infer issues or appreciate my strong opinions on things
It all just comes from taking the time to dive into the code, figure out how all the moving pieces fit together, staying glued to the industry news (especially as it relates to my tech stack), and continually asking myself “why did this break? How can it break? What was the underlying causes? How can I avoid this going forward?”
As others have said:
Trauma. I’m tired of late night on-call or everyone panicking when a node in the cluster goes down man. I just want this stuff to work so I can have a chill work day
Klinky1984@reddit
Being opinionated and getting shit done with minimal hand holding is effectively senior level. While there are those who can do the latter, I find many struggle with the former. It's often crickets when it comes to giving an opinion, sometimes that's from apathy being in an environment where creating problems is easier than solutions, so "what's the point?" creeps in to everyday thinking.
Sheldor5@reddit
you have to ask "why" and "how" during each task, dig deeper into everything you don't know yet
e.g. if you integrate Kafka or MongoDB don't simply make it work, do some research about how those things actually work under the hood and in bigger setups
unconceivables@reddit
And before you integrate Kafka or MongoDB, think very hard about whether they are needed or if they are the right solution. Juniors think every shiny new toy is a solution, seniors only add dependencies after carefully considering the tradeoffs.
Sheldor5@reddit
yeah, especially MongoDB ... and then all their documents have tons of RELATIONSHIPS to other documents ..........
curious_corn@reddit
Maybe add a “relationships” document somewhere? 😏
Zestyclose_Onion4242@reddit
Seems like you're describing my tech lead
Pelopida92@reddit
By the time you are senior, you start to recognize that what matters the most are the high-level architecture decisions. And those decisions goes waaay beyond the corebase.
Wonderful-Habit-139@reddit
"They also seem to have put a lot of effort into understanding both the code base and the business" This parts matters a lot.
You should not make the mistake of thinking the high level architecture decisions are the most important. The codebase is equally as important. But it's hard to actually care about both at the same time, which is why a lot of seniors start neglecting it.
But that's just an easier way to do the job. A better job is done when you care about both a lot.
nullpotato@reddit
And that the lack of any high level architecture causes so much pain down the road.
drnullpointer@reddit
> The seniors are better at avoiding complexity, or more like, better at seeing complexity from a mile away.
Yep. There is some sense, when people present something to me, that "hey, this shouldn't be taking this much code/resources/time/work, etc."
Partly this is experience, because you have to be able to instantly, in your head, disassemble the project into parts and then evaluate what you see against what you think *could* have happened instead. If something does not match, I start asking questions.
And partly this is a mindset. Complexity is the biggest enemy of getting projects done on time and budget. So with some experience you realize that it is trying to get everything done as simply as possible that will get you there, not some brilliant piece of engineering.
NekkidApe@reddit
This right here. Disassemble a project, feature or even an issue, bug or incident. Even good and tenured devs keep prodding at things and then go "no idea, let's ask someone".
safetytrick@reddit
Junior engineers think, "Yeah, we can do that!".
Senior engineers think, "Will that solve the problem? What problems will that create?".
zica-do-reddit@reddit
I would suggest high performance, mission critical software (trading etc.)
high_throughput@reddit
For seniors?
zozoped@reddit
That’s a manager’s role
high_throughput@reddit
This is for senior and staff engineers
zozoped@reddit
These guys should identify this misuse of the company resources. The manager is in charge of these shenanigans - and of listening to his senior engineers. If you are doing politics instead of getting other engineers to build product you might just as well ask for a title change.
TheRealMVP__@reddit
I agree with the most upvoted comment honestly, but there must be a way to improve at home. A well designed, optimal but complex infrastructure is not what we aim for, as you should keep everything simple stupid as long as possible, but are born naturally when the need comes. Maybe pick your already built project, the most complex one architecturally, write perf tests and abuse it to hell until something breaks. Then think what you can do to sustain more load, what you missed initially, and then repeat until you get bored.
Db can’t sustain traffic? Check which query is causing most issues. You don’t know? Add better monitoring. Queries improved but new issues arise? Maybe add cache. Notifications kill your service degrading performance of everything else? Maybe try processing them asynchronous. You can also try messing up one random part of the system and checking how the rest reacts. Perhaps going for microservices makes sense, but then you have whole new bag of issues - a new playground. And so on.
drnullpointer@reddit
Async and distributed patterns is something you would want to avoid as much as possible. If you can get the job done with a simple application then that's what you should do.
I am not saying it is bad to seek experience with larger projects. But in my experience if that's the mindset you are starting project with, then you will find a way to make it large and complicated. Sort of Parkinson's law, just applied to project complexity.
Heavy-Report9931@reddit
you went from 200 to 1? so now you have a single point of failure?
the inverse of what you mentioned is also true.
if non async is all you know then you'll be doing non async for everything when a problem could be solved better solved asynchronously.
the whole point of distributed systems is to distribute the data that cannot fit into or be reasonably processed by one machine anymore.
your server is extremely beefy. but there is only so much more room for you to scale vertically. because hardware cost is not linear. and doesn't mongodb asynchronously merge its database pages every now and then? its a problem you'd never be able to solve if you don't even attempt at trying to understand how asynchronous and distributed systems work. look at DNS and how that gets propagated to the entire planet. thats not something 1 server can do
drnullpointer@reddit
> so now you have a single point of failure?
It is a batch system... just spawn one node to do the job.
Heavy-Report9931@reddit
so no one in your team thought to shard the data so instead of having to spin up 1 gigantic expensive ass server.
you could use multiple cheaper servers and process things even faster?.
the irony of this statement. a forest literally being distribution of trees...
and literally having a 20 TB mongo cluster and arguing against distributed systems
how do you think replication/sharding of the data is done in a cluster?
you missed the point entirely. OPs thread is not about "cAlLiNg iN tOo EaRlY" for distrubuted systems. its wanting to learn about them.
and if you actually want anything that has global reach or just want your users be served the data closest to them geographically. its all distributed and async.
the only one not seeing the forest for the trees is you.
because there are problems that go beyond 1 machine and it doesn't even have to be size of the dataset that it tries to solve. the problem simply being latency. e.g CDNs, Mirrors etc.
ok just because you have a "beefier" server at home.
it doesn't mean a server with those specs is not beefy?. Yao Ming is taller than Shaq. it doesn't mean Shaq is short relative to the population.
I really wonder if your company/app gets more successful and now has to process 2-3 times as much data. are you just gonna spin up a new server with 3x more ram and 3x more cores?.
You're supposedly a lead dev and when someone asks
"how do I go beyond what I know now and be able to tackle hard problems?". you tell them don't? interesting style of leadership
drnullpointer@reddit
> so no one in your team thought to shard the data
You assume that all data can be sharded.
Heavy-Report9931@reddit
the guy isn't working in your project Mr/Ms lead developer.
the guy is working on expanding his intellectual horizon.
there isn't a deadline or a jira ticket to it nor is there management breathing down his neck for him to get it done.
and yet. that is all you see
missing the forest for the trees no?
years of corporate and management really sands down the inner child huh?
the husk of a once brimming individual. reduced to meetings and emails.
seems a bit rather reductive.
considering that the problem of getting this comment sent to you over the internet across multiple hops partitioned into multiple messages possibly coming in random order. assembled in correct order. delivered to the correct process and stored into a database replicated across multiple datacenters then rendered into your browser.
is anything but a simple problem lol.
glad I enjoy programming as an actual hobby and my job.
really keeps the inner child going you know? ;)
Heavy-Report9931@reddit
surely the datastore you source that data from has some kind of index? that uses some kind of key? that could be a shard.
load balancing between 2 or more servers so that multiple concurrent batches run in multiple servers to increase throughput?
skies the limit.
my issue with your take is not so much you're argument about distributed systems.
it is true as much as you can defer it.
because there real and difficult problems and cost that come with it.
my issue is OP is not asking for a pragmatic or practical approach to building. the dude is coming in purely for the sake of learning.
and to shut down intellectual curiosity like that. especially coming from someone such as a lead dev yourself? come on.
how is the next generation of devs going to be when their leads shutdown any form of intellectual curiosity all in the name of "practicality"? the dude want's to learn about distributed systems.
if you're not gonna encourage the guy at least don't discourage him.
feed the intellectually hungry. we are starving for people like those these days
drnullpointer@reddit
I am sorry, what do you not understand about "cannot be sharded"? Just because something has an index does not mean it can automatically be sharded.
morgo_mpx@reddit
Financial systems.
Still-Seaweed-857@reddit
for example, this requires the involvement of senior engineers. Consider this example: My Java open-source framework, gzb-one, has an HTTP request QPS of approximately 700k-800k on a single-core pipeline. Note that this is after full framework scheduling, not just
if(url==x)return xx;. If you try to work on such a project, you'll find a whole host of difficulties and challenges. Example 2: Nested callbacks in asynchronous development can also be very confusing at times.jaktonik@reddit
In one word: proactive. It's not projects that make you senior, it's preventing problems and actively helping others do the same. Mentoring and senior go hand in hand
ohwordsentence_@reddit
The irony of the question is that senior level thinking aims to produce a level of system simplicity that would give the appearance of junior architecture
Growth is realizing less is more and YAGNI
NekkidApe@reddit
Simplicity specifically, for maintainability. Will my system work for the next ten years, and would I like to maintain it down the road? A somewhat crazy approach in a core part might look acceptable, but what about the poor soul to change it in a couple of years? A fancy library might look OK, but expect to replace it. twice.
robhaswell@reddit
Once you realise that every system is a state machine of known states and defined transitions between them, you start to yearn for simplicity.
ImpossibleEbb6862@reddit
Assuming the problem is simple. Once you have a lot of users or data there is an irreducible amount of complexity that is not solvable by junior engineers.
Sure there are clever ways to use more basic technologies like postgresql to deal with lots of users. But those solutions are only simple on their surface. Once you start diving into how the technology is being used it becomes clear that a very experienced engineer designed it.
ohwordsentence_@reddit
To answer the question directly. Projects that force the areas of focus mentioned are typically those requiring a platform solution for many internal dev teams. For instance, a near realtime metrics platform
Requires tradeoffs for event streaming framework, data format, reconciliation, enrichment, DQM, anomaly detection, alerting, domain expertise to make sense of the data (if interested in the product side), and collaboration across eng teams
xpingu69@reddit
I would suggest that you find a genuine problem in your life and solve that.
larriche99@reddit
Building non-CRUD projects is just going to teach you new tech or new domain experience but won’t automatically make you senior. It’s mostly about the scale of usage really. For instance, even something as simple as a todo app can give you a whole lot of experience and senior level thinking when you begin to think about how to design it to serve millions of users. Without learning this way, you’re just going to end up learning a bunch of random tech and thinking that you’re becoming senior because you now know about 3 different message broker technologies while in reality you’re not any much better than how you were when you started.
The_0bserver@reddit
When trying to really build for scalability. Where your services actually choke and even with your best thoughts you aren't anywhere close to dealing with that.
Alternatively, some stuff you barely work around /think of? Example : in about a week's time, I need to start building a sandbox environment for either python or go, where ai could write and test python/go code. (This is for a tiny startup, so we don't exactly have a lot of resources to burn through).. PS if you've already done something like this, hit me up with some good resources.
Icy_Cartographer5466@reddit
Lol @ all the axe grinding responses. The answer, obviously, is scale. Until you get to a sufficient scale, you are assembling off the shelf components that work exactly as expected. If you want to grow technically, that means solving problems that don’t have ready to go solutions, and you find that with scale.
Ambitious-Raccoon-68@reddit
Right now im working on a ddos protection service built from the ground up
bacon_cheeseburgers@reddit
20+ YOE here. Possibly unpopular opinion, but "tough projects" don't make a senior. (Deep breath...here we go) What defines a Senior Engineer has more to with soft skills and less to do with technical skills. Of course the tech skills are important, but let's face, just about all of us have the skills for 90% of the work we'll be asked to do. Here's what's more important: are you polite? Are you dependable? Can the business trust you? Are you patient with newer or less experienced team members? I've mentioned somewhere on Reddit that I've seen multiple devs that knew more and were more technically oriented then me (in the sense that they maintained blogs and githbubs, were up to date on the latest tends in software dev work, etc, etc) that were walked out the door at work because they were smug dicks that nobody liked to deal with. I've always tried to be the kind of coworker that I would want to work with.
To sum up, in my experience the tech part has always been the easiest part of the job, and the skills required to succeed and be truly helpful in a corporate environment came more slowly. And I'm still learning that.
I apologize for possibly derailing the conversation; I know you asked about tech projects and I didn't touch on any of that. But to reiterate, IMO tech skills aren't what differentiate a senior engineer from a junior one.
jacretney@reddit
I agree with this massively - focusing purely on hard skills misses a large part of what makes a good senior. In my experience (early-mid stage startups and now more corporate), this is what's helped me:
Understanding why you're building a system. Try to see the system from the perspective of your PMs and SMEs. What do they actually value? What specific problem of theirs are you solving?
Keep those "it'd be better if the system worked like X" ideas in the bag until there’s a real need for them. I sat on the idea of implementing background jobs for months, despite the fact I know it'd make some things better, because there was no appetite for it when I gently floated the idea within the team. When a problem finally presented itself where they were the natural fit, I worked it into the plan. I added technical value while solving a business need and unlocking revenue. And now, it's a tool we can use in the future without needing to sell the idea. It's a win win!
You need to talk to people at all literacy levels. I’ve found a lot of value in having "high-level" discussions with PMs and then translating those into the specific technical requirements my team needs to execute.
In Sprint Reviews / systems demos etc, sales and marketing teams don’t care that you fixed technical debt by rewriting a bunch of if statements into a strategy pattern. They care about the impact on the customer. If you can get them excited about the "what" without boring them with the "how," you'll earn a great reputation outside of your immediate team.
Focusing on these areas over the past year has led to much more visibility in my org and has been incredibly valuable for my career.
AnonimasPaberzis@reddit
you cannot truly optimize tradeoffs when you dont have any users. You do not want to prematurely optimize.
riggiddyrektson@reddit
Spryker does, albeit it takes SOLID a bit too seriously
tiajuanat@reddit
The trick is to look at what your company is doing, and find a way to do it simpler, cheaper, easier to maintain, and maybe even more performant.
It means talking within your company internal stakeholders and not with a few strangers on the internet
mostly_deterministic@reddit
Senior+ level thinking revolves around knowing when to simplify systems. You say you're not looking for features, but that's exactly what should drive more complex solutions. Senior+ knows when those complexities aren't warranted for a given problem set.
That said, if you're looking for hypotheticals, you could try multi-region deployments with regional failover: Users can do to any region and interact with it and should never notice when a single region fails.
RandomPantsAppear@reddit
All roads lead to the enthusiastic abuse of redis lists.
Don’t wanna hear nothing about your Kafka until you’ve told me why this can’t be a redis list.
LongjumpingWheel11@reddit
Aah what have you been building that you think Redis lists solve the problems Kafka does? No where near the reliability, delivery guarantees, or scale that Kafka is intended to solve. If you have a single consumer and limited scale then yeah sure go for it.
RandomPantsAppear@reddit
Lord, I didn’t expect the aggro fan boys.
Again, I am not saying that there is no use case for Kafka. Kafka is great, it is also just overkill for a lot of situations.
A lot of the time you just need a lightning fast thread safe list, shared across multiple hosts and processes that is just going to expand in size if there is an issue with the consumer or the consumer needs an update.
It is elegant, adds very little complexity, and is more than sufficient in a wide variety of use cases.
LongjumpingWheel11@reddit
Not trying to be aggressive just found your comment surprising but interesting. How I perceive Kafka and how i have used it is in heavily distributed systems where an event has multiple side effects and multiple consumers need to react. If people are spinning up Kafka clusters for 1-to-1 communication they are definitely over engineering
Tundur@reddit
Have you been listening to my VC calls?!
That's not an event, that's a request. Can we build an API?
Will anyone else actually want to ever consume these requests except the one system who can process them?
Okay, what service will be consuming these events?
Can I send these payloads over http and save us $1 per request?
Repeat ad nauseum
titpetric@reddit
I only used kafka once, but I'm gonna go with more friendly queue traversal supporting multiple readers and delivery guarantees, latency knobs. Has a UI. And redis has licensing concerns if you want to. Didn't enjoy cluster setups in redis, moved to KeyDB which seems to be dead these days
The redis client in go is like at version v9, the line protocol is now v3? Look, I already used a fork, but if kafka is more convenient to use (has a managed api + admin panel for noobs). It's a damn queue and not 5 other data types and 100 apis to complicate the point
RandomPantsAppear@reddit
My redis list isn’t a SQL table because I’m trying to solve distributed systems problems, not create them.
I never said that there are no uses for Kafka - just that I need to hear really good reasons that a redis list won’t work and Kafka is actually necessary. Very often, people aren’t actually using the features that make Kafka preferable.
Also: Noobs don’t need to be looking at my redis lists. 🤷♂️
titpetric@reddit
The noob may be anyone with access to create topics, access permissions and clicks through a management interface.
Whats redis management interface again?
Redis is a great general datastore, but you're already working around their publish/subscribe features by implementing your own queue over a list. I don't think it's as strong of a fit as you think
mostly_deterministic@reddit
Hah, perfect example.
vibes000111@reddit
In reality the thing that "actually forces" it is being left as the main responsible persn and having no other choice even if it's all way over your head. Then you make a mess of it, do your best to fix it as you go, and make better decisions next time.
CzyDePL@reddit
It sounds like orthogonal issues - you want more complex logic than CRUD, but you mention non functional requirements like reliability and scaling.
You can have complex business logic within technically very simple architecture and vice versa
Ad3763_Throwaway@reddit
System level thinking. The abillity to zoom out and understand the entire picture, instead of just the lines of code you are working on. You need to switch from task solving to problem solving. You won't get promoted for fixing tickets, but you do for solving the underlying problem which creates the tickets.
alexlazar98@reddit
Connect a socket to binance, consume and process the data in some way. Now do the same for multiple other trading data providers. Make it low latency. Make it high availability.
cajmorgans@reddit
Server-side file processing can sometimes be difficult to handle, depending on scale and file formats. Easy to do locally, much harder if you have 5000 users uploading and processing x files at the same time.
termd@reddit
Being a senior dev (a tenured one, not a "senior dev" with 2 years of experience) is about experience and most importantly breaking things.
I've broken little things, I've broken big things. I've caused outages that caused millions of dollars in projected loss and you can bet that I'm pretty careful about not doing that shit again, and will check to see if you're doing the same dumb shit that I did.
Your happy path "I built a thing" doesn't carry the same weight as your architectural decisions that didn't work and you broke everything and now you're in a panicked state trying to figure out how you can address your dumb ass ideas. This is how you think like a senior dev. Cause you did a bad thing, you dont want anyone else to do it, and you see it in the code of some junior dev.
redatheist@reddit
How big is the scale. Building that to be up and working 9-5 for a dozen employees is very different to building it for 1 million requests per second globally. The latter gives you a ton more experience.
pheonixblade9@reddit
anybody can produce a lot of code with complex designs.
seniors are a lot better at solving problems with less code and simpler designs that can be extended later.
dash_bro@reddit
Dealing with messes has taught me more than any principled learning on my own. You need to get a feel for "why not" and that comes by bad engineering. You build and break things enough that you realize what burned you the next time you start over -- just time and experience, imo.
JetsonDad@reddit
I'm surprised you got all those comments to not do what you are wanting to do.
Their advice is good for the here and now, at work probably, but exposing yourself to new tech and patterns is still beneficial in the long run. So when know-it-all Todd pipes up with "our team should build X and only I can do it," you can respond with, "nope, I know that problem and you should solve it by just doing Y," or "do X but with Z or you'll waste so much money!"
I like this guy who over engineers an app with roughly the same goals in mind https://m.youtube.com/watch?v=nYlv0I9Ips0
mjsimpson247@reddit
It's all crud always. It's just how can you make efficient enough for the requirements?
Emotional-Stand9991@reddit
Same here. Trying to go to FSE 2 to 3 this year, my family depends on it. Anything at all is appreciated
Interesting_Debate57@reddit
Truly full stack means that you understand the system, and you don't truly understand the system unless you can:
Comfortably work on kernel code
Have written packet code in C (opening and closing sockets, dealing with the network at the kernel layer, etc.)
Have written all main sections of an rdbms database system (parser, lexer, logical optimizer, physical optimizer, etc.)
Have written pixel-by-pixel numerical code or matrix/vector code where you have to monitor floating point errors.
Some of these are semester-long projects in a typical CS undergrad curriculum, but all can be learned on the fly, it's just less efficient to learn that way.
Debugging those things requires an entirely different set of skills than user-level code.
meaningincode@reddit
This is an interesting question. Not sure if it makes sense to build for a personal project, but as I have worked in multiple distributed systems, I evaluate engineers by seeing how they're able to understand data flow from one system to another. Such a simple problem, yet so difficult when people don't have the ability to think about system thinking.
czx8@reddit
Take what you've built and add 10 million users to it.
anengineerandacat@reddit
I hear implementation, what are you doing for observability and operations?
TheBigLewinski@reddit
It's not the project that "force senior level engineering," it's the scale. And "scale" doesn't just mean volume of users, it means handling complexity.
Scale is the reason Instagram is actually hard to clone. As a functional project, Instagram is relatively simple to replicate, and doesn't really require deep technical knowledge. Upload photos, let other people like and comment, and tack on some DMs.
The complexity arrives, of course, when you have a global audience of hundreds of millions of users spread across the globe. Just to provide surface level examples, you now have a complex administrative problem for handling troublesome uploaders and harassment. Security issues with people trying to break into popular accounts with next-level sophistication. Then there's the metrics collection of assessing engagement of the product, assessing reliability of the platform, the underlying ad platform that serves your actual customers. And then there's handling subpoenas for legal investigations, etc. There's much more.
But even outside of all of that, basic questions like "how do you notify all the followers of a user who has 100 million followers that they have posted new content?" The answer is much different when you have 10K active daily users vs 100 million. Don't forget the product is mission critical and will be constantly updated.
My recommendation, and I know that not everyone will agree and I'm just a stranger on the internet, is just find a simple project and make it complicated. A todo list becomes really complicated if you're designing for 100 million people. Your strategy has to change, fundamentally.
Hopefully, as part of the process, you'll ultimately learn when you're over-engineering vs solving a problem. Though, you may have to learn that the hard way, at least you'll learn it.
You'll ultimately need on the job experience. To that end, you'll need to pursue projects which are slightly above the scale you understand... and fail. Nothing quite solidifies your knowledge like confidently pouring your time and "expertise" into a system architecture, only to have it eviscerated and exposed by real-world users.
Also, books. Even well into the internet age, the best information is not on medium or blogs, its in books. Search Amazon or your favorite bookstore for software architecture books. They aptly named "Fundamentals of Software Architecture" is quite good. There are many others.
Heavy-Report9931@reddit
this question involves a lot of system design and infrastructure.
buy a mini pc and work from there. im going through the same.
learning to provision and allocate resources to a server. adding observability, adding monitoring,. IAC, containerization and orchestration, security/and the whole 9 yards. I even have my own mirror of public repos.
In short try to build the entire infrastructure. It will help you understand how all things work and how load balancing and distributed systems are designed and what technologies use for certain problems.
Ive been having a whale of a time in my home lab with this exercise
ImpossibleEbb6862@reddit
Scale. Work on problems where you have lots of users, lots of data, strict performance requirements, etc. That’s where you really challenge your engineering skills.
SolarNachoes@reddit
The senior engineers know how to add complexity so they can claim an accomplishment and then get that sweet sweet promotion :)
lisnter@reddit
Find yourself a legacy modernization project. These exhibit a lot of attributes you must develop if you’re to become proficient at senior-level thinking. In them you must develop skills in complex planning, data migration, hidden business logic, scale, integrations, process improvement, etc.
These arent projects you do alone either. Youll learn to manage a team of architects, programmers, UI experts, SMEs and executives.
They are fun!
SquiffSquiff@reddit
As others have said, being senior is a way of seeing, not really about technical ability. As u/ohwordsentence_ says:
I try for systems where people don't even realise how simple they are, they just find them to be obvious, can use them essentially immediately, and move on to the actual problem they are trying to solve.
https://o16g.com/manifesto/
dpsbrutoaki@reddit
Do a solutions architecture course and read designing data intensive applications
SansSariph@reddit
Almost any project can become "senior level". It becomes a game of scrutinizing requirements and deeply understanding what the purpose of the product is and what trade-offs are being made or should be considered.
Toy example anyone can do in high school - "build an RPN calculator that works in a terminal" - force yourself to scrutinize it from different (exaggerated, but that's the point) lenses.
Does the calculator need to support other languages? Number systems? Who is using it and for what purposes? Does it need decimal precision? When we ship it, how do we detect experience problems and errors in the wild? Do users need to customize the modes or features?
Should it detect errors and help the user try to fix them? Does it save history? Does history roam? How is history saved? Is it on our cloud? What's the privacy story?
Is it actually easier to build a proper UI instead of text? How are its accessibility features - can low vision or blind users navigate it successfully? Is it themed to the user's OS or browser? Oh shit, browser - is this a web app? How are we hosting it?
So on so forth. The point is to examine these questions and make intentional decisions, cuts, scope decisions. Then you're thinking of the product as part of a system, and the tech that makes it is a subsystem. Then you can make interesting informed decisions.
shifty_lifty_doodah@reddit
You’ll get a million different answers because there is no clearly defined criteria.
All those listicle things are just poking around the core skill of having good intuition for computational problems.
But the key skill is being able to handle all aspects of projects including the people parts. That responsibility is what senior employees get paid the big bucks for, not any single memorized skill.
thatdudelarry@reddit
I'm a senior and I have no idea what I'm doing.
GuyWhoLateForReddit@reddit
If you are currently working for a company, you could proactively look for problems or optimisations, for instance :
- Do non-engineering teams have automation problems ?
- Do engineering team automation problems?
- Can you improve any of your CI or data pipelines?
- Are there inefficiencies like not deleting old data that you no longer need, which can save your company money?
Promotions generally result of your impact.
GuyWhoLateForReddit@reddit
- Are there non-actionable noisy alerts, can you reduce them or remove them?
- Are there gaps in your systems observability can you fix them?
- Can you improve your on-call processes and tools that on-call engineers use?
titpetric@reddit
Growth. Growing and outgrowing with teams of people. Anything on premise much more than cloud.
Being on call with a technical debt riddled project with the authority to fix observed issues, patch and test and so on and so forth. We agreed to some ridiculous on-call criteria initially, and then also did everything to bring it to stability, including policy changes to deploy process, it's a constant game of iteration and you learn every cursed form of code known to man and machine
Mast3rCylinder@reddit
Every system has bottlenecks and tradeoffs, so does yours. Get to know them and try to solve them yourself.
Sometimes it's just bad code that cause high latency/pricing. Can you deep dive there and understand it and might even fix it? Then you are no longer CRUD programmer.
lardsack@reddit
projects that involve networking and complexity
Fair_Local_588@reddit
Unfortunately your experience won’t be really useful until you work on a real project with lots of users and feel the pain of async processing. I’d try transferring internally at your company to a team that handles this. That helped me go from mainly understanding small-scale CRUD apps to having hands-on experience with large processing pipelines and high volume systems.
I suppose you can do it via a pet project but I can’t learn things through that.
originalchronoguy@reddit
Projects with deep technical "theater." You know it is complex when you approach it.
An example is building a self-driving avoidance system using web sockets and webservices.
Build a raspberry pi that runs docker/kubernetes that can coordinate vision (eye avoidance) with propulsion. The vision part is running in python, the navigation and steering done in java/node. All orchestrated through a central brain (hub).
You see middleschooler/high schoolers tackling these things. And you can tell who is instantly a thinker and a problem solver. They know the surface level things but know how to execute with little hand holding or research. This how I taught microservice and containers to teenagers. They see they can run docker operating robotics from code they wrote on their chromebook then running on a pi. It liberates their train of thought that you can use basic python or nodeJS with REST services to do something like build a walking robot.
GoodishCoder@reddit
Senior engineering is less about the what and more about the who when why and hows. Most engineering is CRUD so the fact that it's a CRUD doesn't mean it's an issue.
PothosEchoNiner@reddit
Intentionally choosing a harder way to implement things misses the point and is the opposite of “senior level” thinking. Build solutions that fit the requirements. But if you want some requirements that you can arbitrarily give to your small scale hobby projects for this goal, you can require zero-downtime deployments and multi-instance high availability.
jl2352@reddit
I have a problem at the moment that probably fits. We have this system. It writes data, and there is a dashboard that reads it back. It works. But it’s slow. It’s easy for one dashboard metric to be fine, and the next is timing out.
How do you fix that? Do you tidy up the code, investigate the slow parts, and improve them? Well I have a list of about 20 slow parts. That’s too many to do. What about rewriting it? Why? How do you get buy in? How do you make the project achievable? What do you change it to?
In my case we are doing a different feature people do want. Doing it opens up PoC work on changing to a different system. The new feature works as a stepping stone. There is also a tonne of stakeholder management to deal with fears, and deal with one chap who we know will hate change (he wrote the original but he should have a right to disagree).
Note how I haven’t event spoken about the technologies. As long as it works and isn’t bonkers, it honestly doesn’t matter. These problems are above that.
Gunny2862@reddit
Building a Backstage IDP
Tall-Introduction414@reddit
Challenging projects every programmer should try from Austin Henley.
tldr: Text editor, 2D game - Space Invaders, Compiler - Tiny BASIC, Mini operating system, Spreadsheet (hard!), Video game console emulator (hard!)
Bonus points if you get actual users.
hummus_k@reddit
I think you are conflating what it means to be a senior engineer with gaining deeper technical skills. The two are correlated, but to me a senior engineer is able to first take a step back and understand the why. Why is this system being made and what does it try to accomplish? Once a senior understand that, they then try to find the simplest way to meet that problem statement, creates a straightforward plan to doing so and drives the implementation from end to end. Creating needlessly complex systems because it appears to be what you are supposed to do is the sign of someone who is not yet senior.
Now putting aside the senior stuff, if you just want to get more experience with distributed systems, you could build a basic distributed KV store, or a collaborative text editor. The key here though is to not look up the optimal architecture and go straight to implementing it, but start by yourself so you can grapple intimately with the problems that are inherent to these projects, and iterate as these problems become apparent.
zugzwangister@reddit
Support thousands of current requests with eventual correctness. Do it in half the time you think you should take. Ask somebody else to make seemingly random commits to your code base while you're doing this. Change the underlying requirements halfway through.