I had worked on two projects, and they both last nearly a year to do.
The first one is a module of the existing system integrated with e-commerce software.
When it started, I didn't have experiences on high demanding business project, also e-commerce software. Due to the demanding todo, I didn't have time to understand the business workflow of both. This is the first project, I think, for me, called software engineering or software development, in different parts of todo, I will analyze the system, understand the todo, and then code on it, test it then commit changes to remote repo from SVN, especially I will have to be really careful on each assignment and test, to avoid any fault on real business circumstance.
In the project, I learned some real practical skills to deal with programming, it's like a learning curve. As a programmer lacking real experiences and knowledge on it, to write code intuitively based on the understanding of the todo, each todo reflect a small part of the whole view of the project, and focusing on it, I missed the opportunity to analyze and understand the outline of the project, due to that, many works are refracted, until it looks natural and elegant to make the requirement meet.
Less experiences on it, that's the major reason of why the project took long. For now, reviewing what I have done, and compare the difference in skills from now and then, I get one lesson, and very important lesson:
there is no way to make todo quick, no way to finish project quick, to slow down and understand it clearly, is the only way to make it quicker, take it as part of a job, not a task for a mission.
The next project, is a new software, the target is to migrate the desktop software to the web app.
To develop web app (not website), is interesting for me, I like to take new adventure on new and promising tech, even though I didn't have experiences on a new software development.
I took about 1month to discuss it with project sponsor and made the plan on it, the plan is pretty immature, I would say now, many parts of it, are not possibly finished. That's the common mistake for a in-experienced developer, most of the possibility are depended on assumption, the logic isn't applicable for real project:
If there is a library, probably (even though not sure, not knowing it clearly) can do, then it CAN do. If there is no library, from the understanding of the lower level API, it probably can do, then it CAN do.
This logic is a mistake. As a in-experienced developer, what the previous system is? what those library can do exactly (not from its demo or something), and can't do exactly? what cost to change it or use lower level API if it can't, all unknown, but assumed to be no-doubt!
After the adventure finished, now I reviewed what I have done, and I knew I learned something new, and gain some more better skills and experiences on it, if there is another opportunity to make the software again, I could make it probably my own. But the lesson is the most important part, that is:
Don't exaggerate the skill we had, and don't assume we can learn some new practical skill quick. And learn something new is always an adventure, and risky for the development.
There is no project to be easy, even though I was passionate in making it quick, but there is no success. I didn't lost the passion on it, but more reasonable, the passion of software development, the idea of create something new, they are attractive and fascinating, thats probably the easiest way today to create something different and new, always exciting, always opportunities, the feeling, kind remind me of the serious issue like "addiction", it wasn't that serious, but sometimes, when we do, we invested too much on it, so its' time to learn how to slow down, and make it fit into our life, no stressful, no intervenient for our life, mostly we can't blame anyone of that, but give our persistence mind up.