|
Ever been asked to do this? I seem to be encountering this more and more -- the last company I worked for, I left because that was stated explicitly by the CTO as the new policy.
What would you do if you were told to do that? And by dumbing down, I mean doing things like avoiding LINQ (except for basic things), metadata, reflection, extension methods, and any of the C# 7.0 language features.
It seems that long gone are the days when companies actually invest in keeping developer skills up to par with the technologies the company uses. Or even more amusingly (not) keeping those technologies up to date.
|
|
|
|
|
Marc Clifton wrote: Ever been asked to do this?
Not me, personally, but I have heard of this same thing from other colleagues. No bueno.
|
|
|
|
|
|
Is it more a question of using the latest language tricks versus making the code more readable ?
for example
I'd rather be phishing!
|
|
|
|
|
Maximilien wrote: Is it more a question of using the latest language tricks versus making the code more readable ?
I agree, though I have no problem reading those examples. But I didn't know (and nothing comes up in google) that a ^ is what you use to index from the end of the array. If that's actually the case, I wish they'd just done what Ruby and Python do -- use negative numbers.
But really, I'm not talking "tricky" code -- I'm talking about simple things like knowing how to use reflection, or how extension methods work and guidelines on when to use them, or basic things like threading -- async/await, Task, TPL, even Thread.
|
|
|
|
|
Marc Clifton wrote: But I didn't know (and nothing comes up in google) that a ^ is what you use to index from the end of the array.
The future of C# : Build 2018 - YouTube[^] - coverage of "ranges" starts at 55 minutes.
Apparently, using negative numbers was ruled out in a language design meeting:
If we use negative numbers, we could make it work for ranges in cases like a[1..-1]. However, we would not be able to make a[-1] work since it already has a meaning in the language. In fact, it would be a pretty a scary breaking change to try and introduce that since it would no longer throw a runtime exception and would instead start returning unexpected values.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
That is nuts. How does that help the business? Failing to challenge and educate engineers leads to mediocre and/or poor code, at best.
Keep your friends close. Keep Kill your enemies closer.
The End
|
|
|
|
|
Conversely, how does having first-class code help the business, compared to having "mediocre" code? If the end result works, and doesn't require massively more expensive hardware to run at an appropriate speed, then why not? "Simple" code helps the business by reducing staff costs, increasing the pool of potential recruits, reducing "up to speed" time for new joiners ... all these things are helping the business far more than using Linq where it's not necessary. Each new language feature or concept is another thing to learn and get expert in - or not. Keeping things "simple" with a smaller subset arguably allows all staff members to become "expert" in the entire gamut of techniques, and therefore able to pick up and work on any bit of the code, regardless of their seniority / experience.
Maybe playing devil's advocate a bit here, but if you look at things from management's point of view, there's something to be said for it. And if it means experienced (expensive) developers leaving in frustration - to be replaced by cheaper juniors - that's yet another win for the bottom line.
|
|
|
|
|
Good point, well made. 
My response would be that first class code should still be simple and robust.
Keep your friends close. Keep Kill your enemies closer.
The End
|
|
|
|
|
The examples given of technologies to avoid are actually in the language to reduce code complexity and do a fantastic job of that. This won't make the code more readable for junior devs it will model the bad habits of the previous generation of programmers for the new generation. More likely this is a policy put in place by a manager who wants to micromanage developers and does not want to keep up with the new language features.
|
|
|
|
|
As Iv'e said for years, this so called "Skills Shortage" in the industry, is as a result of businesses own practices, but they never learn, they just keep doing the same things over and over again.
|
|
|
|
|
Unfortunately, the bottom line drives that. Businesses are not likely to change until they see ROI.
|
|
|
|
|
Dear oh god. How does that help business?
What is a software engineers job, to turn out the latest code or the latest product?
Just what do you think the customer is actually buying ffs?
|
|
|
|
|
Munchies_Matt wrote: What is a software engineers job, to turn out the latest code or the latest product?
No, to turn out the best, most efficient, mist robust code. Otherwise, we might as well hire a bunch of script-kiddies and cut them loose on our latest trading platform.
Keep your friends close. Keep Kill your enemies closer.
The End
|
|
|
|
|
Why is code efficiency important in a product?
For that matter robustness. What is robust code (as opposed to a robust product)?
|
|
|
|
|
Munchies_Matt wrote: Why is code efficiency important in a product?
Why would you want inefficient code in your product?
Munchies_Matt wrote: What is robust code (as opposed to a robust product)?
Seriously? You set out to write code that is not robust? Why would you do that?
Keep your friends close. Keep Kill your enemies closer.
The End
|
|
|
|
|
Why does the latest C++ 7 features make for a better product?
R. Giskard Reventlov wrote: You set out to write code that is not robust?
I asked you to define robust, in reference to a robust product. Do so before making assumptions.
|
|
|
|
|
Munchies_Matt wrote: Why does the latest C++ 7 features make for a better product?
I never said that it did.
Munchies_Matt wrote: I asked you to define robust, in reference to a robust product. Do so before making assumptions.
There was no assumption - just an inference based on your patronizing.
The point here is to encourage engineers to write the best, most robust possible code. That does not necessarily mean using the very latest but most engineers will make it their business to both know about the latest developments and how they might fit it into their programming.
You are welcome not to do that or to scoff at the idea of writing code that may cause junior devs to actually have to think and learn but they will not improve unless they challenge themselves. Writing dumbed-down code is dumb.
Keep your friends close. Keep Kill your enemies closer.
The End
|
|
|
|
|
R. Giskard Reventlov wrote: I never said that it did.
But that is what this thread is about.
R. Giskard Reventlov wrote: Writing dumbed-down code is dumb
Try working in the Kernel....
I write the simplest code I can. Laid out in the clearest fashion possible.
Writing dumbed down code is clever. KISS, every heard of that?
Throwing the latest 'must have' in the code, and making it unmaintainable by anyone without knowledge of that 'must have' is dumb. And it isnt just junior devs who fall foul of this stupidity, it is ANY dev who hasnt used that particular 'must have'.
Like so many devs you evidently fall into the trap of believing the code is the product. It isnt. It is a representation of machine code. That is all. All languages produce machine code.
Of course to remind you that at the end of the day VB achieves just the same as your precious <insert your="" cherished="" tool="" here=""> wont be welcome, but that's a fact.
|
|
|
|
|
Munchies_Matt wrote: Like so many devs you evidently fall into the trap of believing the code is the product
I've been at this far too long to believe that. But I do believe I have a duty to write the best possible code to get the job done. If the latest incarnation visual widgets 35 help me do that, then I'll use it.
Munchies_Matt wrote: Of course to remind you that at the end of the day VB achieves just the same as your precious <insert your cherished tool here> wont be welcome, but that's a fact.
The vast majority of our current code base is VB.Net and whilst what you say might be true, working with it feels like using a screwdriver as a hammer.
Keep your friends close. Keep Kill your enemies closer.
The End
|
|
|
|
|
I think we agree, in principle, so do you also agree that using weird and esoteric features of a language is stupid?
For example, and I forget the name, the ## stuff in C++.
|
|
|
|
|
Munchies_Matt wrote: do you also agree that using weird and esoteric features of a language is stupid?
Unless it is the best way to accomplish a task. But probably not unless I can see a benefit.
Keep your friends close. Keep Kill your enemies closer.
The End
|
|
|
|
|
So, does C++7 allow you to implement a requirement any better than C++3?
|
|
|
|
|
I have not used c++ in over 15 years!
Keep your friends close. Keep Kill your enemies closer.
The End
|
|
|
|
|
C# eh? 
(Sorry, couldnt help it. Snigger snigger...)
Because a change to the language is to make life *easier* for the programmer.
So smart pointers, well, thats because they are too lazy to put deletes in the exception handlers.
Garbage collection? Thats because they are too lazy to put deletes anywhere.
Not that these are bad features, but they dont improve the product. (In fact some make it worse, like garbage collection. Ever wondered why code these days is so big, and uses so much memory?)
The manager in the OP was absolutely right. If you dont control your nerdy devs they will f*** the product up with complexity and shite features, ,just because they like playing with new toys. (This is why so many devs are NOT engineers).
And that explains why 'oldversion.com' exists, because devs f***ed it up.
The manager is right to put a tight rein on them.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
