What do all you coders actually do?

1. Identify a problem. (User wants do something and can't, something that is supposed to work doesn't, someone wrote shit code that works and we want to fix it)
2. Get more info about it: ask users for more context, find out about their workarounds, assess the impact of the bug, find solutions to similar problems. Get together with others and hash out some design.
3. Do the coding. Often involves a bunch of reading documentation and trial running code to see if it works
4. Come up with a way to confirm the change does what it's supposed to: write a new automatic test, or a procedure a person can follow to verify it works
5. Write a description of the change and test plan
6. Get someone else to check what I've done and make any changes they ask for (as long as I agree)

I... write code. It does stuff. Usually the wrong stuff, until I've iterated over it a few times and gotten it to do the right stuff. I don't "click around in a GUI." If a tutorial is making you do that, it's a bad tutorial.

Something something Jira something scrum agile Confluence something another meeting something hit tab and let copilot do it and repeat.

I‘m working as a freelance web developer with creative agencies to create websites or applications and maintain existing projects. Mostly in PHP with a frontend written in HTML / CSS and some JS.

I also had trouble getting into coding initially since I’m a pretty visual thinker but a university course called „coding for designers“ that taught programming in Processing finally got me into it. In it you didn’t start with a boring ass calculator but make pictures and later games with a simple IDE.

There is this channel that live-streams themselves if you wanna watch like 5-20 minutes and get an overall idea.

https://youtu.be/vc5UPu76XOw

Mostly I make JIRA tickets.

Disclaimer: I have a dream job for me and my experience is probably not representative.

Go on open.kattis.com, pick a problem, solve it. That's what 40% of my job is like. 20% more is reading through and understanding where the right place for this bit of code to live or what bits of code I should be reusing to make it. Another 20% is discussing with other engineers the tradeoffs of solving a problem with x vs y and picking what to do, and the last 20% is reviewing code, i.e. making sure other people solve their problems correctly and don't drop a bunch of hack in our tree.

Now it seems every tutorial I see is really just clicking around in a gui. Very little actual typing of code, which is the part I actually find cool and interesting.

Not sure where you're seeing "just clicking around in a gui", but if you like computer games, there's some fun gameplay you can have while coding. Some of those very much contributed to my experience.

BitBurner is a free idle incremental programming game, where you write scripts to hack things to make money to begin with, progressing onto both progressively more complex mechanics (how about automating a manufacturing corporation with a script?) and utility scripts to automate things you've been doing manually.

If you like Minecraft, there's fun to be had with ComputerCraft, scripting things in Lua. With some add-ons (Plethora IIRC) you can access chest inventories via cable and transfer items between them, and set up your own fully automated storage system with recursive autocrafting, as just one example.

Or how about modding games - if there's a Unity game you enjoy that doesn't use IL2CPP, like Risk of Rain 2, it's very moddable using C# and interacting with Unity APIs, and for advanced stuff modifying the underlying IL that C# compiles to. Quite a lot you can learn, and if you stick to pure code mods to begin with, not that hard to get started - though code mod means nothing like new items, new enemies, new characters, buildings etc. since adding models/textures/sounds tends to be more involved.

Have business requirements change by the hour

Tutorials only explain the concepts, maybe takes you 10% there. The rest is is practical application and applying the methods. You might be able to copy and paste some code but I will bet my bottom dollar that there will be some nuances for your use case that you have to amend manually. Thinking about the logic and how everything connects to each other is often the part that takes the longest and the most challenging.

What I can say is that if you like problem solving, technology is a great drug to get your fix, it is endless.

solving business problems by adding more buttons and input fields that go trough various processing pipes and spawn more infrastructure to compute results nobody needs

I have never just clicked around in a gui unless its me testing something I'm building. I would suggest finding some better tutorials.

Today I added a few features and fixed a couple bugs.

We have a screen where users can basically click through a list of contacts to send out emails. The list is system generated, and sometimes users want the email to go out to other contacts not on the list. So I added a section to the screen with a typeahead input box to search through all the companies in our system. Once the user selects the company it has to be broken down by branch (region) so I had to build out a small api for getting the company branches and filtering by some criteria to see if they're even eligible to receive these types of email, so with that data returned I generated a drop down to select the branch, from there another api call to generate a list of checkboxes for each contact at the selected branch. Then I had to build out a mysql table to store the additional contacts to email and work that logic into the code that sends out those types of emails.

Right there you have perl, mysql, html, CSS and JS.

Another thing that everyone's gonna lose it for when it goes live but took me no more than an hour. A lot of our accounting pages are historical reports, there's only a few that are updated in realtime, and almost all of them were super slow to load because of all the heavy calculations. I added a couple tables and a cron job to run daily and populate them. So now instead of doing calculations on the fly those pages just pull the data from the db and load instantly.

I code around 10% of my day. The rest is just meetings about things people want, emails about bugs that occur and small fixes, finding out what network did again and re-doing the automatic syncs again.

Ironically in all my jobs coding is actually one of the smallest/least time consuming things I do. I do much more coding on my own time than at work. And all without AI. Cause AI is silly (and if you dont self host, your coding for Microsoft/OpenAI/Github/etc...etc..).

My suggestion, try to make the smallest MVP possible and just iterate on it. Find a cool game engine? Great! Try to make the character appear on the screen, then do other things. Find a cool library, great! Try to use the library in a small project. It doesn't work for everyone, but it has helped quite a few people. Do what gives you motivation. Or fix something you hate. Hate is an excellent motivation.

Sit in meetings

I send out resumes to job openings that claim to be entry level, only to be shot down because they want five years of experience in a technology that came out two years ago.

Slowly dismembering Azure Devops with my teeth

Oh, these days?

Nothing.

I tinker around with making a video game, lots of code in that, but no one will pay me even half of what I'm worth, as either a software engineer or db admin or data analyst (or all 3 of those at the same time), and the tech industry's idea of a hiring process is an actual sadistic joke, invented by morons, run by idiots.

The tech industry is largely imploding because most of the competent people have been gaslit and forced out by abusive idiots with MBAs who do not know how to code and have now convinced themselves that if they convert the entire economy into destroying the world with AI datacenters, in an effort to make code that can code itself, well then they win, somehow.

I work with a 7-person (6 devs and a lead) on a 20-year-old financial reporting application. We either pull or receive data from about 7 different systems where folks record contracts, funding documents, purchase requests, purchase orders, invoices, bills, etc. and pull them all together to build reports and UIs where users can search across all the data, and have it unified in one place. That's about 90% of our workload, anyway. More recently, we've adopted workload from a couple big legacy systems that got sunsetted, where we're actually the data-entry point, feeding data out to the main billing system.

Day to day, I work on everything from PL/SQL (Oracle's SQL variant for compiled stored procedures) where the majority of our business logic lives, to VB.NET where two different HTTP Web servers live, as well as a large automated testing suite for that database business layer, to TypeScript where most of our UI logic lives. Occasionally, I might dip into plain JavaScript/jQuery or ASPX to work on older features.

There's plenty of time spent writing code, but there's also a LOT of time spent just discussing things among team. Probably about half of the time, overall. Part of why the project has lasted 20 years is that we've gotten very good at being able to interpret what non-technical finance and acquisitions folks want. Like, they might come to us and say "hey, can you add inter-departmental purchase requests to report X", but they can't always tell us what an "inter-departmental purchase request" is, or where that data lives in the external systems (and that's not like a criticism, that's just the reality of the fact that these people are accountants, not engineers). So, we'll have to probe for specific requirements and/or reverse-engineer it out of an external database.

I also do open-source work in some of my hobby time, which is pretty much all C#.

Product owners say, "We want to change the site so users see a list of all the other users on their team with access to this project "

Okay. Do some thinking. Going to need the backend to return that information to the front end. Decide what URL that should be under (api/v1/projects/users, maybe?).

Now we make the backend actually do that. Create a new file for this endpoint. Update the routes file so that url points to this file. Write the handler class.

Does this endpoint take any particular input? We know who the caller is for free from the framework. We only want to return info about one project or all projects? Make that decision. Update URL if needed.

Write the code to get the other users on the projects in question. Maybe that's SQL, but might also be ORM (code from a framework that generates SQL based on objects). Decide what information we actually need. Package that up and send it back. The specifics depend on language and framework.

Write automated tests for this. Make sure it works for

• 401 not logged in
• 403 asking about a project I don't have permission for
• 404 asking about a user with no projects, or a project that doesn't exist
• someone with 1 project
• someone with 2 projects
• someone with 10000 projects
• also consider what happens for 0, 1, 2, 10000 users on the project.

Realize this needs to paginate. Go back and change the handler code to do that.

Realize due to some quirk of how permissions work, someone can be on the project twice. Talk with the team about if we should just decide that here, or try to fix the root problem. Probably the former.

Add deduplication code, then, and test cases.

Open this up for code review.

Start the front end work.

Make a dummy page first and update your API calling code to know about this new route, assuming you don't have that auto magically set up somehow. Make sure it calls it and gets a response.

Realize that staff users technically have access to every project in the system. Ask product if that's how they want that to behave. If no, figure out what you all want that to do instead.

Do a bunch of react work to make the page pretty, put the response in the right UI elements with links to the right place. Realize the response you're sending back makes building the links annoying because you didn't send some part of it, so you'd need to make another request to the backend for every link. That sucks. Update the backend to include the user's team-id that is for some stupid reason still in the URL. Comment on code review.

And now I'm tired of writing.

Edit: I hit submit before I was done. Finished now. Edit: fix typo

I'm retired now but I used to copy and amend shit from Stack Overflow.

You need an actual problem to solve that your hyper focus likes, then you'll go hard I bet. ~ professional developer with ADHD of 17 years.

I program out of my own need, and if something/a project catches me, it really catches me (ADD). So for a large part, it's customizing software and scripting for my server (selfhosting and hosting others).

As for larger projects, rn I'm managing a middle-sized but fucked up old django webapp, and rewriting it.

Mostly, it's actually writing code (primarily python), including reading docs/tutorials and adapting that to how I actually need it, in my head, and integrating that into the codebase.

At work, it's the fixing of small stuff in Java Spring. And that certainly does not catch me at all.

My last project is using machine learning to sort data for a company and the flow kinda goes like this:

1. Use the advanced tab in the browser on the UI search pagr for the company to expose the API query for the data I want to have
2. Write some shell script to programmatically call the API for the data I want.
3. Realize that there's actually a limit to how much data the API can return BUT the metadata says how much there is beyond the limit.
4. Write some script to paginate (scrape over) all that data and save as a JSON file
5. Realize my JSON is badly formatted and some queries are empty, so do some error checking and massage to make it work right.
6. Create a python script to ingest the parts of the saved data I want and write it to a SQLite database. This takes ongoing refinement.
7. Do some sql to count how many entries I got in the time period I was getting data for, and compare to a tool the company has to aggregate said data. It was close enough.
8. Go learn about Jaccard similarity and locality sensitive hashing. Use this to write a script to deduplicate the database so I don't have a zillion repeated entries. Also python, but it starts with some cursor stuff and sql.
9. Do the actual project which is trying to get some reinforcement learning to label the data automagically. This means I also have to write some methods to get particular mixes of the data I've already collected. For example I want my mix to have 50 percent red balls, 20 percent green balls and 30 percent blue balls. How do you pick the right number of balls from the total set? It's not hard but it takes some thinking.
10. Wrap this thing up in a script that will do some load balancing on a machine with lots of gpus and CPUs so I don't hog the entire server rack. Submit it and let it cook.
11. Write it again so I can wrap options around it and optimize hyperparameters.
12. Start working up the results to show improvement overall. If it's better than what the company already has...
13. Time to fire up the old git repo and make sure the commits are clean. Add readme and make files (bc I prefer to deploy with make) and put it in the hands of another engineer who will roll it out for that company.

Idk it's not a super sophisticated problem but it has a lot of moving parts and you have to kind of tackle them in order. Mostly it's "hey here's an obstacle to the end goal, how do I fix it on my own in a smart way?"

Then do it.

Not much.

Crazy to me that GUI seems to be a major focus in those situations. My IDE is most often pretty minimal, whatever it takes for me to get code on the screen, and unless I'm using the debugger, compiling and running has always been easier using a CLI. It's good practice anyway, familiarizing yourself with the shell, code for your code lol.

I've been developing professionally for almost 10 years now, and started learning very young. The circumstances were different, but I think the principles are the same. Some folks here already mentioned taking on projects that interest you, and I'd definitely agree, provided you keep them small. Something that you'll want to make can keep you motivated, and small wins keep you going. For something full stack, I'd recommend coming up with a CRUD web app (create, read, update, delete) that does something that's fun. Maybe it's a recordkeeper for a sports team, or maybe it's a rudimentary forum. That sentence makes sense, no worries. You can use python to write your backend, see if you can make an API that just handles CRUD requests and builds and runs SQL statements for your database. Then just use whatever you'd like for the front end and call that API. It's still a pretty big project depending on how new you are to this, but it's hard not to be when full stack touches everything. If you're completely new, I'd lay off and pick the front or back end to start with.

The best way to get into coding is to surround yourself in it by switching to linux and starting to program your own desktop interfaces (can be through browser too). Once you live in your own software the surface area for motivation is significantly higher so you actually learn stuff. Come up with ways to automate what you do and don't be afraid to fail.

There's coding and there's coding. Just as you can use English to write fiction, you can use it to write a manual. Programming languages are the same. Well, maybe a bit more concise and confined, but the point is, you can flick around bytes on a bus or thousands at a time in CUDA. You can draw a triangle for a game or create a template UI with the click of a button and fill in the blanks. It's all 'coding', but wildly different.

You might have heard about the meme that coders are wizards comanding magical stones, aka processors. Sometimes, we might as well be. Computer scientists come up with stuff so briliant that even the best of their own can hardly understand it. They write stuff that does stuff for stuff that does stuff for the stuff you wrote, and all of a sudden you did something without even really knowing what happened or how it works.

With that in mind, I can explain what I do in one sentence or countless hours. I write stuff to test stuff that absolutely has to work. The devil is in the detail.

It's a very diverse field with myriad platforms. A game dev's day will be very different than a dev working for a bank. Most of my work career has been boring soul-sucking "move dollar amount x from here to there" corporate bullshit that paid the bills. As a hobbyist, I've taken a crack at coding for games, music, custom postscript generation, ray tracing, etc.

Look into “recreational programming.” Make shit for the joy of making shit. Creation in it of itself is something to be sought after imho. Did’t finish that website? Who cares?! Don’t have any useful ideas? Make something useless!! Don’t worry about “users” or making the next big thing in tech. If you’re having fun click-clacking on your keyboard and solving problems, that’s all that matters

So to answer your question, I’ve dabbled in a little bit of everything: web, db, graphics, interpreters, osdev, the works. The very few projects I’ve ever “finished,” however, are my lower-level ones; I just love getting right up close to the metal. Find a niche that interests you, start a million projects in it, and be proud of the one you finish years after you probably should’ve

Right now, I’m working on a custom programming language/game engine built with Vulkan and LLVM. It’s got first-class support for a bunch of cool game and graphics stuff, and I’m super passionate about it right now. I’ll probably lose steam and only come back to it months after, but I don’t mind

Edit: Also, don’t be afraid to use libraries to focus on what you want to focus on. I used to have an obsession with writing absolutely everything myself from the ground up, but I’ve since come to the realization that other people are MUCH smarter and more talented than I am, and I should trust them to write software for me. A great example of this is LLVM and my graphics language — depending on someone else to do the super complex compiler design lets me focus on what I wanna make: a language front-end and graphics library. It’s important to limit your scope to only what you care about

I only program for fun, usually in video games. A lot of games let you code in LUA (shout outs to computercraft)

Its fun for me to write it out, and i dont really understand how to use git, so I write it all out.

I'm in the same boat as you. The GUI thing doesn't interest me. And I end up knowing "basic to intermediate" knowledge of a few different languages because, when you get right down to it, once your somewhat familiar with one object oriented language, the others fall in line pretty quickly.

I find that for learning, I have to have a project to be working on. I can't just sit and do exercises about classes, tuplets, and all that crap. I need to be able to say "okay...I want to make x do x on this project I'm working on...and then troll around the internet to figure out how to do it.

Unfortunately too little coding and too much random busywork. Updating random documents, fixing small bugs, updating versions in like 4 higher projects to make sure my new feature actually shows up in the final software. But when coding, it's indeed quite often just adding a random new button or something with all the backend logic as well. And the testing of course.

I'm currently burnt out because we spent months on end doing preparation work, creating all kinds of UML diagrams to prepare for a big rework, only to be put on a different project and do it again. Although I was probably already on my limit before that..

It all sounds a bit negative, but when we're in the normal flow it's still mostly just coding and debugging, two things that I do enjoy. Spending a whole week hunting down some obscure bug that only happens in certain conditions sounds like hell to some, but to me it's like a murder mystery and I love that shit. With complex and large corporate systems there are so many suspects for a bug, it's a real challenge to uncover the mystery and by the time you find it you've learnt a lot about some random part of the application.

I tend to write Java. Many people don't like Java, and honestly it's also not a fancy language. It isn't Rust, Julia, or Haskell, languages that I find very interesting. But at the end of the day I'm not sure I'd pick any of them over Java for building a large application like this. Java is boring because it's quite well designed for large enterprise work. It keeps people from doing too many flashy things that are understood by no-one. It just works (tm). It's fast enough, has great tooling with Maven, does everything pretty well, has lots of libraries to use, and almost everyone can write it.

I'm a data engineer, which means I write code that manages data aka databases. RN I'm mostly working with python, pyspark, managing data transformations from different providers. I'm also managing the deployment and execution of such pipelines via terraform.

I don't copy much code, if at all. I do search plenty examples online but then I write my own. I'm at the point where I could adapt myself into almost any language in a week though, they are very similar.

If you want to go into coding focus on understanding the functionality of the code, what it is actually doing and why is it done like it is, that should give you a lot of flexibility when changing frameworks or languages. A lot of stuff is super similar across the board.

About your question, "a full stack Dev with sufficient sql and python" is probably a front-end Dev that does JavaScript and CSS, with some front framework like react or Vue, which will have to create the code of the webpages, build components... They also mention sufficient SQL and python, which implies that the backend is done in python and that they have some database. Probably Django or flask. In the backend you create business logic, stuff like "get me the list of users", things the front-end asks the backend. For some queries the backend will also ask info to a database, and it will have a SQL client where it will have sql code to query stuff.

Hope this helps.

Hmm, I am programming as a hobby, but I tried getting into it several times without 'getting' it too. I then somehow found the free cs50x online course and got hooked and finished all exercises. What helped me were clear goals to work toward and the immediate evaluation of the exercises. I could not get any of this from books or websites alone. I especially loved the sql problem sets.

I then worked on my last submission for a long time, which was a work related application. It worked fine on android and linux and I was proud to submit it, but there was no way to compile the program to get it to work on ios (yeah we've got iphones at work...) without a mac.

So then I rebuild the entire app in JavaScript and made it into a multiplatform progressive web app (My main goals were to make it completely work offline and then sync to my server and to let it run on (almost) every device.). I learned a lot in this time, it still got bugs, and designing the ui is somewhat painful (though I love working with inkscape to make icons and pictures and stuff, css though...) but this year I was able to get a test run at work and it was really helpful so far.

Bye, bye maintaining our large, confusing, error riddled, ancient excel tables by hand staring at them for hours!

I still got lots of features I want to implement and bugs to fix. I am aware that my app won't be up to industry standards (no access to some expensive equipment and rule books), but it is still helpful and it is a lot of fun to work on.

And what happend since I am familiar with python and js and such is, that I try to automate everything, even if it sometimes takes more time to write the scripts. With more and more practice I find more and more problems to solve, like I want to build a weight training tracking app, and I know there are many available, but why not?

You need to find some clear goals and get hooked, and yeah that is something that I struggle with too. (I want to get into playing piano, but I currently struggle to make it click too). Too many hobbies and too few time...

I make mods for games. I actually type code. Most of the time... Sometimes I just copy and paste because, I mean... There is not an infinite number of ways certain things you wanna do can be done and why reinvent the wheel.

I taught myself starting in high school, from actual books! Dry, boring, heavy, books.... And they sucked!

I don't know enough to make it a job tho. I certainly have no idea how even working with multiple people on a single thing works.

I am not a programmer, but I did code something from scratch.

I started with a simple idea, I wanted a bot that can chat on twitch.

I did tons of research, applied for a key from twitch, finally got it to log into chat with the most basic of sample code.

Then I started to make commands for it. Added one by one over about a year.

Then the real challenge was getting the code to do math for people in chat: change temperatures between F and C, doing calculations for the blood moon on 7 days to die, and other stuff like that. Eventually I got all that working but it took a ton of trial and error.

The parts I couldn’t get working yet are getting my code to talk with a SQL database and commands so people can add and remove the bot from their channels themselves. Not sure I will ever finish it since I no longer run a server 24/7 now that I’m offgrid.

I work at an Infrastructure Cloud company. I design and implement API and Database schemas, I plan out backend workflows and then implement the code to perform the incremental steps of each workflow. That's lots of code, and a little openapi and other documentation. I dig into bugs or other incidents. That's spent deep in Linux and Kubernetes environments. I hopefully build monitors or dashboards for better visibility into issues. That's spent clicking around observability tooling, and then exporting things I want to keep into our gitops repo. Occasionally, I'll update our internal WebUI for a new feature that needs to be exposed to internal users. That's react and CSS coding. Our external facing UI and API is handled by a dedicated team.

When it comes to learning, Id say find a problem you have and try to build something to improve that problem. Building a home lab is a great way to give yourself lots of problems. Ultimately, it's about being goal oriented in a way where your goal isn't just "finish this class".

I'm not working as a developer right now, so most of the stuff I write are supplementary for my creative projects. If I have a problem involving too much manual work, I want to figure out a solution to minimise it. Mostly done in scripting languages like Python and Ruby. Also doing number crunching and plots in the R programming language.

For example, I'm working on tools to help my photography workflow. I sometimes get weird ideas like "I wish I could have a better idea where I have taken photos in", which turned into a script that takes coordinate metadata from photos and spits out a .kml file a mapping software can read.

I don't really copy/paste code much. Sometimes the tools you use in the scripting language land spit out automatically generated stuff which you then develop further.

Mostly what I do is have anxiety about not knowing what to do since no project ideas come to mind and then feeling guilty about not doing anything.

Doing more game dev helps, but my mindset of not doing something because better projects already exist definitely keeps me from programming a lot.

Right now, I'm upgrading my Nushell plugin in Rust code while not being very familiar with Rust and its mechanisms. I'm using the build errors, cargo crate (libraries) documentation, auto completions/suggestions, existing own and cate/lib source code to find the correct methods and way to do data format transformations. I managed to make it compile again, so now I'll test-run it. I "accidentally" extended what it can map as well, which is a positive side-effect.

It depends very much on the role I'm in, and what you're asking in particular. As far as hands-on development work,

• No, I don't copy tons of code
• I read and/or search and/or analyze and/or remember existing code, to understand what is happening, identify bugs, or embed and write solutions that make sense within the project, reuse existing mechanisms and approaches
• I develop and write solutions, sometimes in one iteration, sometimes through multiple iterations, when I have new findings during development or solution behavior or new questions raised
• When it's web, it's more writing, if it's a Windows Forms app developed with Visual Studio, UI placement and layout is a UI process, but connecting it to and implementing it's logic and behavior is still a coding task
• I love making use of efficient editor and IDE features like multi-cursor editing when they're useful
• Overall, I think being in the UI is the smaller part of development

Professional development in general entails much more. I work with my customer and consider their workflows, needs, I discuss and question their requirements, I design solutions both in user workflow, UI, UX as well as in code architecture and implementation. For a long-running project, improving existing code is a large part of what I do when implementing new changes. Documenting what I find out or see and is not documented yet is another big part.

If you feel you never get it beyond absolute basics I encourage you to work on tools, utils, or projects that you use or care about. I wrote various utils for my own benefit and use, and do regular drive-by contributions to projects I find useful or interesting (mostly related to documentation or tech approachable to me).

Don't just follow tutorials. Set a goal of something that works. Be it a clock, a calculator, a command line tool that let's you read music file metadata, or starts or stops programs for you. Or whatever you feel might be reasonable to explore and achieve, whether with or without practical use.

Junior - code Mid - code and meetings Senior - meetings

It helps to have a concrete problem to solve. If you just say I want to learn coding you'll not go very far

Full stack python and SQL means python to handle user interface, data connectivity, interfacing with APIs, understanding/designing a database to perform the necessary data storage / retrieval in an optimal way for how your application works, creating all the logic, safe guards, etc.

Basically I have this thing I want to do, and it's going to interact with a lot of data. Your tools are python and SQL and a small stack of money - make the thing that does it all

Full stack means all the parts, soup to nuts

So my question is, since everyone on lemmy is a programmer, what do you guys actually do?

Hey now, some of us hate programming and the deepest we go is being scripters. I, for example, am dogshit at coding, but I am pretty solid at systems and network administration.

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.

https://xkcd.com/303

I’m an energy engineer, so coding isn’t the main part of job, but I use Python a lot for data analysis. So I load CSV files and reformat the data into how a particular program or person wants it. I also dabble with SQL and PowerShell for configuring data pipelines, basically picking a subset of data out of a database and using PowerShell to automate that extraction and the upload to a server.

I make e-commerce websites. It's a lot about making widgets, making logic for connecting to their accounting system and how prices and discounts work together. Then whatever delivery and payment system they need and so on.

I write 90% of the code by hand since it works for me very well.

almost everyone in my area is coding, programming or software engineer, or an physical science engineer, rarely i see people that are researchers in a lab. its hard if you dint start young where you can retain more info. wish i did it before transferring and sticking it out with bio.

I’m not a dev, but I work with a lot of them, and I do a fair amount of bug testing and reporting for them. Devs do so much: they usually deploy and maintain the infrastructure (servers, virtual machines, databases etc.) upon which they build stuff, they write code in a bunch of different languages, connect things up to external APIs to add more functionality, process and combine datasets to use in the things they build, and plan/track all of that wok as granularly as possible using a variety of project management tools like GitHub or Jira.

Actually writing code from scratch is probably only 15 or 20% of what they do, at least at my relatively small company. And that’s usually spread out among a few different devs who have their own specialities.

Just to add to the answers that the sort of thing you are talking about exists. It’s called low code, with companies like Outsystems and Mendix.

It really depends, most people end up specializing into specific things they work on as software has generally become too big for single developers. We have people that only do frontend stuff so things look nice on the website, some only deal with the database and making sure we return results as efficiently as possible.

I started off doing the typical full stack but I've since branched off into DevOps so now I'm responsible for a few hundred servers across the globe that I keep updated and running smoothly.

Sometimes I work on new tools, sometimes I spend days tracking down weird problems, sometimes I'm rushing hotfixes because something is repeatedly crashing in production.

It's worth noting that because you can click through UIs these days doesn't mean that scales as you go. You can go spin up your app in a container in the cloud mostly through UI, but soon enough the defaults aren't enough. I manage several hundreds of instances across a few clouds, I'll well, well past clicking next next next finish. It's just an easy and visual way to ease you into things, especially for beginners, as all the options available to you are there to see along with little help tooltips explaining what a setting does.

It also depends on what you do: if you work at a startup, clicking through Cloudflare's dashboard is more than enough. When you have thousands of customers, you're not managing the tens of thousands of settings you have to configure, you automate.

Code can describe things (HTML, CSS, HCL), code can configure things (YAML, JSON, Ansible), code can program things (PHP, JavaScript, Python, Ruby, etc), code can query things (SQL), programming as a whole is very wide.

I almost never use a gui with computer languages and im not even a coder. Granted most of what I do is edit code, make a small script, or utilize code syntax in config files and such. I have used an ide but I still am not super comfortable with them. I mean they are guis but its just a way of organizing the files so its not licke click to do things. I don't really get what you are even using. Like cell phone app stuff as that looked kinda gui but is not my type of thing.

It kinda depends on the company, but with growing seniority it will become less and less actual coding. I spent less than 50% of my time on coding. The rest is meetings, coordination with team or stakeholders or other teams I need something from, answering questions, brainstorming, writing specifications, writing technical documentation, research on tools or technology, staying up to date on tech, testing stuff, reviewing other peoples code, root cause analysis, etc.

Actual coding for me is very rarely copying anything. AI assistants made searching for code snippets mostly obsolete. Also, very little clicking is happening. Even the graphical interface we usually write in code (no designer is used).

"Coding" is a huge world and in my opinion in today's world the term "coder" is too abstract to mean anything in practice (other than someone who writes code among other things). What we mostly share is really just the basics. You can improve your fundamental knowledge that will help you learn, understand and navigate through the differences quicker.

But not just from field to field or job to job, but even from just one task to another task, a coding session can be totally different from another. The "actual typing of code" is just one mechanism.

If I understand you correctly and you're specifically interested in the act of typing code and understanding what it does, then maybe you might be more into coding puzzles or you could learn more about algorithm design. Else, if your goal is to see more output by coding, then progress and experience is the only way. I don't have ADHD, but I have difficulties in finishing personal coding projects, too. Coding for work definitely helped with that. Before that, the biggest improvement I found was to use more Git (/version control in general). Helped me a lot to organize and see my progress.

learn new js frameworks an cry when i see agent641@lemmy.world's jira tickets