|
I can understand being asked (in a code review) to not be overly cryptic or to ensure any non-obvious code is well commented, but your examples of being asked to not use features like LINQ, metadata, reflection and extension methods (good grief!) seem to imply the company's dev team is grossly under par when it comes to basic software engineering skills. Perhaps it's time to lose this gig and move on?
/ravi
|
|
|
|
|
Pretty much nail on head.
Juniors should be learning, not code automatons. Ideally if you want that it should be automated via tool or scripts.
|
|
|
|
|
How are juniors expected to learn when nothing will challenge them?
|
|
|
|
|
How does a junior learning something help the company's bottom line? If a junior programmer can understand and maintain every part of the company's codebase, there is no requirement for learning and no requirement for senior (expensive) programmers.
Just sayin' ...
|
|
|
|
|
Touché 
However, that changes the story from career development to office politics, and there's few things other than leaving the company which would remedy that (for the developer asked to dumb down the code).
|
|
|
|
|
DerekTP123 wrote: If a junior programmer can understand and maintain every part of the company's codebase, there is no requirement for learning and no requirement for senior (expensive) programmers.
Because eventually, no senior dev will want to work for the company, leaving junior devs to maintain a code base that is metastasizing into an umaintainable, bug ridden slimy blob. At which point management contracts an outside job shop to come in and rewrite the software because a) it's broken and b) it can't support the demands of the users.
|
|
|
|
|
...and then management changes as the management cannot build the product, and new management begins the process all over again. 
|
|
|
|
|
Tinus Smit wrote: How are juniors expected to learn when nothing will challenge them?
How are juniors expected to learn when they have no motivation to learn? Sad but true.
|
|
|
|
|
I understand both sides (partially):
- dev side: yes it can make sense to use the new and shiny constructs/features of a programming language. No problem with that. But did you make an effort to add comments to clarify the magic shorthand that follows? Or are you the kind of "I only write readable code" developer? I had to modify a program and after the initial "who wrote this crap", I realized it was an old program I wrote. So "dumbing down" should perhaps be perceived as KIS: keep it simple.
- management side: devs are an unreliable bunch of nerds so if they leave, we can't afford to stand still for months just because some star-programmer found it beneath his dignity to add comments and only wanted to use exotic libraries. F them and send it to India (so they can mess it up). Now I'm off to my micromanagement course
|
|
|
|
|
pivertt wrote: So "dumbing down" should perhaps be perceived as KIS: keep it simple.
Agreed -- simple IS best, but how you achieve simple can leveraged with knowing the framework and the language.
pivertt wrote: we can't afford to stand still for months just because some star-programmer found it beneath his dignity to add comments and only wanted to use exotic libraries.
Heh. My concept of a star programmer is one that writes maintainable code - sure, it might require a junior dev to have to hit the books to learn something about the framework or library, but the code should not be "exotic" - as in incomprehensible and cryptic, even to another senior dev!
|
|
|
|
|
If you are told not to make use of good LINQ or extension methods, I do not think the resulting code would be any easier to understand. If in these cases the code is well commented, it is, in fact, compact and easier to understand. OTOH I agree with reflection (people tend to steer clear from it stating it is too powerful for its own good  ) since not many people know it.
Asking developers to "dumbed down" code shows the lack of trust(maybe they have their reasons) in the new recruits. I do not think the code is the problem here.
I would suggest educating the newer members of your team at least the "features" that are commonly used in the project.
I am not the one who knocks. I never knock.
In fact, I hate knocking.
|
|
|
|
|
GKP1992 wrote: I would suggest educating the newer members of your team at least the "features" that are commonly used in the project.
Two things I've been noticing. There also seems to be a lack of motivation to learn from the senior people, and management is clueless so any "motivation" from that direction doesn't happen either. It seems that the young people nowadays have a different focus. The days of the "computer club" where people got together to learn things are long gone. Maybe in places like Google or Microsoft that kind of culture still exists, but I don't often see it in the "meat and potatoes" companies.
|
|
|
|
|
Marc Clifton wrote: The days of the "computer club" where people got together to learn things are long gone.
Ahh the truth. It's usually unpleasant.
But that's what CP is for, isn't it? 
I am not the one who knocks. I never knock.
In fact, I hate knocking.
|
|
|
|
|
Even those of us knowing reflection normally avoid it if the performance hit is unacceptable.
|
|
|
|
|
The times I've found a reason to use reflection have mainly been when using attributes. You can statically load the information into the type itself so you only incur the expense a single time for each class. Works for generics too (cost will be once per unique T). It's really not as bad as people think if you aren't reflecting constantly.
|
|
|
|
|
Excellent. The times I was using reflection was in conjunction with OpenXML, and it was once per run, so little impact. My comment on performance degradation comes from StackOverflow, not personal use.
|
|
|
|
|
Economy is integral part of our jobs. At university I was taught that an engineer is a person who can do for $500 what every damn fool can do for $1.000. Best way to include junior engineers seems to be structuring software to allow pluggable codelets. Usually in places where there is a significant quantity of simple constructs to be programmed, such as data entry screens. We go as far as forcing engineers into simplistic conventions by creating frameworks that do not work unless convention is followed. But I've never heard of a case where one would simplify entire software. There are places that should not be touched by junior software engineers.
|
|
|
|
|
Tomaž Štih wrote: Best way to include junior engineers seems to be structuring software to allow pluggable codelets.
I also experience a lack of consideration for a re-use library. So I see, for example, validation of XML data done a different dozen ways, error handling the same, conversions, formatting, etc. A library is supposed to help with consistency, but again, a junior dev rarely thinks in terms of re-use or consistency. And when the entire team is made up of junior devs, well then.
|
|
|
|
|
That is a valid perspective, and further one could say that junior developers need opportunities to learn and not have their hand held too much; and there must be an expectation that developers meet minimum requirements of understanding many aspects of software development. Code reviews are an effective way to share knowledge and help develop junior devs.
So, for balance, let's look at the other side. Companies invest in and employ devs to develop software assets. These assets are important to the companies value/revenue/future etc. So naturally, maintainability is a hugely important attribute of company assets. And there are many aspects to maintainability of course.
I would say that if someone is asking you to "dumb down" code for easier maintenance, perhaps that is just a diplomatic way of saying that your code is not readable/maintainable. There is an old school rule that when writing code, it should be readable by other people, including yourself at some time in the future.
Since I am no expert in LINQ, for example, I will often write code the simple / old way, and when Re-Sharper suggests a conversion to LINQ, I will have Re-Sharper do the conversion, and then decide if it is easier or harder to understand at a glance, and often I will undo the conversion.
Complicated or unreadable code is not "better" code. (obviously there is a minimum complexity required for every different problem/algorithm).
Well, anyway, I would tell your bosses that any policy that forbids using C# 7 syntax, for example, is a bad policy since every new version of c# provides syntax that is better and/or more maintainable.
Cheers,
Anthony
|
|
|
|
|
soulesurfer wrote: So, for balance, let's look at the other side.
You definitely have a point, and I will definitely veer toward maintainability. However, it really isn't about code (even though my subject line says "code") but about a lack of training, much with regards to what has been around in the .NET framework for years. Even common practices like DRY, writing small functions, decoupling, etc., those are things, as you say, a junior dev learns through code reviews (not just their own code but the code the senior devs produce) but such code reviews are completely lacking. 
|
|
|
|
|
It has been 20 years since I worked at a company that allowed code reviews. $$$
|
|
|
|
|
I had that once, my reply.
"So you want me to do your job of balancing the budget so you can save money by not having to train them, and thus increase profit? Do I get a pay rise and a position in your office if I'm working the same job as you?"
The discussion was very quickly terminated, and the request abandoned.
I left voluntarily 2 months later
|
|
|
|
|
Peter Shaw wrote: Do I get a pay rise and a position in your office if I'm working the same job as you?"
Good one!
|
|
|
|
|
I'm not known for my Tactfulness, that's for sure
Blunt as a brick, and straight faced with it too.
|
|
|
|
|
What is your job, to turn out up to the last minute code or up to the last minute product?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
