4 ms·

Art students learn to critique the work of others. Engineers don't, and it shows

45 points by tantalor 6y ago

proc0 6y ago
You don't really critique engineering, it either works or it doesn't, everything else is extra and based on preference. Art is purely non-functional, therefore critiquing it makes sense, because it's all about how it's interpreted. With code, the interpretation is done by the interpreter; compiler; platform; framework; etc. If a piece of code gives you an error, then it needs to change, if it doesn't, then it's style or preference UNLESS it does have a technical impact, and then it needs to be automated, part of the system itself instead of relying on human eyes. In other words, critiquing code is really doing the computer's work, because in theory you would have linter rules, unit tests, integration tests, that would tell you when you need to change something. That said, you can never have a perfect system that takes care of everything such that reviews aren't necessary (where only making the build pass is needed). Humans are still needed, but that is only because of the lack of automation and rules built into the system. Therefore to the extent you do have to review, you shouldn't be a dick about it. I agree with that, however the real solution is to let the machine handle everything.
- the_jeremy 6y ago
  > if it doesn't [give you an error], then it's style or preference > That said, you can never have a perfect system that takes care of everything such that reviews aren't necessary You refute your own point. Reviews are necessary, and you can critique engineering, and you need to go beyond "it either works or it doesn't". You spend half your comment making a bold claim and the other half backing off.
  - proc0 6y ago
    My main point is reviews are not really critiques like in art. There is a huge difference, art doesn't get compiled by a machine. At the end of the day, your customer doesn't care that you didn't refactor such and such variable. It either works or it doesn't. The last observation was just pointing out we are not there yet technologically, but we're definitely approaching it. Humans are only needed now because of lack of automation, not because the code really needs another human perspective. The human perspective for software comes at the very end, as the end user's feedback, but that's after PR merged.
    - ironmagma 6y ago
      Even “works” is not binary. Take for example this air disaster where the door closed but did not properly seal (even though it worked fine on most flights) and later opened mid-flight killing several people. The design was defended and any concerns about its functioning were dismissed until another plane had the door open on its own volition while on the ground. [1] https://en.wikipedia.org/wiki/United_Airlines_Flight_811 https://en.wikipedia.org/wiki/United_Airlines_Flight_811
      - proc0 6y ago
        I'm failing to see how it disproves my point. If anything this was human error, perhaps something that now is completely automated and tested by machine simulations. Machines are not "perfect" (for lack of a better word), however computers are designed to compute information, and the computation of information ultimately becomes the functionality. I'm saying here that humans aren't as good as machines at interpreting information (that is then computed by the machine) as the machines themselves. We only use humans where we really have to just because the technology and/or resources has not allowed it yet.
        ironmagma 6y ago
        Yes, in the sense that all engineering design errors are human error. This is why we have critiques. Maybe something appears to work (i.e. doesn't give an error, or serves thousands of flights successfully), but that does not mean no changes are necessary. There are latent bugs that can pop up at any moment. Tests (including user testing) are guardrails; no one should be driving to their destination just by banging into the guardrails and letting that guide them. Not least because that's not what guardrails are for, but also because there are guardrails everywhere and they don't actually guide you in any particular direction.
        proc0 6y ago
        > Yes, in the sense that all engineering design errors are human error. This is why we have critiques. I'll agree to disagree... this is the reason we have automated tests, not why we have critiques. If you plot the quantity of human intervention in software development over time, I believe we will clearly see machines taking over in due time.
- FooBarBizBazz 6y ago
  She wasn't really talking about the technical side of engineering work here. Her examples are about written works (essays), and works of product design. It all hinges on the word "work". She's not talking about whether an artifact "works", but about an artifact as "a work".
  - proc0 6y ago
    I missed that, sorry. it's hard to follow when it's a bunch of tweets instead of a normal essay with paragraphs. User experience, and design, ultimately does contain forms of art, so my comment would be different.
dhruvmittal 6y ago
As someone who got a CS degree in the early 2010s, I both 1) agree wholeheartedly that engineers should learn to critique work effectively and 2) disagree that engineers aren't taught this in school. At least my degree program included some efforts at code critiques and reviews. At multiple instances both early and late in the degree program, I was required to offer feedback as part of class assignments. This started with the first "Foundations of Programming" class, in which we'd submit written code reviews of other students' programming assignments as homework assignments. The professor/TAs would evaluate our reviews and provide their own feedback on how to write more effective code reviews. My senior year I had an entire "Software Engineering Lab" course, which required code review notes along with other deliverables for the course (team) project. Again, guidance was provided from the instructor on how to do effective code reviews.
- jdlshore 6y ago
  The thread explicitly states that it’s not about code reviews.
mrtweetyhack 6y ago
art and engineering are very different. One deals with precision while the other can be abstract.
NikolaeVarius 6y ago
I never understood why "engineer" has been redefined as only "code developers" Seems to leave out literally everyone who is an engineer that doesn't just do webdev. In the non web dev world, massive amounts of effort is put into having good, unpersonal triage and review processes.
- FooBarBizBazz 6y ago
  Personally, I drive a locomotive.
- DaveExeter 6y ago
  Can we stop calling programmers Engineers? I see this twitterer describes herself as "Staff Software Engineer at Mozilla". In other words, a programmer.
  - mechatrocity 6y ago
    I agree it's frustrating. I'm a Software Safety PEng that does alot of compliance and standards work, and safety validation. My company is good about delineating between engineering and developers... But very few orgs outside of safety critical industries care at all
  - bsder 6y ago
    And it's not even if you have a PE (Professional Engineering) license. For example, all the VLSI designs I've worked on had "design reviews". Always. And generally you had to pass several layers of automated design reviews before you could get to the layer of having a human review it. Why do software people think other fields all suck as much as software development?
  - Twixes 6y ago
    It's entirely accurate - software development is a branch of engineering. The name doesn't come from a literal "engine" (though the origin is the same), it means "someone who contrives contraptions".
  - david-gpu 6y ago
42droids 6y ago
Oh I always wanted feedback about my work (code) as a software engineer (good or bad) but never really got any.
sheer_audacity 6y ago
I agree with all this. It’s one of the reasons why so many products get built and fail - engineers of all sorts, not just computer programmers, need to consider why things need and get made and who for, even if they’re only concerned about the most particular of technical details. I think a lot of engineers could stand to take a formal graphic design/drawing/writing/critiquing class so they can better communicate and understand themselves better.
throwawaaarrgh 6y ago
Twitter is a really bad blogging platform.
- ergot_vacation 6y ago
  And yet everyone keeps using it, because everyone ELSE is using it and FOMO, real and imagined, is your lord and master. Due to the stupidity of the crowd we seem to be progressing backwards in tech now. I wonder if the Internet will eventually self-destruct and we'll all end up back on 1980s tech.
ergot_vacation 6y ago
Respectfully, what planet is the author from? Artists, and art students, are often the most vicious pit of vipers imaginable. On the flip side, there can be a lot of ego wrapped up in engineering and coding as well, but at least the field in general tends toward a more practical approach. As someone with a foot in both worlds, I'd say it's infinitely easier to collaborate with someone on a programming project than an artistic one, because it's easier to set ego aside when you're just trying to build a good tool instead of express something deeply personal.

45 points by tantalor 6y ago

You don't really critique engineering, it either works or it doesn't, everything else is extra and based on preference. Art is purely non-functional, therefore critiquing it makes sense, because it's all about how it's interpreted. With code, the interpretation is done by the interpreter; compiler; platform; framework; etc. If a piece of code gives you an error, then it needs to change, if it doesn't, then it's style or preference UNLESS it does have a technical impact, and then it needs to be automated, part of the system itself instead of relying on human eyes. In other words, critiquing code is really doing the computer's work, because in theory you would have linter rules, unit tests, integration tests, that would tell you when you need to change something. That said, you can never have a perfect system that takes care of everything such that reviews aren't necessary (where only making the build pass is needed). Humans are still needed, but that is only because of the lack of automation and rules built into the system. Therefore to the extent you do have to review, you shouldn't be a dick about it. I agree with that, however the real solution is to let the machine handle everything.

the_jeremy 6y ago
> if it doesn't [give you an error], then it's style or preference > That said, you can never have a perfect system that takes care of everything such that reviews aren't necessary You refute your own point. Reviews are necessary, and you can critique engineering, and you need to go beyond "it either works or it doesn't". You spend half your comment making a bold claim and the other half backing off.
- proc0 6y ago
  My main point is reviews are not really critiques like in art. There is a huge difference, art doesn't get compiled by a machine. At the end of the day, your customer doesn't care that you didn't refactor such and such variable. It either works or it doesn't. The last observation was just pointing out we are not there yet technologically, but we're definitely approaching it. Humans are only needed now because of lack of automation, not because the code really needs another human perspective. The human perspective for software comes at the very end, as the end user's feedback, but that's after PR merged.
  - ironmagma 6y ago
    Even “works” is not binary. Take for example this air disaster where the door closed but did not properly seal (even though it worked fine on most flights) and later opened mid-flight killing several people. The design was defended and any concerns about its functioning were dismissed until another plane had the door open on its own volition while on the ground. [1] https://en.wikipedia.org/wiki/United_Airlines_Flight_811 https://en.wikipedia.org/wiki/United_Airlines_Flight_811
    - proc0 6y ago
      I'm failing to see how it disproves my point. If anything this was human error, perhaps something that now is completely automated and tested by machine simulations. Machines are not "perfect" (for lack of a better word), however computers are designed to compute information, and the computation of information ultimately becomes the functionality. I'm saying here that humans aren't as good as machines at interpreting information (that is then computed by the machine) as the machines themselves. We only use humans where we really have to just because the technology and/or resources has not allowed it yet.
      - ironmagma 6y ago
        Yes, in the sense that all engineering design errors are human error. This is why we have critiques. Maybe something appears to work (i.e. doesn't give an error, or serves thousands of flights successfully), but that does not mean no changes are necessary. There are latent bugs that can pop up at any moment. Tests (including user testing) are guardrails; no one should be driving to their destination just by banging into the guardrails and letting that guide them. Not least because that's not what guardrails are for, but also because there are guardrails everywhere and they don't actually guide you in any particular direction.
        proc0 6y ago
        > Yes, in the sense that all engineering design errors are human error. This is why we have critiques. I'll agree to disagree... this is the reason we have automated tests, not why we have critiques. If you plot the quantity of human intervention in software development over time, I believe we will clearly see machines taking over in due time.
FooBarBizBazz 6y ago
She wasn't really talking about the technical side of engineering work here. Her examples are about written works (essays), and works of product design. It all hinges on the word "work". She's not talking about whether an artifact "works", but about an artifact as "a work".
- proc0 6y ago
  I missed that, sorry. it's hard to follow when it's a bunch of tweets instead of a normal essay with paragraphs. User experience, and design, ultimately does contain forms of art, so my comment would be different.

dhruvmittal 6y ago

As someone who got a CS degree in the early 2010s, I both 1) agree wholeheartedly that engineers should learn to critique work effectively and 2) disagree that engineers aren't taught this in school. At least my degree program included some efforts at code critiques and reviews. At multiple instances both early and late in the degree program, I was required to offer feedback as part of class assignments. This started with the first "Foundations of Programming" class, in which we'd submit written code reviews of other students' programming assignments as homework assignments. The professor/TAs would evaluate our reviews and provide their own feedback on how to write more effective code reviews. My senior year I had an entire "Software Engineering Lab" course, which required code review notes along with other deliverables for the course (team) project. Again, guidance was provided from the instructor on how to do effective code reviews.

jdlshore 6y ago
The thread explicitly states that it’s not about code reviews.

mrtweetyhack 6y ago

art and engineering are very different. One deals with precision while the other can be abstract.

NikolaeVarius 6y ago

I never understood why "engineer" has been redefined as only "code developers" Seems to leave out literally everyone who is an engineer that doesn't just do webdev. In the non web dev world, massive amounts of effort is put into having good, unpersonal triage and review processes.

FooBarBizBazz 6y ago
Personally, I drive a locomotive.
DaveExeter 6y ago
Can we stop calling programmers Engineers? I see this twitterer describes herself as "Staff Software Engineer at Mozilla". In other words, a programmer.
- mechatrocity 6y ago
  I agree it's frustrating. I'm a Software Safety PEng that does alot of compliance and standards work, and safety validation. My company is good about delineating between engineering and developers... But very few orgs outside of safety critical industries care at all
- bsder 6y ago
  And it's not even if you have a PE (Professional Engineering) license. For example, all the VLSI designs I've worked on had "design reviews". Always. And generally you had to pass several layers of automated design reviews before you could get to the layer of having a human review it. Why do software people think other fields all suck as much as software development?
- Twixes 6y ago
  It's entirely accurate - software development is a branch of engineering. The name doesn't come from a literal "engine" (though the origin is the same), it means "someone who contrives contraptions".
- david-gpu 6y ago

42droids 6y ago

Oh I always wanted feedback about my work (code) as a software engineer (good or bad) but never really got any.

sheer_audacity 6y ago

I agree with all this. It’s one of the reasons why so many products get built and fail - engineers of all sorts, not just computer programmers, need to consider why things need and get made and who for, even if they’re only concerned about the most particular of technical details. I think a lot of engineers could stand to take a formal graphic design/drawing/writing/critiquing class so they can better communicate and understand themselves better.

throwawaaarrgh 6y ago

Twitter is a really bad blogging platform.

ergot_vacation 6y ago
And yet everyone keeps using it, because everyone ELSE is using it and FOMO, real and imagined, is your lord and master. Due to the stupidity of the crowd we seem to be progressing backwards in tech now. I wonder if the Internet will eventually self-destruct and we'll all end up back on 1980s tech.

ergot_vacation 6y ago

Respectfully, what planet is the author from? Artists, and art students, are often the most vicious pit of vipers imaginable. On the flip side, there can be a lot of ego wrapped up in engineering and coding as well, but at least the field in general tends toward a more practical approach. As someone with a foot in both worlds, I'd say it's infinitely easier to collaborate with someone on a programming project than an artistic one, because it's easier to set ego aside when you're just trying to build a good tool instead of express something deeply personal.