Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linus Torvalds: 'I Do No Coding Any More'

linux.slashdot.org

Post reply on HN
Print view View original

131–140 of 246 posts

Re: Linus Torvalds: 'I Do No Coding Any More'

#131

Post by asveikau »

AceJohnny2 wrote: post #93

> " 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…

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....

Re: Linus Torvalds: 'I Do No Coding Any More'

#132

Post by systemvoltage »

jkaplowitz wrote: post #127
systemvoltage wrote: post #111

Earlier quoted context omitted.

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.

There's no general rule about what length a commit message should be, except that often people try to keep the first paragraph as a single short line for better readability in systems like GitHub and the git CLI. When additional detail is helpful about the motivation for or gotchas related to a commit, starting a new paragraph and elaborating there is totally fine. But I agree with you, they aren't mutually exclusive…

Agree with all you've said. Commit messages do serve a slightly different purpose of historical context.

Re: Linus Torvalds: 'I Do No Coding Any More'

#133

Post by dang »

lgats wrote: post #33

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

"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

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

Re: Linus Torvalds: 'I Do No Coding Any More'

#134

Post by dcow »

mrisoli wrote: post #92
dasil003 wrote: post #26

> 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…

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 compla…

Please don’t be discouraged and keep on writing quality code. Most managers at big companies are soft engineers who weren't really into the engineering aspects of the job. They’re more interested in team cohesion and deliverables. In my experience the first things to go when there is a date looming over the team’s head is code quality (code review becomes code approve) and then documentation, followed by tests. It’s really up to the engineers at the end of the day to maintain the quality of their codebase. Managers don't care unless it’s so bad that they can’t onboard new people or things are constantly on fire, but I’m pretty you can onboard a new grad into almost any mess and they’ll eventually figure out how to poke the right things, and fires don’t reflect poorly on the manager.. they just happen as if acts of nature breed unstable rushed code.. so :shrug:. Keep in mind a downside of working at a bigger company is the overarching philosophy that most code will be rewritten in 2 years. Add in that most rank and file employees are just ladder climbing anyway and, well, I think you get a pretty realistic picture. The linux kernel is good on merit and demands good engineering. The exploratory product idea that probably wont be around 6 months after launch... no so much. So find a team that actually cares about the quality of their engineering, if you have that luxury. If not perhaps seek work with a smaller company or on a project that is here to stay. Things with open source components tend to calibrate well in that department in my experience because the code is the product. Also whatever the case, lead by example. It may feel futile but it does work.

Re: Linus Torvalds: 'I Do No Coding Any More'

#135

Post by rtkwe »

snarfy wrote: post #36

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.

It helps that beyond critical fixes the kernel doesn't really have deadlines so there's time to be extremely picky about the code and commits. I think a lot of cruft and bad code comes from time constraints from business, not all for sure but a lot. And beyond that as an OSS project going back and rewriting things doesn't cost anything (at least in real money) so there's not an economic pressure against going back and addressing cruft.

Re: Linus Torvalds: 'I Do No Coding Any More'

#136

Post by randomsearch »

noobermin wrote: post #18

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.

Other side of the fork here, headed to the exit because I don’t want to become a grant writing machine.

Re: Linus Torvalds: 'I Do No Coding Any More'

#137

Post by nemetroid »

tmh88j wrote: post #125
nemetroid wrote: post #119

Earlier quoted context omitted.

> If your code changes why would you leave outdated and misleading comments? The point is that the code might not change. When you wrote it, maybe it was to cover use cases A and B. Sometime later, a new use case ”C” is added to the requirements, and this particular part of the code happens to already support C without making any changes. Now, further down the line, some developer comes along to work on this code. If…

You seem to be confusing end user documentation with code documentation....an actual document that describes how to use the software vs comments in the code that describes how it works >Sometime later, a new use case ”C” is added to the requirements, and this particular part of the code happens to already support C without making any changes. Can you give an example of a new use case being introduced without the code…

I’m not confusing anything, but I’m using the term ”use case” in a very broad sense.

> Can you give an example of a new use case being introduced without the code changing?

I once wrote a framework for processing data in different proprietary formats from different vendors into a unified format. At first, each vendor had its own code module, and any idiosyncrasies between different data files for a given vendor were solved within that module.

However, later on, we had to split one vendor into two modules. Now, some key parts of the code had to be changed to account for this, as it could no longer be assumed that one module would handle one vendor. But most parts of the code was already abstracted over the modules, and didn’t care.

> Why would this be documented in the code in the first place if nothing has changed?

That’s what I’m asking you! :)

Re: Linus Torvalds: 'I Do No Coding Any More'

#139

Post by mrkeen »

dtech wrote: post #107
mrisoli wrote: post #92

Earlier quoted context omitted.

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 compla…

Spending time on commit messages that will be essentially removed when the PR is squashed seems... not very productive

I squash before I open the PR. Then I have last say in the commit message.

Also it gives me a chance to figure out what I actually worked on.

Re: Linus Torvalds: 'I Do No Coding Any More'

#140

Post by dcow »

mehrdadn wrote: post #128
dcow wrote: post #124

Earlier quoted context omitted.

Yep. I actually think PR squashing should be something you ask of someone else when they don’t take the time to clean up their commit history. If they don’t have the discipline to do it then one big sloppy commit is better than 25... I rarely squash my PRs because I always take the time to provide meaningful context surrounding my work.

How do you convince other people of this though? That's been what I've struggled with. I hate squashing too, but I can't convince anybody.

I like to remind people that pull requests are an abstraction over a set of commits. I show people that they can click on each individual commit in a PR and see the granular delta. Surprisingly often I’ve learned that people really don't know you can do this! If they argue that you cant revert entire features remind them that merge commits are a thing. If they don't like lots of merge commits littering the history suggest that most people should be FF merging (rebase and push) anyway. In my experience git has exactly tue right tooling for many diverse workflow scenarios and the problem more often than not is people don't understand their tools. Help educate them.

If your team insists on 1 PR == 1 commit (or if you use an authoritarian tool that allows enforcing it like gh or gerrit) then be abundantly pedantic about making sure that only changes related to a single unit of work are being introduced in new PRs. I find that calling people out when they make sloppy changes starts to get them thinking that it would be really nice to just keep this typo fix in an isolated commit and not require a new PR for it. When I have seen that model be successful, it’s usually the case that the team agrees that it is more important to ask someone to break out an unrelated change than to merge a sloppy PR.

Post reply on HN