Now, granted, I don't always write "up to snuff" code...
-
...but the garbage I've had to look into and fix, well, it's just amazing. 1. Lack of abstraction (makes testing a total PITA) 2. Lack of encapsulation (would be nice to be able to load up the configuration values without hitting a serer that I don't connect to in testing) 3. Absolutely convoluted code for getting something to run on a separate thread (even before
Task.Runthis was basically a 5 liner, not the 100+ lines of drivel I'm wading through.) 4. How many times do I need to xpath the config file to get the same value in the same loop??? 5. Let's instantiate variables and never use them! 6. Let's add debugging that inspects the .NET stack. And not disable it in a release build. 7. Let's load an XSLT transform from a file every time we need to transform something. 8. And maybe XSLT isn't the most efficient? 9. And let's put in comments about "not too pricey performance-wise" for stupid-arsed things and totally ignore the glaring inefficiencies elsewhere. 10. Let's usebool?as a 3 state variable instead of a readable enum. 11. And the list goes on. I am getting sorely disappointed in the code I've had to work with. I have yet to see something decently implemented in this job. It's pretty clear to me that if I were the Trump of the software engineering world, I would cull 90% of them and relegate them to captaining garbage scows. MarcV.A.P.O.R.ware - Visual Assisted Programming / Organizational Representation Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
...but the garbage I've had to look into and fix, well, it's just amazing. 1. Lack of abstraction (makes testing a total PITA) 2. Lack of encapsulation (would be nice to be able to load up the configuration values without hitting a serer that I don't connect to in testing) 3. Absolutely convoluted code for getting something to run on a separate thread (even before
Task.Runthis was basically a 5 liner, not the 100+ lines of drivel I'm wading through.) 4. How many times do I need to xpath the config file to get the same value in the same loop??? 5. Let's instantiate variables and never use them! 6. Let's add debugging that inspects the .NET stack. And not disable it in a release build. 7. Let's load an XSLT transform from a file every time we need to transform something. 8. And maybe XSLT isn't the most efficient? 9. And let's put in comments about "not too pricey performance-wise" for stupid-arsed things and totally ignore the glaring inefficiencies elsewhere. 10. Let's usebool?as a 3 state variable instead of a readable enum. 11. And the list goes on. I am getting sorely disappointed in the code I've had to work with. I have yet to see something decently implemented in this job. It's pretty clear to me that if I were the Trump of the software engineering world, I would cull 90% of them and relegate them to captaining garbage scows. MarcV.A.P.O.R.ware - Visual Assisted Programming / Organizational Representation Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
I agree. I hate that not all programmers are as smart as me. It's the worst. :mad: Why can't they all know exactly what I know? ;)
There are two kinds of people in the world: those who can extrapolate from incomplete data. There are only 10 types of people in the world, those who understand binary and those who don't.
-
I agree. I hate that not all programmers are as smart as me. It's the worst. :mad: Why can't they all know exactly what I know? ;)
There are two kinds of people in the world: those who can extrapolate from incomplete data. There are only 10 types of people in the world, those who understand binary and those who don't.
I don't want to know what you know. I want to know what Marc knows.
Wrong is evil and must be defeated. - Jeff Ello
-
...but the garbage I've had to look into and fix, well, it's just amazing. 1. Lack of abstraction (makes testing a total PITA) 2. Lack of encapsulation (would be nice to be able to load up the configuration values without hitting a serer that I don't connect to in testing) 3. Absolutely convoluted code for getting something to run on a separate thread (even before
Task.Runthis was basically a 5 liner, not the 100+ lines of drivel I'm wading through.) 4. How many times do I need to xpath the config file to get the same value in the same loop??? 5. Let's instantiate variables and never use them! 6. Let's add debugging that inspects the .NET stack. And not disable it in a release build. 7. Let's load an XSLT transform from a file every time we need to transform something. 8. And maybe XSLT isn't the most efficient? 9. And let's put in comments about "not too pricey performance-wise" for stupid-arsed things and totally ignore the glaring inefficiencies elsewhere. 10. Let's usebool?as a 3 state variable instead of a readable enum. 11. And the list goes on. I am getting sorely disappointed in the code I've had to work with. I have yet to see something decently implemented in this job. It's pretty clear to me that if I were the Trump of the software engineering world, I would cull 90% of them and relegate them to captaining garbage scows. MarcV.A.P.O.R.ware - Visual Assisted Programming / Organizational Representation Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
Marc Clifton wrote:
garbage scows.
Reminds me of the time the Klingons called the Enterprise a 'garbage scow'. Wasn't pretty. :doh:
Jack of all trades, master of none, though often times better than master of one.
-
I don't want to know what you know. I want to know what Marc knows.
Wrong is evil and must be defeated. - Jeff Ello
Jörgen Andersson wrote:
I don't want to know what you know.
Too late. ;P
Jörgen Andersson wrote:
I want to know what Marc knows.
Not enough time. :-D
There are two kinds of people in the world: those who can extrapolate from incomplete data. There are only 10 types of people in the world, those who understand binary and those who don't.
-
I don't want to know what you know. I want to know what Marc knows.
Wrong is evil and must be defeated. - Jeff Ello
-
...but the garbage I've had to look into and fix, well, it's just amazing. 1. Lack of abstraction (makes testing a total PITA) 2. Lack of encapsulation (would be nice to be able to load up the configuration values without hitting a serer that I don't connect to in testing) 3. Absolutely convoluted code for getting something to run on a separate thread (even before
Task.Runthis was basically a 5 liner, not the 100+ lines of drivel I'm wading through.) 4. How many times do I need to xpath the config file to get the same value in the same loop??? 5. Let's instantiate variables and never use them! 6. Let's add debugging that inspects the .NET stack. And not disable it in a release build. 7. Let's load an XSLT transform from a file every time we need to transform something. 8. And maybe XSLT isn't the most efficient? 9. And let's put in comments about "not too pricey performance-wise" for stupid-arsed things and totally ignore the glaring inefficiencies elsewhere. 10. Let's usebool?as a 3 state variable instead of a readable enum. 11. And the list goes on. I am getting sorely disappointed in the code I've had to work with. I have yet to see something decently implemented in this job. It's pretty clear to me that if I were the Trump of the software engineering world, I would cull 90% of them and relegate them to captaining garbage scows. MarcV.A.P.O.R.ware - Visual Assisted Programming / Organizational Representation Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
I have faith. All it needs is a couple of years, and you'll have fixed most of it. i.e. All it needs is someone who actually gives a damn.
I wanna be a eunuchs developer! Pass me a bread knife!
-
I don't want to know what you know. I want to know what Marc knows.
Wrong is evil and must be defeated. - Jeff Ello
Oh, how I wish I could upvote that twice!
I wanna be a eunuchs developer! Pass me a bread knife!
-
...but the garbage I've had to look into and fix, well, it's just amazing. 1. Lack of abstraction (makes testing a total PITA) 2. Lack of encapsulation (would be nice to be able to load up the configuration values without hitting a serer that I don't connect to in testing) 3. Absolutely convoluted code for getting something to run on a separate thread (even before
Task.Runthis was basically a 5 liner, not the 100+ lines of drivel I'm wading through.) 4. How many times do I need to xpath the config file to get the same value in the same loop??? 5. Let's instantiate variables and never use them! 6. Let's add debugging that inspects the .NET stack. And not disable it in a release build. 7. Let's load an XSLT transform from a file every time we need to transform something. 8. And maybe XSLT isn't the most efficient? 9. And let's put in comments about "not too pricey performance-wise" for stupid-arsed things and totally ignore the glaring inefficiencies elsewhere. 10. Let's usebool?as a 3 state variable instead of a readable enum. 11. And the list goes on. I am getting sorely disappointed in the code I've had to work with. I have yet to see something decently implemented in this job. It's pretty clear to me that if I were the Trump of the software engineering world, I would cull 90% of them and relegate them to captaining garbage scows. MarcV.A.P.O.R.ware - Visual Assisted Programming / Organizational Representation Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
I agree. I hate that not all programmers are as smart as me. It's the worst. :mad: Why can't they all know exactly what I know? ;)
There are two kinds of people in the world: those who can extrapolate from incomplete data. There are only 10 types of people in the world, those who understand binary and those who don't.
I think Marc is just looking for "Best Practices" or some method to the madness. But since I called it Best Practices, which really just means "hey, dev, use a consistent way of doing things that isn't just typing code but actual contains thought", people will freak out. :laugh:
-
Marc Clifton wrote:
garbage scows.
Reminds me of the time the Klingons called the Enterprise a 'garbage scow'. Wasn't pretty. :doh:
Jack of all trades, master of none, though often times better than master of one.
The Trouble with Tribbles! Laddie, don't you think you better rephrase that? Oh, sure. I didn't mean to say that the Enterprise should be hauling garbage. I meant to say that it should be hauled away AS GARBAGE! <Fists start to fly> :laugh:
The difficult we do right away... ...the impossible takes slightly longer.
-
...but the garbage I've had to look into and fix, well, it's just amazing. 1. Lack of abstraction (makes testing a total PITA) 2. Lack of encapsulation (would be nice to be able to load up the configuration values without hitting a serer that I don't connect to in testing) 3. Absolutely convoluted code for getting something to run on a separate thread (even before
Task.Runthis was basically a 5 liner, not the 100+ lines of drivel I'm wading through.) 4. How many times do I need to xpath the config file to get the same value in the same loop??? 5. Let's instantiate variables and never use them! 6. Let's add debugging that inspects the .NET stack. And not disable it in a release build. 7. Let's load an XSLT transform from a file every time we need to transform something. 8. And maybe XSLT isn't the most efficient? 9. And let's put in comments about "not too pricey performance-wise" for stupid-arsed things and totally ignore the glaring inefficiencies elsewhere. 10. Let's usebool?as a 3 state variable instead of a readable enum. 11. And the list goes on. I am getting sorely disappointed in the code I've had to work with. I have yet to see something decently implemented in this job. It's pretty clear to me that if I were the Trump of the software engineering world, I would cull 90% of them and relegate them to captaining garbage scows. MarcV.A.P.O.R.ware - Visual Assisted Programming / Organizational Representation Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
Marc Clifton wrote:
Let's use
bool?as a 3 state variable instead of a readable enum.That is exactly what Microsoft Developers said when they implemented the Window.DialogResult Property (System.Windows)[^]
-
...but the garbage I've had to look into and fix, well, it's just amazing. 1. Lack of abstraction (makes testing a total PITA) 2. Lack of encapsulation (would be nice to be able to load up the configuration values without hitting a serer that I don't connect to in testing) 3. Absolutely convoluted code for getting something to run on a separate thread (even before
Task.Runthis was basically a 5 liner, not the 100+ lines of drivel I'm wading through.) 4. How many times do I need to xpath the config file to get the same value in the same loop??? 5. Let's instantiate variables and never use them! 6. Let's add debugging that inspects the .NET stack. And not disable it in a release build. 7. Let's load an XSLT transform from a file every time we need to transform something. 8. And maybe XSLT isn't the most efficient? 9. And let's put in comments about "not too pricey performance-wise" for stupid-arsed things and totally ignore the glaring inefficiencies elsewhere. 10. Let's usebool?as a 3 state variable instead of a readable enum. 11. And the list goes on. I am getting sorely disappointed in the code I've had to work with. I have yet to see something decently implemented in this job. It's pretty clear to me that if I were the Trump of the software engineering world, I would cull 90% of them and relegate them to captaining garbage scows. MarcV.A.P.O.R.ware - Visual Assisted Programming / Organizational Representation Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
Marc Clifton wrote:
Let's use
bool?as a 3 state variable instead of a readable enum.You have to admit, that's almost ingenious before it was mixed in with round of WTF by not making it readable. I've actually used a triple state boolean before... with yes, no, and maybe for the valid values.
Jeremy Falcon
-
...but the garbage I've had to look into and fix, well, it's just amazing. 1. Lack of abstraction (makes testing a total PITA) 2. Lack of encapsulation (would be nice to be able to load up the configuration values without hitting a serer that I don't connect to in testing) 3. Absolutely convoluted code for getting something to run on a separate thread (even before
Task.Runthis was basically a 5 liner, not the 100+ lines of drivel I'm wading through.) 4. How many times do I need to xpath the config file to get the same value in the same loop??? 5. Let's instantiate variables and never use them! 6. Let's add debugging that inspects the .NET stack. And not disable it in a release build. 7. Let's load an XSLT transform from a file every time we need to transform something. 8. And maybe XSLT isn't the most efficient? 9. And let's put in comments about "not too pricey performance-wise" for stupid-arsed things and totally ignore the glaring inefficiencies elsewhere. 10. Let's usebool?as a 3 state variable instead of a readable enum. 11. And the list goes on. I am getting sorely disappointed in the code I've had to work with. I have yet to see something decently implemented in this job. It's pretty clear to me that if I were the Trump of the software engineering world, I would cull 90% of them and relegate them to captaining garbage scows. MarcV.A.P.O.R.ware - Visual Assisted Programming / Organizational Representation Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
...but the garbage I've had to look into and fix, well, it's just amazing. 1. Lack of abstraction (makes testing a total PITA) 2. Lack of encapsulation (would be nice to be able to load up the configuration values without hitting a serer that I don't connect to in testing) 3. Absolutely convoluted code for getting something to run on a separate thread (even before
Task.Runthis was basically a 5 liner, not the 100+ lines of drivel I'm wading through.) 4. How many times do I need to xpath the config file to get the same value in the same loop??? 5. Let's instantiate variables and never use them! 6. Let's add debugging that inspects the .NET stack. And not disable it in a release build. 7. Let's load an XSLT transform from a file every time we need to transform something. 8. And maybe XSLT isn't the most efficient? 9. And let's put in comments about "not too pricey performance-wise" for stupid-arsed things and totally ignore the glaring inefficiencies elsewhere. 10. Let's usebool?as a 3 state variable instead of a readable enum. 11. And the list goes on. I am getting sorely disappointed in the code I've had to work with. I have yet to see something decently implemented in this job. It's pretty clear to me that if I were the Trump of the software engineering world, I would cull 90% of them and relegate them to captaining garbage scows. MarcV.A.P.O.R.ware - Visual Assisted Programming / Organizational Representation Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
On my personal scale of unmaintainable code that's about 15 of 100. The real grandmasters use such things as mere decoration. Their centerpiece is absolutely uncorrectable. make one little change and everything falls apart like a row of dominos. What they did? Nothing special. They put a part of the application's logic into the data layer as stored procedures. SQL is great to see what's being done, but you get absolutely no clue to what this is supposed to accomplish. Dozens of SPs with no less than 500 lines already make the whole thing unreadable, but that still does not make it uncorrectable. The final blow comes from a first unexpected direction. On every table are at list 5 - 10 triggers which do really obscure things under even more obscure circumstances and modify things in other tables, which fires even more triggers. To keep the whole trigger avalanche under control, there are columns in the tables to hold status codes instead of data. Let's forget database design for a second and just try to figure out what status 1, 2, 3, -1 and -112 could mean. It would have been to easy if any documentation had existed at all and to add insult to injury, the mastermind behind that thing would deny any knowledge, but take any 'unjustified' criticism against his life's work personally. Obviously we were all too dumb to see the true ingenuity behind it all. And now stop complaining. :-)
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns. -
I agree. I hate that not all programmers are as smart as me. It's the worst. :mad: Why can't they all know exactly what I know? ;)
There are two kinds of people in the world: those who can extrapolate from incomplete data. There are only 10 types of people in the world, those who understand binary and those who don't.
There is a whole lot between knowing what Marc knows and not knowing a damn thing about programming. Unfortunately, it seems people who know nothing about programming still end up programming somehow :~ How would you react if someone built your house, you pay good money, and your front door could always be opened from the outside (even though it seems to have a lock)? You'd be furious, sue your contractor and find a new door. You'd probably not trust the rest of the house anymore either (check your walls, foundation, windows, etc.). I think that's roughly the equivalent of SQL injection. Yet only one is common practice :)
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
-
I agree. I hate that not all programmers are as smart as me. It's the worst. :mad: Why can't they all know exactly what I know? ;)
There are two kinds of people in the world: those who can extrapolate from incomplete data. There are only 10 types of people in the world, those who understand binary and those who don't.
RyanDev wrote:
I hate that not all programmers are as smart as me.
Should be : > I hate that not all programmers are as smart as I think I am. :-D
Nish Nishant Consultant Software Architect Ganymede Software Solutions LLC www.ganymedesoftwaresolutions.com
-
...but the garbage I've had to look into and fix, well, it's just amazing. 1. Lack of abstraction (makes testing a total PITA) 2. Lack of encapsulation (would be nice to be able to load up the configuration values without hitting a serer that I don't connect to in testing) 3. Absolutely convoluted code for getting something to run on a separate thread (even before
Task.Runthis was basically a 5 liner, not the 100+ lines of drivel I'm wading through.) 4. How many times do I need to xpath the config file to get the same value in the same loop??? 5. Let's instantiate variables and never use them! 6. Let's add debugging that inspects the .NET stack. And not disable it in a release build. 7. Let's load an XSLT transform from a file every time we need to transform something. 8. And maybe XSLT isn't the most efficient? 9. And let's put in comments about "not too pricey performance-wise" for stupid-arsed things and totally ignore the glaring inefficiencies elsewhere. 10. Let's usebool?as a 3 state variable instead of a readable enum. 11. And the list goes on. I am getting sorely disappointed in the code I've had to work with. I have yet to see something decently implemented in this job. It's pretty clear to me that if I were the Trump of the software engineering world, I would cull 90% of them and relegate them to captaining garbage scows. MarcV.A.P.O.R.ware - Visual Assisted Programming / Organizational Representation Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
Marc Clifton wrote:
10. Let's use
bool?as a 3 state variable instead of a readable enum.I think that's called "job security". /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
Marc Clifton wrote:
Let's use
bool?as a 3 state variable instead of a readable enum.You have to admit, that's almost ingenious before it was mixed in with round of WTF by not making it readable. I've actually used a triple state boolean before... with yes, no, and maybe for the valid values.
Jeremy Falcon
Code it as a single bit for extra points!
Sudden Sun Death Syndrome (SSDS) is a very real concern which we should be raising awareness of. 156 billion suns die every year before they're just 1 billion years old. While the military are doing their part, it simply isn't enough to make the amount of nukes needed to save those poor stars. - TWI2T3D (Reddit)
-
...but the garbage I've had to look into and fix, well, it's just amazing. 1. Lack of abstraction (makes testing a total PITA) 2. Lack of encapsulation (would be nice to be able to load up the configuration values without hitting a serer that I don't connect to in testing) 3. Absolutely convoluted code for getting something to run on a separate thread (even before
Task.Runthis was basically a 5 liner, not the 100+ lines of drivel I'm wading through.) 4. How many times do I need to xpath the config file to get the same value in the same loop??? 5. Let's instantiate variables and never use them! 6. Let's add debugging that inspects the .NET stack. And not disable it in a release build. 7. Let's load an XSLT transform from a file every time we need to transform something. 8. And maybe XSLT isn't the most efficient? 9. And let's put in comments about "not too pricey performance-wise" for stupid-arsed things and totally ignore the glaring inefficiencies elsewhere. 10. Let's usebool?as a 3 state variable instead of a readable enum. 11. And the list goes on. I am getting sorely disappointed in the code I've had to work with. I have yet to see something decently implemented in this job. It's pretty clear to me that if I were the Trump of the software engineering world, I would cull 90% of them and relegate them to captaining garbage scows. MarcV.A.P.O.R.ware - Visual Assisted Programming / Organizational Representation Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
Haven't met a developer yet that doesn't bitch about how lousy the code is that he has to maintain that was written by someone else!
