Do you want to know what does a software developer do on a daily basis? Do you want to know which type of work does a software engineer do? You are at the right place.

So let’s talk about what does a software developer really do on a daily basis, and to be honest the answer is pretty simple. The software engineers or developers write the code and that’s gonna be it for this article.

Hope you found it insightful and if you did then keep reading this article till its last word. okay, I’m kidding, I’ll give you a little more detail than that, I will describe the whole software engineering life cycle or the product life cycle rather than what happens from the moment you decide to create a product or a feature until the end when you launch it and even afterward.

Of course, we will talk about everything that a software engineer does which basically constitute all the work of the software engineer. I will say this will mainly focus on a product-oriented web full-stack engineering life cycle, if that makes sense I think it will be representative of the larger amount of software engineering out there.

But there are many different types of software engineering that can be a little different and I am going to share on my experience as well as other software developer’s experience who has worked in many big companies in this world.

So now let’s start from the beginning of the software development life cycle. You have a product idea or a feature idea, this is something you decide you are going to build. Now if you are At a large tech company like Google, you, the software engineer, will probably not be the person who decides to develop that idea.

Usually, it will be a Product Manager, a Vice-President, the CEO, or someone of high rank in a different role. But if you’re in a company which is comparatively smaller let’s say XYZ, then you, the software engineer, could be deciding what you are building.

That’s what we do, but regardless once a product idea has been decided or feature, then the real work of a software engineer begins and begins. so I like to call it requirements gathering. This is something you will definitely have to do.

It does not involve coding, we are not at the coding step but it does involve really understanding what it is you are creating. Because when you have a product idea like for example, I will give you a product we recently worked on in the XYZ company we just launched a coding interview evaluations product or feature, as the name suggests, these are just coding interview assessments they’re basically like timed decoding interview questions to mimic a real coding interview.

But that idea of ​​a product feature doesn’t actually tell me what we’re building and I can’t blindly jump into coding without actually knowing what it is I’m building that just doesn’t make sense.

So I have to gather all those requirements by talking to people who know what it is that we are building and asking them questions. So for example for this function is it going to be an externally visible function?

Yes, is it going to be a feature that has its own page, yes, in fact, it is going to have multiple pages, well what are these pages? We’re going to want to have some kind of a list of all the evaluations and then you’re going to want to be able to start an evaluation and the evaluation will be timed. What evaluation will look like even though it’s okay, it will be a normal question.

I’m going to ask an expert question, except It will be timed and the user will not have access to the solutions and they will have several states, so someone could fail in an evaluation, someone could pass an evaluation.

You see that there are all these details, big and small, that you should collect and understand before you can start building out the product and that’s part of your job as a software engineer.

Now, once this is done, once you have a clear and unambiguous picture of what you are going to build, you enter what I like to call the design phase, and here I am talking mainly about engineering design, not UX design,.

Although UX design is also closely related, but here we are talking about how you are actually going to design from an engineering point of view. This feature you are about to build because once again, especially when it comes to large and complex features, you can’t blindly jump into coding.

Even if you know the various requirements of the product, you have to think about how you are going to build this and specifically here I think that the most important design aspect of the design phase is the API design of the function;

In other words, your backend engineers and your full-stack engineers will have to determine how they will design the API that actually going to support this feature and this is very important.

Let’s see with the example, if we are talking about these coding interview evaluations we note that there will be a page where we want to list all the evaluations and we also want to have the evaluations as well all the questions in the evaluations.

So the backend will have to expose an API method to list the evaluations, it will have to give all the questions within an assessment, it’s going to have to provide some data about these questions.

But then as we said earlier we are also going to need a page where someone can take the assessment and this seems to be like the normal XYZ company coding workspace, except as we said earlier it will be timed.

So maybe the backend will have to expose a new API endpoint for normal XYZ company questions. How are we going to handle the timed aspect?

Does the backend give the UI a timestamp for when the evaluation is supposed to end, doesn’t it but instead waits for the UI to continually pull the back end and back end to return to it, whether or not an assessment is done?

There are all these questions to ask yourself that you should effectively embed in the API you are building. But because the API is so fundamental to the product or function you are dealing with, it is very important that you actually put in a great deal of time to this API design phase and you can’t just lock your backend engineers in a room and have them take care of themselves.

Because this API will be consumed by the front-end engineers who will be the ones interacting with the api and need to tell you to backend engineers whether or not that fits their needs as front-end engineers. Your UX designers need to be very involved because API decisions are going to affect UX.

For example, maybe the API needs to expose a certain amount of information at the endpoint of the list. To support a certain UX design feature, such as maybe your UX designers or product managers who don’t want users to be able to see the category and difficulty of a question unless they have completed or failed the question which is an API design problem.

Backend engineers need to make sure they take it into account and if you are in a big tech company like Google, you may not be able to easily make API changes later in the software development lifecycle.

So you need to think proactively about all of those things. The point is that the API design phase is very important, by the way, this is a big part of the systems design interviews we have a couple of API design questions about system experts if you are interested and the key point here is that as a software engineer, you probably haven’t started writing actual code at this point.

You’ve just been designing what your code will support. Writing design docs or conducting whiteboard sessions with other engineers, but you probably haven’t written any code yet.

Once you’re done with the API design phase once all parties are satisfied with the look of the API at that point people can start coding. So their backend engineers can start implementing the API and all the functions that come with it, and their front end engineers can go and build the parts of the UI that don’t depend from the API, which are not blocked by the API.

So it can be static content parts of the UI that just don’t interact with the server, they can also create parts that interact with the server, but everything except interact with the API or can simulate api endpoints and finally, once your backend engineers are done with the api, your front end engineers can complete everything else.

Connect the api endpoints and the client you know have the client make calls to the APIs and really complete the function while the backend engineers work on other backend features that are more internal.

The point is that this is the part of the software development lifecycle where the software engineers really only do code that is likely to pass long periods of time just coding really developing features from scratch, this is when you actually do most of your coding with mostly software engineer.

Now of course there could be a bit more design, such as engineering design, that happens throughout this process. For example, front-end engineers could decide on the design of a front-end component or from the front-end health management aspect of the app there.

There are all kinds of other things or features that people could be designing. The point is here when software engineers really get down to coding. Now eventually the front end engineers will finish building a first draft of the product or feature and everything will be complete.

Someone internally will be able to play with the function end to end and here we enter another phase of the software development life cycle where you have to look for bugs in the function or the product to make sure there are no bugs that it is behaving like we want it to behave, to really fit all the requirements, etc.

So here all the members of your team, including software engineers, are going to try to manually play around with the feature. For example to the coding interview evaluation function, I remember I allocated like 90 minutes a day about three weeks ago, where I went through the whole flow of the function, the first draft of the function that I just used.

As if I was a normal user, I tried to break the UI, tried to look for extreme cases, and pointed out a bunch of bugs and improvements we could make. We had this huge list where there were all kinds of functionality errors, style errors improvements that could be made both from a stylistic point of view and visually.

We could change this color or we could change the wording here but also product improvements things like oh wait you know what we’re figuring out how much maybe it makes sense to show how much time has elapsed once you have completed an assessment.

we didn’t show earlier that the backend didn’t take that into account and we realized as we are looking for the function that would be something. It would be valuable to the user , well now we have to go back to the back end and tell you that we need api level support for this.

Going back to what I said earlier if you are in a big tech company like Google this could be really difficult to add this to the end of the play just because in those big tech companies you have to go through API approval processes and all sorts of things.

So you really have to think preemptively about a big company like Google in everything you need from a features point of view. For us in small company like XYZ we could make the switch very easily, but now we enter this new phase of the software development life cycle where you are still writing code as a software engineer but Instead of building these huge features from scratch you are no longer doing that because you just did that.

Now you are fixing the features or improving them or adding little features as if you know how much time has elapsed on a particular assessment question. So it’s just a different kind of coding but you keep coding not big features but little bug fixes and improvements and I must add that throughout this whole process as a software engineer you are also reviewing other people’s code.

Your code is bug-free, it is ideal code, it is clean code, you have to do all of these things in addition to writing your own code, but going back to all the bug fixes and improvements once it’s all done once it’s passed all the list of errors and improvements that you have had and you may have classified them saying that it is ok.

Some of them are very important, they are blockers, we have to fix them, others are really important, but not blockers if we are in a crisis of time maybe we will be fine with not having them, others are not completely important, it would be nice to have them, but if we can’t make or fix them in time then it doesn’t matter, this is another part of your job as a software engineer that you have to do.

You need to be able to assess what are the most important things that I need to implement and throughout this entire process it is very common for you as a software engineer and other stakeholders to keep looking for bugs in the product or feature over and over again.

While doing the improvements for this coding interview evaluation feature, I was looking for UI bugs basically every day looking for new enhancements that might make new bugs that were introduced during bug fixes. But incrementally or rather progressive you are decreasing the amount of things you need to do until you finally get to a point where you are satisfied that there are really no more mistakes or no more mistakes that you think really need to be fixed or improvements that need to be made before I can start the function and be ready to launch the function.

This is where there is a lot of what I like to call glue work, as a job that is not necessarily technical, it is just putting things together to make sure things are ready for release, so if you are in a big tech company that might involve getting approvals for all kinds of parts, if you are in a Small company like XYZ into something savvy, it’s more just making sure we don’t lose anything that we don’t have blind spots is the backend and UI in sync.

What day will we release this We will make an announcement of all kinds of things and once you have decided all that, once you are ready you are ready to launch well, you start the feature and once the feature is launched your job as a software engineer is not done because after launch you have to monitor feature number one, make sure there are no similar errors popping up right away and your stuff breaks and your customers complain.

If there are then you have to fix them and it may be little bugs that you just fix, you know in your spare time or it can be really bad mistakes or interruptions and you need to fix those and if not, you may want to monitor your product and see if it is succeeding with some definition of success so you have probably talked about pre-launch on success metrics.

And if you have metrics that you are collecting you need to make sure that you have implemented metric collection so maybe you are tracking do how many users are using the feature how many users are clicking on certain buttons and monitor all these things and just see that you know if this is a success then it is great.

If it is not right, get back together with your team and find out if there is any improvement that you can do or any changes you can make and at this point, you are in this kind of maintenance mode. And this is a very real part of the software engineer job who might not be implementing great features or designing API but will support a use product active and you need to make sure it continues to work as it is supposed to and again this might involve fixing new bugs that come up from making small improvements that refactor your code if it wasn’t good to start with or there are performance issues.

It is your job as a software engineer and then this whole software development life cycle that I have been describing is basically reset once there is a new product that you have to develop, except you might be keeping other previously existing features and products.

Conclusion:

It depends on the company to company where a software developer works. If a company is very big then it has different jobs prescribed for different roles. As a software developer, you have some fixed jobs which you have to do like coding , etc.

Software developers at small companies can do different jobs from gathering the requirement of software to making its design. From writing codes for the development of the software to fixing bugs in code and testing the newly developed software that is it up to mark or not.

When you have created software that is up to that mark, you can launch that software or deploy that software to your client. After deploying the software, it’s not over. Developers have to maintain that software according to the market needs and from time to time they have to do maintenance work for that software. Actually, it is a software development life cycle in simple words.

Software developers develop software according to the steps in the software development life cycle which we have discussed above. Hope you understood what does a software developer do on a daily basis.