What I learned on my 1st large project

Congratulations to Me!

Why you ask? I just completed my first large project with my company and couldn’t be any more proud. Considering that my first project ended up with me leaving after 2 weeks (talk about a hit to the gut), I am really proud of the work I did. Before I begin my next project, I wanted to complete a postmortem of what I learned while on this ride. Here are couple key things I picked up:

Don’t Get Attached to Your Code

One of my first tasks on the project was to build out the starter/boiler plate code for the team. I did what any Node engineer does and wrote a server.js file with superficial routes that returned console messages. By the time our team began building, the code I wrote looked nothing like what I had created. I was sad because it felt like my work would not be in the deployments.

But the point I was missing was that it doesn’t have to be my exact code ending up in deployment that matters; its that my work helps get the team to a benchmark. In this case, my code was an example for our team members that had never written Node before. They saw how Node uses routes and callbacks and got a sense of where to do from there.

Know Your Versions

As I started the project, I did not bother to check the version of Node our starter code was relying on. But when I attempted to implement a solution my manager had suggested, it kept breaking. I investigated further and found out that we were writing code to work with a version of Node that was not going to be maintained past a certain point. I quickly informed my manager and explained our change in architecture to the client. They were very happy we had caught this error because if we had not, the deliverable would have been outdated a lot sooner!


One of my favorite replies to a question I would hear often in bootcamp was from a Hacker-in-Residence. Rather than asking what went wrong, he would let us ask the question and reply with, “Did you read the docs?”

Working on large project required me to document everything because I would soon hand this codebase off to the client, who would be dependent on my documentation to understand how it worked.

I largely understood documentation to mean that I add comments in my code to let other team members what it does. But one piece I overlooked was writing out how the technology architecture was structured and how our data was bound to third party data. By documenting what objects were returned or services were called, it made troubleshooting easier. Often times, I discovered that objects were not mapped correctly and data was being sent to wrong service.

In addition, documentation becomes a holy book of dos and donts. I made sure to state how testing would be completed and what inputs should be used for test URLs. But one thing that was often overlooked, was how frequently documentation was updated. An outdated Confluence or Sharepoint folder was useless when you find out that your input JSONs changed two days ago!


I used to log what was breaking in my code by adding a console.log(‘Here is the error: ‘, error) message in my functions. This may work if you’re working on a small piece of code, but for a larger project, logging is critical in helping to pinpoint breaks and stoppage points.

Rather than just seeing a message that points to where the code broke, logging allows you to see detail such as:

  • request ID
  • status code
  • time error occurred (super helpful if you’re monitoring a large project)
  • file or function that threw the error
  • type of error

Libraries like bunyan make it easy to configure the the response JSON you would like to have written in your logs.

Keep an open mind

I will be the first to admit that I came into this project with a very cocky attitude about Node and its related libraries. I was surrounded by enterprise-software types that knew C# and .NET, but had not tried their hand at React. Very quickly however, I was flat on my ass stumped writing a function callback. Needless to say, I changed my attitude and listened to my seasoned coworkers solutions. Yeah, they might have the CS degree I don’t have, and I have the lightweight web app experience they don’t, but when it comes to delivering for a client, I needed to cut it out with the arrogance and listened to those with more experience.

I was amazed with my coworker, with only 3 months more time in the company than me take over the management, creation, defect tracking, architect solution building, and project docs management. He was really the reason why we were successful in making the client very happy.

Wish me luck with the next project!

3 thoughts on “What I learned on my 1st large project

  1. Suzanne K. Schaefer says:

    Thanks for sharing your insights, Kim. As always, I learn something new. Keep up the fabulous work/learning/growing expertise!!!!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s