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 I make JIRA tickets.

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

10% creating bugs, 90% fixing bugs.

https://xkcd.com/303

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

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.

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 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 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 simply started programming before there were GUIs. That helped a lot. Another thing that helped was that I had no means to save a program. I had to re-type it every time from the listings in the magazines, the main method of distributing software back then but for cartridges.

I later learned several different programming languages, and the first GUI I used was one I actually wrote myself (later, on a different computer which actually had a floppy disk drive).

And while my job is in programming, most of it is still typing. GUI use is limited to setting up the project in the IDE, which can be a lot of clicking and selecting, but once the basic hardware framework is set up, it’s all editor work.

Sit in meetings

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

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