Ask Lemmy

Not a developer, but a PM and Dept Manager for many dev teams. Your question is wildly broad, but I'll take a high level stab at it.

First, note that there is a lot of variety in software development. This includes industry knowledge, tech stacks, governance, roles and seniority. I.e. a jr programmer on a long established product may just bugfix, or unfuck client data, or make minor adjustment to features on a well understood codebase.

Alternatively a consultancy may be approached by a client to build something new from scratch using a yet to be determined stack. I'll talk about this one. On a project like this the Most Sr dev usually has a title of "Architect". They review the requirements and select the technologies that are appropriate for the job. You are often assembling multiple products to work together.

For example, if you get comissioned to build a company's bespoke e-commerce website you have to get Inventory systems and to talk coherently with product descriptions and image systems, pricing modules, and payment processors and gateways, your in-house loyalty system for points or coupons, along with various shipping APIs from three different shippers and the postal services API for postal code geolocation and address validation. There are also a ton marketing metrics and data analytics that retailer's want so every step of the way through the website what a customer clicks on and if they abandon the process withput making a purchase they can understand why. You could build all these systems from scratch, but why? There are a ton of pre made solutions that due to specialization, are better faster and cheaper than anything you can make. These are called system integrator jobs. Developers make all the systems talk to each other and build in any necessary business logic required.

Then a team will spend a few days configuring their environments. IDE, Repos, installing the tools amd modules required and configuring everything to work as part of a team. This includes the rules for promoting code, peer review, branch management strategies,

"Full Stack" just means you are adept at the back end - databases like Oracle and Mongo and SQL etc, the middleware business logic and anciliary modules as well as the front end making a usefull UI out of HTML and CSS.

Once the team is ready to start, work is divided based on experience , desire and skill. A backend developer might start by standing up a DB instance, then start writing migration scripts to move and transform the data from the old obsolete inventory system. This has to be done programatically because the live data you start with is constantly changing.

Another bunch of DEVs are reading shitty documentation and taking training from the various product vendors learning how the APIs work. Then they install and configure their instances of the products on the designated platforms (cloud or server). They too start looking at the data they have to start with, the product they are integrating's API requirement and any middleware they need to write to translate data the right way. There is always business logic to be implemented here. Such as shipping only to area x&y. Customers from Z can't purchase. If the product can do this, the dev configures it, if not they will write the code for the conditions and responses.

The front end dev's will make a UI that is styled correctly according to the companies brand standards, with proper spacing and navigation customized to the business logic and will display all the images and customer messaging pulled from the various system as they use and misuse the system.

Now withing this big-picture overview, as a developer sets up systems, configures the goodies and writes code, there is a lot going on on their local system. They are frequently pulling code from the repo to update their local system and writing code on that. When they think they have it working after some level of manual testing, they also write unit tests and often test automation so that is something works today, but breaks next week after another dev makes a change somewhere else, you know right away because the tests. Then you fix it. Throughout development, there is a repeating cycle of dev, test, integrate, retest, publish etc... this happens first on your local machine, then on your test environment and then again on higher environments until you eventually get to production/live server. This cycle is most commonly a 2 week sprint. Long enough to make something useful, small enough to not kill the timeline if something fucks up and gets scrapped.

You are collaborating frequently with other devs, qa who report bugs, and business stakeholders who are constantly changing the requirements. Every day is problem solving, creating, testing, fixing and collaborating using all the tools of the trade.

Please note I gave a high level description of one type of development. There are many more aspects to it, including security and authentication. Maintaining an existing product is way different than building or integrating new ones.

Hope this helps.