|
- 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.
|
|
|
|
|
Can't we simply get the customers/managers fixed?
|
|
|
|
|
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.
And a general complaint:
1. Can we just get rid of passwords? 
|
|
|
|
|
Requirements. Those I surely wish were fixed. Yeah, I can anticipate a couple things, but I also end up with monstrosities after months of iteration.
|
|
|
|
|
I would simply get rid of all technical management, which will solve all your other problems very quickly...
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
I wish companies would stop abandoning perfectly good development tools when they pursue the next big thing.
|
|
|
|
|
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
|
|
|
|
|
I think we should just start with solving World Peace and then start looking at that list. It'll be easier...
cheers
Chris Maunder
|
|
|
|
|
Borders are obsolete; get rid of them.
Problem solved.
|
|
|
|
|
Are you trying to start another of those HTML5/CSS pissing contests that turn into witless whining about obscure typography issues?
Software Zen: delete this;
|
|
|
|
|
Next big thing a holographic keyboard - fixes your emergency debug problem.
Or Peter Hamiltons mind machine interface.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
I'd wish that all my co-workers had exactly the same coding style as me.
|
|
|
|
|
write once, run forever.
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.
Software Zen: delete this;
|
|
|
|
|
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.
Real programmers use butterflies
|
|
|
|
|
It has a 30 day free trial.
I've been using it for years now for cross platform Windows/Linux development, on a variety of embedded hardware (Custom and Raspberry PI).
It does the job well, although the built in tools in VS are catching up for Linux.
Not used it for simpler processors yet though.
|
|
|
|
|
Are you a super hero by chance and if so, what are your special abilities?
|
|
|
|
|
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
|
|
|
|
|
I bought VisualGDB a couple of years ago for a project with a Raspberry PI, ESP32 and the CC1310 (Sub GHz Arm based RF processor). For the Pi and ESP, it worked well. Hid a lot of the gory detail of the build environment setup. Support was fast and competent when getting it going. I now don't know what bits are VS and what are VGDB so have to keep subscribing to support the, now completed, project. VGDB seems to stay out of the way when doing Microsoft stuff on the same VS. Remote debug works a treat on the PI, a few limitations with the ESP32 but still useful. The CC1310, sadly, wasn't supported but they said you can script an environment for other processors if you have the time and inclination. I am happy enough with CCS for that part however. Overall, would, knowing what I know now, buy it again. All up, VGDB saved me a lot of time, avoiding all the intimate build and debug stuff I didn't want to get involved in. Better focus on the application. Proviso is, I was being very vanilla about the PI and ESP32 parts so no experience of non-standard usages and I am an old school, monitor and tag debugger so didn't stretch the debugging much. Hope it is a little helpful.
|
|
|
|
|
Thank you so much!
Real programmers use butterflies
|
|
|
|
|
|
If a frog's car breaks down, does it get toad away?
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Hopfully, it doesn't try to hitchike home to its pad, and jump in the 1st vehicle it encounters. The driver might be a psychopath and the frog might croak.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
