I have been working on developing a "Bash Script Editor" and I have been at it for weeks dedicating at least an hour a day. While I was working on it, I realized that I was doing it all wrong and now I'm in this dilemma of whether I should keep working on it till I get atleast a beta version or I should just leave it undone and concentrate on more important things.
While I was working on ETL scripts at my work, I was using Notepad++ as my editor. It worked absolutely fine except I was totally new with the scripts to know where the functions referred in the scripts were actually called from. Having been working with powerful IDEs in the past, a simple editor to manage such a huge project seemed impossible to me and that was it. Thats what triggered me to build a more powerful editor just for Bash scripts.
The idea first seemed fine to me expect when I realized how big of a task it was and I was the only one really eager to do it. So, here I am sharing my experience so that I or anybody reading not to do/repeat such things with a list of -the rights and wrongs with my approach.
2. I was working on it alone. A small team of 3-4 people collaboratively working on modules would have been brilliant. With a team, the work would have been more organized, faster and optimized.
3. If I wanted to do it so eagerly, I should have first searched for any relevant open sourced projects that I could contribute with the feature. It is always a good habit to do it, only I didn't do that.
4. If I didn't want to make it big and just wanted to do it for experience and fun, then I should have done something that I could learn from. Throwing random line of codes and scratching your head to think of a solution just to make up for dirty codes done earlier is a very unhealthy habit and something that every programmer should avoid.
5. Stop before its too late. If you realize, even in slightest, that you are doing it wrong and you are only making things complicated by just adding random features, you should probably pause and look at what you've done. This would have saved a lot of my precious time.
6. Always start with a solid base to work upon. Defining abstract classes and building your way up with it is always a good habit. A good base will always keep things organized.
So, there you go. Before you go and laugh at me or maybe judge me as a programmer, please note that I was doing it all during my office hours. I didn't have enough breathing space to look at what I was doing, all I wanted to do was to complete the task in hand when I had free time. Despite knowing it all, deep down inside, my major regret is that I started the work anyway completely underestimating the difficulty of the task.
Here's the link to the project : Bash-Script Editor (try not to laugh too hard :P)
 |
| Snapshot of my Bash Script Editor |
While I was working on ETL scripts at my work, I was using Notepad++ as my editor. It worked absolutely fine except I was totally new with the scripts to know where the functions referred in the scripts were actually called from. Having been working with powerful IDEs in the past, a simple editor to manage such a huge project seemed impossible to me and that was it. Thats what triggered me to build a more powerful editor just for Bash scripts.
The idea first seemed fine to me expect when I realized how big of a task it was and I was the only one really eager to do it. So, here I am sharing my experience so that I or anybody reading not to do/repeat such things with a list of -the rights and wrongs with my approach.
What did I do right?
1. The concept seemed valid and I was eager to do it.What did I do wrong?
1. I didn't sketch a plan of how I was going to do it. A simple list to features to add, scope of functionalities to look into or may be a rough class diagram to build upon would have eased things up abit. I remember I was hesitant to do it because I thought I should just get right at it and get it done quickly. That simple hesitation went on destroying my whole effort in the end.2. I was working on it alone. A small team of 3-4 people collaboratively working on modules would have been brilliant. With a team, the work would have been more organized, faster and optimized.
3. If I wanted to do it so eagerly, I should have first searched for any relevant open sourced projects that I could contribute with the feature. It is always a good habit to do it, only I didn't do that.
4. If I didn't want to make it big and just wanted to do it for experience and fun, then I should have done something that I could learn from. Throwing random line of codes and scratching your head to think of a solution just to make up for dirty codes done earlier is a very unhealthy habit and something that every programmer should avoid.
5. Stop before its too late. If you realize, even in slightest, that you are doing it wrong and you are only making things complicated by just adding random features, you should probably pause and look at what you've done. This would have saved a lot of my precious time.
6. Always start with a solid base to work upon. Defining abstract classes and building your way up with it is always a good habit. A good base will always keep things organized.
So, there you go. Before you go and laugh at me or maybe judge me as a programmer, please note that I was doing it all during my office hours. I didn't have enough breathing space to look at what I was doing, all I wanted to do was to complete the task in hand when I had free time. Despite knowing it all, deep down inside, my major regret is that I started the work anyway completely underestimating the difficulty of the task.
Here's the link to the project : Bash-Script Editor (try not to laugh too hard :P)
