Okay so being a developer is mostly like playing a never ending game of whack-a-mole with BUGS, you think you have fixed one until few more pops up like a bad case of acne.
But you know what's even worse? When you finally get something working, and you're feeling all proud of yourself, and then someone comes along and tells you that it's not "visually appealing" enough. "Can't you just add some more glitter and unicorns to the homepage? Oh, and can you make it look like it was designed by a unicorn who majored in art?"

I don't really see any bugs in my code. It either works as I want it to, or it doesn't. If it doesn't, I haven't finished.

@spongegeoff if one could see bugs... Oh boy. That would be a fascinating and terrifying gift. A 10 year old codebase would probably burn your eyeballs out, leaving two black holes ....

@P-Asmita that's how it goes, sadly.

But have a virtual pancake. 🥞.

I'll root for you. Don't give up.

@IntrusionCM I don't actually ever see [='experience', 'become aware of'...] bugs in the code I write.

@spongegeoff that could mean one of three things, your a god at programming, you lack the experience to notice bugs or you do not write much code.

During over 36 years of commercial programming I have yet to meet a developer that do mot create bugs, me included (and with 36 years I usually lead the list of most bugs created :P)

But I good dev finds most if then while coding and acknowledge all that are found.

I expect anything more complex than a “Hello world” to have some bug unless its code you have written multiple times and already ironed out any bugs in.

Even after writing a ton of tests that all pass and even doing some manual testing there’s STILL bugs that rear their ugly asses that I left lol.

@Voxera I just know that "bug" is a word I've only heard once or twice in a work environment. As I say, if the code isn't doing what I want it to do, it isn't finished.

@spongegeoff thats a way to see it yes, but if you discover the problem a year after putting it into production you really cannot claim it was something you intending to change ;)

@Voxera I'm just pushing back on the idea that it's normal for developers to deal with an unending number of "bugs". I don't think it's usually like that for the majority of people working with the proven tech stacks.

Unpopular take, but I feel lately (even if I do agree with @Voxera, we all introduce bugs), the issue comes from there being so many bootcamp "developers", and minimal effort script kiddies that can not reason their way out of a paper bag, and therefore, fail the moment even basic math rears in.

Tests don't help there because if you leave these "professionals" to write them, you can't trust them to even be correct.

@CoreFusionX that... And the general complexity.

Plus devs not wanting to be anything more than code monkeys (build system, don't know don't care... Static code analysis? Who needs that... Uuuuh... There is compiler output? Why bother... Etc.)

Complexity is a painful thing.

It has less to do with the language, more like general complexity.

I remember the severe pain of e.g. chasing one week a seemingly Heisenburg regarding to performance that turned out to be a problem in ASPM, slower NVME speed, slower IO.

Is it a bug? Yes. Is it code related? Nope.

I think hardware and software form organisms... Over 10 years ago it started to become more complex to cater for general complexity.

In my current company, we have Elasticsearch clusters of 14 - 15 terabyte of (primary) data...

Plus the services.

Plus the hardware.

Plus the virtualization.

Plus network / logging / ingest pipelines.

Poking these hornet nests is always fun as most of the time it's really siphoning a few kilobytes of data out of dozens of gigabytes of log data, dashboards, alerting....

@IntrusionCM

I dare say that's not a fundamental problem in software/hardware itself, but rather the inherent complexity of any, well, complex system.

When there are many "moving" parts working as a whole things can get messy.

That's why IMO we should push for recognition that what we do is actual engineering more than in title only, but that's another story.

In the end, it's the same as to why we have only solved wavefunctions for a hydrogen atom. Anything more complex and we are at our wits' end...

@CoreFusionX and its also why we should always code with the assumption there will be bugs and have validation and fallbacks so that bad data is caught and in the bast case fixed before causing problems and log enough to be able to track down bad code.

The current code base I work on has been growing for 14 years now with a team of around 20 that has been changing with people coming and going over the years.

Some are really good and some just good enough.

It consists of some dozen separate projects with a couple of thousands of files, some over a thousand lines.

It uses over 100 external libraries since its built on to of an existing cms/e commerce system thats been heavily modified over time.

Yes complexity is the problem together with that new versions are not released on a ny yearly schedule which would allow for massive testing, but biweekly.

Yes, bugs are more or less inevitable but you can reduce the impact and with code review and automated testing catch most of them before production.

Yes you could define anything caught before production as not a bug, but thats more semantics ;)

I just accept that mistakes will be made and strive to handle them the best I can.