Mixing
Fear of web-app not being “future-proofâ€
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
I'm a web developer of a small, local SaaS web application. It currently has about a half-dozen clients.
As I continue to design the application, it's become increasingly harder for me to convince myself to commit any time to the project, which has happened in the beginning phase. Having grown attached to the project and the code I've already written, I'm scared that all additional work I commit will be overturned in the near future, when the app turns out to not scale well as the business grows.
As a university student applying for internships, I've had employers question my choice in not using any web frameworks during interviews, which has only caused me to further doubt my previous work. I simply don't know any web frameworks, and don't know which one to start using.
I've landed an internship as a full-stack developer in January, where I'll begin to learn front-end frameworks, but the pressure to finish the app is mounting, and I'm considering scrapping the app completely and starting over, which is something I've done before. The app currently is built in PHP and jQuery (for AJAX calls) and uses MySQL for its database. Any thoughts on how I can overcome this mental block, and to ensure my app will be scalable? Thanks in advance.
web-development web-applications
asked 4 hours ago
cameraguy258
161
New contributor
cameraguy258 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
1
down vote
favorite
I'm a web developer of a small, local SaaS web application. It currently has about a half-dozen clients.
As I continue to design the application, it's become increasingly harder for me to convince myself to commit any time to the project, which has happened in the beginning phase. Having grown attached to the project and the code I've already written, I'm scared that all additional work I commit will be overturned in the near future, when the app turns out to not scale well as the business grows.
As a university student applying for internships, I've had employers question my choice in not using any web frameworks during interviews, which has only caused me to further doubt my previous work. I simply don't know any web frameworks, and don't know which one to start using.
I've landed an internship as a full-stack developer in January, where I'll begin to learn front-end frameworks, but the pressure to finish the app is mounting, and I'm considering scrapping the app completely and starting over, which is something I've done before. The app currently is built in PHP and jQuery (for AJAX calls) and uses MySQL for its database. Any thoughts on how I can overcome this mental block, and to ensure my app will be scalable? Thanks in advance.
web-development web-applications
asked 4 hours ago
cameraguy258
161
New contributor
cameraguy258 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I'm a web developer of a small, local SaaS web application. It currently has about a half-dozen clients.
As I continue to design the application, it's become increasingly harder for me to convince myself to commit any time to the project, which has happened in the beginning phase. Having grown attached to the project and the code I've already written, I'm scared that all additional work I commit will be overturned in the near future, when the app turns out to not scale well as the business grows.
As a university student applying for internships, I've had employers question my choice in not using any web frameworks during interviews, which has only caused me to further doubt my previous work. I simply don't know any web frameworks, and don't know which one to start using.
I've landed an internship as a full-stack developer in January, where I'll begin to learn front-end frameworks, but the pressure to finish the app is mounting, and I'm considering scrapping the app completely and starting over, which is something I've done before. The app currently is built in PHP and jQuery (for AJAX calls) and uses MySQL for its database. Any thoughts on how I can overcome this mental block, and to ensure my app will be scalable? Thanks in advance.
web-development web-applications
asked 4 hours ago
cameraguy258
161
New contributor
cameraguy258 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
I'm a web developer of a small, local SaaS web application. It currently has about a half-dozen clients.
As I continue to design the application, it's become increasingly harder for me to convince myself to commit any time to the project, which has happened in the beginning phase. Having grown attached to the project and the code I've already written, I'm scared that all additional work I commit will be overturned in the near future, when the app turns out to not scale well as the business grows.
As a university student applying for internships, I've had employers question my choice in not using any web frameworks during interviews, which has only caused me to further doubt my previous work. I simply don't know any web frameworks, and don't know which one to start using.
I've landed an internship as a full-stack developer in January, where I'll begin to learn front-end frameworks, but the pressure to finish the app is mounting, and I'm considering scrapping the app completely and starting over, which is something I've done before. The app currently is built in PHP and jQuery (for AJAX calls) and uses MySQL for its database. Any thoughts on how I can overcome this mental block, and to ensure my app will be scalable? Thanks in advance.
web-development web-applications
web-development web-applications
asked 4 hours ago
cameraguy258
161
New contributor
cameraguy258 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 4 hours ago
cameraguy258
161
New contributor
cameraguy258 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 4 hours ago
cameraguy258
161
New contributor
cameraguy258 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 4 hours ago
cameraguy258
161
asked 4 hours ago
cameraguy258
161
161
New contributor
cameraguy258 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
cameraguy258 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
cameraguy258 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
5
down vote
Perfect is the enemy of good.
Or put another way, don't worry about it today. If your app does what it needs to do, then it's fine. It's not a bad thing to rewrite parts of software further down the line; by that point you 1) know more clearly what you're trying to build and 2) know which bits are actually the bottleneck. You could spend an enormous amount of time writing an app which would scale to a million users, but it wouldn't be any better for your current six customers than what you've got today.
answered 4 hours ago
Philip Kendall
4,88811825
Good point. If you spend 2 months trying to make it futureproof to ward off an eventual 1 week rewrite, you've lost 7 weeks of your time. Accept that there will be changes, and future proof it only when it's an almost certainty that it will need to be done.
– Neil
1 hour ago
add a comment |Â
up vote
2
down vote
Any thoughts on how I can overcome this mental block, and to ensure my app will be scalable?
The crux of the issue isn't scalability. The crux of the issue is thinking that you will get it right the first time.
You should focus on writing clean code. Because clean code maximizes convenience when you (inevitably) have to change something in the future. And that's the real goal you should have.
What you're trying to do now is try to think of the perfect code to write. But even if you manage to do that, who says the requirements aren't going to change, or you maybe made your decisions based on wrong information or miscommunication?
You cannot avoid making mistakes, even if they're not your fault. Focus on writing code in which it's easy to change things later, instead of hoping to write code that you won't need to change in the future.
Having grown attached to the project and the code I've already written,
I absolutely sympathize with this sentiment. But getting attached to the code you've written is a problem.
The only thing that should be a constant is your desire to solve a specific problem. How you go about solving that problem is only a secondary concern.
If tomorrow a new tool is released that reduces your codebase by 80%, are you going to be upset that your code is no longer used; or are you going to be happy that your codebase has become smaller and much cleaner/more manageable?
If the former, you have a problem: you're not seeing the solution for the code. In other words, you're focusing on the code and not seeing the bigger picture (the solution it aims to provide).
I'm scared that all additional work I commit will be overturned in the near future, when the app turns out to not scale well as the business grows.
That is a different problem for a different day.
First, you build something that works. Secondly, you improve the code to fix any flaws it may still show. What you're currently doing is holding back on the first task out of fear of then having to do the second task.
But what other option is there? You cannot tell the future. If you spend your time pondering future possibilities, you're going to end up guessing anyway. A guess is always prone to being dead wrong.
Instead, build the application, and prove that there is indeed an issue. And once the issue is clear, then you start addressing it.
To put it another way: Henry Ford never built a car that conforms to 2018 standards/expectations. But if he hadn't built the Model T, a flawed car by modern standards, no one would have started using cars, there would be no car industry, and no one would have had a car that they could then try to improve.
I've had employers question my choice in not using any web frameworks during interviews, which has only caused me to further doubt my previous work.
The important part here is not which framework you're using (any employer who judges you on that is not doing their job properly). The important part here is knowing what you're doing and why you're doing it.
For example, you could be avoiding existing framework specifically because you want to learn why a framework is useful by doing it the hard way first. Or you could be trying to make your own framework.
The only bad answer here is "I don't know", as it shows a lack of making informed decisions. That is a red flag for an employer.
I simply don't know any web frameworks, and don't know which one to start using.
The same problem arises here. The solution is not to think more, but rather to act:
Stop pondering the perfect answer.- Pick a framework. Unless you have a preference, pick a random one. Use a dartboard, roll a die, flip a coin, pick a card.
- Use it.
- Did you like using it? Was there anything you found annoying?
- Look up how to prevent these bad elements. Did you misuse the framework, or is this just how the framework is supposed to work?
- Once you feel you have a grip on the framework (regardless of whether you like it or not), pick a new framework and repeat the cycle.
To read more on this, read The doing mindset > the thinking mindset. The author explains it better than I can.
but the pressure to finish the app is mounting, and I'm considering scrapping the app completely and starting over
Unless the current codebase is an absolutely unmaintainable mess; you're making the opposite decision.
Developers often think that throwing things out would be the better choice. It's a very common feeling. But it is rarely the right choice.
Throwing code out and starting from scratch is like getting stuck in traffic on your way to work, worrying you'll be late to work (miss the deadline), and instead drive home and try driving down the same road again. It doesn't make sense. You may be stuck in traffic, but you're still closer to work than you were when you were at home.
answered 3 hours ago
Flater
4,371817
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
5
down vote
Perfect is the enemy of good.
Or put another way, don't worry about it today. If your app does what it needs to do, then it's fine. It's not a bad thing to rewrite parts of software further down the line; by that point you 1) know more clearly what you're trying to build and 2) know which bits are actually the bottleneck. You could spend an enormous amount of time writing an app which would scale to a million users, but it wouldn't be any better for your current six customers than what you've got today.
answered 4 hours ago
Philip Kendall
4,88811825
Good point. If you spend 2 months trying to make it futureproof to ward off an eventual 1 week rewrite, you've lost 7 weeks of your time. Accept that there will be changes, and future proof it only when it's an almost certainty that it will need to be done.
– Neil
1 hour ago
add a comment |Â
up vote
5
down vote
Perfect is the enemy of good.
Or put another way, don't worry about it today. If your app does what it needs to do, then it's fine. It's not a bad thing to rewrite parts of software further down the line; by that point you 1) know more clearly what you're trying to build and 2) know which bits are actually the bottleneck. You could spend an enormous amount of time writing an app which would scale to a million users, but it wouldn't be any better for your current six customers than what you've got today.
answered 4 hours ago
Philip Kendall
4,88811825
Good point. If you spend 2 months trying to make it futureproof to ward off an eventual 1 week rewrite, you've lost 7 weeks of your time. Accept that there will be changes, and future proof it only when it's an almost certainty that it will need to be done.
– Neil
1 hour ago
add a comment |Â
up vote
5
down vote
up vote
5
down vote
Perfect is the enemy of good.
Or put another way, don't worry about it today. If your app does what it needs to do, then it's fine. It's not a bad thing to rewrite parts of software further down the line; by that point you 1) know more clearly what you're trying to build and 2) know which bits are actually the bottleneck. You could spend an enormous amount of time writing an app which would scale to a million users, but it wouldn't be any better for your current six customers than what you've got today.
answered 4 hours ago
Philip Kendall
4,88811825
Perfect is the enemy of good.
Or put another way, don't worry about it today. If your app does what it needs to do, then it's fine. It's not a bad thing to rewrite parts of software further down the line; by that point you 1) know more clearly what you're trying to build and 2) know which bits are actually the bottleneck. You could spend an enormous amount of time writing an app which would scale to a million users, but it wouldn't be any better for your current six customers than what you've got today.
answered 4 hours ago
Philip Kendall
4,88811825
answered 4 hours ago
Philip Kendall
4,88811825
answered 4 hours ago
Philip Kendall
4,88811825
answered 4 hours ago
Philip Kendall
4,88811825
4,88811825
Good point. If you spend 2 months trying to make it futureproof to ward off an eventual 1 week rewrite, you've lost 7 weeks of your time. Accept that there will be changes, and future proof it only when it's an almost certainty that it will need to be done.
– Neil
1 hour ago
add a comment |Â
Good point. If you spend 2 months trying to make it futureproof to ward off an eventual 1 week rewrite, you've lost 7 weeks of your time. Accept that there will be changes, and future proof it only when it's an almost certainty that it will need to be done.
– Neil
1 hour ago
Good point. If you spend 2 months trying to make it futureproof to ward off an eventual 1 week rewrite, you've lost 7 weeks of your time. Accept that there will be changes, and future proof it only when it's an almost certainty that it will need to be done.
– Neil
1 hour ago
Good point. If you spend 2 months trying to make it futureproof to ward off an eventual 1 week rewrite, you've lost 7 weeks of your time. Accept that there will be changes, and future proof it only when it's an almost certainty that it will need to be done.
– Neil
1 hour ago
add a comment |Â
up vote
2
down vote
Any thoughts on how I can overcome this mental block, and to ensure my app will be scalable?
The crux of the issue isn't scalability. The crux of the issue is thinking that you will get it right the first time.
You should focus on writing clean code. Because clean code maximizes convenience when you (inevitably) have to change something in the future. And that's the real goal you should have.
What you're trying to do now is try to think of the perfect code to write. But even if you manage to do that, who says the requirements aren't going to change, or you maybe made your decisions based on wrong information or miscommunication?
You cannot avoid making mistakes, even if they're not your fault. Focus on writing code in which it's easy to change things later, instead of hoping to write code that you won't need to change in the future.
Having grown attached to the project and the code I've already written,
I absolutely sympathize with this sentiment. But getting attached to the code you've written is a problem.
The only thing that should be a constant is your desire to solve a specific problem. How you go about solving that problem is only a secondary concern.
If tomorrow a new tool is released that reduces your codebase by 80%, are you going to be upset that your code is no longer used; or are you going to be happy that your codebase has become smaller and much cleaner/more manageable?
If the former, you have a problem: you're not seeing the solution for the code. In other words, you're focusing on the code and not seeing the bigger picture (the solution it aims to provide).
I'm scared that all additional work I commit will be overturned in the near future, when the app turns out to not scale well as the business grows.
That is a different problem for a different day.
First, you build something that works. Secondly, you improve the code to fix any flaws it may still show. What you're currently doing is holding back on the first task out of fear of then having to do the second task.
But what other option is there? You cannot tell the future. If you spend your time pondering future possibilities, you're going to end up guessing anyway. A guess is always prone to being dead wrong.
Instead, build the application, and prove that there is indeed an issue. And once the issue is clear, then you start addressing it.
To put it another way: Henry Ford never built a car that conforms to 2018 standards/expectations. But if he hadn't built the Model T, a flawed car by modern standards, no one would have started using cars, there would be no car industry, and no one would have had a car that they could then try to improve.
I've had employers question my choice in not using any web frameworks during interviews, which has only caused me to further doubt my previous work.
The important part here is not which framework you're using (any employer who judges you on that is not doing their job properly). The important part here is knowing what you're doing and why you're doing it.
For example, you could be avoiding existing framework specifically because you want to learn why a framework is useful by doing it the hard way first. Or you could be trying to make your own framework.
The only bad answer here is "I don't know", as it shows a lack of making informed decisions. That is a red flag for an employer.
I simply don't know any web frameworks, and don't know which one to start using.
The same problem arises here. The solution is not to think more, but rather to act:
Stop pondering the perfect answer.- Pick a framework. Unless you have a preference, pick a random one. Use a dartboard, roll a die, flip a coin, pick a card.
- Use it.
- Did you like using it? Was there anything you found annoying?
- Look up how to prevent these bad elements. Did you misuse the framework, or is this just how the framework is supposed to work?
- Once you feel you have a grip on the framework (regardless of whether you like it or not), pick a new framework and repeat the cycle.
To read more on this, read The doing mindset > the thinking mindset. The author explains it better than I can.
but the pressure to finish the app is mounting, and I'm considering scrapping the app completely and starting over
Unless the current codebase is an absolutely unmaintainable mess; you're making the opposite decision.
Developers often think that throwing things out would be the better choice. It's a very common feeling. But it is rarely the right choice.
Throwing code out and starting from scratch is like getting stuck in traffic on your way to work, worrying you'll be late to work (miss the deadline), and instead drive home and try driving down the same road again. It doesn't make sense. You may be stuck in traffic, but you're still closer to work than you were when you were at home.
answered 3 hours ago
Flater
4,371817
add a comment |Â
up vote
2
down vote
Any thoughts on how I can overcome this mental block, and to ensure my app will be scalable?
The crux of the issue isn't scalability. The crux of the issue is thinking that you will get it right the first time.
You should focus on writing clean code. Because clean code maximizes convenience when you (inevitably) have to change something in the future. And that's the real goal you should have.
What you're trying to do now is try to think of the perfect code to write. But even if you manage to do that, who says the requirements aren't going to change, or you maybe made your decisions based on wrong information or miscommunication?
You cannot avoid making mistakes, even if they're not your fault. Focus on writing code in which it's easy to change things later, instead of hoping to write code that you won't need to change in the future.
Having grown attached to the project and the code I've already written,
I absolutely sympathize with this sentiment. But getting attached to the code you've written is a problem.
The only thing that should be a constant is your desire to solve a specific problem. How you go about solving that problem is only a secondary concern.
If tomorrow a new tool is released that reduces your codebase by 80%, are you going to be upset that your code is no longer used; or are you going to be happy that your codebase has become smaller and much cleaner/more manageable?
If the former, you have a problem: you're not seeing the solution for the code. In other words, you're focusing on the code and not seeing the bigger picture (the solution it aims to provide).
I'm scared that all additional work I commit will be overturned in the near future, when the app turns out to not scale well as the business grows.
That is a different problem for a different day.
First, you build something that works. Secondly, you improve the code to fix any flaws it may still show. What you're currently doing is holding back on the first task out of fear of then having to do the second task.
But what other option is there? You cannot tell the future. If you spend your time pondering future possibilities, you're going to end up guessing anyway. A guess is always prone to being dead wrong.
Instead, build the application, and prove that there is indeed an issue. And once the issue is clear, then you start addressing it.
To put it another way: Henry Ford never built a car that conforms to 2018 standards/expectations. But if he hadn't built the Model T, a flawed car by modern standards, no one would have started using cars, there would be no car industry, and no one would have had a car that they could then try to improve.
I've had employers question my choice in not using any web frameworks during interviews, which has only caused me to further doubt my previous work.
The important part here is not which framework you're using (any employer who judges you on that is not doing their job properly). The important part here is knowing what you're doing and why you're doing it.
For example, you could be avoiding existing framework specifically because you want to learn why a framework is useful by doing it the hard way first. Or you could be trying to make your own framework.
The only bad answer here is "I don't know", as it shows a lack of making informed decisions. That is a red flag for an employer.
I simply don't know any web frameworks, and don't know which one to start using.
The same problem arises here. The solution is not to think more, but rather to act:
Stop pondering the perfect answer.- Pick a framework. Unless you have a preference, pick a random one. Use a dartboard, roll a die, flip a coin, pick a card.
- Use it.
- Did you like using it? Was there anything you found annoying?
- Look up how to prevent these bad elements. Did you misuse the framework, or is this just how the framework is supposed to work?
- Once you feel you have a grip on the framework (regardless of whether you like it or not), pick a new framework and repeat the cycle.
To read more on this, read The doing mindset > the thinking mindset. The author explains it better than I can.
but the pressure to finish the app is mounting, and I'm considering scrapping the app completely and starting over
Unless the current codebase is an absolutely unmaintainable mess; you're making the opposite decision.
Developers often think that throwing things out would be the better choice. It's a very common feeling. But it is rarely the right choice.
Throwing code out and starting from scratch is like getting stuck in traffic on your way to work, worrying you'll be late to work (miss the deadline), and instead drive home and try driving down the same road again. It doesn't make sense. You may be stuck in traffic, but you're still closer to work than you were when you were at home.
answered 3 hours ago
Flater
4,371817
add a comment |Â
up vote
2
down vote
up vote
2
down vote
Any thoughts on how I can overcome this mental block, and to ensure my app will be scalable?
The crux of the issue isn't scalability. The crux of the issue is thinking that you will get it right the first time.
You should focus on writing clean code. Because clean code maximizes convenience when you (inevitably) have to change something in the future. And that's the real goal you should have.
What you're trying to do now is try to think of the perfect code to write. But even if you manage to do that, who says the requirements aren't going to change, or you maybe made your decisions based on wrong information or miscommunication?
You cannot avoid making mistakes, even if they're not your fault. Focus on writing code in which it's easy to change things later, instead of hoping to write code that you won't need to change in the future.
Having grown attached to the project and the code I've already written,
I absolutely sympathize with this sentiment. But getting attached to the code you've written is a problem.
The only thing that should be a constant is your desire to solve a specific problem. How you go about solving that problem is only a secondary concern.
If tomorrow a new tool is released that reduces your codebase by 80%, are you going to be upset that your code is no longer used; or are you going to be happy that your codebase has become smaller and much cleaner/more manageable?
If the former, you have a problem: you're not seeing the solution for the code. In other words, you're focusing on the code and not seeing the bigger picture (the solution it aims to provide).
I'm scared that all additional work I commit will be overturned in the near future, when the app turns out to not scale well as the business grows.
That is a different problem for a different day.
First, you build something that works. Secondly, you improve the code to fix any flaws it may still show. What you're currently doing is holding back on the first task out of fear of then having to do the second task.
But what other option is there? You cannot tell the future. If you spend your time pondering future possibilities, you're going to end up guessing anyway. A guess is always prone to being dead wrong.
Instead, build the application, and prove that there is indeed an issue. And once the issue is clear, then you start addressing it.
To put it another way: Henry Ford never built a car that conforms to 2018 standards/expectations. But if he hadn't built the Model T, a flawed car by modern standards, no one would have started using cars, there would be no car industry, and no one would have had a car that they could then try to improve.
I've had employers question my choice in not using any web frameworks during interviews, which has only caused me to further doubt my previous work.
The important part here is not which framework you're using (any employer who judges you on that is not doing their job properly). The important part here is knowing what you're doing and why you're doing it.
For example, you could be avoiding existing framework specifically because you want to learn why a framework is useful by doing it the hard way first. Or you could be trying to make your own framework.
The only bad answer here is "I don't know", as it shows a lack of making informed decisions. That is a red flag for an employer.
I simply don't know any web frameworks, and don't know which one to start using.
The same problem arises here. The solution is not to think more, but rather to act:
Stop pondering the perfect answer.- Pick a framework. Unless you have a preference, pick a random one. Use a dartboard, roll a die, flip a coin, pick a card.
- Use it.
- Did you like using it? Was there anything you found annoying?
- Look up how to prevent these bad elements. Did you misuse the framework, or is this just how the framework is supposed to work?
- Once you feel you have a grip on the framework (regardless of whether you like it or not), pick a new framework and repeat the cycle.
To read more on this, read The doing mindset > the thinking mindset. The author explains it better than I can.
but the pressure to finish the app is mounting, and I'm considering scrapping the app completely and starting over
Unless the current codebase is an absolutely unmaintainable mess; you're making the opposite decision.
Developers often think that throwing things out would be the better choice. It's a very common feeling. But it is rarely the right choice.
Throwing code out and starting from scratch is like getting stuck in traffic on your way to work, worrying you'll be late to work (miss the deadline), and instead drive home and try driving down the same road again. It doesn't make sense. You may be stuck in traffic, but you're still closer to work than you were when you were at home.
answered 3 hours ago
Flater
4,371817
Any thoughts on how I can overcome this mental block, and to ensure my app will be scalable?
The crux of the issue isn't scalability. The crux of the issue is thinking that you will get it right the first time.
You should focus on writing clean code. Because clean code maximizes convenience when you (inevitably) have to change something in the future. And that's the real goal you should have.
What you're trying to do now is try to think of the perfect code to write. But even if you manage to do that, who says the requirements aren't going to change, or you maybe made your decisions based on wrong information or miscommunication?
You cannot avoid making mistakes, even if they're not your fault. Focus on writing code in which it's easy to change things later, instead of hoping to write code that you won't need to change in the future.
Having grown attached to the project and the code I've already written,
I absolutely sympathize with this sentiment. But getting attached to the code you've written is a problem.
The only thing that should be a constant is your desire to solve a specific problem. How you go about solving that problem is only a secondary concern.
If tomorrow a new tool is released that reduces your codebase by 80%, are you going to be upset that your code is no longer used; or are you going to be happy that your codebase has become smaller and much cleaner/more manageable?
If the former, you have a problem: you're not seeing the solution for the code. In other words, you're focusing on the code and not seeing the bigger picture (the solution it aims to provide).
I'm scared that all additional work I commit will be overturned in the near future, when the app turns out to not scale well as the business grows.
That is a different problem for a different day.
First, you build something that works. Secondly, you improve the code to fix any flaws it may still show. What you're currently doing is holding back on the first task out of fear of then having to do the second task.
But what other option is there? You cannot tell the future. If you spend your time pondering future possibilities, you're going to end up guessing anyway. A guess is always prone to being dead wrong.
Instead, build the application, and prove that there is indeed an issue. And once the issue is clear, then you start addressing it.
To put it another way: Henry Ford never built a car that conforms to 2018 standards/expectations. But if he hadn't built the Model T, a flawed car by modern standards, no one would have started using cars, there would be no car industry, and no one would have had a car that they could then try to improve.
I've had employers question my choice in not using any web frameworks during interviews, which has only caused me to further doubt my previous work.
The important part here is not which framework you're using (any employer who judges you on that is not doing their job properly). The important part here is knowing what you're doing and why you're doing it.
For example, you could be avoiding existing framework specifically because you want to learn why a framework is useful by doing it the hard way first. Or you could be trying to make your own framework.
The only bad answer here is "I don't know", as it shows a lack of making informed decisions. That is a red flag for an employer.
I simply don't know any web frameworks, and don't know which one to start using.
The same problem arises here. The solution is not to think more, but rather to act:
Stop pondering the perfect answer.- Pick a framework. Unless you have a preference, pick a random one. Use a dartboard, roll a die, flip a coin, pick a card.
- Use it.
- Did you like using it? Was there anything you found annoying?
- Look up how to prevent these bad elements. Did you misuse the framework, or is this just how the framework is supposed to work?
- Once you feel you have a grip on the framework (regardless of whether you like it or not), pick a new framework and repeat the cycle.
To read more on this, read The doing mindset > the thinking mindset. The author explains it better than I can.
but the pressure to finish the app is mounting, and I'm considering scrapping the app completely and starting over
Unless the current codebase is an absolutely unmaintainable mess; you're making the opposite decision.
Developers often think that throwing things out would be the better choice. It's a very common feeling. But it is rarely the right choice.
Throwing code out and starting from scratch is like getting stuck in traffic on your way to work, worrying you'll be late to work (miss the deadline), and instead drive home and try driving down the same road again. It doesn't make sense. You may be stuck in traffic, but you're still closer to work than you were when you were at home.
answered 3 hours ago
Flater
4,371817
edited 2 hours ago
answered 3 hours ago
Flater
4,371817
answered 3 hours ago
Flater
4,371817
answered 3 hours ago
Flater
4,371817
4,371817
add a comment |Â
add a comment |Â
cameraguy258 is a new contributor. Be nice, and check out our Code of Conduct.
cameraguy258 is a new contributor. Be nice, and check out our Code of Conduct.
cameraguy258 is a new contributor. Be nice, and check out our Code of Conduct.
cameraguy258 is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsoftwareengineering.stackexchange.com%2fquestions%2f381047%2ffear-of-web-app-not-being-future-proof%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
