
Linus Torvalds: 'I Do No Coding Any More' - dsr12
https://linux.slashdot.org/story/20/07/03/2133201/linus-torvalds-i-do-no-coding-any-more
======
dasil003
> _commit messages to me are almost as important as the code change itself_

This is high on my list of code craftsmanship points. It's very difficult to
explain to young programmers who have never worked on an old code base how
valuable this is when done well. In fact, often you hear complaints about how
a code base "is crap", but more often than not I'd wager this is just a result
of the context at the time not being known or appreciated. Frankly, all code
we write is heavily governed by context we take for granted at the time, but
is in precious short supply 1, 5, 10 years later. If you come back with a
different use case later, the original code may very well be unsuited for that
purpose. We can argue all day about good judgement and YAGNI, but at the end
of the day no one can see all ends, therefore the best we can do is document
clearly why we did what we did.

Taking the time to rebase, cleanup, and explain your changes in detail will
pay huge dividends for any long-lived project. I've literally had successors
write me a thank you note for a commit message from over a decade ago because
I take this so seriously.

~~~
mrisoli
I write detailed commit messages for every single commit I make(even though
commits would be squashed on merges), I write detailed PR descriptions that
included before/after screenshots in multiple resolutions whenever relevant.
Never once did I have any indication that someone took their time to read
descriptions or commit messages.

In my previous job, I received some feedback from my manager that some people
complained about code quality of my work, I was dumbfounded, I have no problem
with being criticised, but I at least wanted to be able to learn from it and
adapt. I went back through every single PR I did at the company and found
little to no comments and it made me feel personally attacked with very little
evidence. I then went on my peers PRs and see what I could learn from them,
most PRs included highly non-descriptive commit messages and descriptions
often only included a link to a JIRA ticket which most of the time was only
visible to their direct team members and not me. From that I took the position
of being more demanding on not just code quality during reviews but also
descriptions, I didn't manage to influence a single developer to improve
documenting efforts. That was a major reason why I eventually left the
company.

I continue to be a believer in taking your time to write good commit messages,
I have yet to collect dividends from it however.

~~~
systemvoltage
Yep, no one ever reads them and the cost to benefit ratio is extremely low.

Writing good comments is far more important. Don't explain what the code does
- that's what the code is for, explain the _why_ and the background
information in the code. Additional, explain what the code does at the
function level or at the module level - at a much higher abstraction level
basically than the line of the code.

No one ever looks at the commit messages when trying to figure out what the
code does as it convolves history and state of the repository, having to
contextually wrap your head around when and how this commit was added.

Inline documentation? Perfect.

~~~
0xEFF
I look at commit messages quite often working on a 10+ year old code base.

Bisect leads to the commit, the commit message explains why the change was
made. I take the explanation from 10+ years ago and determine if the reason
still applies today.

Or, I bisect and there's a low quality commit from 10 years ago from a person
long since departed that simply says "fixup" and I'm dead in the water.

~~~
systemvoltage
Commit messages are supposed to be short. "Fixed stuff" is totally wrong. I
usually write "Added ability to do foo with bar when baz is true."

Commit messages aren't mutually exclusive to the inline documentation.

I am making the case that inline documentation is _far_ more important than
commit messages.

~~~
xorcist
"Supposed" to?

Git was made with the intention that commit messages look like whole emails,
describing not only why the change was made but also the thought process
behind it, why this particular solution was chosen instead of some other etc.

What you describe is a decent header, although most people would probably
prefer "Add ability to" (not "Added ability to", this is a custom that goes
way back before git).

Inline documentation, or comments, is something else entirely. That is a
moving target that can describe intended usage, remote APIs, and hard to
understand passages. Commit messages describes a particular changeset, at a
fixed point in time.

Google it, and see that most people's ideas of a good commit message goes way
beyond the header ("shortlog") line.

~~~
alexchantavy
GitHub discourages making commit messages longer than a certain number of
characters; it’s interesting for me to see other opinions on that.

~~~
andersonvom
You're talking about the title of the commit message. Yes, the title is
supposed to be under 50 characters. Now add a blank line after it and you can
write all you want (line wrap at 72 chars).

If you use markdown Syntax in your commit body, github and other tools will
gladly render it correctly. You can grep for commit messages with "git log
--grep <pattern>" and it will also search commit bodies as well. It's
beautiful!

------
hirundo
This is sad, not so much because of the lack of code coming from this world
class programmer, but because coding is such fun, and Torvalds isn't having
fun programming, else he'd be doing it.

I'm closing in on forty years of coding and still get a kick out of it. I'd
still be doing it if I weren't getting paid for it. But my skills are at best,
uh, modest compared to Linus. I'd think that doing a thing so much better
would only be that much more fun. But this is a data point against that
correlation.

~~~
xfitm3
Coding is fun but for me collaborative development has stopped being fun.
People can be rude, biased, and it seems there is always someone with 50
questions or a concern who sucks the life right out of it.

~~~
tonyedgecombe
This is what I don't like about open source, it seems to encourage these sort
of behaviours.

~~~
neididipp
That’s interesting, because every office I’ve been in is like this while
working only with and building proprietary software

Tool flame wars, constant bike shedding, “that’s too abstract” premature
optimization wars (apparently a list comprehension is too abstract for some
eng, if-else all the way down!). Every Medium post by a tech somebody becomes
a religious soapbox.

I quit it all but kept my job. People complain I skip meetings and take Friday
mostly off.

But my stories are done by Weds, so really I take Thur off and just do work
log updates Fri to make it look like I was still working.

And the reason they’re done by Weds is cause I do the programming and skip
everything else.

Job life feels like being in high school anymore. It’s about social
appeasement, debating well trodden concepts at length, and exploring little
new ground.

Import toolkits and go home. Like most creative endeavors, writing code to
express my own mind is fun. Writing code to satisfy the pretense of our job
worshipping culture is mind numbing.

Edit: Oh almost forgot my “favorite”: environments where open source is
leveraged heavily. Millions of lines of imported code, at best 5% was written
internally. But somehow the business environment is that they’re engineering
thought leaders for building a “tech biz” around a traditional business model.
Smh

~~~
iamstupidsimple
> Edit: Oh almost forgot my “favorite”: environments where open source is
> leveraged heavily. Millions of lines of imported code, at best 5% was
> written internally. But somehow the business environment is that they’re
> engineering thought leaders for building a “tech biz” around a traditional
> business model. Smh

This is definitely a serious issue. Imo, unless the project is tiny, your own
codebase should be at least the majority of whatever binary is shipped,
otherwise you're adding very little value.

~~~
sgerenser
At the same time, reimplementing, say the complex video codec pipelines of
FFMPEG just because of NIH syndrome would be a massive waste of resources. I
think making use of existing solutions (open source or otherwise) when it
makes sense rather than trying to implement everything from scratch is a
hallmark of a good developer.

------
abalashov
Am I the only one who's intensely jealous of Linus? I'm 34, I've been coding
prolifically since I was 9, and by 20 I was running on fumes. That was
probably the last time it was any fun.

By now it's very hard to sustain anything remotely resembling motivation,
especially having been around long enough to have been around the block with a
few technology waves. This article, circulated on HN a while back, resonated
with me more strongly than anything I've seen here in years:

[https://frankchimero.com/blog/2018/everything-
easy/](https://frankchimero.com/blog/2018/everything-easy/)

I'm completely burned out on it all, and I don't even do more than a few hours
of coding a week many weeks. Even that takes some serious psychological effort
to get into, and some weeks I don't manage it. Honestly, I'd much rather sit
in meetings, answer e-mail, and advise others on architecture. I like talking
and teaching, and people issues interest me fairly indefatigably. It very well
might pay better, too, depending. Alas, I picked a business model that
economically rewards me for coding--that other stuff is just non-revenue
overhead.

I really hope a day comes soon when I can say, "I don't really get involved in
code much anymore," before RSI and disinterest foreclose upon the possibility
of a life worth living.

~~~
unethical_ban
Yep, same. I am supposed to be coding and writing Infrastructure as Code for
cloud programs, but I find myself wishing I could be in Architecture or
Design. I am an excellent facilitator of conversations and problem solving - I
would love to "be in the room where it happens" and make sure we as a program
have a coherent vision.

~~~
davidw3
In all seriousness -- why can't you move into architecture and design? I know
it sounds a little trite, but I've seen many times where people don't do what
they want or dream just because they haven't bothered to figure out how to get
to their goal or simply because they don't let themselves. I know the world
isn't always that simple, but I truly believe it is sometimes (plus some work
and planning).

~~~
unethical_ban
I have only been in my current role for a handful of months, and frankly, I
need to put out more work to get the kind of creds I need to command
legitimacy in a design role. Before, I spent years as a SME on a different set
of technologies - in a non-pandemic world, I may drop back to that world and
do consulting. Right now, though, I have a great team, a great manager, and
decent pay, so given all the volatility in the world I am taking what I can
get until I feel a bit safer moving around.

~~~
davidw3
That makes sense -- I guessed it more something like this. Thanks for the
response.

------
snarfy
When you are on your second rewrite, wondering why the new codebase already
has as much tech debt as the previous, it's because you don't have a Linus.
Better engineers might help, but what really matters is a better filter, one
that has final say on the commits and the release date.

~~~
nabla9
"Good programmers write good code; great programmers "borrow" good code; best
programmers remove good code." – Mike Gancarz, "The UNIX Philosophy", mutatis
mutandis.

------
noobermin
I'm an academic (post-doc) and while I am about to transition, I've never
really worked hard to get an actual tenure track position because honestly I
don't want to become a grant writer who does so little actual scientific work,
in all honesty. I might have to for my future's stability sake but I've been
loathe to. I want to do science, not academia.

~~~
Rayhem
> I want to do science, not academia.

Don't get me wrong, I come from the same background you do and have similar
wishes, but isn't this just "I want to do the things I like and not the things
I don't" (which is true for anyone anywhere in any job)? Any job is going to
have unliked things (that's why it's w.o.r.k and not f.u.n).

------
atum47
There are two (old school) people that inspire me, him and John Carmack. I
guess that's the natural course of things. Eventually you get busy to the
point you don't have time to write code anymore. So many thinks to tend...

I tried to write a little bit every day, cause it is something that gives me
joy, but I never have a project taking off like those guys, so I don't know
how much free time they have to start new projects or to program just for fun.

------
aSplash0fDerp
To think that [them] having made so much progress in the kernel by carrying a
"Lean and Mean" profile for all of those decades is astounding!

My guess is Linus is still L&M (if people didn't enjoy his lean, they wouldn't
appreciate his mean), but perhaps he's not in his element right now (and just
taking a breather).

Either way, I'm a fan (not a professional) of a lean (looking) codebase with
perhaps a new "overlay" commenting system being developed to accommodate a
wide range of proficiency (one size fits all is either too terse or too
bloated).

I am not sure of the difficulty of linking comments by line number between
revisions, but outside of having an official repository of comments, being
able to toggle through multiple perspectives from the same line/set of code
would offer valuable insight and chronicle mindset/POV in a way that a global
scratchpad could never deliver.

Writing terse or bloated comments should not be top of mind, but rather a
frictionless byproduct (expect terse, but be pleasantly surprised on occasion
by the detail and multiple perspectives).

~~~
clktmr
You know that 'git blame' exists?

~~~
aSplash0fDerp
I guess the above was more about keeping the comments terse (at best) by
default, rather than instituting an ambiguous or arbitrary formality.

The overlay thought was similar to the map concept, where you can load and
toggle data layers (comments of various verbosity or from a dynamic source)
easily.

------
AceJohnny2
> " _in the end, my job is to say no. Somebody has to be able to say no to
> people._ "

This is funny to me, because I feel like Linux got ahead over BSD specifically
because it had a more accepting policy in the beginning.

I think this says something important about project maturity and lifecycle.
BSD was already a "well established" system by the time the Linux kernel
appeared, and as such had more gatekeeping to meet their standards.

~~~
asveikau
There was also the licensing/copyright controversy. It wasn't clear that BSD
was really free until Linux was already taking off. From 1992-1994 there was a
legal cloud over BSD and probably even after that people had lingering doubts
that something like that could happen again.

[https://en.m.wikipedia.org/wiki/UNIX_System_Laboratories,_In...](https://en.m.wikipedia.org/wiki/UNIX_System_Laboratories,_Inc._v._Berkeley_Software_Design,_Inc).

~~~
toyg
Ten years later, ironically enough, Linux encountered a similar fate:
[https://en.m.wikipedia.org/wiki/SCO_Group,_Inc._v._Internati...](https://en.m.wikipedia.org/wiki/SCO_Group,_Inc._v._International_Business_Machines_Corp).
... and technically it’s not fully settled yet.

------
valuearb
Well said as usual.

And Wow, Slashdots back button disabling is the strongest I’ve ever seen, felt
like I was in the Deathstar’s tractor beam trying to get back to HN.

------
statquontrarian
> So commit messages to me are almost as important as the code change itself.

Why commit messages rather than code comments?

~~~
hasmolo
I've seen that useful commit message make it incredibly easy to see where the
code came from and is going. It also never gets 'out of sync' like code
comments tend to, as it's a comment on a static place in the code, not a
dynamic one.

~~~
pengaru
> It also never gets 'out of sync' like code comments tend to, as it's a
> comment on a static place in the code, not a dynamic one.

That's simply not true, not in a git world where rebasing to rewrite history
is standard practice.

~~~
urxvtcd
The branches you rebase most of the time are your own topic branches, where
you know what's going on. And they should be relatively short-lived.

------
buserror
After having been paid for a few months to do upstreaming, I know very well
that nobody close to the linux kernels is doing any 'coding' anymore.

it's seems to be more of an excercise into pleasing the priesthood to their,
current, very important way/shape/form "canon" of what IS right at the moment
than actually get any 'coding' done. And given the time it takes, i wonder if
ANY of the top level maintainers actually program anymore, and are just "patch
gateways".

And yes, there is a massive caste of priesthood of the patch series,
discussing and making decisions on stuff they often borderline understand, and
on criteria that are in fact quite far from the "it make sense" line of
thinking.

I know, I've spend months re-writing drivers which were perfectly fine, neat,
written with the upmost care of "upstreaming" as our team could figure out, to
have to rewrite them completely and entirelly in the whim of someone halfway
across the world, who didn't couldn't possibly have known what we were working
on (as we were the designers, mostly) but who decided that version of the
"canon" was not matching ours.

It's a stupid waste of time, money, brain cells, and the result is actually
_lesser_ than the original code.

 _For no good reason_ as the canon will change next year anyway.

For many years, I thought that the Linux kernel ecosystem was pretty much
self-sufficient, but it's grown way too big, to the level of MASSIVE bloatware
level nowadays. Massive corps have dozens of guys working on it, and many of
them are also 'maintainers' \-- full time; threading patches, some of them
with conflicts of interest, or lack of understanding, or both, or just having
been left behind a while back while still being innundated with patches.

I think it's doomed, in that form anyway.

------
staycoolboy
Please next time link to the source and not to another discussion forum:

[https://www.youtube.com/watch?v=H8Gd9t7FQqI](https://www.youtube.com/watch?v=H8Gd9t7FQqI)

~~~
mkl
Many of us don't have time (or inclination) to watch a 25 minute video just
for a few key sentences. Yes, I'm sure there are other interesting things in
the video too, but that bit is what the submitter found interesting enough to
submit, and what the upvoters found interesting enough to upvote, and the link
to the source is on the first line.

~~~
staycoolboy
There is a very well-known function in YouTube that allows you to link to the
exact time of interest. For example, simply suffix the query-string
"?t=10m32s" to the URL to skip to 10:32.

Odd that there doesn't seem to be enough time to read beyond 140 characters,
yet there's plenty of time to type up lengthy opinions...

------
gentleman11
Website will not let me edit with the back button on safari, had to close the
tab to escape. Why do so many sites do that?

~~~
ivanstojic
I can confirm: if you try to back out, you are presented with a blue bar at
the top saying something like "before you leave..."

[https://imgur.com/a/93wjGED](https://imgur.com/a/93wjGED)

~~~
thedanbob
And when I click on that link I immediately get a popover ad for the Imgur
app. The mobile web is such a mess.

~~~
amedvednikov
Firefox + UB origin

------
worik
" '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, "

Yes he does so write code....

------
mD5pPxMcS6fVWKE
I don't know about Linux Kernel, but in 99% of projects, 99% of commit
messages are write-only.

~~~
iso8859-1
It's self-reinforcing. People won't start reading them unless they know that
they may contain usable information. Given that the process of making a clean
history can make you understand the project better even if you are alone,
saying they are write-only is misleading.

------
dependenttypes
Just like Stallman except 12 years later.

------
sunstone
So it was git then the mic drop.

------
lgats
Wasn’t expecting slashdot to hijack my browser back button...

~~~
dang
" _Please don 't complain about website formatting, back-button breakage, and
similar annoyances. They're too common to be interesting. Exception: when the
author is present. Then friendly feedback might be helpful._"

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

(added recently:
[https://news.ycombinator.com/item?id=23648867](https://news.ycombinator.com/item?id=23648867))

------
jpgleeson
Tech deed I

