Why Coder Pay Isn't Proportional To Productivity
Anne & Lynn Wheeler
Why Coder Pay Isn't Proportional To Productivity
http://developers.slashdot.org/story/09/12/23/1820214/Why-Coder-Pay-Isnt-Proportional-To-Productivity
Why programmers are not paid in proportion to their productivity
http://www.johndcook.com/blog/2009/12/23/why-programmers-are-not-paid-in-proportion-to-their-productivity/
... i've periodically used KISS (or maybe it is the lines of code that
you don't write).
this frequently came in when doing cp67 & vm370 ... more akin to
microkernel ... periodically traditional operating system approaches
would add more & more to the monitor/microkernel ... in part because at
the start, it was so small and easy to modify ... but unbridled adding
... turns it into large, unwiedly and possibly "spaghetti" code. then
it is in need of large cut&burn.
i had to do something like that for i/o subsystem for the disk
engineering lab ... so that they could do on-demand, concurrent testing
of multiple devices under development. misc. past posts mentioning
getting to play disk engineer (& doing operating system for them ... at
one time they had tried standard MVS and experienced 15min MTBF):
http://www.garlic.com/~lynn/subtopic.html#disk
recent post that part of the rewrite ... significantly reduced the total
lines of code, the total pathlength ... and added more function ... with
unintended side-effect better alternate path operation
http://www.garlic.com/~lynn/2009q.html#79 Now is time for banks to replace core system according to Accenture
which was related to this post about making the redrive logic
significantly (smaller) faster ... resulted in degradation:
http://www.garlic.com/~lynn/2009r.html#52 360 programs on a z/10
also mentioned in earlier post in the previous thread:
http://www.garlic.com/~lynn/2009q.html#74 Now is time for banks to replace core system according to Accenture
post about something that resulted in 100* (hundred fold) increase in
bloat
http://www.garlic.com/~lynn/2009r.html#72 Why don't people use certificate-based access authentication?
http://www.garlic.com/~lynn/2009s.html#10 Why don't people use certificate-base access authentication
doing something that didn't result in such enormous bloat wasn't viewed
as nearly as attractive ... since it wouldn't appear that nearly as much
could be charged (i.e. getting paid less for KISS seems to permeate the
whole value chain).
--
40+yrs virtualization experience (since Jan68), online at home since Mar1970
Charlie Gibbs
(Anne & Lynn Wheeler) writes:
> Why Coder Pay Isn't Proportional To Productivity
> http://developers.slashdot.org/story/09/12/23/1820214/Why-Coder-Pay-Isnt-Pro
> portional-To-Productivity
>
> Why programmers are not paid in proportion to their productivity
> http://www.johndcook.com/blog/2009/12/23/why-programmers-are-not-paid-in-pro
> portion-to-their-productivity/
>
> ... i've periodically used KISS (or maybe it is the lines of code that
> you don't write).
>
> this frequently came in when doing cp67 & vm370 ... more akin to
> microkernel ... periodically traditional operating system approaches
> would add more & more to the monitor/microkernel ... in part because at
> the start, it was so small and easy to modify ... but unbridled adding
> ... turns it into large, unwiedly and possibly "spaghetti" code. then
> it is in need of large cut&burn.
<snip>
> doing something that didn't result in such enormous bloat wasn't viewed
> as nearly as attractive ... since it wouldn't appear that nearly as much
> could be charged (i.e. getting paid less for KISS seems to permeate the
> whole value chain).
Yup. Whenever I took over an existing program for modification
I'd typically reduce its line count by 30%. The nice thing about
working in small shops was that people would tend to pay more
attention to the program's readability, speed, and reliability
than how well it fit some bureaucratic bloatware culture.
--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
Joe Morris
> ly...@garlic.com (Anne & Lynn Wheeler) writes:
>> doing something that didn't result in such enormous bloat wasn't viewed
>> as nearly as attractive ... since it wouldn't appear that nearly as much
>> could be charged (i.e. getting paid less for KISS seems to permeate the
>> whole value chain).
> Yup. Whenever I took over an existing program for modification
> I'd typically reduce its line count by 30%. The nice thing about
> working in small shops was that people would tend to pay more
> attention to the program's readability, speed, and reliability
> than how well it fit some bureaucratic bloatware culture.
..arguably in part because in a small shop there's no "other department in
<name of distant city>" that produced the inedible spaghetti and got it
approved before you had a chance to point out its problems. Everyone knows
everyone else and (hopefully) offers advice in a professional manner when an
application becomes at-risk for a bloatware attack and/or feeping
creatureism.
Joe Morris
Charlie Gibbs
(Joe Morris) writes:
Or the program was just sloppily written in the first place.
On the other hand, at one shop the original author was still there,
having moved into a management position. After my standard slash &
burn, I left for two weeks' vacation. Unfortunately, there was a
bug in my new code. When I returned, I found that the manager had
had a screaming fit and thrown out all my work, when he discovered
what I had done to his precious spaghetti.
Said manager eventually moved to another company, where one of my
cow orkers encountered him - and nearly punched him out.
Charles Richmond
> In article <hgvq7...@news1.newsguy.com>, j.c.m...@verizon.net
> (Joe Morris) writes:
>
>> "Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:
>>
>>> ly...@garlic.com (Anne & Lynn Wheeler) writes:
>>>
>>>> doing something that didn't result in such enormous bloat wasn't
>>>> viewed as nearly as attractive ... since it wouldn't appear that
>>>> nearly as much could be charged (i.e. getting paid less for KISS
>>>> seems to permeate the whole value chain).
>>> Yup. Whenever I took over an existing program for modification
>>> I'd typically reduce its line count by 30%. The nice thing about
>>> working in small shops was that people would tend to pay more
>>> attention to the program's readability, speed, and reliability
>>> than how well it fit some bureaucratic bloatware culture.
>> ..arguably in part because in a small shop there's no "other
>> department in <name of distant city>" that produced the inedible
>> spaghetti and got it approved before you had a chance to point out
>> its problems. Everyone knows everyone else and (hopefully) offers
>> advice in a professional manner when an application becomes at-risk
>> for a bloatware attack and/or feeping creatureism.
>
> Or the program was just sloppily written in the first place.
>
I have inherited programs that were *so* bad... that it was *much*
easier and cheaper (in time and resources) for me to throw the
whole mess out and write an entirely new program. It's amazing to
me how far some "programmers" can get by writing *really* horrible
code!!!
--
+----------------------------------------+
| Charles and Francis Richmond |
| |
| plano dot net at aquaporin4 dot com |
+----------------------------------------+
Anne & Lynn Wheeler
>
> On the other hand, at one shop the original author was still there,
> having moved into a management position. After my standard slash &
> burn, I left for two weeks' vacation. Unfortunately, there was a
> bug in my new code. When I returned, I found that the manager had
> had a screaming fit and thrown out all my work, when he discovered
> what I had done to his precious spaghetti.
re:
http://www.garlic.com/~lynn/2009s.html#16 Why Coder Pay Isn't Proportional To Productivity
slight x-over from this thread
http://www.garlic.com/~lynn/2009r.html#56 You know you've been Lisp hacking to long when
http://www.garlic.com/~lynn/2009r.html#65 You know you've been Lisp hacking to long when
and whether or not actually proficient in a language ... somewhat akin
to writing a really, really bad poem in a language and totally lacking
in any proficiency in that language ... sometimes it seems that the
majority of the programmers in the world are severely lacking in
proficiency in whatever language that they are writing programs in
(possibly assuming that if they are proficient in, say english, that is
sufficient to qualify them as proficient in any other language).
jmfbahciv
was an on-going tweaking session over 3-6 months. That said,
there were coders who thought they were "saving" execution time by
filling their ASCII source with CALLs and/or GOTOs.
/BAH
jmfbahciv
a flow chart.
/BAH
Anne & Lynn Wheeler
jmfbahciv <jmfbahciv@aol> writes:
> Even the most talented coders ended up with spaghetti if the development
> was an on-going tweaking session over 3-6 months. That said,
> there were coders who thought they were "saving" execution time by
> filling their ASCII source with CALLs and/or GOTOs.
or go back 15-20 yrs later and find something that you had been written
had turned into spaghetti.
des...@verizon.net
Flow chart?
I wrote plenty of them, and I've seen many others produced.
But I haven't written one since the 70s and if I saw someone creating
one today, I'd think "danger Will Robinson".
If anything I'd say flow charts lead to crazily dis-organized code.
Create and organize the code in it's final form, not some artificial
intermediate format.
jmfbahciv
>> Even the most talented coders ended up with spaghetti if the development
>> was an on-going tweaking session over 3-6 months. That said,
>> there were coders who thought they were "saving" execution time by
>> filling their ASCII source with CALLs and/or GOTOs.
>
> or go back 15-20 yrs later and find something that you had been written
> had turned into spaghetti.
>
the modules JMF and TW wrote) you wish you could do over because
of all the stuff you learned not to do when writing it for the
first time.
/BAH
jmfbahciv
If you saw somebody writing one today, you would be watching somebody
learning and/or trying to figure out the places which will need
care.
>
> If anything I'd say flow charts lead to crazily dis-organized code.
Flow charting helps one to think about ordering of execution. People
who can't think like this make spaghetti code from the beginning.
>
> Create and organize the code in it's final form, not some artificial
> intermediate format.
It doesn't have to do with how the sources look when the product is
done. Flow charting has to do with bit flows, interruptions,
and decision trees.
/BAH
Natarajan Krishnaswami
> des...@verizon.net wrote:
>> Create and organize the code in it's final form, not some artificial
>> intermediate format.
>
> It doesn't have to do with how the sources look when the product is
> done. Flow charting has to do with bit flows, interruptions,
> and decision trees.
I tend to agree with despen on this -- I find it easier to lay out the
things you mention above by writing/thinking about HLL source code.
HLLs make it fairly easy (but not mandatory, of course) to reify these
in source code.
>> If anything I'd say flow charts lead to crazily dis-organized code.
>
> Flow charting helps one to think about ordering of execution. People
> who can't think like this make spaghetti code from the beginning.
jmfbahciv <jmfbahciv@aol> wrote elsewhere:
> <grin> There is that, too. Or the monitor code (I'm remembering
> the modules JMF and TW wrote) you wish you could do over because
> of all the stuff you learned not to do when writing it for the
> first time.
I can't think of many projects where I haven't wistfully looked back
on how much easier it would have been if I'd known the lessons learned
doing it. Heck, I remember thinking back back in 10th grade how much
easier precalc/trig would have been if we'd gotten to use calculus.
:-)
"Thinking like this" is clearly valuable: I don't think anyone
disagrees that understanding and thinking in terms of data and control
flow are vital.
Methodologies like XP that favor frequent/constant refactoring, when
performed well, trade that up-front analysis for rewriting the code to
reflect these. The programmer still has to think about such concerns,
but to some extent gets to defer more of it, with the rewriting to
avoid spaghetti. As an additional carrot, lessons learned while
solving the problem can be used more broadly than in conventional dev
methodologies. IME, the code's a delight to read. (That's true of
beautiful code in general, of course, but it seems to be more common
for these.)
Regards,
N.
Charlie Gibbs
writes:
> Charles Richmond wrote:
>
>> Charlie Gibbs wrote:
<snip>
>>> Or the program was just sloppily written in the first place.
>>
>> I have inherited programs that were *so* bad... that it was *much*
>> easier and cheaper (in time and resources) for me to throw the whole
>> mess out and write an entirely new program. It's amazing to me how
>> far some "programmers" can get by writing *really* horrible code!!!
For some people, a programming job is nothing more than a stepping stone
to a management position. You can spot these types a mile away - both
by their code and by their general attitude.
> Even the most talented coders ended up with spaghetti if the
> development was an on-going tweaking session over 3-6 months.
This effect can be minimized if the coders are sufficiently
conscientious - and are given time to Do The Right Thing.
Unfortunately, this often doesn't happen; I've gotten into
trouble for "wasting" my time cleaning up code, even though
it pays off in the long run.
> That said, there were coders who thought they were "saving" execution
> time by filling their ASCII source with CALLs and/or GOTOs.
Sometimes memory was sufficiently tight that you had to resort to
such tricks - but not nearly as often as such coders thought. It
made for some interesting (if nauseating) reading. If I was ever
forced to resort to such tricks, I made sure that I commented
everything _very_ thoroughly.
Anne & Lynn Wheeler
> For some people, a programming job is nothing more than a stepping stone
> to a management position. You can spot these types a mile away - both
> by their code and by their general attitude.
re:
http://www.garlic.com/~lynn/2009s.html#16 Why Coder Pay Isn't Proportional To Productivity
http://www.garlic.com/~lynn/2009s.html#24 Why Coder Pay Isn't Proportional To Productivity
http://www.garlic.com/~lynn/2009s.html#28 Why Coder Pay Isn't Proportional To Productivity
once they are in management ... then it is necessary to depreciate the
value of everybody still programming ... preferrably having large
numbers (on theory management value proportional to size of
organization) of (low-value) interchangeable people (no skill required).
another view ... would be boyd's "to be or to do" ... some recent
references:
http://www.garlic.com/~lynn/2009b.html#25 The recently revealed excesses of John Thain, the former CEO of Merrill Lynch, while the firm was receiving $25 Billion in TARP funds makes me sick
http://www.garlic.com/~lynn/2009h.html#5 mainframe replacement (Z/Journal Does it Again)
http://www.garlic.com/~lynn/2009o.html#47 U.S. begins inquiry of IBM in mainframe market
http://www.garlic.com/~lynn/2009p.html#34 big iron mainframe vs. x86 servers
http://www.garlic.com/~lynn/2009p.html#60 MasPar compiler and simulator
http://www.garlic.com/~lynn/2009q.html#37 The 50th Anniversary of the Legendary IBM 1401