Professional Coding for Clients and Managers

Applications Programming
1

My experience programming commercially for clients who are not coders (they are generally managers who do not write code) is very different that what I see discussed in forums and blogs.

Reference the last post of this now closed, long and somewhat confusing topic:

In the topic above @bendingrodriguez (who is a very talented and valued team member) does a nice job of both helping and confusing a member who is not a very experienced programmer. In fact, in that topic @SDohmen wrote his first loop to process an array, which to me is a very basic, beginners task in programming, creating an object model from a document (an array) and then processing that array in a loop. That's a beginners task, at least to me and illustrated (to me, the generally programming experience).

Either way, in that post, @bendingrodriguez, well intended and very skillful, was not really playing attention to the programming skill level of the person at hand (in my opinion) confuses the person working on code with this line in Python where he initializes and integer and an array on the same line in Python:

mx, cmax = -1, []

This is a perfectly acceptable initialization method according to the rules of Python (and many other languages like Ruby, for instance) to initialize variable of mixed types on a single line.

Our good friend @bendingrodriguez (sorry, I'm not picking on our friend, but it makes a good starting point to discuss) replies (perhaps mostly joking) that he wrote this "confusing to a beginner" line because, as he replied:

cause it fits into one line :slight_smile:

When I read this "slight smile" half-joking, have not-joking reply, I thought to myself "Why do so many programmers like to write code which are "one liners" which they easily understand, but others (especially those with less experience or non-coders) do not readily understand. ?

Personally, (I am not saying I am better or smarter in my work flow) I do not generally write one-liners to initialize variables of mixed-types and I always use the form which "bending" later explained (when he explained his one-liner to the confused member):

mx = -1
cmax = []

Actually, personally I do not even name variables like 'mx' and 'cmax' when I code, because I prefer more descriptive variables; and as I mentioned in the other topic, I never initialize variables of mixed type on a single line. For example, instead of:

a,b,c,d = 0,0.0,[],[]

when I code, I do it like this:

initial_count = 0
total_sum = 0.0
sales  = []
inventory = []

Why do code this way? Am I stupid? Do I not know this can be done "in one line"? Why do I use so many characters to describe these simple variables? Neo, are you such a simpleton??

Let me explain.

Normally, when I code, especially for a client, I often review that code on-line using a teleconferencing desktop sharing program like AnyDesk or TeamView. I generally always code in Visual Studio Code (VSC) so when we review code, the client and I are looking at VSC together which has syntax highlighting and colorized brackets pairs, parens, etc. as well.

More-often-than-not, the client I am working with is NOT a software developer and they do not have over 40 years coding and IT design experience like I do. In fact, they do not even like to look at code, for the most part! I am lucky they do. not fall asleep during a telecon looking at code! :slight_smile:

So, I tend to write code for people who are not coders, so they can understand the code easily AND they do not fall asleep staring at code they cannot easily understand at a glance.

However, more importantly, since I write so much code, I might write a method today which I will have to modify a year or two from now. The easier and more simple the code is, the faster we can pick that code up two or three years from now and modify it or debug a problem.

Personally, I absolutely loath trying to figure out, even in my own code, what var "a" is or what "mx" means. So, I do not code to impress coders with my skill at writing short vars and one-liners. Nor, do I code to make the code "more compressed" or "smaller" as if saving a few chars will make the code run so fast. It does not make a difference in processing speed, which is cheap, but it makes human reading must faster, and human processing is much more expensive than machine processimg.

As I mentioned in the topic before this one which I have referenced, I have never, ever had a commercial client, in over 40 years, ask me, nor be willing to pay for, the following tasks:

  • Please remove white space from the code.
  • Please make the variables one or too letters and do not use overly descriptive variable names.
  • Please change the code to have more one-liners and get rid of as many line breaks as. you can.
  • Please make the code harder for a beginner or future developer to understand.
  • Please rewrite the code so coders will appreciate the elegance of the code with impressive one-liners.
  • Etc. etc.

In other words, personally and professionally, I do not code to impress others with my skill at writing one-liners or to save white space, line breaks and save characters. I code as if the person who will need to maintain the code after me is not an expert coder (and might be a novice) and does not want to have to "think too much" about all the cryptic one-liners and "character saving variable names" in the code.

I have noticed over the years, the world has a lot of coders who are just the opposite than me. They seem to take great pride in writing one liners and hard to understand (by others of less skill) code.

Anyway, I am not picking on anyone and certainly have nothing against one-liners and other coders. But on the other hand, I am not a fan of "complexity for the sake of complexity" and think too much optimization confuses people with less experience and make code both harder to maintain and to read. That's my view. Your view might be totally different.

I'm sure others disagree and I think this topic is something coders will debate forever because most coders seem to code for "other coders" and not code for "the client" who is not a coder and may just be "a non-coding manager".

In my long career, I am generally always the most experience person on any project I work on. This is not "a brag", it's just a fact. This was true 20 years ago and it remains true today. Age, education and experience does come into play. I always try to code for "the beginner" and I notice that, more-and-more, I discuss ideas, methods and algorithms using AnyDesk or TeamViewer with non-coders, and the more simple I write code, the more descriptive the variable names, the more others can understand it and the longer they stay interested (do not fall asleep, haha).

That's all from my desktop today.

What do you think? Do you agree? Do you disagree?

We do not all have to agree to enjoy life or the company of each other on-line, that is for sure!

1 Like
2

I would never write it like this in production or customer code. That was an example code, which should only demonstrate the semantics resp. functionality. To such a code I make fewer claims.

Surely I didn't pay enough attention to the skill level of the poster. Sometimes I have patience and time, sometimes only one of them and sometimes none of them. So sometimes it could be better to not answering at all.

It often has simply to do with lazyness - which I can't afford with customer code. The code should surely neither look 'cool' nor be impressive. That's not my business. Short code is not necessarily the same as elegant code. The latter is the real art of coding, not the former.

Fitting in one line makes that code neither more readable nor shorter (in the sense of less bytes, indeed both versions have the same number of bytes) nor 'better looking'. It simply cuts off one line of the post and saves exactly one keystroke - see lazyness above. Explanation and emoji were badly chosen.

I would (almost) never use such variable names in prod code, unless for loop vars resp. list comprehensions or as lambda args:

# ok
for i, name in enumerate(names):
# but not
for idx, nm in enumerate(names):
# and surely not
for index, name_whatever in enumerate(names):
# ok, too
foos = [foo(b) for b in bars if b.is_valid and b not in buzz] # not really optimal
# but this
color = RGB(255, 255, 255)
# is obviously preferable to
col = RGB(*[255]*3)

Variable naming resp. naming things in general can be a pain sometimes.

Nor write several definitions of vars in one line, unless it was a kind of enum, like

OK, WARN, CRIT, UNDEF = 0, 1, 2, 3 # or simply range(4) or State = Enum('State', 'OK WARN CRIT UNDEF')
# or
WIDTH, HEIGHT = 200, 50
# or
row, col = 0, 0
row, column = 0, 0 # is this preferable/more readable? don't think so.
# or
pos_start, pos_end = Position(1, 1), Position(XSIZE, YSIZE)
# but surely not
position_start, position_end = ...

So only if vars have similar meanings and equal types.

Nor write ugly stuff like this, not even in my own private code:

a,b,x= 1,1, 'x'

Of course I'm sticking to PEP 8 (regarding Python) as far as possible resp. using a linter (although modern IDEs already have this more or less built in) when writing production or customer code. So, the above cited code snippet is surely not my professional coding style. Example code is example code.
I've been programming for companies like Siemens, Xerox, Panasonic etc. successfully and honored in various langauages, starting in the early 80s with coding. So I can assume that my style and code quality is sufficiently sophisticated. And it bothered me a little that I even mentioned that. Thanks.

It won’t work.
-- Jenkinson's Law

1 Like