Your pet peeve, technical or otherwise.

[KE5FX]

Qt is popular enough that the major LLMs are likely to give you very good advice.  Don't neglect that resource.  Disregard those who advise otherwise; it's not 2019 anymore.

[metrologist]

Cable entropy.

It makes it hard to deny there's evil spirits at work.

[TimFox]

I wonder if the Bitcoin people secured a trademark?

[Analog Kid]

I notice it most when I'm reading tech news or science updates. Misuse of terms really irks me, especially when it's in supposedly credible places. One of mine is when people refer to cryptocurrency as just “bitcoins,” like it's the only one. Or worse, when someone says they “invested in crypto” but can’t name a single coin aside from Bitcoin.

Well, that's pretty much me.
I know all about blockchain and all that, but I don't know all the different coins because the instrument has yet to be invented that can measure the vanishingly small interest I have in all that crap. So I might throw out the term "bitcoin" erroneously. So sue me.

[paulca]

I notice it most when I'm reading tech news or science updates. Misuse of terms really irks me, especially when it's in supposedly credible places. One of mine is when people refer to cryptocurrency as just “bitcoins,” like it's the only one. Or worse, when someone says they “invested in crypto” but can’t name a single coin aside from Bitcoin.

Well, that's pretty much me.
I know all about blockchain and all that, but I don't know all the different coins because the instrument has yet to be invented that can measure the vanishingly small interest I have in all that crap. So I might throw out the term "bitcoin" erroneously. So sue me.

I have owned about 4 "hoovers".  None of them where actually made by Hoover, but all of htem were called "The hoover".

[Circlotron]

When you have to go through about 500 questions in an online hospital admission form, and you get to the end, and there is a summary page where you are asked to verify that it is all true and correct, but there is no facility to change anything you might see is a mistake. 

[paulca]

When you have to go through about 500 questions in an online hospital admission form, and you get to the end, and there is a summary page where you are asked to verify that it is all true and correct, but there is no facility to change anything you might see is a mistake. 

Is there a bread crumb trail at the top?

Is there a "<< Back" link?

Often it's hidden in plain sight under your nose..  So obvious you look straight past it.

[paulca]

Modern monitors which code like it's 1973.

I have an ASUS "baller" 43" 4K HDR gaming monitor.

When I power the desk up and turn the PC on, the PC has booted BEFORE the monitor has.

Everytime the PC goes into "Screen standby" the monitor goes into standby a few seconds later.  If I wiggle the mouse, type my password, hit enter and I can still take a couple of sips of coffee before the monitor has booted back up from standby.

When you have to, god forbid, try and use it's menus.  OMG.  It really is 1973.  They are still using the same rubbish complicated 2 or 3 button interfaces they used for VHS programmers and bedside radio alarm clocks.  The only thing that has changed is they now have a bit map OSD that looks like their UX designer was 63 years old and his last project was a CRT TV OSD for TeleText.

I know why.  It will offend a lot of people here, but... for the love of god, when your hardware gets better, STOP writing your own software and out source it.  PLEASE.  You simply do not know what you are doing give it to someone that does.

[shapirus]

I know why.  It will offend a lot of people here, but... for the love of god, when your hardware gets better, STOP writing your own software and out source it.  PLEASE.  You simply do not know what you are doing give it to someone that does.

But they did. That's exactly what happened. They hired a team of PC operators in India that slapped a few preexisting pieces of crap written in NodeJS together, and there you go, your shiny new monitor firmware is ready.

[jonovid]

schematic diagrams that are way too fragmented or have components listed in a sub directory when there is plenty of space available on the same page.

[Nominal Animal]

for the love of god, when your hardware gets better, STOP writing your own software and out source it using interns and the cheapest developers you can find to write the software/firmware, and get actual professionals to do it.  PLEASE.  You They simply do not know what you they are doing. Give it to someone that does.

Fixed that for you.

I've been saying the same for years about Linux-based appliances.  The systems integration in most is done by poorly-trained monkeys who left midway, based on what the end results look like, wireless routers being among the worst I've seen.  (Linux/Android is extremely common on TVs, too.)

You don't need to outsource it if you get a proper systems integrator (Linux) or software engineers (custom firmware) or both, especially because most outsourcing companies also use interns and the cheapest developers they can get.  What you do need, is proper people to do the job.

[pcprogrammer]

What you do need, is proper people to do the job.

But that makes it more expensive, and people don't like to pay extra for that. 

[Analog Kid]

I know why.  It will offend a lot of people here, but... for the love of god, when your hardware gets better, STOP writing your own software and out source it.  PLEASE.  You simply do not know what you are doing give it to someone that does.

But they did. That's exactly what happened. They hired a team of PC operators in India that slapped a few preexisting pieces of crap written in NodeJS together, and there you go, your shiny new monitor firmware is ready.

Speaking of crappy monitor OSD firmware, I just loves it when some of the menu options have the up/down buttons reversed, so you're never going in the direction you want to.

[Analog Kid]

What you do need, is proper people to do the job.

But that makes it more expensive, and people don't like to pay extra for that. 

"AI"!!! Offshoring!!! Outsourcing!!! The way to a bright shiny new future!!!

(meaning lotsa $ $ $ $ for us, of course)

[MathWizard]

So can you change font's in LTSpice so the capital letter I is easier to read ?

How hackable is LTSpice? Coders dig into everything, have people modded LTSpice at all?

[paulca]

How hackable is LTSpice? Coders dig into everything, have people modded LTSpice at all?

Given LTSPice still looks like it was written around 1995 I doubt it.

[paulca]

I know why.  It will offend a lot of people here, but... for the love of god, when your hardware gets better, STOP writing your own software and out source it.  PLEASE.  You simply do not know what you are doing give it to someone that does.

But they did. That's exactly what happened. They hired a team of PC operators in India that slapped a few preexisting pieces of crap written in NodeJS together, and there you go, your shiny new monitor firmware is ready.

Wait.  No.  Wrong type of OSD.  NodeJS is android smart TV territory.

I'm talking about non-smart, basic monitors with the buttons hidden down the side (or bottom, or some awkward to get to place).

The ones you feel for the 2 or 3 buttons (the fancy monitor has a joystick!  ... and 3 other buttons which all do random things.)  Press one of them, get the wrong menu, press the other one, but realise the previous menu is active and now you are in a sub menu.

Then you press buttons randomly hoping to find out which one is "BACK" or "HOME"

You give up after changing the brightness or contrast accidentally, or switching it into gaming mode of some crap.  You wait for it to time out.

You try another button hoping it's the menu and luckily it is.  So you press up... nope... down to the "Source>>" text line and press the button.... NOPE.  That IS the back button we were looking for earlier.  Repeat.

Now it gives you menu like:

< DP0 >

If you press "Right" it will cycle to the next source.  If there is a signal there, regardless of whether this is the signal you wanted or not, it will lock onto it and close the menu.

If it WAS the source you wanted and it doesn't (yet) have a signal it will advance to the next signal after 3 seconds and stop on teh first one it finds a signal on.

Each interaction with that button takes a second or two to have an effect.  Multiple button presses when one was required are sometimes ignored and sometimes buffered.

It's exactly like programming a 1980s radio alarm clock.

By in by, I have done the task for writing such an interface.  Well, a 2 button clock/alarm setting interface.  It's a pain stakingly tedious and bug harbouring state machine task full of corner cases to address everywhere.  "Hold for fast?" or "Hold to exit setup?"

Communicating the function of the buttons leaves a lot to be desired, firstly in terms of "affordability".

In my view, the menu I have could be simplified to a single joystick.  The menus "journeys" by use case drawn out and studied, then rearranged into the most practical, intuitive form.  The more common the task, the more obvious and intuitive.    Leave the complex parts for being buried in sub menu hell.  Consistent navigation.  Fast reponse.  Either buffer (ideal) or ignore, don't mix.  etc. etc. etc.   You know HCI and UX.

[SiliconWizard]

What you do need, is proper people to do the job.

But that makes it more expensive, and people don't like to pay extra for that. 

Yeah, fact is, it isn't necessarily more expensive in the long run: quite often, it's the opposite. But short-term management has become the norm.

[paulca]

AITA?

We reviewed a list of work items this morning.  The first section of which added up to 44 developer days.

Management then simple did:

Days / Developers = time elapsed.

Not on my watch it doesn't.    So I point out the ratio is more like 1.6, not 2.0 for 2 developers.  Also no one of the develoepers is 100% allocated to just this singular project.  They are pulled in many known directions and many unknown ones later.

Then the figure of "We have 7 weeks..." was thrown around.

So I ran some basic strawman "real world" project figures and said, "7 weeks is fine.  44 man days into 7 weeks is approximately 6.5 dev days per week for 2 developers, thats pretty good, "Under promise".  So I was happy.

"No...  the 7 weeks is for a total of 70 man day effort" .... and scrolled down the page.

At this point became "pointy" and "negative" about the affair.  We never deliver any where near on time.  We are always asking for more time.

This is why.  In other areas.... "Senior Programme Management", account level types.... they do Year+1, Year+2, Year+3 planning on an excel sheet with months as columns and projects in the rows.  To work out how many months, they ... wait for it.... the "COUNT Business requirements" and multiple by a constant.

Am I the asshole?

[Ice-Tea]

1) Enter their office.
2) Give them this book:

3) Leave their office.

[paulca]

So my code editor "smarts" are reviewing my unit test code, as they do, as I go.

It's currently giving me warnings for most of my "defence" test.  It's warnings like:

"This method with these parameters will always return null.  Remove this useless assignment and just assign null."

This has me frowning in deep incompute right now.  I know it returns null, because I wrote it to return null under those conditions.  I am testing that it does indeed return null.  If I follow it's advice the test would be:

result = null; // cause, well, meh
assertThat(result).isNull();

Which I know 100% it will also give me a warning for because "null" is always "null".

Err:  Does not compute.

[Analog Kid]

Well, it's just a warning so you can ignore it, right?

[Kasper]

What you do need, is proper people to do the job.

But that makes it more expensive, and people don't like to pay extra for that. 

Yeah, fact is, it isn't necessarily more expensive in the long run: quite often, it's the opposite. But short-term management has become the norm.

Some ladder climbers just want to put on their resume: decreased costs by 19.99%.

They don't care what happens after they've hopped on to the next company.

[paulca]

Well, it's just a warning so you can ignore it, right?

I can yes.  The report gets published though.  Don't think anyone is actually paying much attention to them, right now, but they persist over years and can be used against you in compliance and audit reviews.

Analogous to ERC/DRC errors on schematics I'm sure.  Ideally you like them clean.  The more you exclude as "Noise" the more likely you miss one that was actually important.  If the ERC/DRCs are published/recorded and later used to "assess quality" it means you gotta explain them all ... again.

Lets say there are competing paradigms in Java.  There is an influx of folks from the likes of Scala and other JVM functional layers.  For them "null" is a horrifying concept they just don't understand.  Academics have been designing the entire concept of "null" out of software where they can.  Because above all other bugs, "Null pointer" is king in terms of cost.  This leaks into Java land in the form of aspect orientated "validation layers".  When you define an entity to have a property and annotate it with "@NotNull", then the auto generated code will be done such that the property accessors cannot return null.  They will die before they will return null.  Very often that is handled in an blunt fashion like throwing a NullPointerException.... when it hasn't actually occurred, rather it might occur later as the @NotNull contract is broken.

So the code review tools are getting smart enough to see that somewhere there is a "NotNull" enforcement and sees further null checks are redundant.  It is trying to discourage me from unnecessary null checks.

The fact I can produce an uncaught null pointer exception at will, while there are @NotNull's in effect tells me it's bullshit and not to trust it.  So I add null checks.

I use the other "nulls are unsavoury" method of handling them... "Right back at you.  If you feel it is acceptable to send me a null, then you hopefully find it acceptable that I return you one back in kind.".  The alternative is throwing an exception or allowing the NPE to manifest.  All are valid as they all cause a failure for bad data which shouldn't occur.  The tendency however is to catch early and often and don't let errors propagate far from their source as tracing their cause is a lot harder.

On "We don't have null anymore" programmers.  Please, please stop doing the following, if you could be so kind:

object.method().method().method().method().method();

Because I am sick to the back teeth of trying to find the NPE when it ocurrs.  Java only gives me the line number to go on.  ANY of those .method() calls is a canidate.  Now I have to split them all up into local, readible, variables. LIKE YOU SHOULD HAVE!  The compiler has the job of converting your "human readible" code to machine code.  Let it do it's job.

You can do this in a language which actually enforces "no nulls", like "Reply receiver" default pattern etc. etc.  STOP doing it in code where nulls are real.

[Nominal Animal]

It is trying to discourage me from unnecessary null checks.

Well, I am ridiculed for using the pattern "free(ptr); ptr = NULL;", too, in long-running C code.  Yet, my code has far fewer pointer bugs and memory allocation bugs than typical C code I see.  This is why I prefer tools, cow-orkers, and workflow to be evaluated based on their results, not their popularity or fashionableness.