Gregory J Pottie
Department of Electrical Engineering
AD
2.5
Overall Rating
Based on 2 Users
Easiness 4.5 / 5 How easy the class is, 1 being extremely difficult and 5 being easy peasy.
Clarity 3.0 / 5 How clear the class is, 1 being extremely unclear and 5 being very clear.
Workload 3.5 / 5 How much workload the class is, 1 being extremely heavy and 5 being extremely light.
Helpfulness 4.5 / 5 How helpful the class is, 1 being not helpful at all and 5 being extremely helpful.

TOP TAGS

There are no relevant tags for this professor yet.

GRADE DISTRIBUTIONS
50.0%
41.7%
33.3%
25.0%
16.7%
8.3%
0.0%
A+
A
A-
B+
B
B-
C+
C
C-
D+
D
D-
F

Grade distributions are collected using data from the UCLA Registrar’s Office.

44.4%
37.0%
29.6%
22.2%
14.8%
7.4%
0.0%
A+
A
A-
B+
B
B-
C+
C
C-
D+
D
D-
F

Grade distributions are collected using data from the UCLA Registrar’s Office.

ENROLLMENT DISTRIBUTIONS
Clear marks

Sorry, no enrollment data is available.

AD

Reviews (2)

1 of 1
1 of 1
Add your review...
Quarter: Fall 2019
Grade: A
March 27, 2020

Professor Pottie is very enthusiastic and always willing to help. However, his lectures can be kind of unclear and disorganized. I enjoyed the project aspect of this capstone much more than the lecture and homework part.

Helpful?

1 0 Please log in to provide feedback.
Quarter: Fall 2021
Grade: A
COVID-19 This review was submitted during the COVID-19 pandemic. Your experience may vary.
Verified Reviewer This user is a verified UCLA student/alum.
April 23, 2023

This review is for both 180DA and DB because it doesn't make sense to take both classes. This will focus on the capstone itself because frankly its what enraged me the most.

Someone in the engineering department frankly needs to relearn the engineering method/process high schoolers learn in their high school intro engineering classes because its pretty clear that they forgot, I don't know if it was Professor Pottie to blame or higher ups in the engineering department but someone organized this class as a burning dumpster fire.

The fundamental problem with the class is its backwards approach to engineering, engineers solve problems, in fact this is why the engineering method starts with "define the problem." Afterwards you have to define constraints, say what technologies you have access to to solve said problem and what costs should be reasonable. But ucla engineering apparently knows better. I'm not saying this because I'm a stickler to some sort of "engineering rules," I'm not, I'm saying this because the result was garbage.

Which leads to the fundamental problem with this class, **the capstone project starts out with giving you a list of technologies to use and asking you to solve a problem with them, AND YOU HAVE TO USE EVERY SINGLE TECHNOLOGY.**

I repeat, YOU HAVE TO USE EVERY SINGLE TECHNOLOGY. Your project idea doesn't need voice recognition? F*** you, you still need to add it. MQTT is too slow for your use case? F*** you, you still need to add it. Naturally the results are what you expect, instead of focusing on core functionality of the product to make a good product every single project ended up with near useless appendages that weren't actually needed but were just additions time had to be wasted on to satisfy the technology requirements. It's not just a solution searching for a problem, that would be annoying but still fine, perhaps occasionally a realistic constraint. This instead this is multiple solutions searching for a problem.

Any engineering firm that operates like this would go bankrupt, and rightfully so. A gang of orangutans drunk off a bottle of Smirnoff would run such a company better. And yet this is the finest education UCLA engineering has to offer.

I was excited for this capstone, I chose the major I did in part because I wanted to do it, it sucks that my ucla career ended on such a note. This pissed me off so much that when I remembered it a year later I decided to write this, hopefully its been improved since but idk.

Helpful?

0 0 Please log in to provide feedback.
Quarter: Fall 2019
Grade: A
March 27, 2020

Professor Pottie is very enthusiastic and always willing to help. However, his lectures can be kind of unclear and disorganized. I enjoyed the project aspect of this capstone much more than the lecture and homework part.

Helpful?

1 0 Please log in to provide feedback.
COVID-19 This review was submitted during the COVID-19 pandemic. Your experience may vary.
Verified Reviewer This user is a verified UCLA student/alum.
Quarter: Fall 2021
Grade: A
April 23, 2023

This review is for both 180DA and DB because it doesn't make sense to take both classes. This will focus on the capstone itself because frankly its what enraged me the most.

Someone in the engineering department frankly needs to relearn the engineering method/process high schoolers learn in their high school intro engineering classes because its pretty clear that they forgot, I don't know if it was Professor Pottie to blame or higher ups in the engineering department but someone organized this class as a burning dumpster fire.

The fundamental problem with the class is its backwards approach to engineering, engineers solve problems, in fact this is why the engineering method starts with "define the problem." Afterwards you have to define constraints, say what technologies you have access to to solve said problem and what costs should be reasonable. But ucla engineering apparently knows better. I'm not saying this because I'm a stickler to some sort of "engineering rules," I'm not, I'm saying this because the result was garbage.

Which leads to the fundamental problem with this class, **the capstone project starts out with giving you a list of technologies to use and asking you to solve a problem with them, AND YOU HAVE TO USE EVERY SINGLE TECHNOLOGY.**

I repeat, YOU HAVE TO USE EVERY SINGLE TECHNOLOGY. Your project idea doesn't need voice recognition? F*** you, you still need to add it. MQTT is too slow for your use case? F*** you, you still need to add it. Naturally the results are what you expect, instead of focusing on core functionality of the product to make a good product every single project ended up with near useless appendages that weren't actually needed but were just additions time had to be wasted on to satisfy the technology requirements. It's not just a solution searching for a problem, that would be annoying but still fine, perhaps occasionally a realistic constraint. This instead this is multiple solutions searching for a problem.

Any engineering firm that operates like this would go bankrupt, and rightfully so. A gang of orangutans drunk off a bottle of Smirnoff would run such a company better. And yet this is the finest education UCLA engineering has to offer.

I was excited for this capstone, I chose the major I did in part because I wanted to do it, it sucks that my ucla career ended on such a note. This pissed me off so much that when I remembered it a year later I decided to write this, hopefully its been improved since but idk.

Helpful?

0 0 Please log in to provide feedback.
1 of 1
2.5
Overall Rating
Based on 2 Users
Easiness 4.5 / 5 How easy the class is, 1 being extremely difficult and 5 being easy peasy.
Clarity 3.0 / 5 How clear the class is, 1 being extremely unclear and 5 being very clear.
Workload 3.5 / 5 How much workload the class is, 1 being extremely heavy and 5 being extremely light.
Helpfulness 4.5 / 5 How helpful the class is, 1 being not helpful at all and 5 being extremely helpful.

TOP TAGS

There are no relevant tags for this professor yet.

ADS

Adblock Detected

Bruinwalk is an entirely Daily Bruin-run service brought to you for free. We hate annoying ads just as much as you do, but they help keep our lights on. We promise to keep our ads as relevant for you as possible, so please consider disabling your ad-blocking software while using this site.

Thank you for supporting us!