Slashdot Mirror
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 ?
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 ?
Most web sites seems to have far more engineering and art than they need, and far less UX that they should. I don't care how pretty and dynamic a site is if the user experience sucks.
and can not produce a decent web page to save my life.
I am very small, utmostly microscopic.
Yeah, they were probably all sitting there, reading through your resume, trying to figure out just what the fuck all of the acronyms you used in it actually mean.
I mean, in a fairly short Slashdot submission summary you managed to work in these:
I'm sure that you're dropping obscure acronyms in everything else you write, in some vain attempt to seem more important than perhaps you really are.
Unless you are going to be developing a site that is directly related to an EE field (mathematics/signal analysis/electronic parts etc), why would you expect your knowledge to be any more use than say someone else's knowledge of law ? If you want topics that would be useful but aren't directly related, art/art history/graphic design/advertising all come to mind.
I know from experience my undergrad was EE and I have Professional Engineering license and it really doesn't overlap much except for problem solving skills and logical thought.
If you are ever in a position to hire people, you will find it is the hardest business skill to acquire. HR people don't understand the types of skills technical jobs require, and hiring managers don't understand how to evaluate applicants on anything except technical skills.
The result is hiring on trivial but easily tested skills. I was just turned down for a job because, after 20 years of delivering successful projects, which I had documented, they wanted me to take a basic coding test, and I refused.
I'm not usually that ornery, but at some point I want the people I might be working with to show some common sense.
All I can suggest is you are going to run into this over and over, and the only thing you can do about it, especially early in your career, is learn CSS, JavaScript and JavaScript frameworks, and HTML5. You are going to need to learn them anyway.
As for Java, that's a big one, but you could get started. All of the tools you need are free and are available for both Windows and Linux.
but what you are really criticizing is the mediocrity of the hiring process
hiring a good team is perhaps the most vital function of a company, and so many get it wrong, in terms of who and what kind of skills they should be looking for
they'll hire the guy who knows the buzzwords of the moment, and ignore the guy who doesn't know the buzzwords, but could learn them in half a day and, most importantly, apply them with the requisite scalability, maintainability, versioning, testing, etc. that means the difference between a world class site and a brittle piece of shit
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
Being in Webdev for 15 years I can say that getting the job done quick is all that counts. Most of the web is run by the bizarest of contraptions in software you can imagine - but they get the job done. Take for instance Wordpress: It's a prime example for bad software architecture and the inner platform antipattern.
But it works. It delivers, Any idiot can download and install WP, pop in a theme and start fiddling. The webev gets called in when the system is all gummed up and feature x,y or z has to be added with magic programming trick (i.e. dirty hacks) quickly.
Same goes for PHP as a PL. Strange, bizar and hilarious, but it get's the job done.
That's what counts.
All that been said, it's precisely because of this that your skills as a webdev determine wether you'll have some freedom to pick your job and a fair salary or if you'll be treaded badly. I've been through so many projects that I can tell you even the crappy devs don't mean it. If there's a crew of 5 coding without versioning, that's because their to dumb to know any better and they won't listen to you if you're not ready to walk out of a job that only pays you a McDs salary.
If however, you've got the skills and the tools, most people will think you're a demi-god. Use whatever technology you want, but be able to deliver. I've started building my own toolkit a while ago - it involves bash-cli snippets and PHP code - and dive into any mess my client/boss requires me to work with, be it Wordpress, Drupal, Joomla or whatever. I've since become good enough that I can make some demands, but I have no illusions about my outlook in the webdev world. It is a volatile occupation and unless you move into Java/Oralce, SAP or MS territory, it will stay that way.
The upside is the freedom we have. We get to use FOSS most of the time as primary tools of trade and get to try out new things 5 times a week - neat. You can't have it both ways.
In a nutshell: If you want to stand your ground, you have to be good at both: Overall problem solving experience and proficient expert knowledge in the current tools of your trade. If you stick to building those mostly from tried-and-true FOSS technologies, you'll keep pointless learning to a minimum. For instance, I make a point of using grep to search for snippets of code in a project. My IDE may be dead 3 years from now, as may be the system I'm using. grep will be around until I die.
My 2 cents.
We suffer more in our imagination than in reality. - Seneca
Engineering knowledge and skill is way undervalued in the current development climate. It is more about get it done fast, get it out the door. Don't make the code pretty, don't make it reusable, fix it later attitude. Patch it up, put a bandaid on it and move on to the next fire.
The only place I have seen where engineering skills are valued is where lives are at stake (nuclear reactor code, Space Shuttle) or enterprise software that has to be up 24/7 or the business fails.
Welcome to the real world.
Oh dude, you're so overqualified for anything in Web Development.
CS, CS is bogus and only really quantifies anything if you're working in Artificial intelligence or Security. The rest of the time, a CS degree is just acts as a warranty for the interviewer that you supposedly knew enough book facts to pass an exam.
Like, I kid you not, most of the crap people work on in Web Development are bloated Javascript frameworks, or bloated Ruby/PHP/Perl backends, and very few people actually know how to make efficient use of the hardware because none of them know exactly how hardware works. Hence we keep seeing further inefficiency by switches to virtual machines and "cloud" virtualize-everything.
I'll give you a very-obvious example. Lots of sites like to use WordPress. If you compare Wordpress to a flat-file (using only javascript, what was formerly known as AJAX (eg Web 2.0) using only flat files, you have 1000X the capacity on the machine with the flat files. The solution that everyone uses? Throw more hardware at it. So instead of optimizing the CMS so it generates cacheable flat files requiring 10 times less hardware, they instead buy 10 times as much hardware and virtualize it on demand.
Like I see so much waste "cloud" setups it's no wonder that cloud providers are making money hand over fist.
I am also an EE by training, but now write software exclusively, mostly embedded software, and I also dabble in some web development on the side. To me, the general value of any kind of engineering education is that it trains you extensively in problem solving. Although I learned a lot of specific things that I use on the job, the general thing I learned was how to solve problems. I also gained the confidence that problems which seem unsolvable at first could always be solved with a systematic approach and persistence.
I'm not claiming that learning problem solving skills is exclusive to an engineering education, but just that it's a particular emphasis of that. It's a very general and valuable skill that's applicable to many fields. In this example, perhaps you "solved the problem" of doing web development by taking a systematic approach to acquiring the skills needed, and persisting until you mastered them. Of course, anyone can do that, and there are plenty of capable self-taught web developers who aren't engineers, but your EE training certainly doesn't hurt.
I've spent about 20 years refining my programming stereotypes. I think they fit the data pretty well now. Here's my take on you, simply because you're an EE:
* You're smart enough to pick up pretty much any CS concept, from the simple to the arcane. For the most part, only physics majors will simply be smarter than you.
* Your code will look like crap, until you put effort into writing more idiomatically and until you learn the design patterns that help programmers use to tame complexity. Your code will, generally speaking, be harder to read than that produced by CS and physics majors, until you put some work into it.
* You mentioned having only a fragmented understanding of CS theory. I think that's true for most of us (I have a PhD in CS). There's just so much of programming for which good theory has been developed: type systems, parallelism (concurrent sequential processes, deadlock rules), user interfaces (kind of), system complexity, static / dynamic analysis of code, relational algebras, parsing, the expressive power of various languages in the Chomsky hierarchy, graph theory, complexity classes, etc. A lot of these theories can be useful for solving problems, but most programmers muddle by without putting them all together and remembering their implications. Heck, most programmers probably don't know about half of the things I listed.
So I wouldn't feel too anxious about that, especially w.r.t. web programming. But it can be very satisfying to to learn more about them, and may in some cases let you solve some problems that other's can't. If you want to get better at some of the brainier stuff, I'd suggest getting a master's degree in CS from a decent school. But that my be overkill for bog-standard web development, I'm not sure.
Web and other programming is just that and is not engineering.
I saw this happening in the mid 90s - programmers insisting on calling themselves engineers.
I do not know why this happened other than the pathetic egos of our profession and engineering envy - like economists have physics envy. Somehow, programmers got it in their heads that being called an engineer is better than being a programmer or software developer. Why? I have known plenty of engineers who couldn't lay down a decent program. Spaghetti city!
Me, I'm just a programmer - thank you very much. I am not an engineer because I do not have an engineering degree, the experience or the exams that says I am.
HR wants 10 years experience in something that was invented 5 years ago.
If you have bigger-picture skills, you might be tempted to think for yourself.
Sheesh, evil *and* a jerk. -- Jade
Like most engineers, you're under the impression that your "magic ring" should automatically be given respect. Your whole post just screams "prima donna", and THAT'S your problem in interviews.
I do not fail; I succeed at finding out what does not work.
Within the web development industry, which the submitter is referring to, "CS" is often taken to refer to "Adobe Creative Suite". You know, it included Photoshop, Dreamweaver, and lots of other tools that are popular within the web design and development industry. Even since the switch to Create Cloud, a lot of people still refer to it as "CS" out of habit. Computer science isn't their first thought when hearing or seeing that acronym.
Again, within the web development industry, "EE" is first and foremost known to refer to the "Experts-Exchange" website. Electrical engineering isn't the first thought when hearing or seeing that acronym.
So the submitter probably is using acronyms that he thinks mean one thing, but the audience he's expressing them to takes them as having a totally different meaning. Then he wonders why they don't value him. It's because as far as they're concerned, he's talking gibberish to them.
The companies are probably looking for the cheapest code monkeys they can find and thus don't want to pay for any other skills.
I'm a consultant - I convert gibberish into cash-flow.
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.
Since I don't know much more about IT than the average human resources guy, maybe my experience can be useful.
I taught myself how to write spreadsheets, and wrote a lot of them for my own personal use.
Then I talked to a guy who had been an engineer and programmer, and came into corporations to teach other people how to use spreadsheets.
He made the point that, when he wrote a spreadsheet, he included error-checking routines, such as calculating things in different ways, that would catch obvious mistakes in the spreadsheet.
For example, in a checkbook program, he would calculate the balance on each line by adding the debits or subtracting the credits from the previous line, as I did, and get a running balance.
Then he would separately total the columns and get the balance by taking the difference between the totals.
They should be the same. But if you made a mistake, they might not be.
People have made a lot of expensive mistakes by calculating the total of a bid but getting the range wrong.
This is a deliberately stupid example, but it's stupid enough that it was news to me (because I was self-taught), and it's stupid enough for an HR guy to understand.
I would suggest that you think up a few examples of how your general engineering and EE skills gave you insights that helped you write a better program, examples with obvious utility, examples that are simple enough for an HR guy to understand.
Since the HR guy may not even understand programming, you can give him a quick course in programming, which will demonstrate your educational skills as well.
It is true, my post isn't shit.
I am very small, utmostly microscopic.
Well, you apply for web monkey work, they're going to see if you have the essentials. If you don't, forget about the "nice to haves".
Let's reverse the scenario - a web monkey who applies for an engineering job because he's worked as a web monkey at his previous job - an electrical engineering contractor - and has picked up some of the basics over the years. He'd be shown the door pretty quickly.
I tried for several years to teach an engineering friend how to code. The problem is that he couldn't get into the minutiae. The mindset is simply not the same.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
It used to be that you'd go in and you'd be asked to talk about the projects that are on your CV, talk about what challenges you faced and how you solved them, and you'd be asked some basic technical questions to confirm that you hadn't completely made it all up.
Now, nobody gives a crap about your CV. The last time I went through it, to be a PHP/MySQL developer, the tech lead or whatever came in without my resume in hand, gave a curt look and a limp handshake, and launched into it:
"I have 3 questions."
First off:
"Design a game of blackjack." with no further explanation. A silent stare as I asked for clarification. Okay you want me to give you an object model. Doing that.
Much pain later and condescension and derision later (yet in my opinion done well enough to be functional,) comes the second question with only 10 minutes in the hour remaining:
"Design an algorithm to efficiently sort a list of trillions of elements."
And I barely got off the ground on that one. Bounced some thoughts at him with the same derision and impatience in return. Needless to say I never got to hear what the third question was.
His colleagues were not much nicer. I didn't get the job, but fuck them. I wouldn't want to work with these miserable assholes anyway. As I was walked out I saw their big developer pit or whatever they call it, this nightmarish contraption with no privacy and all this agile frenzy going on. No windows, all artificial light in the middle of the day, these giant monitors mounted on walls showing the build status or whatever the fuck, this cheap synthetic carpet, not a single person smiling. I'm sure they are very productive and God bless em.
OTOH, yup, I'm still looking for full time work.
I think instead of asking if it is really necessary to know CS theory and/or Java, you should just learn them for your next interview. Too many people have this "I can learn it easily" attitude and think it is enough, but that does not mean shit to an interviewer. Companies want people who can hit the ground running (i.e. people who already know their shit). You might as well prove that you "can learn it easily" by actually learning it.
I have a degree in Physics (and not an "easy" one) and I have found that my extensive math is usually a significant advantage over CS guys. So I could see how some things from EE could be useful, especially if you were doing much in the telecom/signal processing etc type of EE stuff. Then again I also have a Master's in CS (good US Uni), so I guess it is different. You can brag if you know more than other people in a field, but you can't do it if you are at least as good in the basics... ;)
Violence is the last refuge of the incompetent. Polar Scope Align for iOS
Web Developers are craftsmen not engineers and generally know little about what it means to be an engineer, despite all the automated tools they have at their disposal.
My engineering degree has prepared my for a job in IT in 2 main areas. First, critical thinking, and second, envisioning/building systems with many moving parts. Basic concepts like UID/GID, and file permissions may seem core to IT Skills, but are the last thing that seem to be foundational to many SW developers. Also the ability to think on ones feet, to build a system of moving parts, into a system of many more moving parts. So many of my Graduating class have switched to IT jobs. Civil, Mechanical, chemical, even Electrical gearheads have made the jump. Reason? We are trained to think and consider all the details. Why, its where the money is. Want a foundationally sound system? Pair a software/Visionary with an Engineer and you will get solid/durable results. Be sure to spec out the requirements, the expectations, and the succcess criteria.
Time for a new Political party in the US (or two!) One is off the rails Other cant pony up a leader.
That is why you were not asked about them. In most cases, web-developers are the bottom of the barrel, spotty CS skills at best, no other engineering skills at all. The interview process you experiences tries to make sure the people interviewed are not completely incompetent, nothing more. You are vastly overqualified.
And no, this is not prejudice. I did run into really badly done mission-critical web-applications repeatedly and in different places and tried to find out why they were made so badly. Turns out this is standard. Best so far I found are a couple of web-developers that cannot manage to read and understand the teo content pages of an RFC, where half of the pages are pictures. The one using a self-written bubble-sort to sort an arbitrary large array in Java was also nice.
Also relevant: http://blog.codinghorror.com/t...
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Web developers have engineering skills? Stop the presses!
Scruting the inscrutable for over 50 years.
I can't comment on why or why not you've been able to land a web developer job, but I'll pop in with a bit of related but unsolicited career advice: Look for a job where someone is building devices for the "Internet of Things." There are plenty of embedded systems companies which value the type of skills which came with your EE degree, but have no staff with a background in web development. As they look to get their devices on the internet, someone well versed in the mix of technologies involved - and can build a usable web UI - will be in demand there.
The general idea behind good engineering. Sit down do all the work and build your product. With Web Development or any software development with a lot of end user interactions. The engineering methodology towards development is doomed to failure, unless you happen to have a large marketing engine behind you to push your product.
The first mistake: Collecting your requirements. In development this is an iterative task. As the end users really do not know what they wan't have of them aren't even sure what advantage your product will have to bring.
The second mistake: Prototype. The idea of a prototype is a functional equipment made before mass production. In software Mass Production is not the issue. So you are actually just making an equivalent of a Clay model. for your prototype. This will at least start to spark their imagination so you can actually collect real requirements, however you get stuck in a lot of complaining, how the colors are off, or you are using the wrong logo, or the fact the data is not saving. You get a bunch of non-requirements from it. As a side note. I once released a prototype software back in the 1990's we just recently got a CD Burner, and a CD Labels that we can print too. So when we distributed the prototype, I printed a label with some fancy graphics, and put it in a jewel case. Some bonehead got his hand on the prototype system, impressed by the graphics on the CD and Jewel case. and Installed it over his version of the software and wrote a nasty level on how horrible the new version of the software was, how half of the screens didn't work, and how he deleted all his existing data. Needless the CEO of the company blasted him back and told him how much of an idiot he was, for installing a software labeled in big writing "PROTOTYPE" and expecting it to work like production software, and also for Installing software he wasn't suppose to install on his system anyways.
The third mistake: Requirements and spec signoff. The requirements and specs are not done until the product is done. Any assumption made early on may be a major issue later. You decided to use HTML Tables and you found out they were slow for large data sets so you needed to switch to divs. Or you were suppose to use divs but getting the CSS just right on the required browsers is near impossible, so you need to switch to tables. The original data format took hours to process, while a different format takes seconds.
In general with modern software development engineering principles don't work too well, as the IDE and coding is the design process, and the steps of making a formal design with a bunch of flow charts etc... Is for a large part just redundant.
This is for software that is intended to end user interaction (Web development). These engineering skills are much more useful for back end type of work. Where there is a fixed process and you just need to have the computer do the work and you really don't care about making it look nice to the end user.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
I see that there are lots of silos within the SW profession. The 2 biggest camps are MS dotNet and Java EE based tech. Then there are lots of sub types. At one time, I use to be a Jovial programmer working on big DoD projects until I got laid off. Most of the interviews questioned lots of language specific stuff. However, I felt that my biggest strength was in SW design and analysis, and SDLC. No one asked me questions about that, as I suppose they thought it was hard to evaluate an answer.
Lately, I have become a Java programmer and had a C++ interview. I use to know C++ quite well, but after being away from it for a while, I even forgot a lot of that. My first observation was that if you don't keep up, you fall behind quite rapidly. On top of that, it is easy to juxtapose knowledge between the two. For example, while working on Generics in Java, I could not keep my syntax straight and used patterns from C++ templates.