I’ve worked at many different places, from startups to fortune 500 companies. The one thing I’ve noticed that most engineering managers struggled with was implementing a process that provided valuable insights and true collaboration. Working in an environment that had a well-oiled development process makes a world of difference in team morale, code velocity, and open collaboration. I am going to give you a glimpse of what we practice at DeveloperX, hopefully, this article gives you helpful insight into the development process.
I’ve worked at many different places, from startups to fortune 500 companies. The one thing I’ve noticed that most engineering managers struggled with was implementing a process that provided valuable insights and true collaboration. Working in an environment that had a well-oiled development process makes a world of difference in team morale, code velocity, and open collaboration. I am going to give you a glimpse of what we practice at DeveloperX, hopefully, this article gives you helpful insight into the development process.
In my experience, the one thing I always notice in developers is how well they work with others. Some developers believe they are gods gift to this planet and their way of thinking is going to solve world hunger with only one line of code. I truly believe developers that don’t have an open mind are not good software engineers. Technology is changing all the time, there is no person in the world that understand every intricate detail of the current technology in the market or all the new technology coming out.
Having an ego closes the opportunity for open collaboration and the challenging of ideas. Having open discussions isn’t something you should avoid, it should be something that is encouraged. If your engineering team is scared to give their opinions, then you have already failed. Ultimately, logic will always win but having your methods challenged and discussed allows for better understanding of the objective.
Before starting any project, I highly recommend vetting through the user stories and having a whiteboard session. At DeveloperX, we personally use Asana, but you could use Jira or Trello to accomplish the same thing.
Begin by understanding the project and what needs to be done to accomplish the goal… BREAK IT DOWN into smaller tasks that can be measured. The goal of writing user stories is not only to have a solid understanding of the project and the direction it is going but also to communicate the task and what is necessary in order to complete the work.
Make the tickets useful for anyone that is viewing them, add all the screenshots needed to tell the story, write replication steps if you find a bug, add all the data points, and don’t be afraid to create tickets. You wouldn’t believe how many places I’ve worked in the past that would get upset when you find a bug in the code and write a ticket. Don’t be like them. Write as many tickets for as many bugs you find, I’d rather remember it for later then forget to fix it.
Don’t forget the importance of writing acceptance criteria. Be very clear on what it would take for that particular user story to be completed. It allows developers to know what is all the work needed to be done before the ticket can be sent for a pull-request.
PROTIP: DON’T CHANGE THE TICKET ACCEPTANCE CRITERIA WHEN IT IS IN PROGRESS. It only slows down the development process and makes for unhappy developers. There are some instances where this is necessary, if you find yourself in that position, just have an open conversation with the developer assigned the task.
If you haven’t done so already get your code on a version control system like GitHub (what we use at DeveloperX). I personally love GitHub but there are other options out there like Bitbucket and Gitlabs. Just this simple step allows for open collaboration and better transparency into the development flow.
Once you have selected the right VCS, start thinking about a branching strategy. The goal of having a branching strategy is getting everyone on the same page and knowing what state staging and production are in. I won’t go into great detail but here are a few articles I recommend.
Microsoft git branching guidance
Now, everything is moving along great but now you have to find a way to deploy your application to production or deploy to staging to test a new feature. This is the perfect time to set up a release strategy that works with your branching strategy. I typically keep a “GOLDEN” branch which represents production, and a “DEV” branch that represents staging.
PROTIP: Set up continuous integrations with unit tests. It will speed up your development flow… trust me.
As a developer, I always test my code locally before submitting a pull-request. I take the time to check off all the acceptance criteria and update the ticket to its current progress status. Once I submit a pull-request (PR), I ask my fellow developers to take a look and test the code on their local machines.
During the pull-request process, I am expecting to have an open conversation to explain my solution and how I believe it solved the issues on the ticket. It is also a good time for another member of the team to bring up something I might have missed or a different way of integrating. LISTEN and apply the changes requested if it makes sense.
This is also the ideal time to push back and implement best practices like documentation. Before any pull-request gets accepted the developer must provide updated documentation that represents the change being made. If the expectation is having documentation before the code is accepted, then your codebase will always have up to date docs.
PROTIP: Always have another member of the team accept the pull-request.
By creating and implementing a well-defined development process, you will be pushing out higher quality code faster with fewer bugs. Onboarding new developers just got a whole lot easier, and other developers will appreciate the efforts put forth to streamline the process. It is actually one of the biggest complaints in the development world. I also want to mention that your technical talent is more likely to stay if you have a well-defined process in place.
Read this article to get a bit more understanding:
The Five Biggest Headaches For Software Developers
I hope you learned a lot from reading this post, My name is Mansoor Bahramand and I am the founder of DeveloperX a creative technology studio based out of Denver, Colorado. I hope to share my knowledge and experience from having spent the last decade being in the software world. If you have any question or if I can provide any guidance on your software development journey, please feel free to reach out on any of our social networks or fill out the form below.
You will never miss my podcast, latest news, etc.
