|
I got that twenty years ago... .net and C#. Done.
|
|
|
|
|
|
The super chicken problem.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
I'd like to see software development best practice being informed by science instead of the opinions of influential groups and individuals.
|
|
|
|
|
Dev life MOSTLY depends from IDE. Your items can be useful in a narrow applications, but in general you sit in IDE. Me personally use Visual Studio and even after 20 years of "improvements" it still suxx in many features. Intellisense still on the level of 80es. Code organization still primitive. Navigation suxx. A LOT of problems, but M$ doesn't care - they play with ugly Git and teams features. Teams? On Personal Computer? They definitely loose main point of personal tool.
|
|
|
|
|
Thornik wrote: Dev life MOSTLY depends from IDE.
At the lower levels, yes. By the time you are expected to write specifications, high- and low-level designs, perform mentoring, etc., your major tools are Word and PowerPoint.
Thornik wrote: Me personally use Visual Studio and even after 20 years of "improvements" it still suxx in many features.
Agreed. But it's still better than much of the competition.
Thornik wrote: they play with ugly Git and teams features. Teams? On Personal Computer? They definitely loose main point of personal tool.
Most professional programmers work in teams, and need to integrate their code with others'. Having an IDE that helps with this is a plus. That is not to say that they couldn't do it better...
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Ask me again in a few weeks! Whatever is broken in the technical ecosystem I’m using at the time will come to mind first.
Right now, I’m doing a lot of JavaScript. The language itself is bad enough, but when you look at the big picture, it’s a disaster.
- Issues in the language itself are well-known. You may not agree with all the criticisms of the language, but you have to agree with some.
- The dev environment is something out of the movie Brazil: a curious mix of technologies and practices that seem intended mostly to annoy everyone involved and can only have evolved because no sane person would ever design it this way.
- The lack of a standard library leads to NPM and frameworks that change every six minutes and it’s a cesspool.
I’d go on, but focusing on this is starting my day off the wrong way!
|
|
|
|
|
oh totally the part where we have only loser coders (or pretending/being forced to be losers) nowadays, that only can use those horrible non languages that are object oriented based... with focus only on stupid capitalism, and totally lack of quality or compatibility.... instead of the beauty and freedom that regular C is... with the simplicity of a simple build system...
ofcourse one IDE that would allow to compile as you type, causing modules to become obsolete, and that can understand what you do with some minor form of AI, so that it can suggest the next piece of code for you to code even on the phone (if it was possible to code for phones without all that java/OOP garbage) touch would be nice... i wanted to do that if i had a team... and that is very lightweight (totally not the MSVC monstruosity) ... but this IDE part is optional, but as a wish that would be very nice....
|
|
|
|
|
|
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
- Renewal of my 007ish license to enforce the above
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Maybe it's Users and Coders understanding each other a tad more (and managers getting out of the way)  .
|
|
|
|
|
I'm afraid that ship has sailed.
The penultimate example:
Screen: "Press ANY Key to continue"
User: "I can't find the ANY key"
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Maybe there isn't an "ANY" key among the many keys they have on their keyboard
Maybe they tried Ctrl+Alt+Del. Genius has it's limits.
|
|
|
|
|
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.
Charlie Gilley
<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
|
|
|
|
|
Kent Sharkey: 'Fixed' as in 'plumber', or 'fixed' as in 'veterinarian'?
Clueless meddling, and fixed as in encased in cement.
@kentacmebinarycom
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?
--Zachris Topelius
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.
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
