|
I'm not sure if it's exactly the same.
I know nothing about cars, especially not in English, so I can't really follow you analogy 
In software I'm also about "bolt on component" where possible.
Things should be easy to use even though it was hard to write.
In a car you'll need a combustion engine, but in software it's possible to go for a Flinstones approach (and somehow often done that way) because an engine is too difficult.
However, when you have the engine some maintenance tasks are pretty easy, like changing oil or coolant.
What my boss asked, and I'm guessing what Marc is talking about, we need the complex combustion engine, but it has to be maintained and understood at a deep level by the people who usually change a bolt.
Since that's pretty much impossible you'll end up with a Flinstones car after all 
|
|
|
|
|
A line from "Real programmers don't use Pascal" - it was difficult to write, it should be difficult to understand 
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
I thought the idea was to use only the newest features, because that's all the newbs know.
|
|
|
|
|
I've been managing various dev teams (java, .net) for around 15 years now.
I would have never asked my dev's to dumb code down but I would suggest that there have been occasions where devs would use a new tech or dev method not because it was needed or warranted but because it was an opportunity to learn something new.
The cost of that is a general slowdown in the output of your team as the overhead of working out how the new stuff works start to impact timelines and commitments.
If the new way genuinely is better then I think its an easy discussion because the cost/benefit argument should win. I encourage my devs to focus on that and we haven't really had this issue.
|
|
|
|
|
You sound like the type of boss I would like to work for!
If your company is in central Texas and you are hiring, please tell me! I would be delighted to apply!
__________________
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
|
|
|
|
|
Well, you sound like the type of employee a boss wants heheheh
If you plan on moving to Melbourne, Australia... let me know
|
|
|
|
|
Yeah....
I usually ignore those comment, while saying I will. Because this is what happens, say you use a very useful new syntax such as await SomeTask() .
- it legit make the code more readable, less bug prone, more maintainable
- some people are freaking out because they didn't keep up, and can't parse that syntax, hence find it "overtly clever"
- time pass, they get over their initial shock, everybody does it by the time you force yourself to comply
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
