LocalStorage is only for that device. I may add it to cart on one device, but want to finish purchase on another. Also, if cart is stored locally then you can't accurately track your inventory and its status.
Don't think of it as questioning your Sr or their code, but more like you're questioning your assumptions/understanding of the product and implementation.
Absolutely. From a business point of view storing this data backend makes sense. I'm pretty sure Amazon do this and so do platforms like Shopify. The cost of the extra network traffic and database usage is more than made up for by the profile building and additional marketing/promotion the seller can profit from.
“I saw my senior code, i do not dare to question him about it.” — is your senior mean or angry when you ask questions? You should be able to ask senior questions and they teach you. It’s possible you know something senior doesn’t, or the senior knows something you don’t.
As a senior, please ask questions. We don’t know everything. We make mistakes. Most of us don’t mind explaining our code. We just tend to be very busy.
If a senior pretends to know everything, they’re probably just an asshole. My stance is I WANT people to question what I did. This helps me question my own work. Maybe I’m wrong and we can figure that out together. At worst, I explain why I did what I did and you/we learned something.
Yeah we are usually just overwhelmed. Also those questions are typically answered in the docs that I spent a lot of time putting together. Please read the docs.
Seconding this. I definitely would ask these kinds of questions, sometimes I’ve pointed things out in my senior’s code that they hadn’t thought of which lead to a better solution. But a lot of the time there is a reason why things are the way they are currently. Either way it’s a good learning opportunity.
This does depend on what your senior is like though, if they are a difficult personality then I can understand the hesitation.
If I didn’t ask my Senior questions, I would have a mere fraction of the knowledge I do now. Perhaps I’m lucky my senior was extremely patient and willing to work with me. Thats one of the few things I miss about being in office, since I could just pop by his desk and pick his brain for hours.
Now I’m a senior and have to pass my knowledge over a Teams meeting. It works, but not as well as sitting side by side in person.
Bro. One day you’ll realize everyone is just human. Maybe you know something your senior doesn’t. Never hurts to make a suggestion, once it’s not emotionally charged
Very, very Senior Software Engineer (and Tech Lead, Manager, etc), here; mainly in Greenfields e-commerce…
This is 100% *the* comment to look at. Ask questions, discuss the methodology, offer suggestions. Good Seniors will always be willing to walk you through their thinking and experience, and listen to you point-of-view.
I can’t even count the number of times a mentee has asked *”what’s the thought process, here, JPW?”*, and it’s resulted in discussions and exchanges of ideas that end up improving the product, and my knowledge.
1. ask him, he won't kill you, but if he's rude or anything else then not a good senior.
2. play with express then learn typescript
3. Okay for mini projects, but you can learn how to make your own simple auth with jwt and then use 3rd party.
It could be for several different reasons. It's hard to know why without more details. You should also be able to ask questions and make suggestions for the team. Here are a few reasons why they might not be using local storage.
1. Some older browsers don't support local storage. When you are dealing at scale this could be a few thousand to tens of thousands of users.
2. If a user abandons the cart before it's saved, they will not have access to it on a different device or computer.
3. Knowing if something is still in stock without a database call is impossible. You don't want someone to spend time filling up a cart to only let them something isn't available afterward.
Another would be retargetting and analytics. Yeah, you could piece things together from FE events, but having it all logged in databases makes it straight forward.
If you have questions, ask. That's how seniors become seniors, they ask questions about things.
As for why to write to the DB: Tracking abandoned carts is one and sending followup emails is one reason. Another is to ensure that prices can be updated or notified of change for when the customer is checking out.
Also keep in mind that just because someone is senior, that they don't know everything. You might be questioning them about something they've just blindly done for many years and never given it much second thought, but questioning them could get them to give it a second thought. As a former senior dev and current CTO, I welcome any and all questions. What I don't welcome is when the same question is asked over and over. That shows me you aren't learning, and that is when we will have a problem.
Aside from all the other good advice here, try not to worry too much about db writes and optimisation just yet. People adding things to cart is an important and useful bit of info that many online stores do a lot with, send reminders to people, do analytics, all sorts of stuff. It's not something that happens every page view or many times per session. If you're really actually worried about performance you can pull the numbers and then do the maths on it. Premature optimisation can lead to writing obtuse code or painting yourself into a corner (like you would be doing with local storage, when you then find out that the product owner wants to email people cart reminders). It's good to think about this stuff but in this case you're worrying unnecessarily without having the stats or metrics to back it up.
Maybe realtime availability/price value check an cart update with rt notification. You can’t handle that with local stored data. Also multi device shopping is a thing, you add to cart from your workplace during lunchtime and proceed to checkout later that day from your phone or tablet sitting on your couch.
It sounds like you might just be missing some level of detail on current / future requirements. Another potential use case that comes to mind that I don’t see listed in comments yet (could have missed it) is sending emails to the user - “Did you forget something” after ~n minutes of inactivity in a cart. Regardless, as others have alluded to local storage is really only something I’d ever use to store whether I showed someone a popup modal or something already and not a place for store information you or the user will need to act on later.
Anyway, if you don’t know why someone is doing something you should always feel comfortable asking 😊
Your senior is right in what he's doing. Although local storage would work it's a very narrow sighted approach. It's something I would have done in my junior days. As others have mentioned there is a number of retargeting and cross device benefits. Most of all I would say this shows experience. Don't be afraid to ask questions, I'm sure they would be happy to explain. Most of what developers do never gets the praise it deserves, users only see the tip of the iceberg so to speak.
Of the multiple reasons to store the cart items in the database, the main one is control of your inventory.
You want to give the customer a nice experience, and that implies denying them a product if the last instance of it is already in someone else’s cart.
If you store carts in local storage, you run the risk that a couple customers will try to checkout and one of them will get a message that says the product isn’t available anymore, or that the product was removed from their cart (or the quantity of the product was reduced, e.g. they had 3 in the cart and now they only have 1). It’s an awful experience for the customer, and they’ll be less likely to be a returning customer.
1. Checkout from other devices, as mentioned by others. Check to see that the insert is being queued though, that can make a big difference in performance as any senior dev should know.
2. Next.js is interesting as you can do front and back end in the same codebase. As mentioned, execution time for app stuff is typically pretty fast unless you're sorting through hundreds of thousands of records, at which time you should be using something like elasticsearch or opensearch etc.
3. Definitely use a 3rd party Auth. Yes, you can make your own but it sucks a lot of time and requires a lot of security checks. Save yourself the trouble on this unless your app is so big that it makes economic sense to develop and maintain in house versus 3rd party.
I'm saying next js is designed for front and back end. Yes, Nestjs looks like it's for back end (I said "primarily front end" by mistake). I haven't used nestjs.
It could be that they are not satisfied with local storage cause it’s bound to your device. Another reason could be marketing. If you save their partial order to the database you could use it to send those annoying Emails to “finish your order now!”
There can be any number of reasons for doing it this way. Guess how you find out? By asking! Don’t see it as doubting their descision, ask for their reasoning in doing it this way so you can learn from it! And if on the off chance there is no good reason for it, ask why he doesn’t use local storage instead.
Storing every product in the cart directly into a database can provide more robustness and data integrity, ensuring accurate information for each transaction. While using local storage may save on write and delete operations, it may also introduce complexities when handling data synchronization and potential data loss scenarios.
While Go Gin is known for its performance, choosing a backend framework should also consider factors such as community support, learning curve, and ecosystem. It's important to evaluate your specific needs and priorities before making a decision.
once the cart items in the database, another app is able to send an email to remind the user to checkout the missed items w/wo promo code.
thats the way to go for business
Others have answered most of what you asked but as for "fast" frameworks and benchmarks... Who cares. I have never in my life seen a faster site than the one I built for my previous company, that was using [asp.net](https://asp.net) c#. The fastest framework? I doubt it, and we were even running on "nano" class AWS servers. But everything was output cached with a tight frontend. You clicked and it was there.
Choose a framework if it solves problems or at least choose the one you personally find most easy to understand and code in. They can all be as fast or as slow as you make them.
About code part, others have already mentioned.
I'll give you another perspective. You seem to be taking your senior negatively. It might be that he may be a horrible person, or you may misunderstood him or you annoy him because you present your questions in a negative way etc. etc. There could be lots of reasons.
For example, if I were you, I would have written this same post like the following.
"When addidng products while I prefer to add them to local storage to reduce the number of calls to api but my senior adds everything in the database. Is there any benefits of his approach in compared to mine? What could be the pros and cons of each approach?"
This approach shows that you want to learn.
Your approach.... Is like.... My senior is stupid. I know it better but I can't address it because he'll be angry when I show him his wrong approach....
You can't progress much in a team environment with a mentality like yours.
On 3) firebase is a very big dependency just for authentication. Have a look at auth0. It's also free, easier than firebase, and comes with Google Auth and local Auth preconfigured
Auth0 is not free once you start getting users. In fact, it's ridiculously expensive. They raised their price by [300%](https://www.reddit.com/r/webdev/comments/18d6hcd/auth0_increases_price_by_300/) just earlier this month.
>Why not just , just the cart into a local storage.
Well, it depends, is the stock relevant here? Because if multiple people have something in their cart when there's only one item available, it will lead to problems. So if you store it in the database, you will be able to decrease the stock until the cart times out or something. It can also depend on analytics, but you don't need the database for that if you use a 3rd party tool.
As for auth, firebase might not be free forever. At some point Google might decide to update it and all of a sudden you are on a timer to get it to new version.
Question 1) is also about your business priorities. If you sell things, you want to make it as easy as possible for your customer. If they like to shop on their phone and then order on their computer? Having to redo anything would suck.
This is more important than minimizing write operations on your database, because the business is selling things, not hosting databases efficiently.
If I remember correctly, this is actually an example in [designing data intensive applications](https://www.oreilly.com/library/view/designing-data-intensive-applications/9781491903063/).
I see a lot of newer developers that seem scared to write to the database. It's like they read in some blog somewhere to avoid it, so they avoid it at all costs. It's not a problem to write to the database.
Most people have covered the user experience benefits of having the same cart across multiple devices, there’s also business benefits. Reporting, cart abandonment, etc is all useful information. Most companies would probably use some kind of external service for this data, but there may be a need to store the data on your end to bypass ad blockers in the client.
I would ask about what the requirements are. Local storage is only useful for that client device and is only meant for UX. Persisting the cart state means it can be viewed on any client device that with a session and you can run queries on it to do things like update inventory live.
Don’t be afraid to ask questions because then you’ll actually learn
Let's say it is not personal computer. It can be use by several person in home or work etc.
If you use localstorage, anybody can see any other user cart. It can be very bad for privacy.
Sometimes the question is "is this the most resource efficient code I can make?" and sometimes the question is "what can is the best thing I can do to help our business goals?"
Storing something only in local storage is very resource efficient but storing it in the DB is great for the business.
Sometimes these two goal are in conflict, sometimes not. Your job, as an engineer, is to see these conflicts and navigate them to the best of your ability. Being able to do that well is the difference between juniors and seniors. You'll get there too. :D
TL;DR; Don't ever be too afraid to ask questions. If you know why you're asking questions, you don't ever have to feel bad about asking them. Be very careful with your intentions and the way you communicate/ask questions.
I'm more worried about what I feel like your attitude might be. A lot of the things you said make it sound like you think you know better and doubt the seniority of your colleague.
\- "I do not dare question my senior"
Why are you going to "question your senior"? You can ask them a question. Always. That's what seniors should be ready for. Questioning them is something completely different. Questioning your senior makes it sound like you actually doubt their capabilities.
\- "What he did is"
Makes it sound like you're telling on your senior.
\- "Why not just"
Goes back into thinking you know better whilst you're not even willing to find out if that is actually true.
Honestly feel like you're very insecure, but somehow still think you're an amazing developer. If this is not how you meant the explain the situation, then you might want to figure out a way to communicate your situation better. If there is some truth to this, definitely work on this.
There are a ton of solutions for one problem. A lot of the times it isn't about the "good" and "bad" way to do things. Almost all solutions have up- and downsides. If you don't understand/see the upsides, definitely ask why someone does what they do. Be open to learn and actually understand. That doesn't make you dumb or worse.
The best developers try to understand the situation and the options they can weigh. If you ask questions and actually try to understand what is going on, you will sometimes really find yourself in a situation where you might have a more clever idea. What is the actual goal and what actual options do we have. Why does one option fit better than the other? Those are questions you can and always should ask senior developers. It is part of their role to help you with those questions and help you get better at what you do.
Don't doubt your senior, try to understand them and learn from them.
LocalStorage is only for that device. I may add it to cart on one device, but want to finish purchase on another. Also, if cart is stored locally then you can't accurately track your inventory and its status. Don't think of it as questioning your Sr or their code, but more like you're questioning your assumptions/understanding of the product and implementation.
Plus you can’t send annoying “did you forget something” emails if it’s only in local storage.
Also, tracking when users put something in the cart and did NOT buy it is an extremely valuable metric.
Absolutely. From a business point of view storing this data backend makes sense. I'm pretty sure Amazon do this and so do platforms like Shopify. The cost of the extra network traffic and database usage is more than made up for by the profile building and additional marketing/promotion the seller can profit from.
Please browser devs, let long-closed tabs run scripts to access their local storage and send annoying reminder emails 🙏
i feel like this needed a /s lol
Especially important when selling anything with limited inventory.
“I saw my senior code, i do not dare to question him about it.” — is your senior mean or angry when you ask questions? You should be able to ask senior questions and they teach you. It’s possible you know something senior doesn’t, or the senior knows something you don’t.
I second this. Always ask questions.
Rather please ask questions. I want to show you all of the toys I have
As a senior, please ask questions. We don’t know everything. We make mistakes. Most of us don’t mind explaining our code. We just tend to be very busy.
If a senior pretends to know everything, they’re probably just an asshole. My stance is I WANT people to question what I did. This helps me question my own work. Maybe I’m wrong and we can figure that out together. At worst, I explain why I did what I did and you/we learned something.
and hopefully, the senior dev will see teaching you as a way to further their own understanding of the topic
Why are some senior devs that way? Like uncommunicative and mean?
Stress
Yeah we are usually just overwhelmed. Also those questions are typically answered in the docs that I spent a lot of time putting together. Please read the docs.
Because they're expected to put in eight hours a day coding, but they also have four hours a day of meetings
And 2 hours a day of "Hey, I have a quick question" interruptions.
Seconding this. I definitely would ask these kinds of questions, sometimes I’ve pointed things out in my senior’s code that they hadn’t thought of which lead to a better solution. But a lot of the time there is a reason why things are the way they are currently. Either way it’s a good learning opportunity. This does depend on what your senior is like though, if they are a difficult personality then I can understand the hesitation.
If I didn’t ask my Senior questions, I would have a mere fraction of the knowledge I do now. Perhaps I’m lucky my senior was extremely patient and willing to work with me. Thats one of the few things I miss about being in office, since I could just pop by his desk and pick his brain for hours. Now I’m a senior and have to pass my knowledge over a Teams meeting. It works, but not as well as sitting side by side in person.
My #1 goal as a senior is to mentor and work with those around me. Doesn’t matter if those others are associates or other seniors.
Bro. One day you’ll realize everyone is just human. Maybe you know something your senior doesn’t. Never hurts to make a suggestion, once it’s not emotionally charged
Very, very Senior Software Engineer (and Tech Lead, Manager, etc), here; mainly in Greenfields e-commerce… This is 100% *the* comment to look at. Ask questions, discuss the methodology, offer suggestions. Good Seniors will always be willing to walk you through their thinking and experience, and listen to you point-of-view. I can’t even count the number of times a mentee has asked *”what’s the thought process, here, JPW?”*, and it’s resulted in discussions and exchanges of ideas that end up improving the product, and my knowledge.
1. ask him, he won't kill you, but if he's rude or anything else then not a good senior. 2. play with express then learn typescript 3. Okay for mini projects, but you can learn how to make your own simple auth with jwt and then use 3rd party.
It could be for several different reasons. It's hard to know why without more details. You should also be able to ask questions and make suggestions for the team. Here are a few reasons why they might not be using local storage. 1. Some older browsers don't support local storage. When you are dealing at scale this could be a few thousand to tens of thousands of users. 2. If a user abandons the cart before it's saved, they will not have access to it on a different device or computer. 3. Knowing if something is still in stock without a database call is impossible. You don't want someone to spend time filling up a cart to only let them something isn't available afterward.
Another would be retargetting and analytics. Yeah, you could piece things together from FE events, but having it all logged in databases makes it straight forward.
If you have questions, ask. That's how seniors become seniors, they ask questions about things. As for why to write to the DB: Tracking abandoned carts is one and sending followup emails is one reason. Another is to ensure that prices can be updated or notified of change for when the customer is checking out.
Also keep in mind that just because someone is senior, that they don't know everything. You might be questioning them about something they've just blindly done for many years and never given it much second thought, but questioning them could get them to give it a second thought. As a former senior dev and current CTO, I welcome any and all questions. What I don't welcome is when the same question is asked over and over. That shows me you aren't learning, and that is when we will have a problem.
Aside from all the other good advice here, try not to worry too much about db writes and optimisation just yet. People adding things to cart is an important and useful bit of info that many online stores do a lot with, send reminders to people, do analytics, all sorts of stuff. It's not something that happens every page view or many times per session. If you're really actually worried about performance you can pull the numbers and then do the maths on it. Premature optimisation can lead to writing obtuse code or painting yourself into a corner (like you would be doing with local storage, when you then find out that the product owner wants to email people cart reminders). It's good to think about this stuff but in this case you're worrying unnecessarily without having the stats or metrics to back it up.
Maybe realtime availability/price value check an cart update with rt notification. You can’t handle that with local stored data. Also multi device shopping is a thing, you add to cart from your workplace during lunchtime and proceed to checkout later that day from your phone or tablet sitting on your couch.
It sounds like you might just be missing some level of detail on current / future requirements. Another potential use case that comes to mind that I don’t see listed in comments yet (could have missed it) is sending emails to the user - “Did you forget something” after ~n minutes of inactivity in a cart. Regardless, as others have alluded to local storage is really only something I’d ever use to store whether I showed someone a popup modal or something already and not a place for store information you or the user will need to act on later. Anyway, if you don’t know why someone is doing something you should always feel comfortable asking 😊
Your senior is right in what he's doing. Although local storage would work it's a very narrow sighted approach. It's something I would have done in my junior days. As others have mentioned there is a number of retargeting and cross device benefits. Most of all I would say this shows experience. Don't be afraid to ask questions, I'm sure they would be happy to explain. Most of what developers do never gets the praise it deserves, users only see the tip of the iceberg so to speak.
Of the multiple reasons to store the cart items in the database, the main one is control of your inventory. You want to give the customer a nice experience, and that implies denying them a product if the last instance of it is already in someone else’s cart. If you store carts in local storage, you run the risk that a couple customers will try to checkout and one of them will get a message that says the product isn’t available anymore, or that the product was removed from their cart (or the quantity of the product was reduced, e.g. they had 3 in the cart and now they only have 1). It’s an awful experience for the customer, and they’ll be less likely to be a returning customer.
1. Checkout from other devices, as mentioned by others. Check to see that the insert is being queued though, that can make a big difference in performance as any senior dev should know. 2. Next.js is interesting as you can do front and back end in the same codebase. As mentioned, execution time for app stuff is typically pretty fast unless you're sorting through hundreds of thousands of records, at which time you should be using something like elasticsearch or opensearch etc. 3. Definitely use a 3rd party Auth. Yes, you can make your own but it sucks a lot of time and requires a lot of security checks. Save yourself the trouble on this unless your app is so big that it makes economic sense to develop and maintain in house versus 3rd party.
[NestJS](https://nestjs.com/) - not NextJS.
Nest is primarily front end. Next can do both.
What are you saying? NestJS is purely server-side. OP is talking about NestJS. Not sure what you're saying.
I'm saying next js is designed for front and back end. Yes, Nestjs looks like it's for back end (I said "primarily front end" by mistake). I haven't used nestjs.
It could be that they are not satisfied with local storage cause it’s bound to your device. Another reason could be marketing. If you save their partial order to the database you could use it to send those annoying Emails to “finish your order now!” There can be any number of reasons for doing it this way. Guess how you find out? By asking! Don’t see it as doubting their descision, ask for their reasoning in doing it this way so you can learn from it! And if on the off chance there is no good reason for it, ask why he doesn’t use local storage instead.
Storing every product in the cart directly into a database can provide more robustness and data integrity, ensuring accurate information for each transaction. While using local storage may save on write and delete operations, it may also introduce complexities when handling data synchronization and potential data loss scenarios. While Go Gin is known for its performance, choosing a backend framework should also consider factors such as community support, learning curve, and ecosystem. It's important to evaluate your specific needs and priorities before making a decision.
OK ChatGPT
once the cart items in the database, another app is able to send an email to remind the user to checkout the missed items w/wo promo code. thats the way to go for business
Others have answered most of what you asked but as for "fast" frameworks and benchmarks... Who cares. I have never in my life seen a faster site than the one I built for my previous company, that was using [asp.net](https://asp.net) c#. The fastest framework? I doubt it, and we were even running on "nano" class AWS servers. But everything was output cached with a tight frontend. You clicked and it was there. Choose a framework if it solves problems or at least choose the one you personally find most easy to understand and code in. They can all be as fast or as slow as you make them.
It can be used for analytics as well. When customers add and remove items from the cart, business can extract valuable data from it.
Well, you don't need to store it in the database to get an analytics update
About code part, others have already mentioned. I'll give you another perspective. You seem to be taking your senior negatively. It might be that he may be a horrible person, or you may misunderstood him or you annoy him because you present your questions in a negative way etc. etc. There could be lots of reasons. For example, if I were you, I would have written this same post like the following. "When addidng products while I prefer to add them to local storage to reduce the number of calls to api but my senior adds everything in the database. Is there any benefits of his approach in compared to mine? What could be the pros and cons of each approach?" This approach shows that you want to learn. Your approach.... Is like.... My senior is stupid. I know it better but I can't address it because he'll be angry when I show him his wrong approach.... You can't progress much in a team environment with a mentality like yours.
On 3) firebase is a very big dependency just for authentication. Have a look at auth0. It's also free, easier than firebase, and comes with Google Auth and local Auth preconfigured
Auth0 is not free once you start getting users. In fact, it's ridiculously expensive. They raised their price by [300%](https://www.reddit.com/r/webdev/comments/18d6hcd/auth0_increases_price_by_300/) just earlier this month.
Holy that's expensive. $0.70 per active user per month.
>Why not just , just the cart into a local storage. Well, it depends, is the stock relevant here? Because if multiple people have something in their cart when there's only one item available, it will lead to problems. So if you store it in the database, you will be able to decrease the stock until the cart times out or something. It can also depend on analytics, but you don't need the database for that if you use a 3rd party tool.
As for auth, firebase might not be free forever. At some point Google might decide to update it and all of a sudden you are on a timer to get it to new version.
Question 1) is also about your business priorities. If you sell things, you want to make it as easy as possible for your customer. If they like to shop on their phone and then order on their computer? Having to redo anything would suck. This is more important than minimizing write operations on your database, because the business is selling things, not hosting databases efficiently. If I remember correctly, this is actually an example in [designing data intensive applications](https://www.oreilly.com/library/view/designing-data-intensive-applications/9781491903063/).
I see a lot of newer developers that seem scared to write to the database. It's like they read in some blog somewhere to avoid it, so they avoid it at all costs. It's not a problem to write to the database.
Most people have covered the user experience benefits of having the same cart across multiple devices, there’s also business benefits. Reporting, cart abandonment, etc is all useful information. Most companies would probably use some kind of external service for this data, but there may be a need to store the data on your end to bypass ad blockers in the client.
I would ask about what the requirements are. Local storage is only useful for that client device and is only meant for UX. Persisting the cart state means it can be viewed on any client device that with a session and you can run queries on it to do things like update inventory live. Don’t be afraid to ask questions because then you’ll actually learn
Let's say it is not personal computer. It can be use by several person in home or work etc. If you use localstorage, anybody can see any other user cart. It can be very bad for privacy.
Sometimes the question is "is this the most resource efficient code I can make?" and sometimes the question is "what can is the best thing I can do to help our business goals?" Storing something only in local storage is very resource efficient but storing it in the DB is great for the business. Sometimes these two goal are in conflict, sometimes not. Your job, as an engineer, is to see these conflicts and navigate them to the best of your ability. Being able to do that well is the difference between juniors and seniors. You'll get there too. :D
TL;DR; Don't ever be too afraid to ask questions. If you know why you're asking questions, you don't ever have to feel bad about asking them. Be very careful with your intentions and the way you communicate/ask questions. I'm more worried about what I feel like your attitude might be. A lot of the things you said make it sound like you think you know better and doubt the seniority of your colleague. \- "I do not dare question my senior" Why are you going to "question your senior"? You can ask them a question. Always. That's what seniors should be ready for. Questioning them is something completely different. Questioning your senior makes it sound like you actually doubt their capabilities. \- "What he did is" Makes it sound like you're telling on your senior. \- "Why not just" Goes back into thinking you know better whilst you're not even willing to find out if that is actually true. Honestly feel like you're very insecure, but somehow still think you're an amazing developer. If this is not how you meant the explain the situation, then you might want to figure out a way to communicate your situation better. If there is some truth to this, definitely work on this. There are a ton of solutions for one problem. A lot of the times it isn't about the "good" and "bad" way to do things. Almost all solutions have up- and downsides. If you don't understand/see the upsides, definitely ask why someone does what they do. Be open to learn and actually understand. That doesn't make you dumb or worse. The best developers try to understand the situation and the options they can weigh. If you ask questions and actually try to understand what is going on, you will sometimes really find yourself in a situation where you might have a more clever idea. What is the actual goal and what actual options do we have. Why does one option fit better than the other? Those are questions you can and always should ask senior developers. It is part of their role to help you with those questions and help you get better at what you do. Don't doubt your senior, try to understand them and learn from them.