Ask Lemmy

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.

Junior - code Mid - code and meetings Senior - meetings

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.

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

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

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.

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

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.

https://xkcd.com/303

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.

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

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

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