[thelist] Coning conventions, pet peeves
nadeem at nadeemh.com
Mon May 2 07:22:30 CDT 2016
I don’t have anything to add to this. I just wanted to say that I appreciated the points you raised especially about, what I understood as, a shift in perspective in coding today.
I am a young coder compared to a lot of you having been born in 77 well after a lot of you had already started out, but one of the first things I was taught was that concepts in IT need to be forward thinking and we need to be prepared to deal with things that don't immediately make sense. On some level, to me this means trusting other developers to do things for a reason and not to automatically assume incompetence or cultural differences.
I fired a couple of clients (amicably) last year and had to find developers to fill the gap. During my search I found that a lot of new developers rely so much on trending frameworks that they never learnt the basics such as normalising databases, planning for future cases, modularity, not to hardcode values, etc. I suppose anything I list comes down to one thing: they don't think of future flexibility. One caveat to this though: I do live on a small (annoyingly sunny) island with a population of just over a million people and the pool of developers is already small to begin with so maybe it's not so indicative of anything.
Anyway, thank you, you are not reviled in the slightest and I for one fully appreciate the wisdom in your words.
(230) 5766 9169
From: thelist-bounces at lists.evolt.org [mailto:thelist-bounces at lists.evolt.org] On Behalf Of subscription_thelist at harrier.ch
Sent: 01 May 2016 12:18
To: thelist at lists.evolt.org
Subject: Re: [thelist] Coning conventions, pet peeves
Interesting, equality is no longer associative. Is there actually a grammatical rule in English that forces the literal to the right? The anti-"Yoda" coalition seems to be bound by such.
Back in the days I started coding (late '60s) when initial development tools were being refined, we were happy when we could just get them to make the hardware do what we wanted. Different to how it appears now, there was no right or wrong way to code, there was just maintainable and not maintainable. So some, like myself, developed their own constructs to allow our tools to help us better. This is one of them. (Restoring the state of all registers after returning from a subroutine was also one I was criticized for - which was later reflected in local variables in higher languages.) I found it was not a bad habit to maintain as one can never be 100% sure of design decisions made by current or future developers.
I remember fighting this one with Sybase SQL - expressions would not be optimized if written in your so-called "Yoda" way. Shortsighted, but those were the tools at the time.
Seems that in terms of coding, the time over for out-of-the-box thinking, even tho that is what got us to where we are today. But I know that, that's one of the main reasons I got out of industry. Ingenuity is no longer appreciated at this level. I have long stopped recommending coding as a long term career - after 4 major retooling efforts, the last two simply to satisfy managerial concerns, I decided to get off of the hamster wheel. The changes merely provided different ways to reach the same goal, driven by marketing, requiring a lot of effort and not enhancing my market value significantly.
I can feel that all the young warriors on this list have now discounting me as a dinosaur. I write OO code in Perl, because it reduces my dependencies and I KNOW how to easily make it dance to my tune - I am in control. I'm not driven to keep up with the development package of the day. I still make my decisions based on actual value, not what is trendy and convenient. Oh well. At the end of the day, I'm confident that like me and my parents and their parents, today's advocates will also be reviled at by those of the future. Enjoy it while you can.
Okay, I'll go back to lurking to further chuckle at the significance of current issues from the perspective of the past.
...>From: Jason Handby <jason.handby at corestar.co.uk>
...>Subject: Re: [thelist] Coning conventions, pet peeves
...>Date: Thu, 28 Apr 2016 18:33:00 +0000
...>> By putting the comparison
...>> the other way around - making sure that the thing to the left of the operator ...>> is not an lvalue - you make it harder to make this mistake.
...>("lvalue" just means something that can legitimately go on the left of an assignment operator.) ...> ...>Jason
More information about the thelist