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

231–240 of 253 posts

Re: Code review can be better

#231

Post by albrewer »

epolanski wrote: post #87
3036e4 wrote: post #81

What bothered me for a long time with code reviews is that almost all useful things they catch (i.e. not nit-picking about subjective minor things that doesn't really matter) are much too late in the process. Not rarely the only (if any) useful outcome of a review is that everything has to be done from scratch in a different ways (completely new design) or that it is abandoned since it turns out it should never have…

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

> Because in the software engineering world there is very little engineering involved.

I can count on one hand the number of times I've been given the time to do a planning period for something less than a "major" feature in the past few years. Oddly, the only time I was able to push good QA, testing, and development practices was at an engineering firm.

Re: Code review can be better

#233

Post by bornfreddy »

integralid wrote: post #228
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…

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.

> In the IT world it's entirely possibly to learn everything yourself and learn it better than one-fits-all course ever could.

Strong disagree. However, this is closer to truth:

In the IT world, if you have learned everything yourself, it's entirely possible to think you have learned it better than one-fits-all course ever could.

There is lots of theoretical knowledge that comes with the degree that, while mostly useless in day-to-day work, is priceless in those rare moments that it comes handy. A self-taught developer won't even know they are missing this knowledge. Example of this is knowing how compilers work (which is surprisingly useful) - without the theoretical background one might attempt to parse HTML with regex and expect correct results.

Not that all degrees are created equal. But those X years do give you an edge over self-taught developers. You still need to work on other skills too, of course.

Re: Code review can be better

#234

Post by mytailorisrich »

stonemetal12 wrote: post #218
mytailorisrich wrote: post #137

Earlier quoted context omitted.

> You are confusing waterfall-y "big design upfront" with having a design. I do not and I have explained it. > In software engineering fields you start with a design and you implement it And part of my previous comment is that this "waterfall-y" approach in which you design first and implement second does not work and has never worked. > you do not need to pay the cost of a big design upfront Exactly, and not only th…

>How many experiments, prototyopes, iterations go into building a car or a rocket? Many. Engineers do not come up with the final design up front. No where did anyone claim you need the full final design up front. For cars\rockets how many of those experiments, prototypes, and iterations had designs? All of them. You never see a mechanical engineer walk out to the shop and just start hammering on a pile of slop until…

> If you have no design to meet how do you judge the output of an iteration or know you have arrived at the final product?

I think you mean "requirements" here instead of "design".

Re: Code review can be better

#235

Post by epolanski »

pjmlp wrote: post #223
epolanski wrote: post #220

Earlier quoted context omitted.

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.

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

Of course you would/could.

1) a degree doesn't imply you've built any specific skills or retained any information, just that you passed a set of exams. I've met a huge bunch of people from important universities that clearly studied just to pass exams with good degrees, but where absolutely crap problem solvers and even worse coders.

2) plenty of brilliant engineers did not graduate, from Leonardo Da Vinci to, just to stay in software John Carmack, Zuckerberg, Paul Allen, Romero, Wozniak (technically he did, 12 years after founding Apple), Karp, and many others.

What I'm trying to say: engineering skills are acquired by sheer will of studying and solving problems. And in 2025 you can follow pretty much any course/lecture from most top rated courses just watching your computer. A person doing so with interest will leapfrog anybody sitting there and going through the exam just because he has to.

Re: Code review can be better

#236

Post by ozim »

closewith wrote: post #198
hgomersall wrote: post #171

Earlier quoted context omitted.

Ah, you've defined yourself to be right. Nice move. I'm not sure the generally accepted definition of engineering makes any reference to taking responsibility: https://dictionary.cambridge.org/dictionary/english/engineer...

In fact, every definition of engineering used by professionals includes explicitly taking responsibility, including in law in many countries.

I will add this link once more.

This is the talk on real software engineering: https://www.youtube.com/watch?v=RhdlBHHimeM

Re: Code review can be better

#237

Post by vlovich123 »

jacques_chester wrote: post #227
vlovich123 wrote: post #207

Earlier quoted context omitted.

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.

I don’t follow. Regardless of where you merge, are you not developing features on a shared branch with others? Or do you just have a single long development branch and then merge once “you’re done” and hope that there’s no merge conflicts? But regardless, I’m missing how reviews are being done.

Re: Code review can be better

#238

Post by ozim »

gabrielpoca118 wrote: post #194
wolvesechoes wrote: post #175

Earlier quoted context omitted.

Mechanical engineering also uses prototypes, iteration, lab testing etc. Building architects build multiple models before the first shovel is put into the ground. Software is clearly different than "hardware", but it doesn't mean that other industries do not use experiment and iteration.

ok you lost me then xD I was trying to understand what you meant by it not being engineering most of the time.

I will add this link once more.

This is the talk on real software engineering: https://www.youtube.com/watch?v=RhdlBHHimeM

Re: Code review can be better

#239

Post by hxtk »

integralid wrote: post #228
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…

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.

CS is sort of unique in that regard. I value my university degree, but when I think about the classes that helped me the most, only one of them was a degree requirement. Not because the degree was useless, but because the information was accessible enough that I already knew most of the required content for an undergraduate degree when I got there.

I took lots of electives outside my major, and I know that I could have easily loved chemistry, mathematics, mechanical engineering, electrical engineering, or any number of fields. But when you're 12 years old with a free period in the school computer lab, you can't download a chemistry set or an oscilloscope or parts for building your next design iteration. You can download a C compiler and a PDF of K&R's "The C Programming Language," though.

CS just had a huge head-start in capturing my interest compared to every other subject because the barrier to entry is so low.

Re: Code review can be better

#240

Post by motorest »

mytailorisrich wrote: post #234
stonemetal12 wrote: post #218

Earlier quoted context omitted.

>How many experiments, prototyopes, iterations go into building a car or a rocket? Many. Engineers do not come up with the final design up front. No where did anyone claim you need the full final design up front. For cars\rockets how many of those experiments, prototypes, and iterations had designs? All of them. You never see a mechanical engineer walk out to the shop and just start hammering on a pile of slop until…

> If you have no design to meet how do you judge the output of an iteration or know you have arrived at the final product? I think you mean "requirements" here instead of "design".

> I think you mean "requirements" here instead of "design".

No. This is exactly what you are getting wrong. Requirements are constraints that guide the design. The design then is used to organize, structure, and allocate work, and determine what code needs to be written.

Post reply on HN