|
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.
|
|
|
|
|
Munchies_Matt wrote: C# eh?
Yes, c++ was too simple - needed more of a challenge. 
Keep your friends close. Keep Kill your enemies closer.
The End
|
|
|
|
|
R. Giskard Reventlov wrote: Yes, c++ I was too simple - needed more too much of a challenge.
FIFY.
I take your lack of response as implicit agreement about the rest of my post.
|
|
|
|
|
Munchies_Matt wrote: I take your lack of response as implicit agreement about the rest of my post
If that makes you feel better...
Keep your friends close. Keep Kill your enemies closer.
The End
|
|
|
|
|
"Junior Devs" is often code for "the boss". And if the Boss wants to see the code in a certain way, that is the way you do it, I suppose.
Brent
|
|
|
|
|
you seem to have the know how !
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
convert it all to visual basic: boss should have no problems with a simpler programming language.
This internet thing is amazing! Letting people use it: worst idea ever!
|
|
|
|
|
Visual Basic is a simpler, easier to read language that can do anything that C# can do — both are converted to the same "executable" language. For highly regulated industries where audits of all kinds are a constant interruption, it has the advantage of being understandable to the auditors. I would rather code in Visual Basic and get something done than waste spend my time explaining C# code to accountants!
__________________
Lord, grant me the serenity to accept that there are some things I just can’t keep up with, the determination to keep up with the things I must keep up with, and the wisdom to find a good RSS feed from someone who keeps up with what I’d like to, but just don’t have the damn bandwidth to handle right now.
© 2009, Rex Hammock
|
|
|
|
|
Maybe a few walk-through session for the junior devs would be adequate.The so called junior devs need to basically maintain or add features, they are not expected to scrap the whole project just because LINQ or reflection is used. As such code is normally optimized / refactored , re-written and not dumbed down! (Maybe if it was the old days where you hardcode everything !!!). Besides , later the junior devs can become senior devs...
Besides there would be documentation on how to work say MVC or other frameworks in which the code would be organized.
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
abmv wrote: Maybe a few walk-through session for the junior devs would be adequate.
Yeah, unfortunately, management's view of training consists of watching Pluralsight videos rather than learning things directly from the senior devs on code that is actually relevant to the company and job.
|
|
|
|
|
Usually the management should be in agreement that in-house training ( or sessions) for developers should be conducted periodically by the senior devs or the software architect, how boring they may be , but it is in they interest of the company to do so.Say the senior dev is on vacation.This could be pro-actively arranged and attendance recorded.This could be done with each major release or milestone of the project.
Pluralsight videos or online tutorial are for people starting to code or learning and not even for junior devs.
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
modified 29-May-18 14:08pm.
|
|
|
|
|
My small team is highly vertically stacked. Our new management declared we would cross train each other. It is all great on paper, but the stress of learning a departed developer's undocumented code in every silo is palpable. In-house training sessions would be a joy in comparison.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
