Breaking News
Comments
Newest First | Oldest First | Threaded View
Page 1 / 2   >   >>
prabhakar_deosthali
User Rank
CEO
Patches in memory
prabhakar_deosthali   5/6/2014 9:04:19 AM
NO RATINGS
In early eighties , we used manual code by using coding sheets to modify  our programs in binary code using piono key switches on the front panel of the computer. This was because the recompilation was done only once in a while .Any changes of the programs had to be done as patches as the recompilation of the code was not possible every now and then . So we used to keep a record of the patches until the enxt compilation. One of or smart programmers kep all the record of the patches in his brain, never recording it on the paper. This led to many a situations where we used to spend hours in debugging a code until this smart programmer pulling out a patch from his memory and fixing the problem.

Bert22306
User Rank
CEO
Perceptions
Bert22306   5/5/2014 3:57:10 PM
NO RATINGS
Reading the article and the some of the comments, my reaction was, I'm sure glad I don't work in that environment. Took me some time to figure out how to get this across.

Sure, code should be clear in preference to JUST efficient. That's not my problem. My problem is, engineers who feel they are "subordinate" to management, or management that feels it has "ownership" of the work. Both concepts are foreign to me and to where I work.

Where I work, the management of the actual engineering work is done by engineers, typically lead engineers. And "ownership" is definitely with the engineers that did the work. Everyone knows who they are. I wouldn't have it any other way. Surprising that others haven't reacted similarly.

jonnydoin
User Rank
Blogger
Re: Management
jonnydoin   5/3/2014 1:26:21 AM
@Jimmy99Neutron: I agree that expectations should be clear. Actually, the programmer mentioned is a very good Engineer. The case described took place during his integration into the project, and into our Aspect Oriented methodology. It took a little time and effort to convince him that I wanted his brilliant mind on the logic and design, not really on cryptic descriptions. He ended up contributing with many good designs, and also learning a lot with his peers also. Instead of adhering to rigid rules, the person must adopt the style due to the perception of gain. Peer review and code clarity are much more than management concerns. When people realize that they can easily tackle projects with 300k lines of code by practicing a clear style, they embrace it. In a well integrated team, we can write code at ten hands and the code seems to have been written by the same person. That's what peer review does for you: you get all the best contributions to rapidly disseminate through all the programmers. - Jonny

GSKrasle
User Rank
CEO
Re: cin >> isReaderCoder;
GSKrasle   5/2/2014 7:22:38 PM
NO RATINGS
Hmmm,

It also matters what you get used to. I can type this useful formula in my sleep:

=IFERROR(MID(L60,FIND("[",L60)+1,FIND("]",L60)-FIND("[",L60)-1),IF(ISERR(FIND("\",L60)),"",MID(L60,FIND("*",SUBSTITUTE(L60,"\","*",LEN(L60)-LEN(SUBSTITUTE(L60,"\",""))))+1,LEN(L60))))

It's probably Bad Style, but I like to think that's because this language never heard of comments or formatting. You can see what it does though?

Seriously, I use stuff like this all the time, but I try not to inflict it on others; I Copy-PasteValues before the data gets to them. 

Jimmy99Neutron
User Rank
Rookie
Management
Jimmy99Neutron   5/2/2014 12:33:33 PM
NO RATINGS
Firstly, as this person was a subordinate, expectations for his work should be clear, a process is to be followed as it benefits the team, the project and its management and the product ( reduced maintenance, robustness, correctness, etc.).  

Knowing this persons history, the guidelines or standards should have been emphasized.  Tolerating deviations incurs risk, re-work, time/schedule implications, quality and money.  As the Leader of the project you "own" the results.  In no way does this condone the Coders preferences and choices.

ghova
User Rank
Manager
Re: Eschew obfuscation
ghova   5/2/2014 11:17:11 AM
NO RATINGS
Re "clarity is the prime virtue."  Amen - writing turgid code that's "efficient" costs more than it saves.  From a cost-benefit standpoint the optimal program is no faster than adequately fast (C and assembly programmers reading this are probably reaching for the smelling salts).  If future additions makes it unacceptably slow, then and only then do you make an analysis of hot spots and work on those that produce the greatest bang for the buck until the program is again adequate.

Re the manager who wanted three clever lines replaced with one that would be familiar to other readers: they promoted the right guy to manager.

However, the managers referenced, who insist on rewrites to improve clarity, are thin on the ground, at least in my experience (1959 - present).  The ones I've encountered would not take kindly to the programmers taking the time to (in their view) "beautify" code.  And it wouldn't win them any friends among THEIR managers.

BrainiacVI
User Rank
CEO
He followed a Magazine Article on Management
BrainiacVI   5/1/2014 6:01:42 PM
NO RATINGS
I had a (terrible) manager once who insisted one of the programmers on my team recode the three move statements he used to make a string and use sprintf instead.

So we went from three small, fast MOV statements (when compiled) to a slow, interpreted function call that would have added K's of code if it wasn't already used elsewhere.

All for the edict of "One line of code is easier to maintain than three."

perl_geek
User Rank
CEO
Eschew obfuscation
perl_geek   5/1/2014 5:32:24 PM
There's a place for code like that; the "Obfuscated C" competition, where programmers can get the perversity out of their systems before producing real work.

People acquire all sorts of ideas about what constitutes good code, from all sorts of haphazard sources, but managers should make it clear upfront what constitutes merit. (It took me a while to figure it out, and I ask forgiveness of my victims.)

A program is not just a set of instructions to the compiler, it's an open letter to the next unfortunate who has to maintain it. As long as it does the job in a reasonable time, clarity is the prime virtue. It should be obvious what it's doing, and why.  This can take a surprising amount of work, distilling the essence of the problem's structure and using the most powerful tools available.

One of the unfortunate consequences of CS education is that people feel compelled to recreate compilers and usurp the functions provided by the operating system, presumably to justify the pain of studying them. KISS, dammit!

 

 

betajet
User Rank
CEO
Re: C? No!
betajet   5/1/2014 1:43:25 PM
NO RATINGS
anon wrote: This man is an APL programmer at heart.

I'd say more likely a LISP programmer at heart.  The LISP conditional expression is COND, which is a superset of C's conditional expression.

If this were APL, there'd be a bunch of outer products and none of us would be able to understand it :-)

Sheepdoll
User Rank
Blogger
Re: C? No!
Sheepdoll   5/1/2014 1:42:14 PM
NO RATINGS
% For a moment I thought perhaps this programmer was a postscript programmer.  We use lots of % as these are comments.

% Normally I code my lashups in postscript. This last week I have been coding in C.  Must remember to put the ifs and elses at the top of the bracketed {} blocks not the bottoms.  << and >> are used to denote dictionary structures.

% Perhaps this is why I prefer AVR ASM for embedded.  It feels really strange to use C on an 8 bit micro with only 2K of SRAM.  printf and fprintf are not the best solution in such a limited environment.

Page 1 / 2   >   >>


Flash Poll
Top Comments of the Week
Like Us on Facebook
EE Times on Twitter
EE Times Twitter Feed

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
EE Life
Frankenstein's Fix, Teardowns, Sideshows, Design Contests, Reader Content & More
Max Maxfield

Energizing the Young Engineers of Tomorrow
Max Maxfield
15 comments
It doesn't seem all that long ago when I was a bright-eyed, bushy-tailed young engineer. Now I feel like an old fool, but where are we going to find one at this time of the day (LOL)?

Jolt Judges and Andrew Binstock

Jolt Awards: The Best Books
Jolt Judges and Andrew Binstock
1 Comment
As we do every year, Dr. Dobb's recognizes the best books of the last 12 months via the Jolt Awards -- our cycle of product awards given out every two months in each of six categories. No ...

Engineering Investigations

Air Conditioner Falls From Window, Still Works
Engineering Investigations
2 comments
It's autumn in New England. The leaves are turning to red, orange, and gold, my roses are in their second bloom, and it's time to remove the air conditioner from the window. On September ...

David Blaza

The Other Tesla
David Blaza
5 comments
I find myself going to Kickstarter and Indiegogo on a regular basis these days because they have become real innovation marketplaces. As far as I'm concerned, this is where a lot of cool ...