The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
My boss gives me grief for daring to read and understand CodeProject articles to improve my skills on company time!
The ironic thing is that I limit my learning to material that I could apply at work, where I a limited to Visual Studio 2010 and SQL Server 2012! My desktop is 2 gigs of memory with 72 gigs of disk space. He is the kind of boss who does not trust his underlings to work while not in his sight
At home, I currently use Visual Studio 2017 (community edition) and I just installed SQL Server 2017 (developer edition) on a desktop with 8 gigs of memory and a terabyte of disk space.
It's an upside down world really.
I can't imagine this happening in any other field.
Heck, most stuff wouldn't work at all if kids who just got out of school had to be able to understand it.
Guy at NASA: Guys, guys, we've been doing things all wrong!
Other guy: What do you mean?
First guy: I just spoke to an intern and he doesn't really understand how rockets work...
Third guy: So what do you suggest we do?
First guy: Well...[^]
I can't imagine this happening in any other field.
It's called "deskilling" and it's been happening for a long time: things are designed so idiots can maintain / fix them. Think of cars - how many mechanics can swap a bearing instead of a whole assembly? Or strip a brake caliper and replace the seals, rather than fit a new caliper? How many electronic repairs are done with a soldering iron, instead of a screwdriver and a new PCB?
And it's been apparent that many of the new "developers" we get in QA believe in the "bolt on component" approach to coding ...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
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
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.
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?
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.
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).
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.
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
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.
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!