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

Code review can be better

tigerbeetle.com

Post reply on HN
Print view View original

221–230 of 253 posts

Re: Code review can be better

#221

Post by hgomersall »

stonemetal12 wrote: post #216
hgomersall wrote: post #156

Earlier quoted context omitted.

Engineering is just about wielding tools to solve problems. You don't need to use formal methods to do engineering in general. Sometimes they're useful; sometimes they're required; often they just get in the way. In the context of software vs other sub-disciplines, the big difference is in the cost of iterating and validating. A bridge has very high iteration cost (generally, it must be right first time) and validati…

>Engineering is just about wielding tools to solve problems. You don't need to use formal methods to do engineering in general. Way to general to be useful. By that definition the store clerk is an engineer (tool cash register, problem solved my lack of gummy bears), janitors swinging a mops, or automotive techs changing oil. Engineering is applied science.

It wasn't a definition. Everything an engineer does is wield tools to solve problems. That doesn't mean wielding tools to solve problems automatically makes you an engineer. That said, I'm much less restrictive in those I would class as "doing engineering" than many.

Re: Code review can be better

#222

Post by jacobegold »

ndr wrote: post #196
abound wrote: post #191

Earlier quoted context omitted.

It requires a bit of scripting between the `gh` CLI and `jj`, but it's totally doable to maintain even complex stacks of PRs on GitHub with jj. One thing I've found at $DAYJOB is that I have to set the PR's "base" branch to "main" before I push updated commits (and then switch it back to the parent after), otherwise CI thinks my PR contains everything on main and goes nuts emailing half the company to come review it.

Is there something that does this? I've played with git town which is great for what it is. But at $DAYJOB we are now all on graphite and that stacking is super neat. The web part is frustratingly slow, but they got stacking working really well.

we have a big effort in the works to improve web perf! where specifically are you seeing slowness in the app — what flows, what pages, etc?

Re: Code review can be better

#223

Post by pjmlp »

epolanski wrote: post #220
pjmlp wrote: post #173

Earlier quoted context omitted.

There is plenty on large scale enterprise projects, but than whole that stuff is looked down by "real developers". Also in many countries, to one call themselves Software Engineer, they actually have to hold a proper degree, from a certified university or professional college, validated by the countrie's engineering order. Because naturally 5 year (or 3 per country) degree in Software Engineering is the same a six we…

In Italy a degree isn't enough, you need to take an exam and be certified.

Like in Portugal, and in many countries yes, usually having Software Engineer on legally bound contracts implies taking the final examination.

However, already by having been through the degree there is a whole set of skills that one would not have gotten otherwise.

Assuming that they actually did it the right way, and not getting through it with minimal effort.

Re: Code review can be better

#224

Post by skybrian »

guytv wrote: post #197
skybrian wrote: post #104

Earlier quoted context omitted.

One way to fix it: pair programming. You're getting feedback in real time as you write the code. Unfortunately, the conditions where it works well can be difficult to set up. You need people who are into it and have similar schedules. And you don't want two people waiting for tests to run.

Anyone actually done long-term pair programming and lived to tell the tale? Is it real, or just a utopian fantasy?

I did it at a startup for a few months. The startup failed, but I think it was more of a business failure.

Pivotal Labs was a contracting firm that did it for years. They aren’t around anymore, but they had a good run:

https://en.m.wikipedia.org/wiki/Pivotal_Labs

Re: Code review can be better

#226

Post by jacques_chester »

guytv wrote: post #197
skybrian wrote: post #104

Earlier quoted context omitted.

One way to fix it: pair programming. You're getting feedback in real time as you write the code. Unfortunately, the conditions where it works well can be difficult to set up. You need people who are into it and have similar schedules. And you don't want two people waiting for tests to run.

Anyone actually done long-term pair programming and lived to tell the tale? Is it real, or just a utopian fantasy?

It's not for everyone. Some people have excellent reasons why it isn't workable for them. Others have had terrible experiences. It takes a great deal of practice to be a good pair and, if you don't start by working with an experienced pair, your memories of pairing are unlikely to be fond.

However.

I paired full-time, all day, at Pivotal, for 5 years. It was incredible. Truly amazing. The only time in my career when I really thrived. I miss it badly.

Re: Code review can be better

#227

Post by jacques_chester »

vlovich123 wrote: post #207
mytailorisrich wrote: post #114

Earlier quoted context omitted.

Stacked pull requests seem to add a layer of complexity to solve a problem that should and can be avoided in the first place. Frequent, small changes are really a good practice. Then we have things like trunk-based development and continuous integration.

I’m confused. How do you do frequent small changes and avoid stacked PRs. Do you just do a small commit, wait for a review, merge, do another small commit? Or do you make a bunch of small commits locally and only put up the next one for review when the previous one is reviewed and merged? That’s the only models I can think of and it’s weird to advocate to have a variable time asynchronous process in the middle of you…

Trunk-based development, by itself, is a fool's errand.

But combine it with TDD & pairing and it becomes a license to deliver robust features at warp speed.

Re: Code review can be better

#228

Post by integralid »

pjmlp wrote: post #173
epolanski wrote: post #87

Earlier quoted context omitted.

> and that isn't something I ever encountered in the wild (in any formal sense) Because in the software engineering world there is very little engineering involved. That being said, I also think that the industry is unwilling to accept the slowliness of the proper engineering process for various reasons, including non criticality of most software and the possibility to amend bugs and errors on the fly. Other engineer…

There is plenty on large scale enterprise projects, but than whole that stuff is looked down by "real developers". Also in many countries, to one call themselves Software Engineer, they actually have to hold a proper degree, from a certified university or professional college, validated by the countrie's engineering order. Because naturally 5 year (or 3 per country) degree in Software Engineering is the same a six we…

I never finished my degree, but I believe I'm a very good developer (my employere agree). In my times most good programmers were self-taught.

I don't mind (hypothetically) not being allowed to call myself "engineer", but I do mind false dichotomy of "5 year course" vs "six week bootcamp". In the IT world it's entirely possibly to learn everything yourself and learn it better than one-fits-all course ever could.

Re: Code review can be better

#229

Post by sywhang »

m11a wrote: post #158
tomasreimers wrote: post #16

Just taking a step back, it is SO COOL to me to be reading about stacked pull requests on HN. When we started graphite.dev years ago that was a workflow most developers had never heard of unless they had previously been at FB / Google. Fun to see how fast code review can change over 3-4yrs :)

Graphite seems cool, it’s just unfortunately quite expensive and sometimes hard to convince procurement/etc to invest in when it has a noticeable cost involved. So I’m really hoping something like Graphite becomes open-source, or integrated into GitHub.

git-spice is completely open source and free: https://abhinav.github.io/git-spice/

Re: Code review can be better

#230

Post by akshayshah »

m11a wrote: post #158
tomasreimers wrote: post #16

Just taking a step back, it is SO COOL to me to be reading about stacked pull requests on HN. When we started graphite.dev years ago that was a workflow most developers had never heard of unless they had previously been at FB / Google. Fun to see how fast code review can change over 3-4yrs :)

Graphite seems cool, it’s just unfortunately quite expensive and sometimes hard to convince procurement/etc to invest in when it has a noticeable cost involved. So I’m really hoping something like Graphite becomes open-source, or integrated into GitHub.

git-spice does everything I liked from Graphite, but it’s fully open source and easy to adopt piecemeal.

https://abhinav.github.io/git-spice/

Post reply on HN