• Home
  • Blog
    • Programming
    • Art
    • Recipes
    • Home Automation
    • Life
    • Friday Faves
    • Books
    • Writing
    • Games
    • Web Accessibility
    • Advent of Code
  • Projects
  • GLSL Shader Art
  • Glitch Art

  • Github
  • Bluesky
  • Mastodon
  • Duolingo
  • LinkedIn
  • RSS
  • Bridgy Fed

mary.codes

Web development, art, and tinkering with fun projects. JavaScript, Python, WebGL, GLSL, Rust, Lua, and whatever else I find interesting at the moment.

Lessons Learned From Shipping a Large Project

Mary KnizeBlog iconJan 9th, 2018
2 min read

Programming

These are the lessons I've learned from shipping a year-long software project.

Today at work we shipped a large project that I had been working on for over a year. Not only did I have to create a new feature from the ground up, but that feature was WebVR, so I had to figure out how the interface was going to work, how to integrate it with our current product, and solve cross-browser issues with the ever-changing WebVR specification.

These are a few things I've learned working on this project for the past year:

  • Patience is a virtue with new technologies. I was able to implement features in the last six months that wouldn't have been possible in the first half of 2017. Slowing down the pace of development and taking deliberate pauses to work on other projects allowed for the WebVR spec to catch up to our product wishlist.
  • Taking a break to work on something else can be a great way to recharge your batteries, just be sure your code is well-commented or self-documenting, otherwise you're going to have a bad time when you resume work on the main project.
  • Be sure the code works after it's compiled. Heck, make sure it's going to compile in the first place! Sometimes adding new libraries to an existing codebase can wreak havoc with the delicate ecosystem.
  • After living with your code for so long, your perspective is going to get weird. Ask people of a variety of backgrounds to take your product for a test drive, if possible. Get a bunch of honest opinions and suggestions. Make changes as needed.
  • Don't spend too much time in VR. It will wear your eyes out faster than looking at a regular computer monitor. Take regular breaks from both VR and the computer screen. Take care of your peepers.
  • Iterate interface designs on paper/whiteboard before putting any code to IDE. Then be prepared to code half of it before throwing all those formerly great ideas in the trash.
  • Like a great writer, be ready to kill your darlings. You're going to make something really cool and changes will have to be made for a variety of reasons. Don't get sassy with it, just do it and make it even better than the original.
  • Try to keep notes. It's hard to stay organized when you're trying to add features but it'll be a lifesaver in ten months when you're asked about how a feature works.
  • Get weird with it. Before even sending it off to QA, try to make the craziest use cases you can think of. It'll save everyone some time if you do some of your own testing.
  • Something will break in production and if that doesn't happen on its own, don't worry, someone will come along shortly and break everything. I'm waiting for someone to try to upload a 64x64 animated gif as a VR background.

Other Programming posts

How I'm organizing my work in 2024

Finding the Design Engineer within the Full-Stack Developer

Displaying the current Git branch in my Linux terminal prompt

Generating a 3D map with OpenStreetMap and A-Frame

Translating OpenStreetMap data to HTML5 Canvas with Rust and WebAssembly

Latest posts

I started painting again

100 days of Japanese on Duolingo

How I'm organizing my work in 2024

Watch the documentary 'Good Night Oppy' if you're feeling science-y

Sculpted robo-goldfish, a rainbow office building, and a look inside click farms