|
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?
|
|
|
|
|
Munchies_Matt wrote: What is your job, to turn out up to the last minute code or up to the last minute product?
For my client, we pretty much make sure we're using the latest 3rd party library (in this case DevExpress) and the latest development tools and database from Microsoft. The only exception is maintaining an application in VS2015 with an older version of DevExpress because some of my client's clients are, believe it or not, still using XP, but we're working on that.
Other places, I've recently experienced using VS2008 to write SSRS reports against a database that VS2008 / SSRS doesn't support (VS2008 only support SQL Server 2005 and below) so you can't use the query designer tool (hand code queries instead) and requires opening up VS2015 to commit the report in TFS, because again VS2008 doesn't support the version of TFS being used. Said company was until recently still building with C# 5 (or was it 4?) and .NET 4.5.
|
|
|
|
|
You havent answered the question.
Is a carpenters job to make furniture, or to use the latest saw, plane, and screwdriver?
|
|
|
|
|
Munchies_Matt wrote: Is a carpenters job to make furniture, or to use the latest saw, plane, and screwdriver?
To make furniture. But...when the hand-me-down tools are worn out, or there's a more efficient tool, or a specialized tool for just that particular requirement, then one should not try to "get away" with using "the wrong" tool.
[edit]And often, a new tool requires training. And new safety protocols! [/edit]
|
|
|
|
|
Marc Clifton wrote: worn out,
C++ 3 is worn out is it?
Marc Clifton wrote: specialized tool for just that particular requirement
How does a customer requirement dictate that C++7 should be used in preference to C++3?
|
|
|
|
|
You're not going to carve that table legs by hand with a rusty blade and charge customers 40 hours for each leg, are you? Hey it's made by hand and antique so the cost would be expensive. Most customers wouldn't pay for it.
|
|
|
|
|
|
This is also probably about the push for Python, a much simpler language. It's also likely the reason javascript is tolerated in places it should not be. I suspect they are looking at it as hardware is cheaper than maintaining efficient software. At the same time, I understand it. My code is stuffed with comments and directions aimed at directing anyone needing to maintain it.... but good luck, it's some sophisticated multi-threaded fault-tolerant code.
|
|
|
|
|
What would you do if you were told to do that?
Uh oh ... I'd start getting my resume polished up because it sounds like an expensive person is about to be replaced by a "more cost-effective" person once you make it possible for the company to make that swap.
|
|
|
|
|
I slept on this (not really) and this morning I came up with another likely motive for this.
Since the code is made so thoroughly easy to follow (and much larger do to inefficiency), we have two bonus' from the management point of view:
1) The impression, do to sheer bulk, that more work was done
2) More time for the Jr. Dev's can be sent out for coffee
See - there's a perfectly reasonable explanation for everything.
| 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 are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
I'm convinced that things like this can only happen to you 
This space for rent
|
|
|
|
|
1. It would be unprofessional to write anything but the most efficient code possible.
2. How would a junior programmer ever progress if not presented with more challenging code.
3. It would not be possible to determine exactly what each junior programmer was capable of until they were presented with something they could not cope with alone. So how would you know how much to dumb down.
4. If I were a senior programmer on this team, I would take this as my cue to look for another job.
5. If I were a junior programmer on this team, I would take this as my cue to look for another job.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
