10% creating bugs, 90% fixing bugs.

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)

A "full-stack developer" is someone who can do front-end / UI work (HTML, CSS and Javascript or whatever the frameworks and tools de jour are nowadays if we're talking webdev), back-end work (APIs and "business logic" and all the stuff users don't see), and often storage and infrastructure work (manage databases, write and optimize SQL queries, put things in buckets, get your code running on AWS / k8s / a pack of gophers / whatever)

that is

someone who wears too many hats and isn't paid nearly enough by a company that doesn't want to hire 4 engineers

10 Get told to stop working on whatever I'm working on, some tech debt just became tech foreclosure.

20 Some new problem is now problem number 1

30 Get about 70% done fixing the problem (it's functional but ugly, just need to wrap up this mess so it doesn't become tech debt...)

40 GOTO 10

I write code in a niche industry, in an even more niche language.

With 20 years experience I am finally at the point that much of my stuff works without too much headache.

Unfortunately, now that I'm finally good at it, it's become a much smaller part of my overall job.

Nothing I look forward to more than being left alone for a few hours with my headphones on banging out a project.

I’m a DevOps guy and seem to spend most of my time fixing AI slop. It’s supposed to mean automating builds, tests, scans, deploys, compliance, etc, so the other developers can focus on product code and all the process just works

First of all, there is no graphical stuff. That’s just for simple learning sandboxes.

We have an IDE - Integrated Development Environment. You can think of it as a glorified text editor. We type code in text and it gives us the equivalent of spellcheck, grammar check, autocomplete. They usually colorize the code so you can see structure, match parens and quotes, and other low level assistance. But it gets much more useful with integrations to version control, scanners, build tools, download dependencies . You can click to build, test, scan, commit. They’re usually tons of other tools to make life easier.

But code is cheap and easy to write the first time: much more expensive to fix. Maintenance over time is far more expensive than writing it.

So now we have AI as another tool integrated into IDEs, and it is somewhat useful for generating new code based on patterns from previous code. But it’s never good enough to be an end result. A good developer can use the ai to get a jumpstart on new code, iterate it to get better, and almost always have to use their own knowledge to finish it to a working, maintainable result.

So I have a bunch of junior developers in another country, just directly checking in ai slop. They don’t seem to be experienced enough or diligent enough to recognize when it needs more work. Which means I need to spend a lot more time on code reviews trying to figure out the unorganized mess, give the same feedback over and over, review the same code many times, and inevitably spend much more time on bug fixes for their mess than I would have taken implementing it myself.

The thing is ai is not good at bug fixing. You can try to have it summarize the code, or compare it to best practices but it can’t really help figure out what’s going wrong and how to best fix it. Especially if the original code is ai slop to begin with. So I don’t even get any advantage from it

since everyone on lemmy is a programmer

Just because I'm on Lemmy, does not make me a programmer.

I mean, I am a programmer.

But not because I'm on Lemmy. (I think.)

what do you guys actually do?

I say "please" in various ways that computers understand.

Is it copying and pasting tons of code?

Well... Yes, but with a lot more swearing at the computer.

But I'm very good at it, so I copy and paste very small amounts of code very cleverly.

Is it fixing small bugs

I fix small bugs, huge bugs, critical bugs, and intermittent sneaky bugs. I get paid either way.

I'm a data analyst, not so much a developer, but in my work I write SQL, DAX, and M code. My job involves sales people telling me what metrics they think they want, delivering those metrics, then being told to make different metrics because the ones I delivered didn't play into their narrative 🙃

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.

Pointless meetings.

Pointless and harmful forced commuting to and from office.

Pointless agile ways of working.

Pointless managers.

Pointless eating expensive lunch.

Pointless learning of frameworks that gets replaced in a year.

Pointless forced team events.

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

a full stack developer sufficient in sql and python

Ok, let me first try to explain what happens on a good day, before going cynical.

Let's assume we have an existing system. You go to what for you appears to be a website, fill some text fields, click on a button, etc. In the background a lot of shit happens. Typically the backend part of the system consists of tens of services each doing it's own thing. Some participate in returning a response to you, the user. Others just process data further for analytics, security, etc.

One day someone (in most companies a product manager, or a UX researcher) comes up with an idea for a new feature. A user should be able to do XY. And of course pay for it.

That's where you step in. Since you mentioned full stack, you will need to do everything.

• Create a new page with forms, buttons, nice colors and pictures on the frontend
• Accept the result of user actions of the above to an API in one of the services mentioned
• Save the data into a database (this is where SQL comes into play)
• Retrieve data from a database (SQL again)
• Emit various events or API calls to other services, informing about what just happened

This is all done with code. You can copy/paste, vibe code, just type it yourself. Code is the least of your concern. Making sure it all works together is what's tricky. You will go through several iterations until you get it right. Then you write automated tests for it (TDD people don't come at me).

Also you communicate to other people in the company about any dependencies and overlaps with what others are doing. Finally, you can deploy the code to production which will make it available globally to users.

I just described about 50% of the programmer job. I didn't mention code reviews, architecture discussions, plannings, retros, communities of practice, incident handling, herding cats...

This is all valid in a good case scenario. good company and a good organization in it.
In reality it's mostly waiting. A lot of waiting. Despair if you can't make it work. Happiness if you can. Then despair again because all you do is pointless. A lot of fighting against the system designed to make you as unproductive as possible. Or just giving up and faking it for a paycheck.

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.

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.

I think you need to start a project, accept it will be slow and painful, and don't become an expert before you start, just use the skills you have and see where they take you. The only thing that matters in software is that it works. The definition of working changes over time, but get that first working version and you will keep going.

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 am a machine that turns nonsense requirements into nonsense code.

Here's the point in which I realized I didn't understand coding at all.

There as a mod for a game, that was like 95% of what I wanted. It just needed a few values changed, and it would have been perfect for me.

Fortunately, the entire mod was hosted on github, and it was just 3 '.js' files. I figured, hey, how bad could it be? I'll have a look around, find the values I'm looking for, make a couple tweaks...

All three files were entirely, top to bottom, just INCLUDE statements. Not a single line of 'code'. And somehow that's supposed to do something? That's when I realized I was cooked.

Have business requirements change by the hour

Mind i ask what are you trying to archive? At what point would you see yourself as a programmer? When its in your job description? X amount of projects worked on on GitHub?

As an auti-dd I really really like coding and i had a developer job once to discover i absolutely loathed it. I hated having rules and infrastructure that directed me how to code, i hated being told what i could work on. I could not stand having a schedule telling me when to code and from what desk to do it.

The only thing that makes me want to code is to creatively express myself. I no longer accept compromise beyond creative limitations i myself put in place. (Really autistic-pedantic shit sometimes)

My current job description is an IT position that could not be further removed from coding in its description. It also doesn’t challenge me. I don't want it too because now i often have spare free to “improve the functioning of the workplace” which i do by writing scripts and tools that fix common annoyances in our legacy software and save my coworkers plenty of time.

Or in house developer team (who have no time and are to distant from other day-to-day work have expressed confusion why someone like me wants to stay in my role rather then join them but i know i wont be able to continue my side projects and am just going to get assigned to expensive-big-ego-pet-project instead.

I also have plenty of code related projects at home, i lost motivation for those when i was a “real programmer”

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.

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.

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.

I have adhd and I’m a software developer. We make enterprise software for various clients.

We don’t copy and paste, per se, but we do have common practices and many let’s say functions for simplicity that we will reuse over and over as a lot of enterprise looks similar and just the customer screens change. So we still do a lot of problem solving but if we have already solved that problem before we can use it again.

Currently working with a large transport authority to build a claims tracking system and create a bespoke Sage integration to track payments and receipts. And I’m not that smart dude and I don’t even feel like an adult in my forties.

We offer ongoing support to all our clients and genuinely do what’s right and fair all the time as my boss and the own is an incredible dude and just nice and fair and open.

Sit in meetings

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.

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

There's a big difference between hobby coding and corporate coding. I do the latter and work on large applications as part of a team. I spend a lot of my time

• Using debugging tools and probing at code to investigate and fix bugs
• Coming up with system architectures to achieve whatever feature we want to add
• Cleaning up my other teammates' AI generated slop 😑 (fuck AI)
• Writing test suites for our code that guarantee everything works as expected
• Occasionally I write new features
• Juggling this with pointless meetings and a long ass commute that take up 60%+ of my work day

I'm a glorified data analyst. Almost all my work is done with a single database using a narrow range of commands and SQL queries. I memorized the syntax for stuff I use regularly and just type it out every time.

No I do not want to write a bunch of macros. No I do not need an AI assistant. What I need is for all these "helpful" tools and popups to get the fuck out of my way. I've been typing typing typing since AOL Instant Messenger.

I make game mods as a hobby. 90% of the time is taken with deciding what to write, 5% is actually typing, and the other 2500% just seems to vanish without a trace.

Knowing what to type always takes much more time and effort than actually typing. IDE autocomplete has increased this difference further, and AI promises to do this even more (although it seems to increase typing time at the moment).

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.

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#.

Programmer here.

Clicking things in elaborate IDE GUIs and copying stuff they don't understand appears widespread because it's easy to teach and make a video about, but it's not it.

My days are spent in Emacs, (used to be Vim), and a Bash terminal. I sometimes use an more "fancy" IDE for a year or two but I always realize they slow me down and make me stupid.

I write code I understand based on system models I discuss with the team. My time is spent thinking about the models, learning the components I work with, debugging, etc. While all of these involve typing up some code, only 5% or so is writing actually "finished" code.

I write software in many languages that does the things i want it to do. i understand how to write code that works. most of the time i write software it works on the first few tries. i don't do a lot of copy pasting. i write functions and use libraries to create things. it's strange to me, but from what i hear, it's becoming rare for people to really understand how to make software.

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.

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.

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.

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

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.

Slowly dismembering Azure Devops with my teeth

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.