6 ms·

One of the biggest issues I see with this mentality going forward is a) lack of mentors for younger generations; b) repeating the same mistakes our generation

by Annatar 10y ago

One of the biggest issues I see with this mentality going forward is a) lack of mentors for younger generations; b) repeating the same mistakes our generation made. a) is bad. b) is worse. a) and b) combined lead to fads in which one burns tremendous amounts of time figuring out what it is and how it works, only to become obsolete by the time one masters it. Old people like me pick their technology very carefully, because they've already burned exorbitant amounts of time mastering all kinds of technology fads during their lifetime, only to find that most of them don't fix, or make the problems even worse. In plain English: we reject 99% of the fads out there because we can tell from experience what will work and what won't, and what the challenges and pathologies will be if we deploy on that particular fad. We don't reject fads a priori just because it is something new, but on the very simple metric: could it be as bulletproof as possible, so I don't get a call at two o' clock in the morning? Yes: continue research. Attempt breakage. Re-evaluate based on the results of breakage. No: reject. Where we, the old people failed: I take on apprentices. Most of my peers do not. That is why we end up with, for example, https://www.youtube.com/watch?v=Ms3EifxZopg https://www.youtube.com/watch?v=Ms3EifxZopg ...where a few lines of AWK code would do. And my peers are nowadays almost embarrassed to even mention such robust technology, instead of actively teaching and promoting it: http://dtrace.org/blogs/ahl/2016/08/02/i-love-go-i-hate-go/#comment-56586 http://dtrace.org/blogs/ahl/2016/08/02/i-love-go-i-hate-go/#... this is where we failed: to teach. To take on apprentices. This is why humanity keeps repeating the same mistakes over and over again, and nowhere does that appear to be so acute as in information technology. We can do better. Take on apprentices, and have them commit to teaching others once they themselves become masters. I don't mean casual mentorship; I mean a formal apprenticeship. Yes, that means you Bryan, and you Adam. And you Jerry. And you Max. And you Robert. You know who you are.

throwanem 10y ago
> I don't mean casual mentorship; I mean a formal apprenticeship. This is an intriguing idea. But our culture doesn't offer much in the way of a framework for it. Will you expand upon what you mean by it, and how you've made it work for you and others?
- Annatar 10y ago
  I arrange my work spaces such that there is always a chair and ample desk room for anyone to bring their laptop over, plop themselves next to me, and start talking to me about the problem they want to solve. I've also planned an apprenticeship program, where I had pupils formally assigned to me to mentor. I'd start them while they were still at the university doing their bachelors or masters. Usually they are new to UNIX, so the first thing I have them do is read the entire manual page for tcsh and zsh. Then move on to teaching them how to shell script, then how to program in AWK. Once they're past that, I move on to teaching them C. For shell programming, I tutor them one on one, covering looping, input, syntax, interface design with getopts). I teach them why having ".sh", ".pl", ".py" or any other extension on an executable is a bad idea on UNIX, and there I cover what it actually means for a file to be executable on UNIX. I teach them about the runtime linker. I teach them about compiling and linking, about how functions map to symbols in an ELF executable. I teach them about ELF. About process spawning, context switching, high interrupt counts, 32- versus 64-bit code, instruction encoding. About what being a zombie process actually means, how they become such, how they get adopted by init(1M). Eventually they hit deeper and deeper problems, so I inevitably end up teaching debugging and OS programming. For teaching them how to program in AWK, I have them go through all the chapters and all the exercises in the Gray AWK book by Aho, Weinberger, and Kernighan. Then I help them with the actual real world problems they are attempting to solve with AWK, by showing them how to do it and explaining how it works. This is usually the time when I cover all the formal algorithms they're supposed to be learning at the university but aren't: stacks, queues, linked lists, doubly linked lists, sorting, pointers and pointer arithmetic, topological sorting. For teaching them C, I have them go through the ANSI C programming language book, 2nd edition, and then cover anything that they don't understand with examples. Then I have them follow that up with the Advanced C programming by Example book. Then I cover dbx(1), gdb(1), and mdb(1) with them (what I know about mdb(1) anyway, and I touch upon kdb(1)). Throughout all of this, I cover cpp(1), make(1S), gmake(1), and m4, as well as lex(1) and yacc(1). If I am forced by circumstance to teach them on GNU/Linux, I constantly and consistently pound it into my students' heads never to use GNU constructs or GNU specific features; by the time I'm done, they are able to write clean, portable programs in shell which work on any UNIX-like platform without any modification, and ditto for C programs. I purposely teach them to stay the hell away from bash(1), and use either the original Bourne or Korn shells to program. If they are apprenticed to me for a long enough time, I will also cover complete UNIX system, network, and security administration (up to and including locking down the system and configuring the firewall and IPsec); by the time I cover the material, any of my students should be able to take on and pass a Solaris system administration exams and get certified. And with that knowledge and some shallow preparation, they can then easily ace the redhat Enterprise Linux certification exams. Next, I cover SQL and database administration. Usually the places I work / consult at have Oracle, so I teach them how to administer an Oracle database, show them where the documentation can be found, and generally prepare them to take the Oracle database administration exam. If we have it, I will also cover PostgreSQL, and I cover SQLite. Finally, I show them all the bugs and all the issues in MySQL with a warning to stay the hell away from it and never use it for projects. By the time I'm done with them, they are comfortable taking on a database administrator's job or programming applications in PL/SQL inside of the Oracle database. And where there is Oracle, sooner or later, there is Automatic Storage Manager (ASM), so covering that inevitably leads to covering storage area network administration on the OS side, which ties into their UNIX administration I taught them earlier. By the time I'm done with them, they are able to comfortably program applications in shell, AWK, or C, in addition to being able to administer UNIX systems and relational databases. From that point on, they have enough knowledge to master pretty much anything in computer science.

by Annatar 10y ago

throwanem 10y ago

> I don't mean casual mentorship; I mean a formal apprenticeship. This is an intriguing idea. But our culture doesn't offer much in the way of a framework for it. Will you expand upon what you mean by it, and how you've made it work for you and others?

Annatar 10y ago
I arrange my work spaces such that there is always a chair and ample desk room for anyone to bring their laptop over, plop themselves next to me, and start talking to me about the problem they want to solve. I've also planned an apprenticeship program, where I had pupils formally assigned to me to mentor. I'd start them while they were still at the university doing their bachelors or masters. Usually they are new to UNIX, so the first thing I have them do is read the entire manual page for tcsh and zsh. Then move on to teaching them how to shell script, then how to program in AWK. Once they're past that, I move on to teaching them C. For shell programming, I tutor them one on one, covering looping, input, syntax, interface design with getopts). I teach them why having ".sh", ".pl", ".py" or any other extension on an executable is a bad idea on UNIX, and there I cover what it actually means for a file to be executable on UNIX. I teach them about the runtime linker. I teach them about compiling and linking, about how functions map to symbols in an ELF executable. I teach them about ELF. About process spawning, context switching, high interrupt counts, 32- versus 64-bit code, instruction encoding. About what being a zombie process actually means, how they become such, how they get adopted by init(1M). Eventually they hit deeper and deeper problems, so I inevitably end up teaching debugging and OS programming. For teaching them how to program in AWK, I have them go through all the chapters and all the exercises in the Gray AWK book by Aho, Weinberger, and Kernighan. Then I help them with the actual real world problems they are attempting to solve with AWK, by showing them how to do it and explaining how it works. This is usually the time when I cover all the formal algorithms they're supposed to be learning at the university but aren't: stacks, queues, linked lists, doubly linked lists, sorting, pointers and pointer arithmetic, topological sorting. For teaching them C, I have them go through the ANSI C programming language book, 2nd edition, and then cover anything that they don't understand with examples. Then I have them follow that up with the Advanced C programming by Example book. Then I cover dbx(1), gdb(1), and mdb(1) with them (what I know about mdb(1) anyway, and I touch upon kdb(1)). Throughout all of this, I cover cpp(1), make(1S), gmake(1), and m4, as well as lex(1) and yacc(1). If I am forced by circumstance to teach them on GNU/Linux, I constantly and consistently pound it into my students' heads never to use GNU constructs or GNU specific features; by the time I'm done, they are able to write clean, portable programs in shell which work on any UNIX-like platform without any modification, and ditto for C programs. I purposely teach them to stay the hell away from bash(1), and use either the original Bourne or Korn shells to program. If they are apprenticed to me for a long enough time, I will also cover complete UNIX system, network, and security administration (up to and including locking down the system and configuring the firewall and IPsec); by the time I cover the material, any of my students should be able to take on and pass a Solaris system administration exams and get certified. And with that knowledge and some shallow preparation, they can then easily ace the redhat Enterprise Linux certification exams. Next, I cover SQL and database administration. Usually the places I work / consult at have Oracle, so I teach them how to administer an Oracle database, show them where the documentation can be found, and generally prepare them to take the Oracle database administration exam. If we have it, I will also cover PostgreSQL, and I cover SQLite. Finally, I show them all the bugs and all the issues in MySQL with a warning to stay the hell away from it and never use it for projects. By the time I'm done with them, they are comfortable taking on a database administrator's job or programming applications in PL/SQL inside of the Oracle database. And where there is Oracle, sooner or later, there is Automatic Storage Manager (ASM), so covering that inevitably leads to covering storage area network administration on the OS side, which ties into their UNIX administration I taught them earlier. By the time I'm done with them, they are able to comfortably program applications in shell, AWK, or C, in addition to being able to administer UNIX systems and relational databases. From that point on, they have enough knowledge to master pretty much anything in computer science.