On Thu, Sep 14, 2017 at 5:15 PM, Bakul Shah <bakul(a)bitblocks.com> wrote: No, please; not this old saw again. This guild system for software keeps coming up but I don't see how it cannot but be abused. I remember reading one of those self-help books by one of the agile types (I forget which one) and there was a vignette about one of the self-styled agile gurus (Robert C Martin, I think) coming into some room where people were undergoing "apprenticeships" an, seeing an overflowing trashcan and taking out the trash. The person telling the story went one and one about being so embarrassed because s/he was "just" a lowly intern and this "master software craftsman" had taken out the trash. I pretty much stopped reading after that. Sorry, but I cleaned enough heads and squad bays when I was in the Marines; Robert C Martin can take out his own trash, thank you very much. Also, I read one of his books once and he misspelled "Lieutenant" in the chapter about quality and attention to detail (a minor detail I was acutely aware of because I was a Lieutenant at the time). I think a better system than putting us into this rigid hierarchy system is to think of programming as somewhat analogous to writing; it requires proofreading and good editing. Some authors are better than others; practice helps a lot, writers workshops can help, seeking out advise and mentorship from more accomplished writers similarly, etc. But the guild/craftsmanship metaphor just doesn't work for me. - Dan C.

On Thu, Sep 14, 2017 at 09:24:44PM -0400, Dan Cross wrote: It's a good thing real engineers don't put themselves on these pedestals. We wouldn't have any bridges left. I'm glad NCEES is making efforts to formalize 'software engineer' as a class of PE; maybe in another hundred years or so I'll be able to believe promises that programmers make. khm

below... On Fri, Sep 15, 2017 at 1:42 AM, Steve Johnson <scj(a)yaccman.com> wrote: called 'good taste' was being show examples. Reading others code. Thinking about a problem. Think about simple, ugly CS problems and why they are hard or ugly. Your moral equiv of cleaning a few latrines. ​ ​ !!! ​ I worked as an assembly programmer supporting TSS and York/APL when I first broke in. ​ I had exactly the same experience. Were as one of my friends did not. I'll not name the person here because he's a good friend and many of you know him. But a one-time officemate of mine at start up and MIT grad​ were working on a system. And I was b*tching at him about something he had written. It was marvelous code, quite ingenious. His comment was "Well I only comment stuff I did not understand." I look at him agast. I said... "'Fred' you are on the smartest guys I have ever known. There is not much you don't understand. Comment it for us mortals please." This was a lesson I was taught very early in my career (there are usually spelling and grammar errors because of my dyslexia, but my comments are usually parsable and understandable 40 years later - even by me). forever indebted. My hope is that I am able to pay them by helping the next generation a small amount, and trying to keep their ideas and spirits alive in those new programmers. I hope the new programmers do continue to write new things and extend the art, but as I said recognise, they do their work the shoulders of some wonderful and great people starting with tools and ideas that hopeful they understand they learned from those masters. Only time will tell. ​

Mine, too. In grad school in 1976 I learned Computer Science, not the art of Software Engineering. The latter I learned from my project leaders and supervisors at my first job at DEC. -Paul W.

Well, here I go trying to be the voice of reason. Not my natural state :-) Can't see any good coming out of RMS bashing. I'm one of those who thinks that GNU/Linux is absurd; RMS had nothing to do with Linux. I can imagine that, like many of our peers, he has ego issues may feel slighted that Linus gets more media attention than he does. Maybe he would be happy if anything built with GNU tools would append a tag line equivalent to the bandwidth- wasting "sent from my iPhone" stuff on emails. All that aside, he has had a huge and positive influence with the GPL and by making many of the tools that we all depend on available for free. I remember that when I switched from SunOS to Solaris that Sun started charging for the C compiler and I was very happy to have gcc available. I would claim that the issues of maintainability, guilds or other standards for programmers, etc. is really a management issue. And it's exacerbated by what I have observed about management which is that it's not about managing any more. Since managers are theoretically responsible for programmers sensible things don't happen when the managers are not competent. Nothing says it more than the Chief Security Officer at Equifax being a music major with no relevant skills. What could possibly go wrong? Managers don't care about maintainability today, and I'm not sure that it would matter if they did. When I started working there was an expectation that one would look after one's employer's interests and the employer would look after yours. That's pretty much gone for a number of reasons. Few programmers are going to worry about maintainability when they expect to change jobs frequently. As an aside, one of the reasons why I chose to work for myself is that I got spoiled by having awesome management on my first job. I remember Hank Macdonald who I think was co-director of whatever branch of area 10 in which I was working at BTL pulling up a chair next to me at 3AM one late night/early morning and asking me how it was going. I told him great except for some problems with display flicker at which I was staring. He thought about it for about 30 seconds and said "I'll bet your delay constants are too big." He was right. I realized that he was a director because he had mastered everything that everyone under him was doing, not because he couldn't. All other managers that I've had since were Peter Principled. Oh, and under Hank I had Joe Condon as a supervisor which was another amazing experience. When I went to work at Tektronix I had an expectation that I'd spend my entire career there. Of course, shortly after I started the technical founder was replaced by an uneducated bean counter who looted the company. But, I remember a day when someone who sat near me celebrated ER (engineering release), which meant that his product went to manufacturing. A day or two later someone from manufacturing was sitting in the chair by his desk asking questions. This happened for a week or so and then that engineer's desk got moved down into manufacturing. I observed this and told myself that I would never let that happen to me. Another thing from Tek was that we supported products for ten years after ship. That made maintainability and reliability important. When someone makes a web page component that's going to be around for a few months at best it's hard to justify spending dollars on maintainability. Final thing on this thread: get used to it. As with any field, programming is a commodity item now. It's not a field populated primarily by people with PhDs. Think about the number of baristas who were hired as programmers during the .com boom. And the "everybody must learn to code in high school" movement is not about making more programmers like the ones on this list. It's about calling people programmers who don't even have the prerequisite skill of knowing how to coffee drinks. It's still a management problem because these people are being hired to do jobs for which they really don't have the skill. It's part of the hollowing out of America; we still have great sounding names for a lot of things that no longer really exist. Fortunately for people like me, companies often get in serious trouble and need someone who knows about bits and cycles and interrupts and propagation delay and so on. Good for the toy budget. I'll illustrate this with an emergency job that I did a few years ago. I was hired to get something working with a hard 3 week deadline where the person who had done the original work claimed that everything worked but it only worked for him; nobody else could get it to work. One of the things that I noticed was that the absolute maximum electrical values on one of the parts was being exceeded. Mentioned it to the CTO who looked at it and told me that she had looked at the circuit diagrams of the chips and wasn't worried. I responded with "I guess you've never worked at a company where you were responsible for warranty repairs." Turns out that she hadn't. On the software side, I replaced around 8,000 lines of undocumented code with about 300 lines including comments and whitespace that did the job. Probably less than 100 lines of actual code. I see this over and over with the "we'll just import packages and make library calls and call it programming" mentality. BTW, it's not just software. On this same project there was a problem internal to the Atmel SOC. Turns out that Atmel had just purchased a bunch of IP and glued it together on the chip and even they didn't know the particular detail that I needed. Took several months of escalation to finally get it resolved. Jon

On Sat, Sep 16, 20 ​ ​ 17 at 2:05 PM, Toby Thain <toby(a)telegraphics.com.au> wrote: ​I hear you and I agree in so many ways but .. but its hard to get someone, particularly some one young and eager to to see that value.​ This is why I like to have them work side-by-side with my my senior folks. And everyone does maintenance - everyone working on the same project. I'll carefully pick something for them to do. But some of my best and creative work, has come from some of my most junior folks - because they did not know it was hard. That said, it's my job to keep a weather eye on them. But I want the sr folks doing the maintenance work also. Just like when is a system programmer, I was required to be and system operator (the grunt task - changing tapes, paper, answering questions) at least 4 hours a week. Why? because it was incentive to make sure we had the procedures right and easy. Jon described the effect of putting everyone together at Bell Labs (and Tektronix). I admit, Jon and I were lucky. We grew up in environments were we got to working most anything, but we were next to pros (if not geniuses). But we knew them as people and colleagues and they quietly taught us. And I picked up 'good taste' by readying their code, looking at their designs; have been comment on mine. Having them show me something... Clem