> Has anyone roughly calculated “man years” spent developing Unix to 1973 or 1974?
> Under 25 "man-years”? (person years now)
I cannot find the message at the moment (TUHS mail archive search is not working anymore?), but I recall that Doug McIlroy mentioned on this list that 1973 was a miracle year, where Ken & Dennis wrote and debugged over 100,000 lines of code between them. In software, “man year” is an elastic yardstick...
There is also this anecdote by Andy Herzfeld:
===
Quickdraw, the amazing graphics package written entirely by Bill Atkinson, was at the heart of both Lisa and Macintosh. "How many man-years did it take to write QuickDraw?", the Byte magazine reporter asked Steve [Jobs].
Steve turned to look at Bill. "Bill, how long did you spend writing Quickdraw?"
"Well, I worked on it on and off for four years", Bill replied.
Steve paused for a beat and then turned back to the Byte reporter. "Twenty-four man-years. We invested twenty-four man-years in QuickDraw."
Obviously, Steve figured that one Atkinson year equaled six man years, which may have been a modest estimate.
===
There is also another anecdote involving Atkinson. At some point all Apple programmers had to file a weekly report with how many lines of code they wrote that week. After a productive week of refactoring and optimising, he filed a report saying “minus 2,000 lines”.
On Tue, Oct 11, 2022 at 01:15:38PM +0200, Paul Ruizendaal via TUHS wrote: > There is also another anecdote involving Atkinson. At some point all Apple programmers had to file a weekly report with how many lines of code they wrote that week. After a productive week of refactoring and optimising, he filed a report saying "minus 2,000 lines". We bonused people for that. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
[-- Attachment #1: Type: text/plain, Size: 978 bytes --] On Tue, Oct 11, 2022 at 7:49 AM Larry McVoy <lm@mcvoy.com> wrote: > On Tue, Oct 11, 2022 at 01:15:38PM +0200, Paul Ruizendaal via TUHS wrote: > > There is also another anecdote involving Atkinson. At some point all > Apple programmers had to file a weekly report with how many lines of code > they wrote that week. After a productive week of refactoring and > optimising, he filed a report saying "minus 2,000 lines". > > We bonused people for that. > I love commits like this, thought it wasn't refactoring so much as deleting obsolete code... commit c09981f1422ef0d44042dacc5d1265392fba39f1 Author: Warner Losh <imp@FreeBSD.org> Date: Thu Dec 30 20:56:09 2021 -0700 mips: Remove sys/mips Remove sys/mips as the next step of decomissioning mips from the tree. Remove mips special cases from the kernel make files. Remove the mips specific linker scripts. Sponsored by: Netflix ... 594 files changed, 4 insertions(+), 134,562 deletions(-) [-- Attachment #2: Type: text/html, Size: 1420 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2496 bytes --] A friend of mine at IBM Research told me the following experience from his early career. He was hired to join the MVS development team in Poughkeepsie (or Endicott?) right out of school. He got the "new kid" assignment - maintaining the JCL interpreter. 500K lines of H Assembler (might have been G Assembler ... disremember). The job was to take bug tickets, analyze them, and respond with either a fix or a rejection. After a bit of this he thinks to himself, "Self, this is a programming language, but badly implemented in assembler with lots of copy-paste crap." He had studied computer science in college, so he knew something about compiler implementation. So he builds a set of parser tables using what he learned from the Dragon Book and implements a new JCL interpreter in PL/1 (or PL/S?). About 20K LOC. The new JCL interpreter is faster, though that doesn't really matter. More importantly, it also closes hundreds of bugs that arose from the fact that many of subcommands had suboptions with variant implementations, even though they were *supposed* to be the same suboption. So, come annual review time he gets the most negative possible score. Why? Because he produced -480K lines of code. So he transferred to the Research Division where his skills were more valued and where I met him. ===== nygeek.net mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home> On Tue, Oct 11, 2022 at 10:00 AM Warner Losh <imp@bsdimp.com> wrote: > > > On Tue, Oct 11, 2022 at 7:49 AM Larry McVoy <lm@mcvoy.com> wrote: > >> On Tue, Oct 11, 2022 at 01:15:38PM +0200, Paul Ruizendaal via TUHS wrote: >> > There is also another anecdote involving Atkinson. At some point all >> Apple programmers had to file a weekly report with how many lines of code >> they wrote that week. After a productive week of refactoring and >> optimising, he filed a report saying "minus 2,000 lines". >> >> We bonused people for that. >> > > I love commits like this, thought it wasn't refactoring so much as > deleting obsolete code... > > commit c09981f1422ef0d44042dacc5d1265392fba39f1 > Author: Warner Losh <imp@FreeBSD.org> > Date: Thu Dec 30 20:56:09 2021 -0700 > > mips: Remove sys/mips > > Remove sys/mips as the next step of decomissioning mips from the tree. > Remove mips special cases from the kernel make files. Remove the mips > specific linker scripts. > > Sponsored by: Netflix > ... > 594 files changed, 4 insertions(+), 134,562 deletions(-) > [-- Attachment #2: Type: text/html, Size: 4929 bytes --]
On Tue, Oct 11, 2022 at 03:43:19PM -0400, Marc Donner wrote:
> So, come annual review time he gets the most negative possible score.
> Why? Because he produced -480K lines of code.
>
> So he transferred to the Research Division where his skills were more
> valued and where I met him.
Whoever wrote that review should have been fired. Absolutely no clue.
Actually, he should have been demoted and had to report to, and learn
from, the guy who wrote the compiler.
On 11 Oct 2022 12:54 -0700, from lm@mcvoy.com (Larry McVoy): > On Tue, Oct 11, 2022 at 03:43:19PM -0400, Marc Donner wrote: >> So, come annual review time he gets the most negative possible score. >> Why? Because he produced -480K lines of code. > > Whoever wrote that review should have been fired. Absolutely no clue. Isn't it relatively well established, though, that IBM culture at least for a very long time put heavy emphasis on counting lines of source code, and that more SLOC was considered to be better? I definitely recall it being mentioned in _Triumph of the nerds_ as a major issue between IBM and Microsoft during development of OS/2. -- Michael Kjörling https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
[-- Attachment #1: Type: text/plain, Size: 1774 bytes --] I think it is (used to be?) a common pattern. Tom Cargill took a year off from Bell Labs Research to work in development. He joined a group where every subsystem's code was printed in a separate binder and stored on a shelf in each office. Tom discovered that one of those subsystems was almost completely redundant, as most its services were implemented elsewhere. So he spent a few months making it completely redundant. He deleted 15,000 lines of code. When he was done, he removed an entire binder from everybody's shelf. His coworkers loved it. During his performance review, he learned that management had a metric for productivity: lines of code. Tom had negative productivity. In fact, because he was so successful, his entire group had negative productivity. He returned to Research with his tail between his legs. -rob On Wed, Oct 12, 2022 at 7:03 AM Michael Kjörling <e5655f30a07f@ewoof.net> wrote: > On 11 Oct 2022 12:54 -0700, from lm@mcvoy.com (Larry McVoy): > > On Tue, Oct 11, 2022 at 03:43:19PM -0400, Marc Donner wrote: > >> So, come annual review time he gets the most negative possible score. > >> Why? Because he produced -480K lines of code. > > > > Whoever wrote that review should have been fired. Absolutely no clue. > > Isn't it relatively well established, though, that IBM culture at > least for a very long time put heavy emphasis on counting lines of > source code, and that more SLOC was considered to be better? > > I definitely recall it being mentioned in _Triumph of the nerds_ as a > major issue between IBM and Microsoft during development of OS/2. > > -- > Michael Kjörling > https://michael.kjorling.se > “Remember when, on the Internet, nobody cared that you were a dog?” > > [-- Attachment #2: Type: text/html, Size: 2675 bytes --]
On Tue, Oct 11, 2022 at 08:02:41PM +0000, Michael Kj??rling wrote:
> On 11 Oct 2022 12:54 -0700, from lm@mcvoy.com (Larry McVoy):
> > On Tue, Oct 11, 2022 at 03:43:19PM -0400, Marc Donner wrote:
> >> So, come annual review time he gets the most negative possible score.
> >> Why? Because he produced -480K lines of code.
> >
> > Whoever wrote that review should have been fired. Absolutely no clue.
>
> Isn't it relatively well established, though, that IBM culture at
> least for a very long time put heavy emphasis on counting lines of
> source code, and that more SLOC was considered to be better?
That's just stupid. I rewarded more functionality in less or the same
lines of code. Want to add 5K LOC? Great, find 5K LOC of dead code.
My team worked on on the same project for 18 years, the main source
base grew to about 125K LOC and stayed there even though we added
more and more functionality. It is possible.
On 11 Oct 2022 13:10 -0700, from lm@mcvoy.com (Larry McVoy): >> Isn't it relatively well established, though, that IBM culture at >> least for a very long time put heavy emphasis on counting lines of >> source code, and that more SLOC was considered to be better? > > That's just stupid. You're getting no argument from me there. -- Michael Kjörling https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
On 10/11/2022 3:14 PM, Michael Kjörling wrote: > On 11 Oct 2022 13:10 -0700, from lm@mcvoy.com (Larry McVoy): >>> Isn't it relatively well established, though, that IBM culture at >>> least for a very long time put heavy emphasis on counting lines of >>> source code, and that more SLOC was considered to be better? >> >> That's just stupid. > > You're getting no argument from me there. > It was likely true that some parts of IBM put heavy emphasis on LOC, but as Marc points out, that wasn't true in Research. I don't remember heavy LOC emphasis in AIX groups, and I suspect even in Boca (OS/2) there was not "heavy" emphasis. -- voice: +1.512.784.7526 e-mail: sauer@technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Twitter: CharlesHSauer
[-- Attachment #1: Type: text/plain, Size: 2310 bytes --] On Tue, Oct 11, 2022 at 4:09 PM Rob Pike <robpike@gmail.com> wrote: > I think it is (used to be?) a common pattern. > > Tom Cargill took a year off from Bell Labs Research to work in > development. He joined a group where every subsystem's code was printed in > a separate binder and stored on a shelf in each office. Tom discovered that > one of those subsystems was almost completely redundant, as most its > services were implemented elsewhere. So he spent a few months making it > completely redundant. He deleted 15,000 lines of code. When he was done, he > removed an entire binder from everybody's shelf. His coworkers loved it. > > During his performance review, he learned that management had a metric for > productivity: lines of code. Tom had negative productivity. In fact, > because he was so successful, his entire group had negative productivity. > He returned to Research with his tail between his legs. > Was this vignette in, "The Practice of Programming"? I know I've read it somewhere before, either there, or in the first edition of "Programming Pearls." In the latter, Bentley makes a quip about incentives and lives of code. Basically, if one incentivizes repetitive code, that's one what gets; "if you pay by the line of code, how do you think an array with 500 elements gets initialized?" - Dan C. On Wed, Oct 12, 2022 at 7:03 AM Michael Kjörling <e5655f30a07f@ewoof.net> > wrote: > >> On 11 Oct 2022 12:54 -0700, from lm@mcvoy.com (Larry McVoy): >> > On Tue, Oct 11, 2022 at 03:43:19PM -0400, Marc Donner wrote: >> >> So, come annual review time he gets the most negative possible score. >> >> Why? Because he produced -480K lines of code. >> > >> > Whoever wrote that review should have been fired. Absolutely no clue. >> >> Isn't it relatively well established, though, that IBM culture at >> least for a very long time put heavy emphasis on counting lines of >> source code, and that more SLOC was considered to be better? >> >> I definitely recall it being mentioned in _Triumph of the nerds_ as a >> major issue between IBM and Microsoft during development of OS/2. >> >> -- >> Michael Kjörling >> https://michael.kjorling.se >> “Remember when, on the Internet, nobody cared that you were a dog?” >> >> [-- Attachment #2: Type: text/html, Size: 3596 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2536 bytes --] I told this anecdote in an internal talk at Google. You might have seen it then. -rob On Wed, Oct 12, 2022 at 8:08 AM Dan Cross <crossd@gmail.com> wrote: > On Tue, Oct 11, 2022 at 4:09 PM Rob Pike <robpike@gmail.com> wrote: > >> I think it is (used to be?) a common pattern. >> >> Tom Cargill took a year off from Bell Labs Research to work in >> development. He joined a group where every subsystem's code was printed in >> a separate binder and stored on a shelf in each office. Tom discovered that >> one of those subsystems was almost completely redundant, as most its >> services were implemented elsewhere. So he spent a few months making it >> completely redundant. He deleted 15,000 lines of code. When he was done, he >> removed an entire binder from everybody's shelf. His coworkers loved it. >> >> During his performance review, he learned that management had a metric >> for productivity: lines of code. Tom had negative productivity. In fact, >> because he was so successful, his entire group had negative productivity. >> He returned to Research with his tail between his legs. >> > > Was this vignette in, "The Practice of Programming"? I know I've read it > somewhere before, either there, or in the first edition of "Programming > Pearls." > > In the latter, Bentley makes a quip about incentives and lives of code. > Basically, if one incentivizes repetitive code, that's one what gets; "if > you pay by the line of code, how do you think an array with 500 elements > gets initialized?" > > - Dan C. > > On Wed, Oct 12, 2022 at 7:03 AM Michael Kjörling <e5655f30a07f@ewoof.net> >> wrote: >> >>> On 11 Oct 2022 12:54 -0700, from lm@mcvoy.com (Larry McVoy): >>> > On Tue, Oct 11, 2022 at 03:43:19PM -0400, Marc Donner wrote: >>> >> So, come annual review time he gets the most negative possible score. >>> >> Why? Because he produced -480K lines of code. >>> > >>> > Whoever wrote that review should have been fired. Absolutely no clue. >>> >>> Isn't it relatively well established, though, that IBM culture at >>> least for a very long time put heavy emphasis on counting lines of >>> source code, and that more SLOC was considered to be better? >>> >>> I definitely recall it being mentioned in _Triumph of the nerds_ as a >>> major issue between IBM and Microsoft during development of OS/2. >>> >>> -- >>> Michael Kjörling >>> https://michael.kjorling.se >>> “Remember when, on the Internet, nobody cared that you were a dog?” >>> >>> [-- Attachment #2: Type: text/html, Size: 4327 bytes --]
Rob Pike <robpike@gmail.com> wrote:
> I think it is (used to be?) a common pattern.
Clearly, the metric in both cases should have been the absolute
value of the number of lines of code changed...
Both stories are rather sad; one hopes that today's world is
a better place.
Arnold
On 12 Oct 2022 00:59 -0600, from arnold@skeeve.com: > Clearly, the metric in both cases should have been the absolute > value of the number of lines of code changed... Oh, that one is easy. Just make a copy of all the code for safekeeping, and replace all of it with something absolutely trivial. Then the next day, restore the old code. That way, if the code base was, say, 100K lines, your productivity is slightly in excess of 200K LOC in those two days. -- Michael Kjörling https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
I recall hearing about a new hire at IBM who was tasked with working on the JCL processing code. After looking it over, he decided to rewrite it using compiler-compiler technology. The result worked, was about 250 KLOC smaller than the original, and was accepted. However, at review time the employee received an absolutely terrible review. Seems he had generated a really substantial negative amount of code. Story I heard was that he was soon picked up by IBM Labs... -r
[-- Attachment #1: Type: text/plain, Size: 1095 bytes --] On Tue, Oct 11, 2022 at 2:34 PM Charles H Sauer (he/him) < sauer@technologists.com> wrote: > On 10/11/2022 3:14 PM, Michael Kjörling wrote: > > On 11 Oct 2022 13:10 -0700, from lm@mcvoy.com (Larry McVoy): > >>> Isn't it relatively well established, though, that IBM culture at > >>> least for a very long time put heavy emphasis on counting lines of > >>> source code, and that more SLOC was considered to be better? > >> > >> That's just stupid. > > > > You're getting no argument from me there. > > > > It was likely true that some parts of IBM put heavy emphasis on LOC, but > as Marc points out, that wasn't true in Research. I don't remember heavy > LOC emphasis in AIX groups, and I suspect even in Boca (OS/2) there was > not "heavy" emphasis. > Speaking of "just stupid" Word on the street is that Elon Musk stack ranked the engineers by lines of code over the last year (source: https://ma.nu/blog/bye-twitter) and layed off the bottom performers in terms of LoC... Not 100% sure this is legit, since some tweets about it have been deleted. Warners [-- Attachment #2: Type: text/html, Size: 1725 bytes --]
[-- Attachment #1: Type: text/plain, Size: 319 bytes --] On Nov 7, 2022, at 9:52 AM, Warner Losh <imp@bsdimp.com> wrote: > > Speaking of "just stupid" > > Word on the street is that Elon Musk stack ranked the engineers by lines of code > over the last year (source: https://ma.nu/blog/bye-twitter) and layed off the bottom > performers in terms of LoC... Just LoCo! [-- Attachment #2: Type: text/html, Size: 753 bytes --]
On Mon, Nov 7, 2022 at 12:52 PM Warner Losh <imp@bsdimp.com> wrote: > On Tue, Oct 11, 2022 at 2:34 PM Charles H Sauer (he/him) <sauer@technologists.com> wrote: >> On 10/11/2022 3:14 PM, Michael Kjörling wrote: >> > On 11 Oct 2022 13:10 -0700, from lm@mcvoy.com (Larry McVoy): >> >>> Isn't it relatively well established, though, that IBM culture at >> >>> least for a very long time put heavy emphasis on counting lines of >> >>> source code, and that more SLOC was considered to be better? >> >> >> >> That's just stupid. >> > >> > You're getting no argument from me there. >> >> It was likely true that some parts of IBM put heavy emphasis on LOC, but >> as Marc points out, that wasn't true in Research. I don't remember heavy >> LOC emphasis in AIX groups, and I suspect even in Boca (OS/2) there was >> not "heavy" emphasis. > > Speaking of "just stupid" > > Word on the street is that Elon Musk stack ranked the engineers by lines of code > over the last year (source: https://ma.nu/blog/bye-twitter) and layed off the bottom > performers in terms of LoC... Well, if I ever go to work for Twitter, I know how I'm initializing large arrays. > Not 100% sure this is legit, since some tweets about it have been deleted. I suspect it was slightly more nuanced, having more to do with "total output" measured as some combination of number of changes and their total size. It sure is dumb, though. - Dan C.
[-- Attachment #1: Type: text/plain, Size: 1477 bytes --] My buds in the SRE community confirm that Twitter laid off the entire SRE team, since of course they didn't write enough code. Good luck with keeping the system up. ===== nygeek.net mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home> On Mon, Nov 7, 2022 at 12:52 PM Warner Losh <imp@bsdimp.com> wrote: > > > On Tue, Oct 11, 2022 at 2:34 PM Charles H Sauer (he/him) < > sauer@technologists.com> wrote: > >> On 10/11/2022 3:14 PM, Michael Kjörling wrote: >> > On 11 Oct 2022 13:10 -0700, from lm@mcvoy.com (Larry McVoy): >> >>> Isn't it relatively well established, though, that IBM culture at >> >>> least for a very long time put heavy emphasis on counting lines of >> >>> source code, and that more SLOC was considered to be better? >> >> >> >> That's just stupid. >> > >> > You're getting no argument from me there. >> > >> >> It was likely true that some parts of IBM put heavy emphasis on LOC, but >> as Marc points out, that wasn't true in Research. I don't remember heavy >> LOC emphasis in AIX groups, and I suspect even in Boca (OS/2) there was >> not "heavy" emphasis. >> > > Speaking of "just stupid" > > Word on the street is that Elon Musk stack ranked the engineers by lines > of code > over the last year (source: https://ma.nu/blog/bye-twitter) and layed off > the bottom > performers in terms of LoC... > > Not 100% sure this is legit, since some tweets about it have been deleted. > > Warners > [-- Attachment #2: Type: text/html, Size: 2663 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2007 bytes --] On Tue, Nov 8, 2022, 1:57 PM Marc Donner <marc.donner@gmail.com> wrote: > My buds in the SRE community confirm that Twitter laid off the entire SRE > team, since of course they didn't write enough code. Good luck with > keeping the system up. > It's ok. I'm sure users can just fax problem reports to Elon. To tie this back to TUHS a little bit...when did being a "sysadmin" become a thing unto itself? And is it just me, or has that largely been superceded by SRE (which I think of as what one used to, perhaps, call a "system programmer") and DevOps, which feels like a more traditional Unix-y kind of thing? - Dan C. ===== > nygeek.net > mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home> > > > On Mon, Nov 7, 2022 at 12:52 PM Warner Losh <imp@bsdimp.com> wrote: > >> >> >> On Tue, Oct 11, 2022 at 2:34 PM Charles H Sauer (he/him) < >> sauer@technologists.com> wrote: >> >>> On 10/11/2022 3:14 PM, Michael Kjörling wrote: >>> > On 11 Oct 2022 13:10 -0700, from lm@mcvoy.com (Larry McVoy): >>> >>> Isn't it relatively well established, though, that IBM culture at >>> >>> least for a very long time put heavy emphasis on counting lines of >>> >>> source code, and that more SLOC was considered to be better? >>> >> >>> >> That's just stupid. >>> > >>> > You're getting no argument from me there. >>> > >>> >>> It was likely true that some parts of IBM put heavy emphasis on LOC, but >>> as Marc points out, that wasn't true in Research. I don't remember heavy >>> LOC emphasis in AIX groups, and I suspect even in Boca (OS/2) there was >>> not "heavy" emphasis. >>> >> >> Speaking of "just stupid" >> >> Word on the street is that Elon Musk stack ranked the engineers by lines >> of code >> over the last year (source: https://ma.nu/blog/bye-twitter) and layed >> off the bottom >> performers in terms of LoC... >> >> Not 100% sure this is legit, since some tweets about it have been deleted. >> >> Warners >> > [-- Attachment #2: Type: text/html, Size: 3899 bytes --]
Dan Cross <crossd@gmail.com> wrote:
> To tie this back to TUHS a little bit...when did being a "sysadmin" become
> a thing unto itself? And is it just me, or has that largely been superceded
> by SRE (which I think of as what one used to, perhaps, call a "system
> programmer") and DevOps, which feels like a more traditional Unix-y kind of
> thing?
>
> - Dan C.
Sys admin was a thing in the mid-80s already; I worked as one at the Emory
U Computing Center for several years, ~ 1985 - 1990. Around then USENIX
started the LISA (Large Installation System Administratin) workshops.
Clem can undoubtedly tell us exactly when.
And yes, SRE + dev ops seem to have displaced that, with SRE focusing
more on keeping the bazillions of systems up and running, and DevOps on
things like build and CI/CD systems.
Personally, I'm glad to have gained the sys admin experience, but I
don't want to do it for a living; it's much more fun building product
and letting someone else have the headaches. :-)
Arnold
> On 9 Nov 2022, at 19:41, Dan Cross <crossd@gmail.com> wrote: > > To tie this back to TUHS a little bit...when did being a "sysadmin" become a thing unto itself? And is it just me, or has that largely been superceded by SRE (which I think of as what one used to, perhaps, call a "system programmer") and DevOps, which feels like a more traditional Unix-y kind of thing? > > - Dan C. In The Beginning, We were All Programmers… Machines were smaller, programs simpler and we were closer to the hardware. Literally, like the “Unix Room”, in the Attic at Bell Labs. Admin & Operations weren’t too onerous and “Maintenance” was done by the people doing the kernel & systems software, at a guess. And maybe hardware was fixed by the Vendor, or super-programmers did the plug and play themselves. As sites got bigger, work became multi-person project ’teams’ and admin problems got tricker, while ‘certain people’ did the work. When Unix became properly commercial - multiple vendors, big manuals, support contracts, and a plethora of Unix variants - some Bright People created “Unix Training” courses, in many topiocs. Somewhere around this time, courses and job titles for “System Admin” appeared. Sadly, all this happened without any distinctions in capability & ‘levels’, or actual problem solving testing (cf CISCO’s CCIE: 2 days of testing, 1st day quizzes on a PC, 2nd day is by invitation. Lab session: “fix the broken network in the allotted time”) SAGE - System Admin Guild, part of USENIX - put together a bunch of small books on (Unix) System Admin Topics and tried to guide the development of the field. After 10 years, I was out of the loop and hadn’t seen anything positive in the workplace. SRE roles & as a discipline has developed, alongside DevOps, into managing & fault finding in large clusters of physical and virtual machines. Never done it myself, but it’d seem the potential for screw-ups is now infinite and unlimited in time :) -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin
steve jenkin <sjenkin@canb.auug.org.au> writes: [snip] > SRE roles & as a discipline has developed, alongside DevOps, into managing & fault finding in large clusters of physical and virtual machines. > > Never done it myself, but it’d seem the potential for screw-ups is now infinite and unlimited in time :) My final $DAYJOB was more DevOps / SRE than system admin which I had been doing for a long time. And, Very Much Yes, the "potential for screw-ups" is very much infinite. It seems like that there are a lot of people messing in areas that they are ill prepared to deal with and tend to do it poorly at times. Very often they will invent structure that is just a reinvention of something that already exists because they lack the background to know what was really available. > -- > Steve Jenkin, IT Systems and Design > 0412 786 915 (+61 412 786 915) > PO Box 38, Kippax ACT 2615, AUSTRALIA > > mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin -- Brad Spencer - brad@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
[-- Attachment #1: Type: text/plain, Size: 2766 bytes --] > Never done it myself, but it’d seem the potential for screw-ups is now infinite and unlimited in time :) Indeed! USENIX SREcon generally releases presentations a short while after each conference. Some interesting experiences there... https://www.usenix.org/conferences/byname/925 https://www.usenix.org/srecon -- Stuart. On Wed, 9 Nov 2022 at 17:03, steve jenkin <sjenkin@canb.auug.org.au> wrote: > > > On 9 Nov 2022, at 19:41, Dan Cross <crossd@gmail.com> wrote: > > > > To tie this back to TUHS a little bit...when did being a "sysadmin" > become a thing unto itself? And is it just me, or has that largely been > superceded by SRE (which I think of as what one used to, perhaps, call a > "system programmer") and DevOps, which feels like a more traditional Unix-y > kind of thing? > > > > - Dan C. > > In The Beginning, We were All Programmers… > > Machines were smaller, programs simpler and we were closer to the hardware. > Literally, like the “Unix Room”, in the Attic at Bell Labs. > > Admin & Operations weren’t too onerous and “Maintenance” was done by the > people doing the kernel & systems software, at a guess. > And maybe hardware was fixed by the Vendor, or super-programmers did the > plug and play themselves. > > As sites got bigger, work became multi-person project ’teams’ and admin > problems got tricker, while ‘certain people’ did the work. > > When Unix became properly commercial - multiple vendors, big manuals, > support contracts, and a plethora of Unix variants - some Bright People > created “Unix Training” courses, in many topiocs. > > Somewhere around this time, courses and job titles for “System Admin” > appeared. > > Sadly, all this happened without any distinctions in capability & > ‘levels’, or actual problem solving testing (cf CISCO’s CCIE: 2 days of > testing, 1st day quizzes on a PC, 2nd day is by invitation. Lab session: > “fix the broken network in the allotted time”) > > SAGE - System Admin Guild, part of USENIX - put together a bunch of small > books on (Unix) System Admin Topics and tried to guide the development of > the field. > After 10 years, I was out of the loop and hadn’t seen anything positive in > the workplace. > > SRE roles & as a discipline has developed, alongside DevOps, into managing > & fault finding in large clusters of physical and virtual machines. > > Never done it myself, but it’d seem the potential for screw-ups is now > infinite and unlimited in time :) > > -- > Steve Jenkin, IT Systems and Design > 0412 786 915 (+61 412 786 915) > PO Box 38, Kippax ACT 2615, AUSTRALIA > > mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin > > [-- Attachment #2: Type: text/html, Size: 3600 bytes --]
On Wed, 9 Nov 2022, arnold@skeeve.com wrote:
> Sys admin was a thing in the mid-80s already; I worked as one at the
> Emory U Computing Center for several years, ~ 1985 - 1990. Around then
> USENIX started the LISA (Large Installation System Administratin)
> workshops. Clem can undoubtedly tell us exactly when.
It was a thing in the 70s, when I was maintaining Edition 6 on a lot of
11/40s (and a few 11/23s etc) for UNSW; it's all in AUUGN.
-- Dave
On Tue, Oct 11, 2022, at 23:59, arnold@skeeve.com wrote: > Rob Pike <robpike@gmail.com> wrote: > >> I think it is (used to be?) a common pattern. > > Clearly, the metric in both cases should have been the absolute > value of the number of lines of code changed... > > Both stories are rather sad; one hopes that today's world is > a better place. I do hope the anecdotes of twitter’s firings based on LoC end up being mistaken. But I’m also reading Machiavelli’s Discourses on Livy while catching up on TUHS, I’m not sure I believe in better places any more. And it reminds me of the Pascal quote, “I have made this longer than usual because I have not had time to make it shorter.” https://quoteinvestigator.com/2012/04/28/shorter-letter/ -- Joseph Holsten