Remix.run Logo
Remix clone Hacker News
new | show | ask | jobsGithub
▲ 3036e4 5 days ago

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 been done at all.

It always seems as if the code review is the only time when all stakeholders really gets involved and starts thinking about a change. There may be some discussion earlier on in a jira ticket or meeting, and with some luck someone even wrote a design spec, but there will still often be someone from a different team or distant part of the organization that only hears about the change when they see the code review. This includes me. I often only notice that some other team implemented something stupid because I suddenly get a notification that someone posted a code review for some part of the code that I watch for changes.

Not that I know how to fix that. You can't have everyone in the entire company spend time looking at every possible thing that might be developed in the near future. Or can you? I don't know. That doesn't seem to ever happen anyway. At university in the 1990's in a course about development processes there wasn't only code reviews but also design reviews, and that isn't something I ever encountered in the wild (in any formal sense) but I don't know if even a design review process would be able to catch all the things you would want to catch BEFORE starting to implement something.

▲epolanski 5 days ago | parent | next [-]

> 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 engineering fields enjoy no such luxuries, the bridge either holds the train or it doesn't, you either nailed the manufacturing plant or there's little room for fixing, the plane's engine either works or not

Different stakes and patching opportunities lend to different practices.

▲j2kun 4 days ago | parent | next [-]

Summoning Hillel Wayne....

https://www.hillelwayne.com/post/are-we-really-engineers/

▲epolanski 3 days ago | parent [-]

He's spot on.

▲pjmlp 5 days ago | parent | prev | next [-]

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

▲integralid 4 days ago | parent | next [-]

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.

▲hxtk 4 days ago | parent | next [-]

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.

▲bornfreddy 4 days ago | parent | prev [-]

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

▲epolanski 4 days ago | parent | prev | next [-]

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

▲pjmlp 4 days ago | parent [-]

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.

▲epolanski 4 days ago | parent [-]

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

▲pjmlp 4 days ago | parent [-]

Except most people that call themselves Engineers without a degree aren't Leonardo Da Vinci, or any of the others listed by you.

Exceptional individuals that made an impact to mankind, regardless of which kind.

There are schools for special developed kids with advanced cognitive skills for a reason.

Also there is a huge difference between being immersed in an engineering degree between 3 to 5 years almost every single day with compulsory assignments, depending on the country, and occasionally watch a couple of videos, or read one or two books.

This all without getting into the soft and ethical skills that engineering degrees also require.

▲ 5 days ago | parent | prev [-]
[deleted]
▲ozim 5 days ago | parent | prev | next [-]

It still is engineering you only mistake design phase.

Writing code is the design phase.

You don’t need design phase for doing design.

Will drop link to relevant video later.

▲ChrisMarshallNY 5 days ago | parent | next [-]

I see there has been a “spirited discussion” on this. We can get fairly emotionally invested into our approaches.

In my experience (and I have quite a bit of it, in some fairly significant contexts), “It Depends” is really where it’s at. I’ve learned to take an “heuristic” approach to software development.

I think of what I do as “engineering,” but not because of particular practices or educational credentials. Rather, it has to do with the Discipline and Structure of my approach, and a laser focus on the end result.

I have learned that things don’t have to be “set in stone,” but can be flexed and reshaped, to fit a particular context and development goal, and that goals can shift, as the project progresses.

When I have worked in large, multidisciplinary teams (like supporting hardware platforms), the project often looked a lot more “waterfall,” than when I have worked in very small teams (or alone), on pure software products. I’ve also seen small projects killed by overstructure, and large projects, killed, by too much flexibility. I’ve learned to be very skeptical of “hard and fast” rules that are applied everywhere.

Nowadays, I tend to work alone, or on small teams, achieving modest goals. My work is very flexible, and I often start coding early, with an extremely vague upfront design. Having something on the breadboard can make all the difference.

I’ve learned that everything that I write down, “ossifies” the process (which isn’t always a bad thing), so I avoid writing stuff down, if possible. It still needs to be tracked, though, so the structure of my code becomes the record.

Communication overhead is a big deal. Everything I have to tell someone else, or that they need to tell me, adds rigidity and overhead. In many cases, it can’t be avoided, but we can figure out ways to reduce the burden of this crucial component.

It’s complicated, but then, if it were easy, everyone would be doing it.

▲marcyb5st 5 days ago | parent | prev | next [-]

Googler, but opinions are my own.

I disagree. The design phase of a substantial change should be done beforehand with the help of a design doc. That forces you to put in writing (and in a way that is understandable by others) what you are envisioning. This exercise is really helpful in forcing you to think about alternatives, pitfalls, pros & cons, ... . This way, once stakeholders (your TL, other team members) agreed then the reviews related to that change become only code related (style, use this standard library function that does it, ... ) but the core idea is there.

▲mytailorisrich 5 days ago | parent | next [-]

This should only be a first phase of the design and should be high level and not a commitment. Then you quickly move on to iterate on this by writing working code, this is also part of the design.

Having an initial design approved and set in stone, and then a purely implementation phase is very waterfall and very rarely works well. Even just "pitfalls and pros & cons" are hard to get right because what you thought was needed or would be a problem may well turn out differently when you get hands-on and have actual data in the form of working code.

▲ozim 5 days ago | parent | prev [-]

This is the talk I mentioned in my original comment:

https://www.youtube.com/watch?v=RhdlBHHimeM

▲jmholla 5 days ago | parent | prev | next [-]

I also read this series of blog posts recently where the author, Hillel Wayne, talked to several "traditional" engineers that had made the switch to software. He came to a similar conclusion and while I was previously on the fence of how much of what software developers do could be considered engineering, it convinced me that software engineer is a valid title and that what we do is engineering. First post here: https://www.hillelwayne.com/post/are-we-really-engineers/

▲wolvesechoes 5 days ago | parent | next [-]

Personally I don't need to talk with "traditional" engineers to have an opinion there, as I am mechanical engineer that currently deals mostly with software, but still in the context of "traditional" engineering (models and simulation, controls design).

Definitely making software can be engineering, most of the time it is not, not because of the nature of software, but the characteristics of the industry and culture that surrounds it, and argument in this article is not convincing (15 not very random engineers is not that much to support the argument from "family resemblance").

▲hgomersall 5 days ago | parent | next [-]

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 validation is proven over decades. Software has very low iteration cost, so it makes much more sense to do that over lots of upfront design. Validation of software can also generally be implemented through software tools, since it's comparatively easy to simulate the running environment of the software.

Other disciplines like electronics live a little closer to a bridge, but it's still relatively cheap to iterate, so you tend to plan interim design iterations to prove out various aspects.

▲wolvesechoes 5 days ago | parent | next [-]

"In the context of software vs other sub-disciplines, the big difference is in the cost of iterating and validating."

People forget that software is used in those other disciplines. CFD, FEA, model-based design etc. help to verify ideas and design without building any physical prototype and burning money in the real lab.

You can do some strain and stress analysis on a virtual bridge to get a high degree of confidence that the real bridge will perform fine. Of course, then you need to validate it at all stages of development, and at the end perform final validation under weight.

The thing is that people building engines, cars, planes, sensors, PCBs and bridges actually do so, largely because they are required to do so. If you give them freedom to not do that, many of them will spare themselves such effort. And they understand the principles of things they are working on. No one requires any of that from someone that glued together few NPM packages with a huge JS front-end framework, and such person may not even know anything about how the HTTP works, how browser handles the DOM etc. It's like having a mechanical engineer that doesn't even understand basic principles of dynamics.

There are industries that deal with the software (i.e. controls design) that have much higher degree of quality assurance and more validation tools, including meaningful quantitative criteria, so it clearly is not a matter of software vs hardware.

▲tsimionescu 4 days ago | parent | prev | next [-]

> Engineering is just about wielding tools to solve problems.

By that standard, doctors and hair stylists are also engineers, as are some chimps and magpies. I don't think it's a useful definition, it's far too broad.

▲closewith 5 days ago | parent | prev | next [-]

> In the context of software vs other sub-disciplines, the big difference is in the cost of iterating and validating.

No, the big difference is that in the Engineering disciplines, engineers are responsible end-to-end for the consequences of their work. Incompetence or unethical engineers can and regularly do lose their ability to continue engineering.

It's very rare that software developers have any of the rigour or responsibilities of engineers, and it shows in the willingness of developers to write and deploy software which has real-world costs. If developers really were engineers, they would be responsible for those downstream costs.

▲hgomersall 5 days ago | parent [-]

There are plenty of engineering of physical things where nobody has or takes responsibility. Equally, there's plenty of examples of software where careful processes are in place to demonstrate exactly the responsibilities you discuss.

▲closewith 5 days ago | parent [-]

> There are plenty of engineering of physical things where nobody has or takes responsibility.

That is by definition not engineering.

> Equally, there's plenty of examples of software where careful processes are in place to demonstrate exactly the responsibilities you discuss.

Software engineering of course exists, but 99%+ of software is not engineered.

▲hgomersall 5 days ago | parent [-]

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

▲closewith 4 days ago | parent [-]

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

▲ozim 4 days ago | parent [-]

I will add this link once more.

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

▲closewith 4 days ago | parent [-]

I think maybe you should watch this video, as it speaks only about software development and not engineering in any meaningful aspect.

▲stonemetal12 4 days ago | parent | prev [-]

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

▲hgomersall 4 days ago | parent [-]

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.

▲gabrielpoca118 5 days ago | parent | prev | next [-]

But what about other engineering fields? From what I understand, if you compare it to chemical engineering, you have many more similarities, because you’re doing Hypothesis -> Experiment -> Analyze -> Refine -> Repeat, which seems very similar to what we do in software

▲wolvesechoes 5 days ago | parent [-]

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.

▲gabrielpoca118 4 days ago | parent [-]

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

▲ozim 4 days ago | parent [-]

I will add this link once more.

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

▲jmholla 4 days ago | parent | prev [-]

I think it's still be worth your time to check out the articles as they talk about other fields of engineering and how they compare to software AND mechanical.

▲3036e4 5 days ago | parent | prev [-]

I was an undergraduate (computer) engineer student, but like many of my friends at that time (dot-com boom) I did not graduate since it was too tempting to get a job and get well paid instead.

However many, probably half, that I work with, and most that I worked with overall for the last 25+ years (since after I dropped out) have an engineering degree. Especially the younger ones, since this century it has been more focus on getting a degree and fewer seems to drop out early to get a job like many of us did in my days.

So when American employers insist on giving me titles like "software engineer" I cringe. It's embarrassing really, since I am surrounded by so many that have a real engineering degree, and I don't. It's like if I dropped out of medical school and then people started calling me "doctor" even if I wasn't one, legally. It would be amazing if we could find a better word so that non-engineers like me are not confused with the legally real engineers.

▲AndrewDavis 5 days ago | parent | next [-]

I've decided that titles are mostly meaningless in software. What X title means in one org means another in a different one with near zero overlap, and another title might have considerable overlap with a differently named one but viewed lowly, borderline pejoratively at another org. Eg system admin vs devops vs sre. In one org sysadmins are deploying desktop machines with no expectations they can cut code, in my old role as one I was working with Linux systems, building glue and orchestration, and when things go wrong debugging backend code written by a development team. Something far closer to the work of "devops" or "sre".

As a aside, I find your example of doctor as amusing because it's overloaded with many considering the term a synonym of physician, and the confusion that can cause with other types of doctors.

▲lukan 5 days ago | parent | prev [-]

If you are doing the work of an engineer and you do it right, I believe you are an engineer, whether you graduated, or not.

And proper software developement definitely has engineering parts. Otherwise titles are just labels.

▲ozim 5 days ago | parent | prev | next [-]

This is the talk on real software engineering:

https://www.youtube.com/watch?v=RhdlBHHimeM

▲erichocean 5 days ago | parent | prev | next [-]

> Writing code is the design phase.

Rich Hickey agrees it's a part of it, yes. https://www.youtube.com/watch?v=c5QF2HjHLSE

▲motorest 5 days ago | parent | prev [-]

> Writing code is the design phase.

No, it really isn't. I don't know which amateur operation you've been involved with, but that is really not how things work in the real world.

In companies that are not entirely dysfunctional, each significant change to the system's involve a design phase, which often includes reviews from stakeholders and involved parties such as security reviews and data protection reviews. These tend to happen before any code is even written. This doesn't rule out spikes, but their role is to verify and validate requirements and approaches, and allow new requirements to emerge to provide feedback to the actual design process.

The only place where cowboy coding has a place is in small refactoring, features and code fixes.

▲mytailorisrich 5 days ago | parent | next [-]

It is, as often, a trade-off.

You need a high level design up-front but it should not be set in stone. Writing code and iterating is how you learn and get to a good, working design.

Heavy design specs up-front are a waste of time. Hence, the agile manifesto's "Working software over comprehensive documentation", unfortunately the key qualifier "comprehensive" is often lost along the way...

On the whole I agree that writing code is the design phase. Software dev. is design and test.

▲motorest 5 days ago | parent [-]

> You need a high level design up-front but it should not be cast in stone.

Yes, you need a design that precedes code.

> Writing code and iterating is how you learn and get to a good, working design.

You are confusing waterfall-y "big design upfront" with having a design.

It isn't.

This isn't even the case in hard engineering fields such as aerospace where prototypes are used to iterate over design.

In software engineering fields you start with a design and you implement it. As software is soft, you do not need to pay the cost of a big design upfront.

▲mytailorisrich 5 days ago | parent | next [-]

> 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 that but usually requirements will also change along the way. The design can change and will change as you hit reality and learn while writing actual, working code. So keep your design as a high-level initial architecture then quickly iterate by writing code to flesh out the design.

Software is often opposed to "traditional engineering" but it is actually the same. 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. The difference it is that this is expensive while in software we can iterate much more, much quicker, and for free to get to the final product.

▲stonemetal12 4 days ago | parent | next [-]

>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 it sort of looks like a car.

>The difference it is that this is expensive while in software we can iterate much more, much quicker, and for free to get to the final product.

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?

▲mytailorisrich 4 days ago | parent [-]

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

▲motorest 4 days ago | parent [-]

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

▲motorest 5 days ago | parent | prev [-]

> I do not and I have explained it.

You should review the sources of your confusions and personal misconceptions, as you deny design and then proceed to admit there is design.

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

Nonsense. "Big design upfront" works, but is suboptimal in software development. That's why it's not used.

"Big design upfront" approaches are costly as it requires know-how and expertise to pull off, which most teams lack, and it assumes requirements don't change, which is never the case.

Once you acknowledge that requirements will change and new requirements will emerge, you start to think of strategies to accommodate them. In software development, unlike in any hard engineering field, the primary resource consumed is man-hours. This means that, unlike in hard engineering fields, a software development process can go through total rebuilds without jeopardizing their success. Therefore in software development there is less pressure to get every detail right at the start, and thus designs can be reviewed and implementations can be redone with minimal impact.

> Exactly, and not only that but usually requirements will also change along the way. The design can change and will change as you hit reality and learn while writing actual, working code.

Yes.

But you do need a design upfront, before code is written. Design means "know what you need to do". You need to have that in place to create tickets and allocate effort. It makes no sense at all to claim that writing code is the design stage. Only in amateur pet projects this is the case.

▲ndriscoll 4 days ago | parent | prev [-]

The difference I see is that in other fields, part of your design process is thinking through the logical details of the thing. Essentially, doing some math. In software, the logical details are the finished product. The math is what you're trying to make. If you've actually thought through all of the details, you have written the software (if only in your head). If you haven't thought through all of the details and only figured out a high level design, you've still written some software (essentially, stubbing out some functionality, or leaving it as a dependency to be provided. However you want to think of it). So naturally, one way to think through things is to write software.

▲motorest 4 days ago | parent [-]

> The difference I see is that in other fields, part of your design process is thinking through the logical details of the thing. Essentially, doing some math.

The "some math" is used in engineering fields in things like preliminary design, sizing, verification&validation, etc. To a lesser degree, "some math" can be used in the design stages of software development projects. For example, estimating the impact of micro services tax in total response times to verify if doing synchronous calls can work vs doing polling/messaging. Another example is estimating max throughput per service based on what data features in a response and how infrastructure is scaled. This is the kind of things that you do way before touching code to determine if the expected impact of going with a particular architecture vs another that mitigates issues.

> In software, the logical details are the finished product. The math is what you're trying to make.

You're confused. The design stage precedes writing any code, let alone the finished product. Any remotely complex work, specially if it involves architecture changes, is preceded by a design stage where alternatives are weighed and validated, and tradeoffs are evaluated.

To further drive the point home, in professional settings you also have design reviews for things like security and data protection. Some companies even establish guidelines such as data classification processes and comparative design to facilitate these reviews.

> If you've actually thought through all of the details, you have written the software (if only in your head). If you haven't thought through all of the details and only figured out a high level design, you've still written some software (essentially, stubbing out some functionality, or leaving it as a dependency to be provided. However you want to think of it).

You're confusing having a design stage with having a big design upfront. This is wrong.

The purpose of the design stage is to get the necessary and sufficient aspects right from the start, before resources are invested (and wasted) in producing something that meets requirements. No one cares what classes or indentation style you use to implement something. The ultimate goal is to ensure the thing is possible to deliver, what it actually does and how it does it, and if it is safe enough to use. You start writing code to fill in the details.

▲ndriscoll 3 days ago | parent [-]

Design reviews don't mean you don't write code first. We have a change that we're about to put through security review right now to special case TLS handling when talking to some older clients, but before we put a proposal forward, I validated that the core idea will actually work and that we can heavily restrict the scope of what the change applies to by writing the code and tests to do it. Meetings and asking multiple people to read through and provide feedback on documents very quickly racks up hours. Best to spend an hour or two first validating that what you're proposing isn't nonsense. This lets us be very specific about what the problem is, what the proposed solution is, and what the risks are.

With data classification, you're going to need to think through what data you are using and what you want to do with it. i.e. write a program.

I didn't claim class structure or indentation matters. I'm saying that assuming you are discussing some sort of algorithm or functionality, a formal language is a perfectly fine thing to use for thinking about the problem and writing down your ideas. Writing "what it actually does and how it does it" is just programming. If you write your ideas in a language like Scala, they can easily be more concise (so easier to review) than they would be in English, and you get a compiler helping you think through things.

▲ozim 4 days ago | parent | prev | next [-]

Operation that uses software developers not as code monkeys but actual business problem solvers that have also business knowledge.

Operation that delivers features instead of burning budget on discussions.

Operation that uses test/acceptance environments where you deploy and validate the design so people actually see the outcome.

Obviously you have to write down the requirements - but writing down requirements is not design phase.

Design starts with idea, is written down to couple sentences or paragraphs then turned into code and while it is still on test/acceptance it still is design phase. Once feature goes to production in a release "design phase" is done, implementation and changes are part of design and finding out issues, limitations.

▲ownagefool 5 days ago | parent | prev [-]

This response is rude / insulting and doesn't actually add much because you've just asserted a bunch of fallacious opinions without any meat.

My opinion is reality is more nuanced. Both "the code is self documenting" and "the code is the design" are reasonable takes within reasonable situations.

I'll give an example.

I work in a bureaucratic organization where there's a requirement to share data and a design doc that goes through a series of not-really-technical approvals. The entire point of the process is to be consumable to people who don't really know what an API is. It's an entirely reasonable point of view that we should just create the swagger doc and publish that for approval.

I worked in another organization where everything was an RFC. You make a proposal, all the tech leads don't really understand the problem space, and you have no experience doing the thing, so you get the nod to go ahead. You now have a standard that struggles against reality, and is difficult to change because it has broad acceptance.

I'm not saying we should live in a world with zero non-code artifacts, but as someone who hops org to org, most of the artifacts aren't useful, but a CI/CD that builds, tests, and deploys, looking at the output and looking at the code gives me way more insight that most non-code processes.

▲albrewer 4 days ago | parent | prev [-]

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

▲ghosty141 5 days ago | parent | prev | next [-]

I work in a small team where we are essentially 4-6 core developers. When I develop a feature I usually talk about it with my coworkers once I made a rough draft in my head how I'd approach it. They do the same so our code reviews are mostly only the minor code smells etc. but we usually decide on the architecture together (2-3 people usually).

I find this to be one of the most important things in our team. Once people don't agree on code it all kinda goes downhill with nobody wanting to interact with code they didn't write for various reasons.

In bigger orgs I believe it's still doable this way as long as responsibilities are shared properly and it's not just 4 guys who know it all and 40 others depend on them.

▲sigmaml 4 days ago | parent [-]

I strongly second this. In my own experience of about 30 years, I have seen this method to work almost always.

▲motorest 5 days ago | parent | prev | next [-]

> It always seems as if the code review is the only time when all stakeholders really gets involved and starts thinking about a change.

That is a problem with your organization, not with Git or any version control system. PRs are orthogonal to it.

If you drop by a PR without being aware of the ticket that made the PR happen and the whole discussion and decision process that led to the creation of said tickets, you are out of the loop.

Your complain is like a book publisher complaining that the printing process is flawed because seeing the printed book coming out of the production line is the only time when all stakeholders really get involved. Only if you work in a dysfunctional company.

▲AdrianB1 5 days ago | parent [-]

I saw this in many places, so I read that original statement like a complaint about a widespread problem, not an exception in one company.

Sometimes is not even about a PR, it is about an entire project. I always do reviews (design and code, separate stages) for projects where code is almost complete when people come for design reviews and by the time we get to code reviews it is usually too late to fix problems other than showstoppers. I worked in small companies, huge companies (over 100k employees), some are better, most are bad, in my experience. YMMV, of course.

▲Ozzie_osman 5 days ago | parent | prev | next [-]

> Not that I know how to fix that. You can't have everyone in the entire company spend time looking at every possible thing that might be developed in the near future. Or can you?

You don't need to. I've seen this generally work with some mix of the following:

1. Try to decouple systems so that it's less likely for someone in a part of the org to make changes that negatively impact someone in a more distant part of the org.

2. Some design review process: can be formal "you will write a design doc, it will be reviewed and formally approved in a design committee" if you care more about integrity and less about speed, or can be "write a quick RFC document and share it to the relevant team(s)".

3. Some group of people that have broad context on the system/code-base (usually more senior or tenured engineers). Again, can be formal: "here is the design review committee" or less formal: "run it by these set of folks who know there stuff". If done well, I'd say you can get pretty broad coverage from a group like this. Definitely not "everyone in the entire company". That group can also redirect or pull others in.

4. Accept that the process will be a bit lossy. Not just because you may miss a reviewer, but also, because sometimes once you start implementing the reality of implementation is different than what people expect. You can design the process for this by encouraging POC or draft implementations or spikes, and set expectations that not all code is expected to make it into production (any creative process includes drafts, rewrites, etc that may not be part of the final form, but help explore the best final form).

I've basically seen this work pretty well at company sizes from 5 engineers all the way up to thousands.

▲DixieDev 5 days ago | parent | prev | next [-]

Where I work we tend to write RFCs for fundamental design decisions. Deciding what counts as a "fundamental design decision" is sometimes self-moderated in the moment but we also account for it when making long term plans. For example when initially creating epics in Jira we might find it hard to flesh out as we don't really know how we're going to approach it, so we just start it off with a task to write an RFC.

These can be written either for just our team or for the eyes of all other software teams. In the latter case we put these forward as RFCs for discussion in a fortnightly meeting, which is announced well in advance so people can read them, leave comments beforehand, and only need to attend the meeting if there's an RFC of interest to them up for discussion.

This has gone pretty well for us! It can feel like a pain to write some of these, and at times I think we overuse them somewhat, but I much prefer our approach to any other place I've worked where we didn't have any sort of collaborative design process in place at all.

▲unkulunkulu 5 days ago | parent [-]

I view this process like this: code review is a communication tool: you can discuss concrete decisions vs hand waving and explaining in the conceptual space, which of course has its place, but is limited.

But writing the whole working code just to discuss some APIs is too much and will require extra work to change if problems are surfaced on review.

So a design document is something in the middle: it should draw a line where the picture of the planned change is as clear as possible and can be communicated with shareholders.

Other possible middle grounds include PRs that don’t pass all tests or that don’t even build at all. You just have to choose the most appropriate sequence of communication tools to come to agreements in the team and come to a point where the team is on the same page on all the decisions and how the final picture looks.

▲sdeframond 5 days ago | parent | prev | next [-]

I share your feelings.

Regarding design reviews, we used to have them at my current job. However we stopped doing both formal design documents and design reviews in favor of prototyping and iterative design.

The issue with the design phase is that we often failed to account for some important details. We spent considerable time discussing things and, when implementing, realized that we omitted some important detail or insight. But since we already invested that much time in the design phase, it was tempting to take shortcuts.

What's more, design reviews were not conducted by the whole team, since it would be counter-productive to have 10-more people in the same room. So we'd still discover things during code reviews.

And then not everyone is good at/motivated to producing good design documents.

In the end, I believe that any development team above 5 people is bound to encounter these kinds of inefficiencies. The ideal setup is to put 5 people in the same room with the PO and close to a few key users.

▲benji-york 4 days ago | parent [-]

> The ideal setup is to put 5 people in the same room with the PO and close to a few key users.

(I suspect you are aware, but just in case this is new to you.) This is essentially the core of Extreme Programming.

▲sdeframond 4 days ago | parent [-]

What team size does XP recommends, if any ?

It seems like the standard around me is between 8 to 12 people. This is too many in my opinion.

I believe this is because management is unknowingly aiming for the biggest team the does not completely halts instead of seeking a team that delivers the most bang for the buck.

▲benji-york 4 days ago | parent [-]

I don't know of a canonical XP team size, but "small" is the normal recommendation. 8-12 would seem larger than small to me.

Personally, 8 is the largest I would have a team. At that point you should consider breaking it into two teams of 4 (even if those teams periodically recombine from the original set of 8 people).

▲sdeframond 4 days ago | parent [-]

I find it non trivial to split a team in two independent teams.

If the two teams have to coordinate a lot and work on the same code base, is there still two teams?

To be independent, they would need to work on functionnaly different parts of the project. Not all projects have several independent parts, feature-wise.

What do I miss?

▲skybrian 5 days ago | parent | prev | next [-]

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.

▲guytv 4 days ago | parent | next [-]

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

▲jacques_chester 4 days ago | parent | next [-]

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.

▲skybrian 4 days ago | parent | prev [-]

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

▲grilledcheez 5 days ago | parent | prev [-]

It's crazy that we go out of our way to design processes (code review, design review) to avoid actually just... working together? And then we design organizations that optimize for those processes instead of optimizing for collaboration.

▲guytv 4 days ago | parent | prev | next [-]

With AI based coding (no, i won't use "Vibe coding", thank you) this workflow improves a lot. Instead of jumping straight into code, I have my engineers write a Notion doc that describes what needs to be built. Think of it like an LLD, but really it’s a prompt for Claude-code. This forces them to think through the problem at a low level, and they share the doc with me before sending it to Claude — so I get to review early in the process. Once we finalize this "LLD" or "low-level-prompt", they hand it to Claude. The next time I see the work is in a GitHub PR. At that point, we rarely have to throw everything away and start from scratch.

▲teiferer 5 days ago | parent | prev | next [-]

Seems like your organization is lacking structure and communication.

Where I work, the structure is such that most parts of the codebase have a team that is responsible for it and does the vast majority of changes there. If any "outsider" plans a change, they come talk to the team and coordinates.

And we also have strong intra-team communication. It's clear who is working on what and we have design reviews to agree on the "how" within the team.

It's rare that what you describe happens. 95% of the code reviews I do are without comments or only with minor suggestions for improvement. Mainly because we have developed a culture of talking to each other about major things beforehand and writing the code is really just the last step in the process. We also have developed a somewhat consistent style within the teams. Not necessarily across the teams, but that's ok.

TL;DR: It's certainly possible to do things better that what you are experiencing. It's a matter of structure, communication and culture.

▲ruslan_sure 5 days ago | parent | prev | next [-]

This can be used in any process where the result is only judged at the end.

The solution here may be to add a midterm check. I think this is what you mean by a "design review."

In my experience, there are some rules that need to be followed for it to work.

- Keep the number of stakeholders involved in all decisions, including PR, as small as possible.

- Everyone involved should take part in this check. That way, no one will be surprised by the results.

- This check should have been documented, like in the ticket.

This can be used in any process where the result is only judged at the end. The solution here may be to add a midterm check. I think this is what you mean by a "design review." In my experience, there are some rules that need to be followed for it to work. We should keep the number of stakeholders involved in all decisions, including PR, as small as possible. Everyone involved should take part in this mid-term check. That way, no one will be surprised by the results. This check should have been documented, like in the ticket.

When and how to do this check and how to handle disagreements depend on the task, culture, and personalities.

▲ruslan_sure 4 days ago | parent [-]

We should do something similar with AI-coding.

If you don't have a documented mid-term check, vibe-coded PR might not be what you expected.

▲flir 5 days ago | parent | prev [-]

You can get the same thing if you do user interface testing after you've built the thing. A design system can help there - at the very least, the change can feed back into the next revision of the playbook.

Even if you can't fix it this time, hopefully you've taught someone a better pattern. The direction of travel should still be positive.

On personal projects I've used architectural decision records, but I've never tried them with a team.