Ask HN: Learning Engineering

#1

Post by xel02 » Sat, Jul 03, 2010, 6:56 PM UTC

I understand many people here are either from an engineering background or (like me) from a computer science background. In a lot of discussions people claim that engineering is a better background to have when it comes to problem solving.

I was wondering what are some good resources for computer scientists (or anyone) to learn the principles of engineering?

Re: Ask HN: Learning Engineering

#2

Post by schn » Sat, Jul 03, 2010, 7:18 PM UTC

Lego.

Re: Ask HN: Learning Engineering

#3

Post by MicahStevens » Sat, Jul 03, 2010, 8:39 PM UTC

Learn by doing, taking things apart, exploring. A good school helps too. And legos.. I'm not sure it matters whether you're an EE, or SE, or CS major. It hasn't in my experience, I know crappy engineers from each faith as well as good ones.

Re: Ask HN: Learning Engineering

#4

Post by wwortiz » Sat, Jul 03, 2010, 8:53 PM UTC

I can only speak from a more physical engineering (ME) persspective but the best way to become better at problem solving is by solving problems. To add to that you must also continue to solve harder and harder problems to improve at a steady pace.

Re: Ask HN: Learning Engineering

#5

Post by krf » Sat, Jul 03, 2010, 9:00 PM UTC

MIT OpenCourseWare - ocw.mit.edu - has a lot of engineering courses.

Re: Ask HN: Learning Engineering

#6

Post by CountSessine » Sat, Jul 03, 2010, 9:11 PM UTC

krf wrote: post #5

MIT OpenCourseWare - ocw.mit.edu - has a lot of engineering courses.

So does Berkeley - in fact Berkeley seems to have more core-engineering courses on the web and iTunes-u than anyone else.

Re: Ask HN: Learning Engineering

#7

Post by physcab » Sat, Jul 03, 2010, 9:16 PM UTC

heh, I'm exactly the opposite. I was a physics engineering major with an emphasis on electrical and materials engineering before I switched to more computer-sciency stuff for graduate school.

Having seen both sides, I don't think either discipline prepares you more for problem solving more than the other. It's all about your mindset.

What I will say though is that engineering problems are rooted in practical issues. e.g "This suspect is approaching security, do we have a machine that can spot them far enough away to interrogate them safely?" Science problems by contrast are more concerned with the phenomena, e.g "Does the suspect reflect enough light for our detector to pick them up at extended ranges given atmospheric turbulence?"

tl;dr If you want to be a good engineer, seek out everyday problems and solve them practically with a given budget and timeline. If you want to be a good scientist, learn to ask better questions.

Re: Ask HN: Learning Engineering

#8

Post by r3570r3 » Sat, Jul 03, 2010, 9:16 PM UTC

Principles of engineering is machine building. Then, it takes off as your interest. The funda of Machine building in Computer engineering is called Automata Theory. So, you can start with Formal Language and Automata. That along with mathematics forms the principle of any form of engineering.

Re: Ask HN: Learning Engineering

#9

Post by elg0nz » Sat, Jul 03, 2010, 9:42 PM UTC

CountSessine wrote: post #6

krf wrote: post #5

MIT OpenCourseWare - ocw.mit.edu - has a lot of engineering courses.

So does Berkeley - in fact Berkeley seems to have more core-engineering courses on the web and iTunes-u than anyone else.

And Stanford even has iPhone Programming classes. But MIT was the one who started it all, so some credit is due.

Re: Ask HN: Learning Engineering

#10

Post by mooneater » Sat, Jul 03, 2010, 9:45 PM UTC

I kinda like: http://www.alankennington.com/philo/eng.html after a quick skim.

I have a computer eng undergrad degree from a solid canadian school. I cant say we were explicitly taught "engineering principles", I wish we were. We learned mostly domain-specific principles, but there are some deeper cross-domain principles that are worth learning (like the link above includes).

I would add to the above, a very central concept is the "engineering trade-off" -- there is no free lunch, etc.

Another smaller one I like is "visibility", seeing clearly into your system and its state is critical to debugging/design and clear thinking.

There are also things you kind of learn by osmosis from doing projects and in the workforce. Like, dont overestimate how hard it is to do some custom work to create something new (a good FPGA programmer or C programmer can do amazing things in a week). And also, dont underestimate how hard it is to maintain said custom work (most university projects dont give a sense of maintenance cost, the overriding cost in the real world).