Ask Slashdot: Are General Engineering Skills Undervalued In Web Development?

nerdyalien writes After reading a recent post about developer competence, I can't help but to ask the question, "Are general engineering skills undervalued in web development?" I am an EE major. The course I completed, and the professors who taught it; mainly emphasized on developing skills rather memorizing reams of facts and figures. As a result, I have acquired a multitude of skills such as analytical, research, programming, communication, project management, planning, self-learning, etc.

A little over 3 years ago, I made the fateful decision to become a web developer in a small SME in SEA. Admittedly, I have an unstructured knowledge about CS theory. Still, within a short period of time I picked up the essentials of web development craft, and delivered reliable web applications. Most of all, I made good use of my existing technical/soft skills, despite the lack of my CS pedigree.

Recently I went through a couple of job interviews in MNCs, SMEs and start-ups alike. All of them grilled my CS theory or Java knowledge. Almost no interviewer asked me about my other skills (or past experiences) that could be helpful in the developer position. In my experience, web development is a cocktail of competing programming languages, frameworks and standards. Rarely a developer gets exposed to a single technology for a substantial period to learn it inside-out. Even still, in web development world, deep in-depth knowledge in anything will be outdated in few years' time as new technologies roll out. So, what matter's today? Knowledge on a particular technology or re-usable engineering skills ?

Comments

I hire EEs

[nhtshot]

I'm the head of software engineering at a small company and was a technical director at an MNC previously. I've hired hundreds of programmers.

I regularly hire EEs as programmers, but not for web development. Web development is mostly the bastion of very nimble, hacky types. As others have said, it's frequently more about putting together a reasonably elegant hack in a short period of time.

I hire EEs for board support and other embedded development. Those are the places where real engineering skills are the most useful. I don't want my BSP full of dirty hacks or hard to find/duplicate bugs. I want code that is planned, organized and well executed. That's exactly (in my experience), what I get from engineer coders.

The exception to my above generalization about web development is Java. Java backed websites (JSP and the like) are mostly developed by engineers and are used by large companies. If you want to maintain your engineering mindset and build websites, Java dev as a nameless drone at a big company is the way to do it.

Otherwise, I'd suggest boning up on your C and getting into embedded stuff. I personally find embedded work much more satisfying. It's also much easier to stay relevant without knowing the ins and outs of the latest NoSQL db or javascript library.

Re:No more or less than anything else

[ShanghaiBill]

More to the point, what the hell are "general engineering principles"?

A basic understanding of physics and chemistry.
Knowing how fluids flow, how solids bend and break, how light and electricity work.
Constructing a simple mathematical model of a complex physical system, while understanding the limits of the model.
Understanding how to solve problems, by breaking down complex problems into solvable sub-problems.

I have a formal training in engineering and no one ever gave me a set of general principles to learn.

Really? I have a four year engineering degree, and spend the first two years of that learning mostly general principles.

Re:There is no engineering.

[Balthisar]

The difference is that electrical, mechanical, civil engineers, et al, all have governing bodies and licensing requirements.

Except that vast majority of the working engineers in the USA aren't PE's, and aren't subject to licensing or other regulatory requirements. Some fields -- especially various civil things -- only require engineers to be overseen by a PE, but makes no requirement for engineers who perform the tasks. In most consumer fields no PE requirement exists.

Re:There is no engineering.

[NormalVisual]

My suspicion is that the term railroad engineer for the guy who drives a train derives from the fact that the first men who drove trains were the same men who designed trains.

I think it's probably more that the engineer was responsible for controlling primary aspects of the locomotive's engine back in the early steam days (boiler pressure, signalling, etc.), much as the fireman's role was maintaining the fire that heated the boiler, and the brakemen's job was controlling the brakes on one or more cars.

Re:Don't be so hard on him...

[dgatwood]

I have worked with many CS guys would couldn't code for shit because they never bothered to actually learn the language they're coding in, because according to them it's all just syntax. And the ones with the masters in CS are some of the worst developers I've seen.

Apparently, you've never read code written by people with masters' degrees in physics.... Talk about people not taking the time to learn the language....

The thing is, a master's degree in CS doesn't necessarily give you any real-world coding experience, and doesn't necessarily give you any real-world engineering experience. And there's a wide range of undergrad degrees backing that master's degree. Remember that a master's degree usually gives you a lot of theoretical knowledge, and a lot less practical knowledge. Most of a candidate's practical experience is likely to come from his or her undergraduate degree.

Want to find someone who really understands how to write software? Hire someone whose undergrad degree came from a smaller college (which is more likely to be closer to a trade school, with less theory and more practice), and ideally someone whose background is in something other than Java. Why? Java hides way too much of how a computer works, so Java programmers often lack enough understanding of what's going on under the hood to write good code.

In your interview process, ask obscure low-level architecture questions, like "What is a trap?" or "What does the BEQ/JEQ/JE opcode do?" These questions will rule out anybody who hasn't ever worked with any form of assembly language. From there, try to ask questions about their learning style to try to figure out if they are self-teaching (which tends to be a sign of a good programmer, because it enables someone to rapidly adapt to working on code that he or she didn't write).

Or find somebody with a master's degree whose undergrad degree came from a small school, and just assume that the odds are good that he or she was serious enough about programming to figure it out on his or her own.