|
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.
|
|
|
|
|
5. If I were a junior programmer on this team, I would take this as my cue to look for another job.
If I were a junior programmer on this team and I refuse to learn that more efficient paradigm, I should change career. 
|
|
|
|
|
Member 12364788 wrote: It would be unprofessional to write anything but the most efficient code possible.
Really?? Agreed, "efficiency" is certainly in the mix of attributes that a professional coder should aim for; but as the overriding consideration (implied by "most efficient possible") is surely not right. I would certainly be reluctant to deliver the "most efficient" code if it meant that it was virtually undecipherable by anyone but a guru-level developer; or was so rigid that a minor change to requirements would result in a total re-write. And coding purely for efficiency can certainly sometimes result in these types of solution.
There are of course (at least) two sorts of "code efficiency": execution efficiency (minimising elapsed time and/or other resources during the usual execution route) and source efficiency (minimising the lines of code / method calls etc).
These days hardware resources are typically very cheap compared to developer / maintenance costs so businesses will often opt to develop a simple, maintainable, and/or quickly-developed solution and offset any inefficiency by buying a few extra MIpS or MBytes.
As a (freelance) professional, part of my (unspoken) remit is to fully understand the client's requirement - do they need something mega-efficient (maybe to fit on an embedded chip), very quick to develop, something very flexible to maintain in the future, something that could easily be easily ported to another system (so maybe using a common subset of a tool or language), etc..etc..; and then to develop to meet those requirements.
In practical terms, "efficiency" can sometimes mean not adding a dependency to yet another external assembly (or to a specific newer version of an assembly). When I create a new VS solution, the LINQ modules are usually included by default. If a solution requires LINQ then I'll use it, but I'll try and avoid just a single usage of LINQ as that adds not only a dependency on an extra assembly, but a dependency that any future maintainer knows LINQ. (LINQ used simply as an example here).
Also, "more challenging" may mean a more sophisticated technique or concept; but sometimes it just means a new or different syntax. It may "challenge" the developer to learn that additional syntax, without actually "improving" the developer's skills. Instead of learning "better" ways, they just learn "more" ways to do something. It adds to the buzzwords on their CV but just gives them brain-bloat and I've seen junior devs "freeze", like a rabbit in car headlights, because they can't decide which technique they should use out of half-dozen ways they can think of to do something. Maybe for "dumbing down" code, we should instead think of "standardizing" techniques and avoiding conceptual aliases. (Really, what can an extension method do that a static function can't, and without risking future name clashes and ambiguities!)
|
|
|
|
|
Congratulate yourself, you have outgrown company you are working now 
As someone who just recently started to discover beauty and efficiency of simplicity, I think that writting good simple (some may call it dumb) code is harder than putting together some popular/advanced patterns and new language features to hide code smells and call it a modern code base. Good dumb (readable and maintainable) code is not a task for junior dev. Looks like company doesn't understadnd what they are asking.
|
|
|
|
|
I would say if the code isn't easy to read, then all the devs should read clean code and working with legacy code. Doesn't matter how complex the logic is, it should be readable or you're doing devs who read your code a disservice. Long chained linq is an abomination. You should decompose it to individual functions that return IQueryable that have a name that describe what it does, so the original linq reads like a nice sentence. Devs spend 90% of the time reading code, not writing it. Shouldn't you write it so 90% of the rest of your job is easier and make everybody more efficient and a better developer?
|
|
|
|
|
I haven't logged in to this site in years but this came up in my newsletter and I had to respond.
This is a thing in the industry now. My experience with this most recently was at Dupont/Dow Pioneer in Johnston, IA. The code was intentionally dumbed down to accommodate for the least capable people on the team. This meant that many important aspects of development were not taken into account like transactions and idempotency, for example. Dependency Injection/Inversion of Control was a big no no because "there was too much magic" and for some reason it was considered easier to change a dozen or so constructors to account for one new parameter. We were told not to use LINQ because "it was too slow" (this was a web app used by dealers throughout the country sometimes with only 2G internet available).
We used vanilla JS because it's what most people knew even though the front end code was a complete mess. One team took the initiative and moved to TypeScript which set a precedent and my followed suit. There was some initial complaining but quickly that subsided when we saw how much cleaner our code became.
I thought we were all supposed to get better at this stuff so we have the "rising tide lifts all boats" thing going on but it seems like the industry would rather sink to the bottom like a dying shark. For my particular experience I believe the consulting firms were more to blame than the actual company itself. You see in some markets it is very difficult to find quality people so these firms have to place anyone they can even if they are unskilled.
At some point the skilled get overwhelmed by the unskilled through sheer numbers alone. We know what happens next; Dead Sea Effect, Brooks Law etc etc.
|
|
|
|
|
Let me rephrase the question you ask:
Who do we write code for:
- The compiler?
- Ourselves?
- The next developer?
- The Company we work for?
At a high level, ALL of them. And importantly, the company claims this as an asset.
So, you get a Really High IQ individual come in, and do COOL things in the code that few people understand. (Terry B. in my old PDP days. What he was trying to do became clear to me 2-3 years later when I got my degree! But his code was buggy AND hard to work with, so it was tossed.)
I wonder if you are doing recular Code Reviews?
What is the process for introducing new concepts, and documenting them in the Corporate Wiki?
As a Manager I understand the company perspective. Once you leave, you assume the code will live forever without changes... And it was easy... to you...
Given that you write code for ALL of those vested interests... I think adding Code Reviews, and introducing (and documenting/explaining how these fancy fangled things work) will eventually drag the organization closer to your level, and leave something of true value behind.
BTW, when you do a Code Review, and nobody else understands the code... it's not really being reviewed. Also, Code Reviews are a great way to disseminate that knowledge to the newer programmers (and yes, the manager). I can barely read a Linq statement, but I don't code in C# often, and have not used them personally. I don't stop others, but I do make them explain the flow... And we review the naming and variables used within...
|
|
|
|
|
I hate to throw rain on your perceptions but writing code for the least experienced in your team is what you are supposed to be doing.
It is one of the first axioms that maturing developers should be picking up.
The idea that you want to write code your own way using whatever complexities you deem fit only drives the cost of maintaining your applications up.
If everyone in your team is familiar with LINQ for example, than you should be free to use it. If they aren't than you should be using what they do know in its place unless these team members are provided the time to learn how to use such technologiess efficiently.
In addition, code is supposed to be as simplistic as possible so anyone can easily absorb it when it is necessary for new people to pick up on your work.
Most of the so called latest and cool technologies are just fluff or junk technologies that do the same thing we have been doing for years with older, more mature technologies, yet far more complex since the younger professionals seem to be masochistic in their outlooks on what makes up good coding techniques.
Like with Linux, harder and more complex is seemingly better than simple and intuitive... 
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
I don't mind the most cryptic, tricky piece of code as long as it is also accompany be good comments. I've seen some comment describing the code but not the meaning of it. Anyone call themselves programmer should be able to determine the syntax with meaningful comments.
|
|
|
|
|
Oh, yeah. Didn't want to spend the extra time because of this and let them know. Got fired. C'est la vie.
|
|
|
|
|
Heh, it's a cost saving plan.  If you dumb down the code enough that a newbie developer can grok it you can then get rid of some of your senior (expensive) developers. Or at least you don't have to hire senior developers any more.
|
|
|
|
|
Nice try. Unless the company doesn't plan to stick around long. Sooner rather than later that simple saving will come back to bite the rear end good. Happens all the time.
Think it is expensive to invest in good engineering, try a bad one. 
|
|
|
|
|
Yeah, I agree. Unfortunately you see it out there a fair amount. I've always been of the opinion that newbie engineers need to be mentored by a senior engineer. Unfortunately, that doesn't seem to happen much.
|
|
|
|
|
How about dumbing down code so that it can be understood by senior devs?
|
|
|
|
|
Well, I'm all for keeping things as simple as possible when developing code but "dumbing it down" by avoiding the use of a technology that might help keep it simple, or retroactively doing it just so that some junior developer could understand it ... no.
If you think hiring a professional is expensive, wait until you hire an amateur! - Red Adair
|
|
|
|
|
Statistically, half the people you know are below average. Programmers are no different. Maybe worse. In programming, the mean is well below the median. Web development reminds me of "departmental programmers" that write Excel macros. They can do some pretty good work (from a business needs perspective) quickly, and with limited technical knowledge.
The thing is, if you can make it work with "commodity programmers", it makes economic sense. Things have changed a lot. Look at user expectations. Before the web, users used to complain if an app didn't respond within 1/4 second after a button push. Now a user might wait 4 seconds without complaining. The programmer that can squeeze those milliseconds out just isn't as valuable if their cost is much higher and they are not interchangeable with "just any" programmer.
That said, there is a difference between "dumb" and "stupid". Extension methods and C# 7 features are all pretty simple and easy to understand/learn. I'd say on a scale of 1-10 they are about a 4. Using LINQ deeply is a little higher and the learning curve can be steeper, but still, once you grasp it, not hard.
I approach this using a two-tiered approach. A small set (even just one) of advanced programmers are responsible for building "internal toolkits". Basically, domain specific libraries (wrapped with training wheels and pretty little bows and ribbons). The rest of the team just uses these libraries. It's like in manufacturing. You have your tool-and-die makers, and your commodity (lower-paid) workers that use the tools. Good tools make the workers job simple and efficient, and they don't need to know how to build the tools themselves. Management reduces labor costs and manages risk by encapsulating it in the tool/die makes realm.
|
|
|
|
|
I guess that company wants to dumb down their developers, let them. Good that you got out of it. 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
