3

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?

My questions:

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.

2 Answers 2

1

Welcome to just about every project ever. What you've described is actually quite normal in the industry, even on team projects. You know the most about the project domain at the end of the project, so looking back you can usually find things that could have been done better. And as pressures to meet deadlines loom, you often have to make compromises. Both of these ideas fall into a category known as "technical debt."

The fact that you've reflected on this and even asked this question shows that you're wanting to learn and improve. That's a great trait that if kept up will yield the experience which over time answers your questions of "What could I have done better?" and "How could I review myself better?"

All the best developers I know are the types that constantly try to refine their skills. They're the types that usually look back at code from months ago and think, "Yikes, why did I make such a mess." (Though they also have a few polished gems that stand the test of time.)

Going forward, I'd suggest:

  • Keep trying, and keep reviewing yourself.
  • Learn about coding patterns that help with these types of situations.
  • Research which software development methodologies and processes will help you keep a project under control.
  • Look for opportunities to collaborate with others on a project so you can learn from them.
  • Find a good balance between iterating to improve code vs. calling it "good enough" to be done.
2

A couple of thoughts.

  1. Three months is not a lot of time. That you got one complete project working, and another 80% done in that time (utilizing the entire SDLC), is fairly impressive. In my experience, employers expect this to happen in a coop setting; being a coop is primarily an educational process, not a product push.

  2. For better or worse, getting a working product out the door is generally considered more valuable that crossing every best practices T and dotting every coding style I.

There was a good set idea on what each piece would do, but not the specific parts that made that piece work

It is the job of a Software Engineer to design and code implementations of specified problems. Some problems are better specified than others. To improve on a specification (I assume that you had a formal set of requirements), you can write a Software Design Specification. The SDS describes the public API of each class in your project, and states what it is supposed to do (the expected inputs and outputs, etc). This can form the basis for Unit Tests that formalize those requirements into a coded specification.

I started destroying some of the organization in favor of quick things so that I could get a working prototype

As you gain experience in software development, it will become easier for you to combine rapid prototyping with a sensible design structure.

1
  • I will keep these in mind next time. Thanks for the input. The part about the destroying the organization just kinda bugged me because I'm leaving and going back to school and I feel as if I'm dumping it on them. I guess we'll see and if they need help I'll always be there next term. +1 if I could.
    – Cobertos
    Mar 27, 2014 at 4:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.