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.

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.

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

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.

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

Not much.

https://xkcd.com/303

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

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.

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.