How is The First Professional Project of A Junior Developer Going?
I was hesitant to write this article, which is simply an experience sharing from my last project, Novin Quiz.
However, it engaged me and I am passionate about recounting what I have recently accomplished and sharing it on this great platform.
You won’t find basic rules and standards for creating a good article or post here because they are all new experiences that an 18-year-old boy acquired in just 4 months!
So let’s begin. You will encounter titles that may not seem related in a conceptual sense but are simply discussing various occurrences in the project.
From experiencing bad feelings to great feelings, mastering times, hard times, and amazing events when giving an 18-year-old boy the opportunity to steer clear of unimportant events typical of his generation while working on an average software project with older teammates in their respective fields — it was quite challenging for my mental health.
I attribute this experience to a young entrepreneur in my city whom I will thank at the end of this post.
ABP Framework
One of the key topics I have chosen to explain is the best framework built on top of ASP.NET Core, known as ABP. This framework, which has numerous benefits in specific software development scenarios, has been in existence for 10 years since its inception and release on the internet. According to its marketing videos and my recent email exchange with a support team member, ABP can enhance development performance by up to 50% compared to standard practices.
For instance, consider a scenario where you are a startup founder in the software industry with an exceptional product and a tight deadline. You need to devise a solid technical roadmap for your project with only four developers working within the .NET Core framework. If you were to hire and compensate all four employees until the project’s completion (e.g., over three months) at a basic salary of $1000 per month, you would need $12,000 in total. However, by utilizing ABP, you could manage with just two developers and pay them $6000 collectively over the same period.
As a business owner, it is crucial to make informed decisions when selecting the appropriate backend framework for your product at the right time. This choice can lead to significant cost savings and improved usability. In our previous project — where my experienced leader and I were the core team members — we opted for ABP due to its structured modularity based on clean architecture principles. By adhering to Martin Fowler’s concepts and maintaining clean coding practices within an ABP-generated template, we ensured better software maintainability.
ABP’s alignment with Domain-Driven Design (DDD) was another pivotal factor in our decision-making process. DDD provided us with essential rules and concepts that proved invaluable in tackling business complexities and intricate domains during software development. By incorporating integration and unit tests across application, domain, infrastructure, and host layers within ABP’s framework, we could ensure that our development tasks met predefined criteria for completion — a critical aspect when following agile methodologies like Scrum or similar approaches. That’s it! If you want to know more about ABP check it’s website here.
Experience of Coding with .NET Core
Yes! But how is development going with the .NET Core framework? Is it good? Is it hard? Or what?
As a junior developer, it was hard for me to code with that powerful framework, which I had only learned for 1 year. Even though I had defined many projects for myself or in GitHub repositories before my professional project. However, until you engage and tackle the main programming problems and challenges, you will not grow and improve your skills in both development and engineering! So, I plan to dedicate 14 hours a day to working on projects, even during weekends and holidays, to gain more experience in programming with .NET Core, which I will share with you.
Firstly, the power of .NET Core and its infinite features make it compelling for developers to use in various projects with different contexts. This is due to major reasons such as Microsoft's support and the extensive developer community on platforms like GitHub, which aids in resolving framework issues and defects, ultimately benefiting its user base.
Secondly, the strength of C# as a strongly-typed language facilitates convenient debugging within shorter time frames. The fixed type system ensures that developers know the exact type of every element throughout coding and compilation, enhancing efficiency.
Thirdly, when choosing a development approach with .NET, developers may find themselves overwhelmed by the multitude of available features. This can lead to confusion regarding what tools to utilize in different scenarios, presenting both challenges and opportunities for growth.
Fourthly, the comprehensive documentation provided by .NET through resources like learn.microsoft.com proves invaluable for developers facing challenges or requiring additional debugging assistance. This documentation from Microsoft offers insights into common questions, concepts, and features of .NET with detailed explanations.
Lastly, the potential of .NET Core extends to software engineering concepts, system design issues, and Object-Oriented Programming (OOP), making it well-suited for managing and maintaining projects in the long term. As the first framework I learned and an integral part of my career journey, I am particularly enthusiastic about leveraging its capabilities.
Importance of Having A Good Mentor
A good leader is everything! I had Mohsen(will know about him in the end) in the project as my lead, mentor, and friend. With about 15 years of experience in software creation, he helped me immensely. It’s crucial to have someone who can show you the way and see the end of the road.
Do you know what to do and when? What techniques to use? What technologies to use next? These are questions you do not know at the start of your journey and need a leader to guide you. With a leader, you gain stable experience without fearing mistakes in creating services, models, APIs, etc.
Alongside learning technical and engineering topics from my mentor, I received important tips about being a mentor. The most important thing is to have a lot of patience in this matter, as Mohsen demonstrated in my interactions with him. I am often impatient and hasty in presenting my work, but I strive to improve over time and in many projects. Mohsen’s patience with my temper tantrums was always impressive. He interacted with me well, taught me, and even joked with me!
Constant and daily interaction with a junior who informs you of updates, raises problems, and suggests ways forward can be very difficult and time-consuming. However, this is what a leader does, and a mentor should be familiar with it. I suggest that you get to know the samurai methodology and read about it. Mohsen cleverly explained the principles of leadership, interacting with people, and convincing them. His book is available on the Internet and even on Amazon. I got to know it through a professor at my university. Ehsan Ghasemi is one of the most influential people during my studies.
From the beginning to the end, many decisions were made regarding the choice of technology. One significant debate between Mohsen and me was whether to use SQL or NoSQL and MongoDB. At first, considering the project context where we had to store seven types of questions in the database, I thought we should use MongoDB and store the data in collections. However, Mohsen believed it was unnecessary, and he was absolutely right. After about three weeks, we realized we had to do it, and I undertook the task of completely changing the codes, which was very difficult.
The reason I shared this part of the story is to conclude that at any level of work and professionalism, if you are not in a team of experts and do not use their opinions, you can make complete mistakes. These mistakes can only be understood by trying and realizing what was right and wrong. Don’t focus on why and who changed their mind; focus on why and for what reason they changed their mind. No one is perfect. As a leader and mentor at any level, you must consult and poll other experts. So, a good mentor is everything!
Back-End VS Front-End Battle
Now the story begins:
Popular battles exist in software development teams. The first is between the front-end developer and the UI/UX designer, and the second is between the front-end developer and the back-end developer. If you’re not new to the software industry, you might want to skip this section as it covers my first experience in a professional team and may be repetitive for you if you’re a professional.
First, about the UI and front-end, the conversation often goes like this:
Front-end: "Hey! What is this design? It is not possible to implement it with code. Change it, fix it."
UI/UX: "Definitely not! It's necessary for the user, and I define what you develop. So, do it!"
Front-end: "I will talk with the product owner/manager."
This is common in teams and quite normal because the front-end must implement everything as close to the UI design as possible. When the UI gets complex according to the company’s flow, the front-end will raise these issues, and designers must communicate, solve issues, or convince the front-end developer that the design is correct. These days, designers use tools like Figma or Adobe XD.
Second, about the back-end and front-end, there is a popular phrase I heard from my product owner: "The front-end is waiting, pending on the back-end!" I experienced this in my last project, and it is one of many challenges in this communication.
Some of these challenges include:
- The front-end needs back-end APIs. If the APIs are not ready, the front-end cannot proceed in many situations.
- The back-end should be a week ahead of the front-end in every sprint, or even a full sprint ahead. Why? Because the back-end may encounter sudden and unexpected problems, such as illness or the sudden unavailability of team members. The solution is to stay ahead of the front-end and deliver the APIs timely. This way, at the end of the sprint, everything is ready and working properly. Demo meetings with employers go smoothly, and there are fewer conflicts in retro meetings. If you don’t know about these meetings, read and research Agile and Scrum.
The front-end needs the back-end running in its development environment. If there isn't a good way to deploy and work on their machines, we face significant problems. Here’s a story from my experience:
I was working on a project during the first sprint. After planning and poker planning sessions, it was time to deploy for front-end developers. We used Docker with a specific .NET Dockerfile for all dependencies like Redis and MongoDB. The story begins! We followed the wrong deployment flow on developers' machines and lacked a staging server. I had to go to the front-end developers, manage git changes, and run the Docker image on their systems. Considering we live in Iran with restricted rules for many businesses and websites, and very slow internet, we had to spend hours of the workday on deployment. This made me bored, angry, and tired, leading to lower performance and wasting team time every sprint. The solution was configuring a staging server for QA or testers to test and request from that server. It was a bad but valuable experience, and I’m happy for it.
Communication between the front-end and back-end is crucial. How it’s done and how much is important. We used Telegram for communication with this flow:
1. If I need something or someone to solve issues.
2. I tag the person or people related to the issue and inform them about the problem and needed solutions.
3. If they provide feedback, I communicate with them. If not, I call the scrum master or product manager to follow up and give me feedback about the issue. They may directly tell the person to talk to me or handle it themselves and update me on the events.
Every company has different communication styles, usually dependent on its scrum masters.
Experience of Working in Holidays
One of the main advantages of the software industry is that it differs from other employment jobs that follow a strict 8-5 working hours pattern and involve repetitive tasks requiring stable, unchangeable skills. In software development teams and projects, learning is continuous and must be implemented daily. I have discovered and experienced numerous benefits in the software industry, which I will outline here.
- The first notable aspect is the absence of repetition, as well as facing successive challenges, problem-solving, and engaging in continuous learning. I find typing code characters very intriguing and am consistently passionate about it.
- Another significant advantage is the flexibility to work at any hour of the day or night, without fixed working hours like 8 am to 4 pm. This freedom allows you to work remotely on projects at any time, even from home.
Depending on your role within a software company, there are various challenges associated with this flexibility. For instance, in fields like DevOps, issues such as server downtime can arise where engineers must promptly address problems regardless of the time—requiring them to gather at the company premises at any hour to resolve critical issues.
Student Base Team(exactly like a startup!)
One of the main things I need to experience and test is working on a startup, preferably my own, and working tirelessly. With just one or more employees, we would build our software and application from scratch to minimum viable product (MVP). In my last project, I worked alone on the backend with my aforementioned leader. It was challenging for me, a difficulty I will elaborate on in the future. We worked relentlessly, and these were my responsibilities:
- Developing backend APIs using ABP Framework and .NET Core.
- Coordinating APIs with frontend developers and assisting them with frontend integration.
- Collaborating with experts who had worked on the previous version of the project (we were developing a new version of a software with updated technologies).
- Communicating with my busy leader to enhance development performance.
This experience gave me insight into what it feels like to work in a startup, facing both difficult and ordinary situations alone. I referred to it as a "student team."
Special Times in My Life
In the previous section, I mentioned the difficult moments I experienced during the project. Imagine being 18 years old, focusing on your personal growth and development while embarking on your first professional project. At the same time, you are working with a startup team on a project that needs to be quickly prepared and accessible to about three hundred thousand people. The project demands rigorous development and functionality, adding to the pressure.
Simultaneously, I was studying and practicing university courses, including challenging subjects like operating systems, which required high grades to pass. To add to the complexity, I was constantly commuting between Tehran, where the university was located, and Kashan, where my work was based. This constant movement left me physically and mentally exhausted.
In the midst of these challenges, which occupied a significant portion of my thoughts. Living in a dormitory with its own set of hardships, coupled with a demanding project, rigorous studies، created one of the most difficult yet memorable periods of my life. These moments were filled with stress about the future but also excitement that I will never forget.
Many people tell me that I seem older than my age, unaware of the experiences I have been through. The saying, "Hard days make hard men, hard men make easy days, easy days make easy men, easy men make hard days," resonates deeply with me, as I have lived through these tough times that have shaped who I am today.
Deployment or Sufferment?
I previously mentioned the difficulties of deploying the project, particularly with Docker in both the front and back ends. Here, I will elaborate on those challenges in more detail.
Many of our working days were spent focusing on the front-end system due to the complexities of the project deployment process. I frequently moved between my own system and the front-end system at the company, commuting back and forth until we were overwhelmed and decided to run the project using Visual Studio instead. This shift was driven by our frustration with the initial deployment approach.
Eventually, we decided to consult our DevOps engineer to provide a test server for the team. The engineer configured the test server on GitLab, enabling us to conduct all frontend and QA tests efficiently. This decision marked a turning point in our deployment process, streamlining our workflow and reducing the deployment complexities we had faced.
Despite these difficult moments, the experience proved to be incredibly valuable. I gained a comprehensive understanding of the deployment process, honed my problem-solving skills, and learned the importance of effective collaboration and communication within a team.
Hybrid is so Hard
I worked remotely for half of the week in the dormitory and carried out the project. During this time, I experienced different modes of working with the laptop, such as lying down, with my feet in the air, or on my stomach. While this brought some benefits, it also presented challenges.
- One of the main issues I encountered was remote communication with other members of the agile team and the front team. It was difficult to effectively collaborate and communicate with team members, requiring me to rely on phone calls or communication platforms like Telegram.
- Another challenge was being physically distant from the company while still expected to work in a face-to-face environment. Living in a dormitory with 7 other people in the same room added another layer of complexity to the remote work experience.
Overall, this experience of remote work was interesting for me, but not one that I enjoyed. I hope to avoid similar situations in the future.
Being Responsible or Doer?
In software development teams and processes, it is important to adhere to certain rules and principles. One crucial aspect is taking responsibility for completing tasks and ensuring that all required work is done. As a product manager, you are expected to have a deep understanding of all aspects of the development team, including programming, design, operations, and business. You bear significant responsibilities in ensuring project completion, preparing for demo sessions, and engaging with business stakeholders.
To successfully finish a project, each team member must fulfill their tasks thoroughly and without issues. This necessitates the careful oversight of the product manager and Scrum master, as well as the development of a strong management and leadership vision.
A key question to ask oneself is whether the goal is merely to complete tasks or to successfully finish the project as a whole. With the former mindset, one may be indifferent to problems and simply address them as they arise. However, adopting the latter perspective involves a relentless focus on problem-solving and a commitment to ensuring that issues are addressed promptly and effectively. This approach fosters a sense of responsibility and accountability, leading to a more successful project outcome. Such insights are derived from personal experience and the wisdom of seasoned colleagues.
Do not Take Any Task Which May You Can’t Done it in That Sprint
It is important to know what you should do with others during planning sessions for future sprints and to prioritize tasks that can be realistically completed, rather than what you simply think you may be able to accomplish. As you have a responsibility to earn money and avoid being fired from the company, it is crucial to carefully consider your decisions. I faced a challenge when I accepted every task given to me by my leader without question, only to realize that sprints were taking too long and becoming overwhelming. Therefore, it is essential to assess tasks carefully and make informed decisions.
MongoDB or MSSQL
During the second spring of our project, we encountered the challenge of transitioning from an MSSQL template to MongoDB, a move towards NoSQL. This shift proved complex within ABP as it necessitated the deletion of the previous template's main project and the addition of a new MongoDB project to interact with its collections and documents. ABP lacked automated processes or commands for this task, requiring manual intervention. The decision to migrate to NoSQL mid-project stemmed from our realization that we had seven derived classes in the project, each inheriting from a base class (the question class). These derived classes shared common base attributes present in all types of questions, with additional attributes unique to each of the seven types. Although I raised this concern with my leader once, he did not approve. As time passed, we found ourselves compelled to transfer all structured table data into MongoDB collections to enhance our contextual support effectively.
Change Everywhere! (Change is exist in every moment of your work. Both in code and technology you chosen)
In the previous section, I discussed MongoDB and MSSQL. Now, let's delve into some essential tips. Change is inevitable in the realm of development, encompassing shifts in concepts and technologies. While such transformations are common, safeguarding the correct path is crucial for ensuring successful software outcomes. This may involve altering databases, caches, file systems, object storage, or any other components as needed.
Be with Lead, Do not Take Risks!
Do not disrespect to master and be with its opinion.
I am a bit of a hasty person and I had a lot of problems with my leader in the project, but I finally saw that he sees 10 steps ahead and into the future and knows why? Because he has experienced and felt different events and learned from them, trusting him is very important. You have to be patient, trust and learn, and you have to become an apprentice in order to excel in anything.
DDD Experiences!
I have described my experience working with DDD in my previous article here, which is very interesting and explains the very beginning of the project!
Take Focus, Learn Focus, Focus Better
One of the most important components of problem solving and software development is sufficient concentration to work, and it does not exist in my generation due to various distractions such as virtual media and many other things that everyone is involved in. which should exist to help with better speed and accuracy in completing and developing the software, and it should be learned and practiced first.
Conclusion
These were just a few of my experiences during 3-4 exhausting months, which added a whole lot of experience to me with continuous effort and all its difficulties, and helping others and sharing it makes me happy and more motivated. It gives for the future. I hope you enjoy it and find it useful.
And finally, I want to thank two people along the way. First of all, the young and hard-working entrepreneur who gave me this project and gave me this opportunity, Mohammad Khonsari. And on the other hand, from my good and patient professor and friend, who led the project and helped me a lot, Mohsen Delavari.
Mohammad Mahdi Moghaddam (MoghiTech), June 2024
