Art students learn to critique the work of others. Engineers don't, and it shows
threadreaderapp.com
threadreaderapp.com
In the non web dev world, massive amounts of effort is put into having good, unpersonal triage and review processes.
I see this twitterer describes herself as "Staff Software Engineer at Mozilla".
In other words, a programmer.
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?
I still find this sentiment hurtful after all these years. It comes across as demeaning of my credentials and my work.
Let's start with my degree. My master's degree reads "Informatics Engineer", a title that was approved at the national level by the EU country where I graduated. That alone should be sufficient in my opinion.
Degrees don't matter? What about people? When the exact work I do is performed by "true Engineers" then does that make it true enfineering? Most of my co-workers are Electronics Engineers and while they perform the same tasks I do, I have yet to see anybody question their worth.
Or perhaps my colleagues may be true Engineers, but the work they are doing is mere programming, as evidenced by a simple programmer like me doing it.
Maybe it's the processes we follow that matter. True engineering work involves design, documentation and review processes, after all. Well, the processes we follow come directly from EE best practices because that's the nature of the work we do (computer architecture). Software engineering also has its own similar design processes tailored to their needs. Not significantly different, I must say.
Maybe it's not the accreditation, the people or the processes. Perhaps the demarcation between engineering and programming is in the systems we design. They must be designs worthy of being patented, systems so important that people's lives are at risk if they malfunction.
I have a dozen patents -- none of them in software. I have worked on safety critical systems where death and dismemberment were expected consequences of malfunction.
What else, then?
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.
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.
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.
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.
> 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.
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.
[1] https://en.wikipedia.org/wiki/United_Airlines_Flight_811
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.
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.
It all hinges on the word "work". She's not talking about whether an artifact "works", but about an artifact as "a work".
User experience, and design, ultimately does contain forms of art, so my comment would be different.