As part of my graduate journey, I have recently tried my hand at enterprise software development. Coming from a background of hobby development, this transition introduced a considerably different environment. With this transition, I have experienced some of the differences first hand. This article is meant to give you my view on some of these key differences.
I have included both technical and non-technical points. They are not listed in any prioritized order.
When working on a project with a team, version control is a prerequisite. Being able to successfully manage different versions of your software and track changes is a necessity to develop solutions. You are often not exposed to this when developing your own solutions, as you are not part of a team. Learning and using Git (Version Control System) with a team has been a true eye opener. It’s extremely powerful as a tool for developers to keep track of the solution and to share knowledge within the team. If you haven’t ever used version control, I would recommend getting started as soon as possible. Even if it’s just for your own project. This will definitely help you in your transition to become a developer and teach you a great deal about how larger software projects are developed.
When developing an application for an enterprise, you will be part of a team. This is vastly different from developing on your own. You quickly figure out how communication is just as important as your code when you are about to implement 5 features at the same time. Being part of a team also allows you to learn from your team. Being a junior on a project means I get the chance to learn from the more experienced guys. And they have a great deal of knowledge to share! This is a great chance to understand topics that have previously been difficult to grasp on your own.
Being part of a project means meeting certain deadlines and budgets. This is naturally not a priority when developing solutions on your own. Although other people might be in charge of scheduling and managing the project, you should still be aware of certain limitations and opportunities within the project in regards to resources. These limitations can play a big role in some projects and influence technical decisions along the way.
In a personal project you never have to show your code to anyone. In an enterprise project, you will always have to show your code and make the information available for your colleagues. This is a very good exercise as it makes you think about the code you write and reflect upon its purpose. A project could potentially include different developers over the course of its lifetime, which emphasizes the need for proper documentation. This is not just within your code but also for the entire solution. An application will continue to live even though you leave the project, which means other people need to understand what’s going on.
You often create personal projects without a customer on the other end. It might be a project you are planning on releasing but you still don’t consider the client in your development process. Having a client on the other end will always influence decisions during the project. Will this feature benefit the customer? Is it necessary for the MVP (Minimum Viable Product) or should it be pushed to another iteration? Does it take too long to create this feature in regards to our delivery date? These are considerations you don’t usually have to worry about on your own. You simply decide whether you want to include a feature in your project or not.
Smaller personal projects often don’t include tests. Why would they? You know all about your own code and every decision in the project has been made by you. However, creating maintainable solutions do require tests. Generally speaking, production becomes an environment you want to respect. Bugs should be caught before production, which makes it necessary to include development environments and sufficient tests. This underlines a need for building the integration and delivery pipeline — an area that has received increased focus in the past years.
For every project in the software world you have to select the right tools for the job. On your own you have the possibility to choose from any stack and framework, because you have the sole responsibility. An enterprise project often includes certain restrictions. This could be because of a certain environment or existing legacy solutions. Furthermore, you have to consider whether your choice of framework actually benefits the ultimate goal of delivering a stable and maintainable solution. Going with the newest, hyped toys does not necessarily bring any value to the client. In a larger project it is often necessary to view the choice of tools from a cost/benefit perspective.
Get started today
These experiences briefly sum up some of the key differences between developing hobby projects and enterprise applications from my perspective. These points are not meant to scare you away from entering the software world, but should rather be seen as a perspective from someone that recently entered this world coming from a hobby background. I have enjoyed every bit of it and I’m thrilled to have experienced being part of an enterprise project. Don’t be afraid to try your hand at development if you have a passion for it. Be open about your shortcomings and focus on learning what you don’t already know. The projects will often include loads of opportunities for you to learn on the fly.
Feel free to reach out to me with any questions or comments regarding developing applications. I would be happy to share my experiences and listen to yours.