Crash course from political science to computer science

August 22, 2006 2:38 PM

How do I go from social scientist to engineer in a month?

How to make this story short… I graduated from a liberal arts college a little over a year ago, with a political science degree but a keen interest in technology. I’ve always been able to learn software quickly, but I’ve never done any coding more than HTML, VBA, and basic BASIC javascrp, etc. Anyway, I took a job in the Washington DC area for what I thought was a very highly respected management consulting firm. [Names are being omitted – both innocent and guilty]. If you’re familiar with this area at all, you might know that even the most respected consulting firms become beltway bandits down here, and I was very much part of the military industrial context.

After I reached the breaking point and couldn’t take the mind-numbingly boring work, I moved to another firm – still doing gov’t work, only now a different (more interesting) sector. This firm is known for its extensive systems integration consulting work, and the team I’m working on has learned that I have an affinity for technology. Now, I might be an official software developer (in the SOA realm) within a month – which is great, I’m very excited to be doing the work, I find a lot of what the firm does fascinating. But as interested as I am in technology, I’m not an engineer! I have no training in it at all.

So now that that's out of the way, my question has two main parts:

1) How do I start to learn to think like an engineer? IE working in terms of process flows, interations of development, etc. I know that half of engineering is thinking the right way. I've found that since I've adopted GTD about a month ago, I've started to think in this way anyway -- but other advice would be helpful.

2) What do you all recommend as a crash course in software development? SOA, system engineering, all of it

Any and all help would be MUCH appreciated…

posted by SanctiCrucis05 to technology (11 comments total)

SanctiCrucis05, for a social scientist, your "question" is phrased as dismissively to engineers as any about the profession that I've ever read. This:

"... I know that half of engineering is thinking the right way. ..."

being something of a backhanded example.

For what it is worth, in the 4 or 5 years one attends an American university to become an engineer, the main thing one learns to do is never take shortcuts. The reason for that is that, too often, in many of the disciplines, including aerospace, mechanical, electrical, nuclear, chemical and civil engineering, people are hurt or die when engineers make mistakes, or take shortcuts. So a big part of engineering is simply learning to have great respect for prior art, and the accumulation of craft knowledge over time. Not taking shortcuts is the lesson you have to thoroughly understand to impressively pile rocks, and it is still one of the hardest to get across to bright 18 year olds.

Nothing says an engineer shouldn't be innovative, but he ceases to be an engineer the moment he allows hubris to color his work ethic. One of the first places I worked in electronic engineering used to have a test that all new technical and engineering employees went through in the first week of work, that was mainly intended to check an individual's understanding of this.

The newbie would be assigned to strip down a fairly complicated piece of electronic equipment, whose chassis was held together with hundreds of small screws. They were told that the unit they were working on was required for life safety, and would be completely function tested and certified for safety after they completed certain upgrades on reassembly, and that they were expected to work as carefully as possible and ask any questions they needed to ask, if problems came up. The sub assemblies and parts removed were to be put in egg crates and anti-static bins, and certain sub-assemblies and circuit boards were to have been replaced on re-assembly. Sometime during the first day, a senior person would surreptitiously add 1 tiny screw to one of the parts bins. A couple of days later, when the newbie was reassembling the unit, he had to have that one screw, at least, left over, and know that he absolutely shouldn't.

Those that cussed under their breath, picked up a screw driver and started taking the unit apart again, without asking, to find their mistake, stayed. All others were let go for performance reasons. The accepted wisdom was that if a person had gotten hired through personnel, and didn't have the humility and honesty to admit he'd made a mistake in that circumstance, and immediately begin to work to find and correct it, he wasn't worth working with. And if he didn't have exactly 1 screw left over, he was sloppy.

Where in GTD do they cover that?
posted by paulsc at 3:47 PM on August 22, 2006 [15 favorites]

Great story paulsc and spot on about engineers being meticulous. I agree that the poster shouldn't expect to become an engineer in a month, but then I would also argue that doing SOA type software development is NOT engineering as you and I understand it to be. If peoples' lives depended on most of the crappy "enterprise" software I've seen there would be a lot more dead people.

Some practical advice from a software development point of view: always look for ways to simplify and compartmentalize your pieces of code. Shorter functions and unit tests are in general better. Read up on test driven development and agile programming- you may not put it all it to practice but understanding the point of view is helpful. Study up on design patterns. Read about the basics of software engineering and various buzzwords in enterprise development. A lot of people say this last one is a waste of time, and for people steeped in software development for years it may be, but it will allow you to communicate and understand what the hell everyone else you are working with is talking about.
posted by gus at 4:03 PM on August 22, 2006

I think you should take heart in the fact that most of the knowledge you will need for a particular software engineering job is specific to that job only. In other words the guys with engineering degrees that are starting the same time as you are just as clueless as you.
posted by bugloaf at 4:04 PM on August 22, 2006

paulsc could not have said it better. Even more important than the training behind engineering is the knowledge and experience that can only be obtained through years of work and exposure to different scenarios. A good engineer will take the education and experience and combine it to achieve the end results. Often (and rightfully so), many engineering teams are multidisciplinary to make sure that all possibilities are explored and no intentional or accidental shortcuts are taken.

In my opinion, the cornerstone of what makes a good engineer is someone who is a constant STUDENT. A good engineer will realize his or her limitations and make efforts to learn more material and gain more experience. To safely gain this experience, have a mentor or a more senior colleague help you out and include you in various projects. In many aspects of engineering, lives are at stake, so shortcuts, while seemingly innocent, can be deadly. As a chemical engineer, I've seen this firsthand in many of the refineries and chemical plants in which I've worked. While good business is always a top priority, the safety of people and the environment come first. ALWAYS. Engineering is a hugely ethical profession and requires much committment and respect.

It takes years to really develop the expertise and the "engineering sense" that you are striving toward. Just realize that this will be a greatly positive learning experience for you, and as long as you are open to exploring problems from every possible angle, you'll do well as an engineer. Stay open to all possibilities and realize that engineering is immensely rewarding as a career choice.

Best of luck!
posted by galimatias at 4:07 PM on August 22, 2006

I'm an international relations major who made the jump to computer engineer (M.S.Eng) between undergrad and graduate school. Frankly, I found myself agreeing with paulsc re: the tone of your question, and I tried to figure out how best to explain it using my experience. Here's my best shot:

You know how we polysci/IR folks grumble when people with NO PRIOR DIPLOMATIC EXPERIENCE buy or otherwise politically maneuver their way into ambassadorships, when we're the ones who have studied the topic and states for years on end?

You're essentially asking how to do the same thing in a different field.

Bottom line: you may be able to pass yourself off, at a casual glance, as a software engineer in a month, but I wouldn't count on being able to maintain that appearance long-term without some really intense work. Engineers, in particular, are trained to see through BS and can be harsh critics.
posted by aberrant at 6:40 PM on August 22, 2006

I have nothing against you, SantaCrucis05, but for God's sake, work as hard as humanly possible to understand what you're doing and what you're getting into when you take this job. I work for the government and see idiotic contractors all the time -- not to say that we don't have our fair share of idiotic govies. Unfortunately, a huge part of the problem lies with idiots in the government not understanding when idiots in the private sector have no idea what they're doing, however well-intentioned. If you're as tech-savvy as you say you are, read up on object-oriented programming and take an intro to programming course or two at a local university.

Software engineering isn't engineering, and computer science isn't a science, but there is a distinct method and framework of thinking that you need to grasp before you dive headfirst into code. A degree in computer science teaches you how to think about approaching software problems, not the actual languages, so don't fret the syntax. Please, please, please educate yourself, and if you find yourself getting in too deep, ask for help from someone with experience. Find a mentor and learn the ins and outs. Buy some books on software engineering from Amazon. Stay abreast of new technologies. Don't copy and paste code samples from websites to get the job done; it's unlikely they'll solve your problem, and they won't help you understand what went wrong.

Good luck.
posted by kdar at 7:13 PM on August 22, 2006

Beautiful story from paulsc, as usual.

And remember, "If you don't write it down, it never happened." Get a bound corporate minutes book with numbered pages, and a pen of your choice -- I like Uniball micro's, myself.
posted by baylink at 7:29 PM on August 22, 2006

I second finding yourself a good mentor. My jump from legal work to programming was hellish because I was self-taught. I lucked into working for an individual who personified meticulous but was also a patient and willing teacher. Having someone willing to sit down and discuss design patterns and conduct code reviews is gold. While I'm fairly useful nowadays, I'm still a bit unorthodox and that creates extra work on my part when integrating with formally trained compsci folks.
posted by Fezboy! at 9:17 PM on August 22, 2006

I'm an engineer, and I didn't find the "half of engineering is thinking the right way" comment that inaccurate. I might say it's more about confidence than thinking the right way, but fundamentally a can-do attitude is critical. Even people with engineering degrees aren't trained how to do everything. The point of engineering education is to make students solve successively harder and more complex problems, so they're used to dealing with future problems. This is why it seems to me like thinking the right way / being confident is quite important; problem solving is as much a state of mind as it is a set of practiced skills. In my experience, this is probably different from the kinds of skills you pick up in a liberal arts degree, but probably not that different from your days as a consultant.

Also, be prepared to get hammered on technical issues. Some engineers are nicer about it than others, but be prepared for harsh discussion about technical questions. It's not that people think less of you, it's that through discussion and debate, a group should hopefully be able to converge on the "right" answer. These decisions should be based on data, so brush up on your quantitative reasoning. It's not so much about crunching numbers, but understanding the numerical relationships between parts of your systems will be critical regardless of your field. If you don't have the numbers you need, go get them. Don't make it up, don't guess, get real data.

Good luck!
posted by heresiarch at 9:46 PM on August 22, 2006

"Software engineering" isn't really engineering like electrical, chemical, mechanical, civil, etc. It would probably be nice if it was or develops into one, but it's ... something else...

To illustrate, this SOA stuff seems to have come out in the past few years, and it will probably be forgotten in the next few. The thinking techniques (as opposed to the technological techniques) applied in any of the traditional engineering fields are much longer-lived than that, e.g. a little over a hundred years ago someone thought to apply the complex numbers to AC circuit analysis, and it's still used today. (I also recall reading that was one of the first applied uses of complex numbers. It's very interesting how far ahead the math is developed before the applications - A guy named Nyquist was coming out with stuff on sampling rates, a key concept in digital systems, pretty much before sampling was invented. He did it on telegraphs.)

For now, find out what language and environment you'll be programming in, and learn as much about that as possible. Do some tutorials and whatnot until you can get done what needs doing.

Later on, learn C. (If software engineering ever becomes a real discipline of engineering, I do believe that part of programming which becomes engineering is going to be based on something like C/C++ and not any of this fancy crap the kids use today.)
posted by TheOnlyCoolTim at 11:26 PM on August 22, 2006

Thanks for all of your responses. Paulsc and others, I am sorry if my tone appeared dismissive of the engineering discipline in any way. I did not mean to imply that one could become an engineer in a month, or that years of experience could be encapsulated by simply "thinking the right way". What I mean is that engineers (from my point of view) approach problems in a very unique way -- completely disassembling a problem to its smallest whole parts and tackling each part individually, slowly building to an overall solution.

When I posted my original question, I did not mean to imply that I could learn all the skills I will need in a month, year, or ever -- as several pointed out, one must be willing to learn continuously, and with technologies changing quickly, engineers may have to learn more than anyone else. However, I do think it is possible to begin the journey of "thinking" like an engineer -- learning to approach problems with an engineering mindset.

Let me put out a quick comparison. If someone wanted to learn college or graduate level economics, they clearly could not learn the necessary math or complex analytical approaches of econometrics in a short time. However, recommending a book like Freakonomics, The Undercover Economist, or the Naked Economist might demonstrate the ways that economists think.

Thanks for all of your help, and again, I apologize for any offense...
posted by SanctiCrucis05 at 12:09 PM on August 23, 2006