A Reflection on...A Reflection on My First Year in Software
A Reflection on My First Year in Software
Priyanshu Chaurasiya
2 days ago
I graduated in Computer Science Engineering around a year ago, and at that time, I thought I knew quite a lot about software engineering. I had built multiple projects, written thousands of lines of code, hosted many of them, and a few even had real users from different parts of the world. I had built and added features to my projects iteratively and had experienced what a typical development cycle could look like.
Then I joined Coforge, got exposure to real industry work, and that gave me a lot of new experiences, reality checks, and, most importantly, a different perspective on software engineering.
So hello, I am Priyanshu Chaurasiya, the author of this blog, and today I completed one year at Coforge, one year in the software industry.
Before you skip this blog and close it after writing a “Congratulations!” in the comments below, let me tell you something. This blog is not about “Hey, I completed one year at Coforge, congratulate me.” Rather, it is about my experiences, the things I learned, the changes in my mindset, and a lot more that I believe can be useful to anyone starting their journey in software.
So give me a few minutes. Monsoon season is going on, so grab a cup of tea, sit somewhere comfortable, enjoy the rain, and let’s complete this blog together.
I Thought I Was Ready
Before joining Coforge, I thought I knew plenty about software engineering and the kind of work done in the industry. I had done DSA, solved LeetCode problems, built projects with real users, hosted applications, and worked on features myself. All of that gave me a certain level of confidence.
And honestly, I don’t think that confidence was wrong. Those things did teach me a lot. But I was about to discover that there is a difference between knowing how to build software and knowing how software is built in an organization.
Comments
Have something to share?
Join the conversation by signing in below!
The Image I Had of a Software Engineer
I had an image in my mind that a software engineer’s role was mostly about building features, writing code, solving problems, and doing all of this throughout the day.
What I came across in the last one year was a little different. Building and coding are definitely part of the job, but they are not the whole day.
There is analysis, requirement understanding, documentation, discussions, debugging, testing, coordination, and a lot more around the actual coding.
The Nervousness Wasn’t About Coding
Before joining Coforge, I did have a little nervousness. I had written code, built projects and added features to them, but all of that was at a personal level.
A thought that kept coming to my mind was, “I have done all this on my own, but how will I do the same thing in an industry environment? Is what I know enough? Will I be able to understand the requirements and actually contribute?” I believe many freshers have similar thoughts before entering their first job.
Industry Is Not a Personal Project
One thing that definitely changes between college, personal projects, and the industry is the flow of development.
When we build our own projects, we usually make most of the decisions ourselves. We decide the requirements, design the system, write the code, do the testing, and decide what needs to be changed. But in the industry, the story changes completely.
Software Development Starts Before the Code
When we work on a real project, development doesn’t start with, “This is the feature I need, so let’s start coding.”
It starts with understanding the business flow and requirements, analysing the existing system, figuring out the changes, checking dependencies and impact, discussing the approach, and documenting things. Then comes coding, followed by testing, review, acceptance, and eventually the change reaching the users. I realised that coding is only one part of the development process.
The First User Story That Felt Real
I received my first user story somewhere around 6–8 months after joining, and that also has an interesting story. You can read about how I got my first user story.
That user story made me experience the process I just discussed. My changes involved calling third-party APIs, so I had to go through their documentation, understand the existing logic, figure out where the changes needed to be made, and think about how my changes could affect existing functionality.
After that, I got a few more user stories in the upcoming sprints, and the learning continued.
The Gap Between College and Industry
This is something I believe many people can relate to. I am not saying that nothing was taught during college, we studied Data Structures, Computer Networks, Operating Systems, DBMS, and many other important subjects.
But there is still a huge gap between what we study and what we actually do in the industry. Most college subjects don’t teach us how development works in an organisation, how to work with an existing codebase, how business requirements are handled, or how a team actually builds and maintains software.
And then, towards the end of college, students are often expected to build a major project as if they are already supposed to know all of this.
A lot of the technologies and tools we eventually work with have to be learned independently through documentation, courses, tutorials, blogs, or simply by working on the job. For me, .NET, .NET Core, Angular, Microsoft Azure, Visual Studio, and many other tools were things I had barely encountered during my four years of college.
The Skill I Improved the Most
In the technical category, a lot of my skills have improved over the past year, and I have learned many new things as well. But if I had to pick the skill I used and improved the most, it would probably be analysis and debugging.
Initially, I used to think learning meant building more projects, learning more technology stacks and frameworks, exploring new areas, and writing more lines of code. All of these are important, but I never gave enough importance to understanding existing software.
Writing a new block of code is one thing. Building something from scratch is one thing. But understanding someone else’s code, finding a bug, and figuring out why something works perfectly for most users but breaks for a few specific users is a completely different game.
Over time, I also became much more comfortable with developer tools in the browser and using them as part of debugging and investigation. It changed the way I look at development: sometimes the real challenge isn’t writing the solution, but figuring out what the problem actually is.
Being Surrounded by People Better Than Me
This one is a bit personal.
In the past year, I have met and interacted with a lot of people, and obviously, everyone is different in their own ways. But I also found a few people around me who are really smart. They understand situations quickly, learn things faster, and have a deep understanding of the systems they work with.
Instead of feeling insecure because I know less than them, I started looking at it as an advantage. Being around such people helps me learn differently and also gives me a reality check that I should not become overconfident just because I know something.
If you are a fresher, don’t always look for an environment where you are the smartest person in the room. Sometimes, being surrounded by people who know more than you can be one of the fastest ways to learn.
Beyond Code
There has been a lot of technical, coding, and development stuff so far, right? But don’t worry, let’s talk about something beyond coding.
In the past year, I realised that growth isn’t only defined by how strong you are technically. Technical skills are obviously important, but communication, teamwork, asking questions, managing time, and taking responsibility also play a huge role in how you work with people and handle your responsibilities.
Communication
We hear “communication is the key” almost everywhere, and honestly, it is. Whether you are talking to teammates, colleagues, seniors, managers, or leads, being able to clearly explain a problem and understand what someone else is saying can prevent a lot of confusion.
Good communication doesn’t necessarily mean speaking a lot. Sometimes, it simply means making sure the other person understands what you are trying to say.
Teamwork
In the industry, you won’t be working all alone on a personal project. Different people are involved in the same project, and everyone may be working on different parts of the system.
I experienced this while working on user stories, analysing issues collectively, discussing solutions, and coordinating changes with others. Being technically good is important, but being able to work well with a team is equally important.
Asking Questions
Clear communication also starts with asking questions.
When something isn’t clear, asking the right question can save a lot of time and prevent assumptions. Instead of trying to understand an unclear requirement on your own and building something based on assumptions, it is often better to ask, clarify, and then move forward.
And no, asking questions doesn’t mean you don’t know enough. Sometimes, asking the right question is itself a skill.
Time and Responsibility
These are going to be important throughout your professional life. In a project, it is not always like, “Here is your one task. Once you complete it, you will get another one.”
There can be multiple tasks, user stories, issues, discussions, and responsibilities at the same time. You need to understand what is important, what is urgent, what the timeline is, and what needs to be completed first. Learning to manage all of this while taking responsibility for your work is very different from completing a college assignment.
As we are getting towards the end, there is one thing I would tell you: learning never stops.
Before joining, I had already learned different technology stacks and frameworks, solved problems, built projects, hosted applications, and even had real users. Still, I wondered whether all of that would be enough for the industry.
After one year, I have realised that there is no fixed definition of being “industry ready.” Every day, I learn something new — sometimes a technology, sometimes a concept, sometimes a different approach to solving a problem, and sometimes simply a better way of doing my work.
So perhaps the question should not always be, “Do I know enough?”
Maybe the better question is, “Am I open to learning something new at every point in my career?” For me, that is what real growth looks like.
Still Just Getting Started
So, that was my one year at Coforge, one year into the software industry.
Not every day has been awesome, but not every day has been dull either. Has everything gone exactly in my favour? Definitely not. But the learning and experience I have gained during this time have been valuable.
And this was just one year. There is still a long way to go, a lot more to learn, many more mistakes to make, and hopefully, many more things to build and experience.
Thank you for staying till here and spending these few minutes with me. If you have any feedback, suggestions, or your own experiences from your first year in the industry, do let me know in the comments. I would genuinely love to hear them.
I hope this was worth your time. Keep the hustle, and let’s meet again some other day, in some other blog, with some other story in tech.