I'm a coop (in college but I work 3 months, then do classes for 3 months, work again for 3 months, etc until I graduate) at a company in their IT department. My job usually has to do with writing software but we are not a software company and much of the software that is is written in India. This work term (3 months) I was given a large project, to design some software to visualize data pulled from another one of our systems.
I ended up at the end of this term with two pieces of software for, one 100% done (the data pulling back end) and the other 80% done (the graphical front end). I had fun and learned a lot as always, but I'm not too happy with the results code wise. I have never gotten a chance for a code review or a chance to do any learning about design and analysis strategies for the reason I mention above in the year that I've been here (4 terms).
Here's how the project went, and it reflects how I have done pretty much every project to date, although it's more clear in this project as this is the biggest thing I've done so far. The first thing I did was diagram out how the whole system would operate from a high level. I don't usually do this but I was asked to by my boss. Then, I dove right into the problem and start banging away. To me, I find that it helps (and is more fun at the same time) to get something down and working to revise for organization shortly after so that I can continue in an organized fashion. From there the building slowed down a bit as the project got bigger. I would get more confused but also start diagramming more things out first, stopping to think about how what I'm currently building will fit into the entire system. This continued on for a while until my 3 month term was almost up. Here, I started rushing to get things done. I started destroying some of the organization in favor of quick things so that I could get a working prototype (I was only asked for a prototype so I figured this was alright and if the project went forward I could always revise it). This is where my entire thing started to fall apart as I didn't really have time to properly think through how a lot of what I was coding would affect everything else. I feel like now, at the final stage, I have a lot a mix of loosely and tightly coupled code with a barely working prototype.
In hindsight, here's what I see:
- I did a good job on the original overview and it helped me too because I could break down the entire thing into a few main chunks. Problems started to arise when I got into specifics of each chunk. There was a good set idea on what each piece would do, but not the specific parts that made that piece work (I don't know what I could have done more though to explain each piece though. I find when it comes down to specifics like this, I find out as I go).
- There were many things about the system that I was pulling data from that I did not know at the very start and I should have gotten a lot more insight onto how the system works as a whole. However, at the start of the term I'm always shy and tend to not ask questions. This probably also contributed to why I usually don't know the specifics of each piece until I'm actually doing them.
- I was also a victim of a bit of scope creep as few features were added to the todo list with about a month and a half to go.
- I never seem to know exactly where I want to go on specific parts. I try something and if that doesn't work, I try something else until it works or I get something that's neater. Is this the right way to do things?
What could I have done better? I know no one here will know the specifics of my project but there's no one else with coding knowledge who could tell me how I could grow in this situation.
How could I review myself better? Since I never really have anyone else reviewing my coding and I'm not working with any other coders directly, how could I have reflected better on my own project, both after, and during the project?
The question about what I could do better is directed mainly at the bolded portions of my explanation where I feel most concerned about how I approached the problem.