Four Pillars of a Successful Development Project

Or, How I Learned to Stop Worrying and Love a Detailed Meeting Outline

As a technical project manager turned full stack JavaScript developer, I have a unique understanding of the complexities of a development project and the many and varied ways one can succeed or fail. Different PMs apply different management methods to different projects based on their experience and the needs of the client. Some projects are handled the old fashioned way, following a strict waterfall schedule with deliverable deadlines and features set from the start. Others are more agile, with features being regularly re-prioritized based on user feedback and the clients’ changing needs. I’ve seen projects succeed and fail under a variety of management methods and processes for many different reasons. That’s all well and good. HOWEVER…

This post isn’t about all that.

In this post, I want to go a little deeper than method or process. I’d like to talk about philosophy. Specifically, the philosophy that transcends method and applies to all your projects, regardless of who’s involved or how they’re run.

Over the course of my 10+ years in this industry I’ve developed a set of pretty straightforward principles that I use to guide a technical project. These are my “pillars of success”, so to speak, and I strive to apply them in every project I take on. They’ve helped me manage projects big and small, as part of a team or as a sole freelancer. They’ve also helped me when I wasn’t in a management position and was simply a part of a larger whole. I hope you find them helpful!


1. Preparation

My first and most import project pillar is preparation. (Second is alliteration, apparently.). When I’m beginning a project I try to front-load it with as many planning meetings as I can, from SOW planning with biz dev, to the general project kick-off with the client, to the technical kick-off with developers, dev-ops, and QA. These meetings may sometimes seem like overkill, but they are necessary for laying the foundation for understanding project milestones and setting the team up to for success.

By answering questions and working out as many details at the beginning of a project as possible, we avoid coding blindly and having to backtrack and rework components or features. Planning and documenting upfront also helps us set client expectations appropriately and more easily handoff tasks and project assets between team members.


2. Transparency*

I strive for radical transparency on all my projects. This means being proactively communicative and keeping appropriate stakeholders apprised of one’s progress at all times.

Transparency is a tricky idea to throw around because it can mean different things to different people. For me, transparency comes in many forms: being vocal on Slack or over email about when you will be working and when you’re unavailable; writing clear sprint or kanban tickets and keeping them in the appropriate progress columns; coming to and fully participating in meetings and stand-ups; letting PMs and other team members know when you’re blocked on a task; asking for help when you’re stuck; and much more.

The above are all good examples of transparency; however, they can still leave room for misunderstanding. That’s where the radical part comes in. Radical transparency happens when you pair good communication with relevant and necessary context. For instance, when giving an update in a stand-up, we talk about what we just finished working on, what we’re currently working on, and what we plan on working on next. This format keeps stand-ups relatively short, but still gives everyone a good idea of who’s doing what so there’s no cross-work.

Another example is writing clear reproduction steps and attaching screenshots when writing bug reports. Sometimes a bug or error that seems obvious to you will be meaningless to the person to whom it’s assigned. Repro steps, device/environment info, and screenshots help contextualize the bug in a way that lets anyone read the issue and understand it without having to come back to you with more questions.

*Everything in the transparency section is meant to be applied internally. While I also believe in radical transparency with the client, it’s still possible to overshare and needlessly worry them, and that’s a whole other blog post.


3. Modularity

My third pillar of project success is modularity. Well-contextualized design systems and component diagrams help developers break down work into the smallest possible chunks, making iteration easier and rework less likely.

Building out an app modularly also help PMs and producers explain the scope of a feature to the client by offering all the different moving parts involved in that feature. For instance, a client might view a request for a login form as a relatively simple ask. It’s just an HTML form, right? How hard could it be? What component breakdowns help you do is show what’s actually involved in that request, from user authentication (is this a third-party API call?), to data storage (where is the user info being held?), to higher-order functions (how will you restrict certain page access to users that aren’t logged in?). Discussing these components and asking these questions help the client understand everything that goes into “just adding a form”.

For site and app redesign projects, rolling out changes modularly helps reduce the amount of acquired knowledge users must gain (or re-gain!) in order to continue to use the system they know and love. In other words, modular roll-outs means a user isn’t presented with an entirely different UX or design the next time they update your app.

Finally, having clear and up-to-date design systems and component diagrams in place makes on-boarding new devs a lot easier. ‘Nuff said!


4. Ownership

Finally, I encourage all stakeholders (including the client!) to take ownership of their part of the development project. This means educating yourself on something that you’re not familiar with if it’s an integral part of the project. It means taking notes during meetings and speaking up if your notes don’t match what’s being discussed in a stand-up or future meeting. It means wireframing full pages and individual UI components, even if you’re not a designer, so that team members have an idea of what you’re building. It means writing and updating component diagrams and READMEs.

Most importantly, ownership means creating a deliverable that is useful, decipherable, and has obvious intent, no matter how small the scope. Current or future team members should be able to review your deliverable and, without any input from you, understand why you made it and how it can help them.


Of course, these are just a few of my favorite pillars of a successful development project. There are many others that are equally indispensable. What are some of the principles that you stick to in a project? Leave a comment and tell me all about ’em!

Thanks for reading, and until next time, here codes nothing!

Feature Photo by NESA by Makers on Unsplash

Introducing Mega Nap!

For the love of apps!

Yes this is a post about an amazing web application I helped create but first…

I finished coding school!

I graduated on June 26 with a Certificate of Training in FullStack JavaScript from Alchemy Code Lab in beautiful downtown Portland, Oregon. The program kicked my ass and there were a few moments when I wasn’t sure I was going to make it, but I worked really hard and came out of the program confident, capable, and full of great ideas and the programming chops to make them a reality. A huge thank you to Ryan for being a great instructor, Paige, Ryan, Easton, and Mack for being great TAs, Shannon for teaching us how to prepare for our job searches, and Marty and Megan for running such a great program.

What a fine looking group of alums!

Okay, on to the fun stuff!

I’m thrilled to present Mega Nap, the easiest way to make a full stack application without having to write a lick of backend code.

Mega Nap was my final project at Alchemy and was created by myself and four other students: Emily Baier (@hellotaco), Chris Piccaro (@picassospaint), Marty Martinez (@TDDandDragons), and Tommy Tran (@TranTTommy). We built it in just six days using an agile development process involving user stories, story point estimation, mini-sprints, and daily retrospectives. It was an incredibly balanced team and we worked really well together.

What Is Mega Nap?

Mega Nap is a web application that allows frontend developers to create a database, design database models, populate their new database, and receive RESTful API endpoints they can ping to access their data. All of this is done via a few simple web forms, so they can quickly and easily create and use API endpoints without having to write any backend code.

The inspiration for this project came from working almost exclusively with the Pokemon API while learning to fetch from third party data sources in React/Redux applications. Now don’t get me wrong, that API is legit. However, using the same data over in over our apps was getting boring, so we decided to create a tool frontend developers or those new to programming could use to make their own APIs. We brainstormed features, divvied up the work, and Mega Nap was born!


The Client

The Mega Nap client is build with React/Redux and deployed to Netlify. We used Auth0 for user account creation and authentication and styled components in lieu of plain CSS for most of the styling. We ran unit and snapshot tests in Jest and used Redux promise middleware for handling promises in our API fetch services.

One particularly tricky part of the front end was the data entry form the user fills out after creating their database models. We needed a form with fields that were dynamically generated based on the name and type the user had just set as the key/value pairs in their database model. To accomplish this we had to create an array of fields by running Object.entries on the parsed model schema JSON object we got from our server after the model was created. We then passed this to our form component, which mapped through that array and created a list of fields by running each array item value through a switch and returning the correct JSX form label and input based on the field type. We then rendered the list of returned labels/inputs, allowing the user to immediately enter their data!


An example of a dynamically-generated data upload form based on a “Dog” model.

The Server

The Mega Nap server is built with Node.js and Express, is deployed to Heroku, and uses MongoDB for data storage. We used the jwks-rsa auth0 npm package to create middleware that ensures authentication and only needed to create two database models: the Database, which is used to create a new database for each of the user’s models, and the Model, which has a schema value that holds all the user’s inputted model values. We used Cloudinary for uploading and storing images, so our users can upload images and receive image URIs back in their API calls and we don’t have to waste precious database space on storing their images.

We create each new model schema by using the reviver function, which takes the key/value pairs entered by our user as field names and input types, and then runs them through a switch and is passed as the second argument in creating a new Schema using Mongoose. We intentionally restricted the data types the user could use in their models to strings, numbers, and booleans, in order to keep our database super flat and not have to worry about models referencing or being dependent on other models. This allowed us to maintain a very flat, two-level database structure, with each user model being it’s own collection and all data being added as single documents in their appropriate model collections.

Each user’s model gets their own collection in our MongoDB database.
The data uploaded for each model is stored as an individual document in its appropriate collection.

The Look and Feel

We knew from the beginning that we wanted the user experience to be as painless and fun as possible. To achieve this we chose a modern, earthy-yet-energetic color scheme, using the Color Marketing Group’s prediction for 2020 Color of the Year, Neo Mint, as our primary color and combining it with cooler neutrals and one pop of vibrant pink for contrast.

I designed the homepage based on wirefames we worked on together and using modified iconography found on FlatIcon.com, trying to create an aesthetic that spoke to the fun, simple experience we wanted the user to have on our site. Emily and I styled the site together, with me handling most of the static or global components and her working on form styling and transitions. This was the first time either of us had really used styled components, so we not only had to figure out our styling in just a few days, we also had to learn a new styling language to do it.

An earlier version of the logo and word mark. We liked it, but it was too difficult to incorporate into a web design.

Next Steps

We’re all really proud of this project and are planning on making improvements to it as our individual schedules allow. My contribution to the future of the site is to make a mobile version of it using React Native. I’ve played around a bit with React Native and am excited to dive deeper into the documentation and begin building our mobile version soon.


Thanks so much for reading about our humble little web app! I’m really proud of what we were able to accomplish in under a single work week and hope you have fun creating API endpoints using it.


Until next time friends, here codes nothing!