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.

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.

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

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

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

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.

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

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

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.

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.

Not much.

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

I work at a mid-tier B2B tech company. I specialize in frontend but am otherwise a full-stack engineer.

My big project over the last two-ish weeks was building a demo environment for one of the company's products. It involved:

• Updating some configurations in our backend to ensure the database can store the information for the demo sessions.
• Writing a class to represent these demo sessions, acting as an interface between the database and runtime environment.
• Building sets of endpoints so that our products' frontend can interface with the server.
• Building a system on the frontend that regularly syncs with the backend on the state of the demo session and provides it to the UI.
• Building a pretty UI that shows the user the current state of the demo session and lets them update it.
• Writing unit tests to ensure every individual component of the system works as it's expected to.
• Manually testing the system as a user to ensure it's all working together as expected.
• Writing a summary of my work and submitting it for review by my coworkers, discussing and applying any feedback given.
• Deploying my work to production and confirming it's all still working as expected.
• Praying to every God that there is no bullshit issue I missed somewhere and will have to take accountability for later.

Along the way, I got several other smaller tasks, like updating logic in one of our algorithms, adding internal tooling so that the customer service team can stop bugging engineering to fix things and just do it themselves, hypothesizing on the sources of random bugs and updating documentation. In between all that, I've got meetings to discuss random other bullshit.

Still lots of coding, but at this point in my career it's more about knowing how my company's systems work together and how to take an idea and turn it into usable software.

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.

https://xkcd.com/303

10% creating bugs, 90% fixing bugs.

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

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.

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)

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

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.

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.

Mostly I make JIRA tickets.

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

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.