Linus Torvalds: 'I Do No Coding Any More' (youtube.com) 63
The Linux Foundation recently uploaded its video from the Open Source Summit and Embedded Linux Conference: Europe. And there was a poignant moment when Linus Torvalds did his traditional keynote conversation with Dirk Hohndel, VMware's vice president and chief open source officer.
Honndel had asked Linus — his hair now uncharacteristically long — what he spends his time on as a kernel maintainer. What's his workflow? "What do you do?"
Linus Torvalds: Um, I read email. [Hohndel laughs] I read email, I write email, I do no coding at all any more.
Most of the code I write, I actually write inside my mail reader. So somebody sends me a patch, or more commonly they send me a pull request or there's a discussion about the next pull request, and there's something I react to and say, 'No, this is fine, but...' And I send out pseudocode, or — I'm so used to sending out patches that I sometimes edit patches and send out the patch without having ever compiled it, ever tested it, because I literally wrote it in the mail reader, and saying 'I think this is how it should be done.' But this is what I do. I'm not a programmer any more.
I read a lot more email than I write, because what my job really is — in the end, my job is to say no. Somebody has to be able to say no to people. Because other developers know that if they do something bad, I will say no. They hopefully, in turn, are more careful. But in order to be able to say no, I have to know the background. Because otherwise I can't do my job. So I spend all my time, basically, reading email about what people are working on... It is an interesting job, but you do end up spending most of your time reading email.
On the developer side, what I hope people are doing is trying to make, not just good code, but these days we've been very good about having explanations for the code. So commit messages to me are almost as important as the code change itself. Sometimes the code change is so obvious that no message is really required, but that is very very rare. And so one of the things I hope developers are thinking about, the people who are actually writing code, is not just the code itself, but explaining why the code does something, and why some change was needed. Because that then in turn helps the managerial side of the equation, where if you can explain your code to me, I will trust the code...
A lot of open source in general is about communication. And part of it is the commit messages, part of it is just the email going back and forth. Communicating what you're trying to do or communicating why something doesn't work for you is really important.
Honndel had asked Linus — his hair now uncharacteristically long — what he spends his time on as a kernel maintainer. What's his workflow? "What do you do?"
Linus Torvalds: Um, I read email. [Hohndel laughs] I read email, I write email, I do no coding at all any more.
Most of the code I write, I actually write inside my mail reader. So somebody sends me a patch, or more commonly they send me a pull request or there's a discussion about the next pull request, and there's something I react to and say, 'No, this is fine, but...' And I send out pseudocode, or — I'm so used to sending out patches that I sometimes edit patches and send out the patch without having ever compiled it, ever tested it, because I literally wrote it in the mail reader, and saying 'I think this is how it should be done.' But this is what I do. I'm not a programmer any more.
I read a lot more email than I write, because what my job really is — in the end, my job is to say no. Somebody has to be able to say no to people. Because other developers know that if they do something bad, I will say no. They hopefully, in turn, are more careful. But in order to be able to say no, I have to know the background. Because otherwise I can't do my job. So I spend all my time, basically, reading email about what people are working on... It is an interesting job, but you do end up spending most of your time reading email.
On the developer side, what I hope people are doing is trying to make, not just good code, but these days we've been very good about having explanations for the code. So commit messages to me are almost as important as the code change itself. Sometimes the code change is so obvious that no message is really required, but that is very very rare. And so one of the things I hope developers are thinking about, the people who are actually writing code, is not just the code itself, but explaining why the code does something, and why some change was needed. Because that then in turn helps the managerial side of the equation, where if you can explain your code to me, I will trust the code...
A lot of open source in general is about communication. And part of it is the commit messages, part of it is just the email going back and forth. Communicating what you're trying to do or communicating why something doesn't work for you is really important.
Comes with the job (Score:5, Insightful)
My experience is that the higher you go the less coding you get to do. The people that report to you don't like it if you try to contribute that way. And of course the customer and investor meetings always take precedence. And the people that report to you love it when you do that because then they don't have to.
Looks like Linus is in the same boat.
Re:Comes with the job (Score:5, Insightful)
At some point, it becomes more important to program the programmers.
Re: (Score:1)
Re: (Score:2)
I'm not yet at that point. I do try to guide programmers, but quite often, I find myself thinking: can I just please do this myself?
Re:Comes with the job (Score:5, Insightful)
Yep, all management ends up being a pyramid of some kind. With 24 hours in a day, most questions have to be delegated.
The smart companies also have a short circuit protocol though to cut out the day-to-day delegation/filter so that urgent items can skip levels if they are urgent/dangerous/being ignored.
This is good for customer service too. I have the CEO's email for a company (and he actually reads it) I work with. If something is crashing I email tech support. If I discover a flaw that can cost them millions: I email tech support and CC the CEO.
Organizations really need to implement less black and white org structures, everything shouldn't be flat or deep... it should be deep with short cuts and express lanes.
I was working with a huge corporation recently and we had a question. The project was a high urgency (pandemic related) project that had an emergency deadline. Our contact in the company CC'ed 3 levels of decision makers at once. The bottom level decision maker was furious that it didn't go through them exclusively and wrote a letter complaining/apologizing about our contact's behavior, but the 2 higher levels above shut them down because they appreciated that given the urgency and priority of the project they were kept directly in the loop about time sensitive decisions instead of the normal filtered game of telephone.
It's very rare that one line of code is exceptional and determines the course of an organization. As a leader you should be focused on strategy and direction.
Re: (Score:1)
Doing the right thing is not always good for your career. In this case it seemed to work out, but it will not alway
Re: Comes with the job (Score:4, Insightful)
This employee's job is to facilitate external vendors with internal teams. They've been in the business for decades and with the company for a long time. This was the first time the low level decision maker had even worked with external vendors so while our contact probably had lower seniority... their boss was like "anything they think is necessary is necessary."
That's what orgs have to give their employees the right to do. Because yeah if you are just rolling the dice that you are empowered to act when you see fit then you'll eventually be wrong and get fired.
You need express immunity or trust that you have immunity that a good faith action can't be used against you.
This person that skipped chain of command is also in a separate division. So while they work on behalf of a group, that group's leadership doesn't do performance evaluations. So if an org wants honest feedback, it helps to have employees which are embedded without being answerable to the team.
E.g. it's a good idea to put security developers and auditors in a separate org structure but working within a feature team. Then if a security expert says "no we can't do that." The product manager can't just retaliate and brow beat the security team into submission to meet deadlines. The PM would have to go laterally to a security manager and complain about the embeded employee and say that they're unreasonable. And when the security manager who gets no bonuses for on time deliveries reviews the complaint they can decide on security merits.
I'm a form believer in hierarchies since I believe they always emerge regardless of official policy. So good governance is mitigating the downsides of hierarchies.
Re: (Score:2)
This is 30% of the reason I prefer startups instead of large companies. A startup with any hope of succeeding will be focused on results, not office politics.
Re:Comes with the job (Score:4, Interesting)
The more senior I get, the less HDL (digital logic design) I write and the more code (C, python) I write. I'll be proving an algorithm works and plotting some graphs and explaining things so others can write the HDL. I'll be doing some dark, dank statistics on data sets, for which a bit of code goes a long way. All people get to see is the answer and the explanation and the recommendation in a meeting.
Code is the oil that lubricates my job, which is to have good ideas and show people how to implement them.
Sometimes I'll throw the algorithms into one of my command line tools and throw them on github so the three people that care can look at it.
Re: (Score:2)
It's also a matter of scalability. Regardless of how good of a programmer you may be, you're never going to outperform the teams you're supposed to be managing, and it's much more effective to simply guide things in the right direction and try to free up obstacles such that your programmers can do their work. I spent over 15 years as a kernel programmer / maintainer, but when I started managing increasingly larger R&D teams and departments, my own opportunities for code-level contributions were few and
Re: (Score:2)
Re: (Score:2)
Looks like Linus is in the same boat.
Not really. Due the technical nature of the Linux community, it's evolved into a meritocracy or geniocracy. Most corporations are plutocracies, there's a big difference. Meritocracy is more successful due to the greater difficulty in corrupting technical people. Financial institutions, by definition, lead to economic excess, corruption and class division, which eventually tears such hierarchies, and the systems built upon them, apart.
If only countries, and society, were as well maintained as the Linux kerne
Re: Comes with the job (Score:1)
Itâ(TM)s the same in any field. I do much less server, infrastructure, and support operations as a director/vp. Now my time is spent commanding my minions what I normally do. The main difference is instead of me deciding to do the work and doing it, my employees are an extension of my own hands
Linus does a LOT of coding. (Score:5, Informative)
Linus quote: "Most of the code I write, I actually write inside my mail reader."
He does a LOT of coding. He is a top-level programmer, advising others how to improve their coding!!!
Re:Linus does a LOT of coding. (Score:4, Insightful)
Yes and one day some tool or utility will piss him off and he'll write a replacement/better implementation
Ha! (Score:2)
I don't know Linus personally, but that's what I understand from the news.
He is shockingly good at coding. How many of us have an operating system named after us? Ha!
Add: "...used outside of their basement" (Score:2)
How many of us have an operating system named after us?
This is /. : Probably half of the geeks here to have written a couple thereof.
The actual question is: How many of these systems got used outside of their owner's basement ?
Re: (Score:2)
>This is /. : Probably half of the geeks here to have written a couple thereof.
Those days are long gone, few of the old schools geeks here now.
Re: (Score:2)
Re: (Score:2)
You just need to define a true geek as someone who has attempted to write an operating system.
Re: (Score:2)
Actual Linus quote: "I do no coding at all any more."
The road towards people/project management (Score:4, Interesting)
Either you manage a project, or a group of people as their manager (2 sides of the same thing).
A few old nerds manage to escape this, specially in deeply specialized areas that have not many changes across time (e.g. low level system programming), but for most you are simply too old and outdated in the latest fad, to compete with the kids fresh out of college.And employers eventually let you know that you are "overqualified" or flat out too expensive for a code monkey.
Linus is in an area where he could have remained a respected coding guru, were him not THE God Emperor of Linux, and his all important oversight wasn't required all the time for things taking him away from typing code.
Re: (Score:2)
Re:The road towards people/project management (Score:4, Insightful)
Some of it is burnout. After seeing say UI frameworks reinvented for 10th time, You start thinking, "Oh shit, more change for the sake of change", and then you have to learn your way around all its new bugs and idiosyncrasies.
Re: The road towards people/project management (Score:5, Insightful)
This. Also you just burn out in enthusiasm in general.
New out of college: "OMG we are reinventing how people order pizza this going to be huge! I'm going to work 80 hours for the opportunity to write code that millions of Dominos customers use every week including my Mom! I can't believe I'm even being paid to do this! I'm happy to sleep in my car!"
Old employee: "It's a fucking pizza configurator. I'm not working the weekend for yet another pizza configurator. Also, I need a raise because I need a second bedroom with another kid on the way."
Re: The road towards people/project management (Score:2)
That's why you move into a field that doesnt change much. I've done unix systems programming since the 90s and apart from keeping up to date with C++ my skills from the 90s are just as relevant now as they were then as the posix API barely changes. Plus I dont get bored with it - it's creating the end result I get buzz from, not the tools I use to achieve it. Why some people get so excited about programming languages beats me. Would a carpenter get excited about a new hammer?
Re: (Score:1)
Re: (Score:2)
Similar story for me, embedded programming.
I learned C & make 30 years ago, it's still important in my work. The main change I have to keep abreast with is the version control system of the day.
Re: The road towards people/project management (Score:2)
Uh, you think those new college grads actually know anything useful?
I hire them now so I have someone who can do something useful in 2-3 years.
All the flavor of the week crap coming out of schools today is pretty useless.
All you old guys, don't worry, smart companies want you.
Re: (Score:2)
Re: (Score:1)
It's not a dichotomy between grads and old coders. The preferred range is about 7 to 20 years of experience. Whether that's "fair" or not is another matter.
Re:The road towards people/project management (Score:5, Insightful)
the sad truth is that one day you will be too old for grunt programmer work.
Too senior, not too old. You are never too old to code.
My father-in-law is 89. He is a great C++ coder. Last month, he taught his grandson how to do AVR assembly programming on an Arduino.
Yesterday, I asked him what he was working on. He said he was learning Python's Kera framework to set up a TensorFlow pipeline. I asked him why. His answer: "Just curious how it works."
Re: (Score:3)
I am one of those old engineers and have had both programming and manager roles throughout my career. Right now I am programming with a heavy DevOps leaning. In my current role I had to re-invent and refresh my 10 year old Java , test automation, CI/CD processes and my IT background to make the current role a success. As a result, although I may not be the fastest coder, my depth of experience allowed me to help lead the team from nothing to viable cloud service product in less than a year in an organizat
Re: (Score:3)
Last month, he taught his grandson how to do AVR assembly programming on an Arduino.
Or he could teach his grandson real skills like how to get Node.JS running on Arudino running on AVR with so much abstraction that it takes 12000 cycles just to toggle a digital output. :-)
A practice ... (Score:5, Funny)
Poettering, are you listening?
Re:A practice ... (Score:5, Insightful)
Has he ever?
Ah, finally! I can say this (Score:2)
Linus hates videoconferences (Score:4, Informative)
The very first thing Linus said was "I do not like doing videoconferences, I have not done a single videoconference so far during the last four months, and the fact that it seems to be working at all, frankly, surprises me!"
Much respect for Linus Torvalds (Score:5, Informative)
Consider how Linus Torvalds has had to evolve:
He developed a trivial minimum-viable-product kernel, written by just him. Starting point: 100% developer.
He kept developing it but started getting patches, so he started doing some development and some merging. Less than 100% developer, part manager.
He transitioned to a pretty pure management role. And the Linux kernel kept getting more important, and more and more people worked on it, and he developed his system of "lieutenants" to whom he delegated increasing amounts of authority. Now he was not only managing code but also managing people.
These days he's about 99% manager and only about 1% developer. But he's making the big and important decisions and managing the project.
And I'm not aware of any big issue on which he was really wrong. Famously, in 1992, professor Andrew Tanenbaum commented that Linux was flawed because it wasn't using a microkernel design; he said that if Linus Torvalds was one of his students, he "would not get a high grade for such a design :-)" [oreilly.com]. Linus dissented, saying [ycombinator.com] that a monokernel design is simpler in important ways than a microkernel. Now, here we are three decades later, and Linux is the most important OS kernel in the world; there isn't any serious competition to Linux from any microkernel designs. So IMHO Linux was right about that (really important) issue.
Note: Arguably, Windows is a microkernel design, but not as pure as it was in the first release as Windows NT; Microsoft moved video drivers into the kernel [blackhat.com] for performance. And while Windows rules the desktop, it has no chance to displace Linux in embedded, mobile, cloud, or supercomputing markets. Mac OS X is also not a pure microkernel (according to this [ycombinator.com] anyway).
Linus has often said that his job these days is mainly "to say no" and I agree with him that this is actually an important job. To tell someone "that patch is unacceptable, fix X Y and Z in it and resubmit it"... to say "this approach is bad, I won't accept any code using this approach"... it's only bad to say "no" if you don't have a reason or your reason is wrong. Linus gets a lot of credit for the success of Linux because he says "no" for the right reasons.
And... when there wasn't a revision control system that did what he wanted, he cranked out git really fast [linuxjournal.com]:
So he not only wrote the world's most important OS kernel, he also wrote the most important version control system! And he cheerfully delegated all additional work on Git to the Git community, and returned to give his full focus to Linux!
If I ever meet Linus I'll buy him a Guiness [catb.org].
Excellent comments. (Score:2)
The Linux user interface has never been good enough. -- My observation.
Re: (Score:2)
Just because something is widely used it does not mean it is actually good. Prominent examples are x86 CPU's or Windows 3.1.
Especially when it's something working in the background with the actually useful things building on it.
Who cares how limited and cumbersome the assemble l
Usefullness (Score:3)
Just because something is widely used it does not mean it is actually good.
Or maybe "good" sometime doesn't refere to intrinsic properties but to other advantage.
Who cares how limited and cumbersome the assemble language and address models of your CPU are if you only compile to it from a high level language?
The compiler writers (and the people writing extremely optimized low-level code) do care. The architecture might be ugly, but they have accumulated tons of experience with that architecture, so the architecture dominates the field. The people shipping binary packages also care: the opcode make no-sense, but that what the compiler opcode they have at hand are written in.
Who cares how dumb your operating system is if you only use to launch your office applications?
Part of the reason Linux got it success is because it
Re: (Score:2)
Just because something is widely used it does not mean it is actually good. Prominent examples are x86 CPU's or Windows 3.1.
Intel drank that kool-aid and decided to make a CPU architecture where practically everything was exposed to the compiler, it's called IA-64 aka Itanium. They soon found out that a design grounded in reality beats ivory tower theory. ARM is also CISC with micro-ops these days, some instruction complexity is best left hidden. Forcing the compiler to deliver micro-instructions only hurts performance.
Re: (Score:3)
Just because something is widely used it does not mean it is actually good.
I think your implication is that Linux is not actually good but people use it anyway.
Our context here is that in the early 90's the experts (such as university professor Andrew Tanenbaum) were saying that microkernel architecture is a better idea: it would be easier and faster to develop, the resulting systems would be more stable and secure. With all those advantages for microkernels, where is the microkernel competitor to Linux?
Mi
Re: (Score:1)
And I'm not aware of any big issue on which he was really wrong. Famously, in 1992, professor Andrew Tanenbaum commented that Linux was flawed because it wasn't using a microkernel design; he said that if Linus Torvalds was one of his students, he "would not get a high grade for such a design :-)" [oreilly.com]. Linus dissented, saying [ycombinator.com] that a monokernel design is simpler in important ways than a microkernel. Now, here we are three decades later, and Linux is the most important OS kernel in the world; there isn't any serious competition to Linux from any microkernel designs.
Monokernels "won" because conventional architectures never introduced usable protection mechanisms. It isn't just microkernels which suffer, but all applications which do IPC, which is horrifically slow. This has resulted in massive amounts of kernel and application code sharing an address space with no real isolation, where a single buggy driver or library can have catastrophic results. The security record speaks for itself, and we all lost.
Re: (Score:1)
Microkernels are a better idea and will take over from monokernels just as soon as "conventional architectures" introduce "usable protection mechansims"!
Also, communism is a better idea, and all the death and misery that have accompanied it were just because it was never done right.
Churchill said "...democracy is the worst form of government except all those other forms that have been tried from time to time." Monokernels are the worst form of kernels except that all the others are even worse.
This has resu
He says comments are good. (Score:2)
Who woulda thunk it?
So he does coding???? (Score:1)
Saying no is what made Apple great (Score:2)
I would argue that the loss of Steve Jobs was actually the loss of the guy that said no most effectively. Apple claims they still have that culture but they absolutely don't. Apple still does good work, but I bet if they hired Linus, they could go back to the height of their previous accomplishments. (At least software-wise; I have no idea what his design sense is like.)
Hopefully the other thing he's doing is teaching other people to say no as well. I can't imagine Linux without his guidance, but it'll hap
Re: (Score:1)
Jobs was a really good marketeer. Someone created a really small hard disk. He said - what can I do with that? How about a music player! Then he'd get the propeller heads together and make it into a product. He famously went into Xerox-PARC and stole the GUI. How can I make this into something people want? He'd figure it out. Hell of an imagination. One in a billion. Also one in a billion asshole. He may have said no, he also said - YES! Let's go!
Now apple has no direction. It'll die a horrible death unless
Re: (Score:2)
Yeah, but he didn't just ask the propeller-heads to make a product, he wasn't satisfied with the things they brought to him. He kept saying 'no' until they brought him something GOOD. That's the difference. Ideas are cheap and easy to come by. Knowing when a product is actually ready is much harder.
That thing about Xerox-PARC is a bit of a myth, though. https://www.mac-history.net/co... [mac-history.net]
In any case, they were hamstrung by a corporate culture that didn't care about anything that wasn't directly related to pho
Re: (Score:1)
...In any case, they were hamstrung by a corporate culture that didn't care about anything that wasn't directly related to photocopiers. They were happy to fund research, but it's not like Xerox was on the cusp of releasing their own computer; without Apple (and Microsoft), that product would have died in the dark.
Apple won't die; they've got enough money to wait until the next really inspirational designer comes along. They can make solid, high quality products that do an excellent job for many years. Plenty of companies have survived for decades merely being good at what they do, rather than creating whole new markets. I think we should let Apple be a company like that for a while.
Sounds like you don't know your history. Xerox released computers. When I started at the University of Maryland in 1983 they had a gui based machine that was well used in 1983 - http://www.righto.com/2016/06/... [righto.com] . Here is the Xerox 9700 https://www.news.xerox.com/new... [xerox.com] . I used to run a pair of those machines. It had a pdp 11/84 and would print 2 pages/sec at 300 DPI including form merging. So these guys were the very spear tip of computer science in the day. We even had hyper-links from documents to othe
Re: (Score:2)
No, Jobs did not steal it. Apple licensed it from Xeros, actually - Apple gave Xerox a bunch of shares in Apple to license the GUI concept (Apple never got any code
He deserves to be able to kick back. (Score:3)
IMO, if he decided to spend the rest of his life island hopping in the Caribbean on a yacht, he deserves it.
There are very few people that make a societal contribution. While his might not measure to the level of Madison, or Hamilton, he certainly has been as equally liberating for giving people freedom from the oppression of the previous licensing models. Everything from android smartphones and tablets, to your consumer grade routers, modems, and wifi access points are all financially feasible due to the open nature of the linux kernel.
I would give RMS as much credit, its just he came off a little less likeable and a bit more tinfoil-hat when he lectured. In hindsight he was completely justified, his delivery was just off. However, if both decided its time to kick back into retirement and let others take the reigns, they have earned it.