Roughly in order of importance.

Lesson One – Don’t underestimate how long it will take

A chat app. Sounds simple, doesn’t it? When the project was announced a few weeks ago I figured I’d need about 20 hours. Five or so hours week one, maybe five to ten week two, ramping up to a big ten hour push in the waning days to git ‘er done. This was my first rookie mistake. This past Saturday, after probably 40 hours of clacking away, with the original deadline about 36 hours away and needing at least 20 hours to (possibly) get my project to some incremental but functioning level of completion, gave rise to a significant amount of reflection upon the process and how I got there. The following lessons will reflect those musings.

Lesson Two – Get out of the gate with a strong start

Working with a greater sense of urgency in the initial days can never hurt. It’s not as though I procrastinated, but had I been able to put in 30 hours a week starting week one I either would have been able to finish with time to spare or been able to add more features and make my app prettier.

Lesson Three – Communicating explicitly with our student success coaches is vital

We were lucky to get an extension of a few days, which was a welcome relief and contributed greatly to my happiness. It also made this a better educational experience. When the last minute extension was granted the comment was made that our coaches were caught off guard that we were struggling to finish. I try to be explicit in my communicating, especially as I try to balance the needs and attention that my young family requires, but in this case I probably could have said more. Writing this chat app was a valuable experience. Finishing it in a big panic would have deprived me of some valuable learning opportunities and would have been a disappointing conclusion to a lot of hard work.

Lesson Four – There are no shortcuts in coding

At least I don’t know any! If you’re scrambling to finish a speech or write a paper you can always do a cruddy job and pound it out. There’s always features that can be dropped, and styling shortcuts, but if code doesn’t work… it doesn’t work. And that’s not good!

Lesson Four – Pitches take work too (and it’s a process)

Concurrent with this, our first big project, was also our first real “pitch”. I am not afraid to stand in front of a crowd but there is a difference between not being nervous and not looking nervous. Also up for refinement is the content of our presentation. I know that making a good pitch takes work but I have a new appreciation for how creating a good pitch is a process that takes feedback and refinement. Giving presentations is something we’ll be doing all year and there are lots of resources and mentors to help and give us back whatever we put into it. I hope to be a whiz by year end.

Lesson Five – Plan to finish with time for testing

I should consider the “due date” to be not the actual due date, but at least 24 hours earlier. Leave enough time for thoroughly testing the functionality forwards, backwards, from every approach and in every platform.

Lesson Six – First focus on the deliverables

I think I did an okay job focusing on the deliverables but I saw examples in other projects where non-core components consumed too much time and left the creators scrambling to finish the assigned components.

Lesson Seven – Design for phones first

Mike made a great comment that I will try to remember: plan your design and layout to suit viewing on phones first, then work out towards desktop views. It’s easier to design for desktop so design a phone layout first and the desktop will follow easier than trying to work in the other direction.

Lesson Eight – I don’t like NoSQL

I like data. I don’t like data in NoSQL databases. I thought the slicing and dicing of the statistics I was going to be generating from my chat app was going to be fun but it was no fun at all working in a relational database that I couldn’t intuitively wrap my head around.

Conclusion

Lots of important lessons, which I guess is a great sign in an educational setting! I look forward to not having to learn these same lessons again.

As a final note, I was sincerely impressed by the diversity and quality of the apps my classmates created. There is a great deal of talent and creativity in this room. Also a huge thanks to Rob and Eric, without whose guidance and instruction this app would not have been possible.

1 thought on “Blog Post Number 5 – Lessons from our first MAJOR PROJECT!”

Eric Lortie Eric Lortie says:

What a fantastic breakdown of how complex the past few weeks have been. It’s really great to see how much you continue to take from this experience.

As far as lesson 1: This is such an incredibly valuable lesson. This is why development teams of have managers or systems in place to allow a more objective assessment of task length. It’s really hard to properly gauge how long it will take you to finish something if you’re only thinking about how long it will take you to code what you know about. There’s so much more to it than that.

Lesson 3 should actually read: “There are no good shortcuts in coding”. There are a pile of shortcuts you can learn that will only make you a nightmare to work with, and you will unfortunately encounter these people throughout your career. They exist in every industry. All you can really do is be a positive example using the lessons you’ve learned.

I continue to genuinely enjoy your blog posts. They’re such a great read.


Leave a Reply