The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Were it not for Nagy V, I'd be risking broaching this subject - which was surprisingly absent. In part, however, it's because I'm so well isolated from management and my only real "customer" is someone who actually needs what they ask for and knows how to ask for it.
But the star fixes would be in the following categories:
Mandatory Intelligence test for users before they can use applications
Mandatory Intelligence test for managers, cyber-security, and others before they make comments/suggestions
Painful consequences for those who have me create and refine a project and then never use it
Many years ago, my dad was responsible for coming up with his division's budget. We're talking late 60s here (at IBM no less). This was the most stressful part of his year, as every edit required the budget to be completely re-typed. After a couple of years of misery, he had an epiphany, "My company makes computers. What we're doing is stupid." So off he went, taught himself Algol (I think that's correct), and wrote "the budget program."
Day 1 of release a guy calls him:
him "your program doesn't work....." <snickers>
dad "What's it doing?"
him "It's just blinking at me.."
dad "Did you enter your name?"
him "Yes" <snicker>
Dad ... thinking hard... "press return"
him "hey! it's fixed."
Unfortunately, newer more modern versions of "a user" have been released.
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
I wish hackers would go away so I could stop having to pay security taxes.
For the same reason, I wish customers would pay honestly so I could stop wasting time securing the product against unlicensed use.
I wish Microsoft would finish its APIs before releasing them.
Reliable and deterministic GUI layout (and stop trying to cram the whole world into a browser)
Team members that would stop taking shortcuts, and bosses that think cheaper/faster isn't worth the expense/delay/mess
A complete set of tools that everyone is happy with so we can stop changing them all the time and get some work done
Marketing departments would have small budgets, get it right the first time, and stop forcing us to create nonsensical applications and keep changing them in a giant hurry. Recognize when a product is finished and stop piling in more features that ultimately ruin it. (That goes for programming languages, too.)
Reliable hardware, asynchronous access everywhere all the time, push notifications, easier thread coordination that didn't result in crashes or hangs whenever something went amiss
Hotshot programmers that know their place and humbly stay in it
I wish all customers would follow troubleshooting instructions, in order, to completion, answering every question that was asked, only what was asked, in complete, intelligible, punctuated sentences.
Most of my software development woes are not technology related but people related.
1. Coworkers that actually know how to code (present job excluded)
2. Previous employees that worked on the code that actually knew how to code (present job included)
3. Management that wasn't a collection of overpaid morons (present job excluded)
4. Third party vendors that would actually write decent API's
5. Third party vendors that would actually write decent documentation for aforementioned API's.
The only technology solution I want is:
1. One button click to fully clone my entire development environment onto another computer.
I've been living (and programming) long enough to see myriads of great solutions ... left behind. Lots of the problems that we wish had commonly accepted solutions have solutions - but not commonly accepted. At least not today. Maybe they were common, twenty or thirty years ago, but not today.
An example: The problem of changing APIs. OK, we got "interface definitions" - so make it "changing interface definitions". Every new library version comes with a dozen updated interface definitions, to cater for new, extended functionality. You must update your application, interface definition or not.
The majority of Win16 APIs were like LibFunc that became LibFuncEx (with a different argument list), then LibFuncExEx, ... There was (is?) at least one with five 'Ex'! But another subset of APIs took a single argument: A struct, the first member being the struct size, implying the number of arguments, followed by the arguments. The function can be extended without changing the API: Arguments for extended functionality is added at the end of the struct. Well, you might say that appending "optional" struct members is a change, but certainly a non-breaking one. It doesn't require caller code change. Not even a recompilation. If the new library function is handed a "short" struct, it knows to skip the functionality depending on the extra parameters.
A great way to reduce/avoid API changes! I follow it whenever I control the API. Here and there, I see APIs like that, but it is certainly not standard, The Way to Do It. Never touted in the programming courses and tutorials I have seen. You learn interface definitions; great for implementation independency with one specific set of arguments, but of no help with the next version.
When I suggest this approach for coworkers and programming friends, the most positive response is "Yeah, for a function with more than four arguments on the ARM, the compiler lays out code the way you say". Every programmer I know insist on having every single argument individually visible in parentheses after the function name, not as a list of struct members. And every single of them thing they have a godgiven right to change that argument list for every single version. "Just look at the .h file; there you'll see the arguments you must use!".
I have lived through dozens of similar ignored/forgotten techniques. Sometimes, I have to explain how we used to do it a couple decades ago, and they are truly surprised: Why don't we simply do it that way, then? Well... it just isn't fashionable to do it like that any more...
So my wish is that we learn to use the solutions that exist. Even if they weren't invented here. Even if you could write a Ph.D dissertation proving that in one of a million cases, the it is not a viable solution, and therefore we should forget it and rather switch to this new method proposed here!
The software bike shed is filled to the ceiling with reinvented wheels. The bad part is that many of them are not even round.
- Have all software devs magically realize their build scripts can be hard to read too and they shouldn't hack or overdo them without documentation
- Have all build scripts magically be able to warn a dev when a link dies or a project vanishes (or back it up automatically)
- Have libraries/programs magically all start being backwards compatible unless there's a very strong reason not to (e.g., security issues)
- Have all software magically clearly indicate where every file it needs is, even if the author forgot to make a specific error message
- Have hiring managers evaluate candidates on skill instead of bullet points
- Prefer to train managers from inside rather than hiring them in
- A cross platform C/C++ GUI library that can compete with Winforms on C# and is easy to set up
- Have all software magically detect everything that it needs to make it work and spit out an easy to follow report (even for non-devs) saying exactly what you need to install and where so that anyone can set up their PC like that. Including things that the dev already had set up without noticing.
- Have the industry be one that learns from itself rather than saying "this time is different, we're going to start over without the legacy cruft" and then smashing headfirst into the same mistakes solved years ago.
- Have every interface that takes something that already exists and rearranges / presents it in a different form (e.g., OOP layer over procedural API) clearly indicate what the abstraction is and what problems it solves / makes easier in the old API
beyond bug fixes and such, I would love platforms to stabilize to the point where if I write a solid working code base that it could withstand 40 years of running if needed without any weird hacks to keep them going.
seems today software life span is measured in months before replacement/upgrade is necessary, maybe I should go back to embedded stuff
I would like a way to defeat and disable McAfee's Adaptive Threat Protection, which our IT department force-installs on all of our PC's.
Any process that writes a file that looks remotely executable gets scrutinized and routinely obstructed. Visual Studio compiles are broken when they generate manifests and insert them in executables. It takes multiple tries to get past the McAfee scanning interval.
I have to do a lot of my installer development on our build servers (which don't run McAfee). I was working on an installer on my development box recently using Inno Setup. I compiled it and ran it under the debugger. The installer window appeared for a couple of seconds, and then disappeared. The Inno Setup IDE was gone as well. When I looked, the installer executable AND the source file were also missing. Essentially the executable that was being written along with every file opened by the process that was writing the executable were closed and deleted. Not placed in a quarantine folder where it could be recovered, but deleted.
I've been thinking of buying VisualGDB - Serious cross-platform support for Visual Studio[^] to do embedded/IoT/MCU stuff from within Visual Studio but the problem with these type of things is they're typically terrible to middling (Arduino IDE, Platform IO) for the free stuff, and I don't know if I want to pay to play for something that's going to be as dodgy as what I've used so far.
I want a reliable dev environment, particularly for working with ESP32 and ARM Cortex-A and Cortex-M devices (maybe R too)
VisualGDB looks promising but even though it's only $100 I hate when I buy in to a product and it blows up in my face, and I've had too much of that recently. It's trialware but I need to buy hardware to test it anyway because I don't want it if it only works well with ESP32 gadgets and I have no ARMs yet (soon though)
I just am not up for the risk of buying it cold right now, but if anyone has had any experiences they want to share, I'd love to hear them.
Yeah, trials are nice but like I said, I don't have the hardware yet to put it through its paces for everything I'd want to use it for. Before I buy in, I wanted to hear from people that had used it, so thanks.
Mostly my concern is ARM stuff, particularly Cortex-M since i think microsoft is already able to target cortex-a via UWP unless i miss my guess.
Real programmers use butterflies
Last Visit: 31-Dec-99 18:00 Last Update: 25-Jul-21 6:40