|
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.
|
|
|
|
|
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...
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
