What advice would you give students who are pursuing careers in web development?

Tomorrow I begin teaching the following 4 classes (80 students in total) at Clark College:

  • HTML Fundamentals (2 of these)
  • JavaScript
  • Introduction to Programming and Problem Solving (Python)

My question to you is what advice would you give these students regarding pursuing a career in web development and/or programming?

Thanks in advance for your comments.

Advertisements

Comments

  1. Depending on which side of the career path;

    – User Interface Fundementals, UI Prototyping & User Acceptance Testing
    – Design Patterns (MVC, etc.)
    – Server Side Technologies

  2. Serdar touches on a thought that I had but from a slightly different perspective – Career Path implying the need to specialize.

    I see there is a growing need to specialize as well as to generalize. Web Development has become a very broad and spawned many sub-areas of specialization (some of which have also become obsolete such as Flash/Flex development).

    In short, focus and excel at one (become a subject matter expert) or two things (don’t put all your eggs in the same basket), know a bit about a lot of other things (in order to be able to talk with other subject matter experts) and keep abreast of changing standards.

    My two cents.

  3. Start your company, learn to make a sale, fall down 50 times and get up 51, never give up, make friends and never let your work forget about your family.

    What, you meant technical advice on what to teach …

    Best, AL

  4. Portfolio, linkedin, stackoverflow, blog / personal site. All required for self promotion and future work.

    The portfolio and blog will really help get a foot in the door.

    Always amazes me when interviewing supposedly web developers who have no web presence.

    • Roy Rumaner says:

      Mark, a lot of times consultants write websites for internal sites and cannot legally show them to future employers. I have written sites for dozens of companies yet due to contracts cannot show you even one screen shot.

      • I agree Roy it is a problem.

        At the very least blog about a specific problem and then demonstrate how you solved it which is fine for specific technical issues. For look and feel maybe some prototype sites using different CMS technologies – WordPress etc. Push the boat out.

        The main thing is – if you’re doing web stuff I would want to see a web presence.

  5. Only being our of college for 5 years I can tell you what has helped my career the most thus far.

    1.) Open Source: Pick an open source project that interests you and get involved. You will learn more than you can in any college class. You will meet interesting people. You get experience working on a (virtual) team. You learn how to evolve your ideas. There are probably more benefits I can’t think of now. Oh and start your own open source project.

    2.) When implementing a feature write the code once then throw it all away and start over. Generally the first time you write something you are flailing around trying to figure out how to implement the feature. You are essentially discovering how to implement the feature and lots of times you end up with code that works but could be done better. After you implement it the first time go back and do it again, you’re guaranteed to do a better job the second time.

    3.) Learn how to give a presentation. You may think being a developer means you sit in front of the a computer all day and bang out as much code as you can, but that is not true. You will be asked to share your knowledge with others so you need to be able to convey your knowledge in a meaningful way to your peers. Being able to give a presentation that teaches and motivates people is a powerful tool.

    4.) Be agile. Learn how to adapt, and adapt quickly. New requirements come from all directions all the time, if you can adapt to them quickly you will be successful.

  6. Good tips for a career as developers are in the book “The Passionate Programmer” from by Chad Fowler, too.

  7. “When implementing a feature write the code once then throw it all away and start over.”

    This. A thousand times this.

    And I know you can’t say it to your students, Bruce, but my honest advice would be “don’t go to college.” A college degree matters for 12-24 months after you graduate. After that, any competent employer is going to want to see a portfolio. And a good portfolio makes the degree irrelevant.

    So forget spending money on someone telling you how to do something that you can learn for free on your iPhone.

    You don’t learn how to play drums or sing a song or take photos or paint or sculpt or write poetry or hit a baseball or sell widgets by someone explaining to you the theoretical underpinnings of art or sports or sales. You learn by practicing, and when you practice, you get results. So focus on the results of your practice, and then you don’t have to pay someone else to pretend that you know how to write a sonnet or do a one-handed roll or hit a homerun or design a good website; you can just DO those things and show the results.

    This is why working on an open source project has so much value. If you can point to a real project that you’ve contributed to, then you have measurable, peer-reviewed outcomes for people to evaluate, not abstract credentials. When I interview, the only thing I ask people about is what they’ve DONE. And anyone without direct, verifiable experience is expected to provide a portfolio. If you can’t, then you’re no more likely to get the job than a photographer who says “well, I don’t actually have any pictures I can show you.”

    I realize that’s kinda contrary to the idea that you’re teaching a class at a college, but for those particular students, I would say “take this one class and then drop out and get an internship instead.” 🙂

  8. If you’re just starting out, more than anything, ignore the technology-du-jour. Don’t go to “training.” Dogs go to “training.” Professionals educate themselves, based on good concepts.

    So, get a good grounding in basic concepts:

    1. Mostly, ignore “vendor training.” If you learn to use one vendor’s development tools, you know how to use that vendor’s tools. Rarely will vendor training give you the skills to extrapolate to applying good development practice to ANY toolset: past, present or future. The saying goes, “give a man a fish, he eats for a day. Teach him to fish, he eats for a lifetime.”

    Well, fark that. Vendor training perverts that into “train a man to fish for one kind of fish, and when that pond is fished-out, he’ll starve, clutching the newest version of his fishing gear.”

    You, as a developer, should know how to make your own fishing gear. You should also be able to teach others to make their own fishing gear. It’s not hard. Those of us who started out many years ago knew this in our guts. We knew how to make tools to make tools, and from that, we’re mostly all still able to handle any new fish that we see, no matter where we go, or when.

    If you can, go to college. If you can’t, learn from someone you respect who has, or someone who learned it the hard way, years ago.

    Do not buy vendor-supplied fishing tackle. When that pond dries up, so will your career. Ask anyone who was a dBase III+ “expert” 25 years ago. A lot of them are still standing in a mud bog, wondering where all the fish went.

    2. Learn needs (not “requirements”) analysis: if you’re going into a new build, and your magazine-reading client comes at you with “we need a PHP/Ruby-on-Rails/CouchDB/Jquery application that does…” you should get another client or re-educate your client with extreme prejudice. If you go into a situation where there isn’t already a running system (or where the existing system is so AFU you wanna invent a time machine, go back in time and punch the original developer in the yambag), then you should be in a position where you choose not just the approach, but also the tools.

    Put it this way: suppose you want to build a house, and you call a contractor to build that house. They show up, and you say, “here’s what I want, AND here are the tools I want you to use to build it.”

    And then you hand them a screwdriver, a toothbrush, and a roll of toilet paper. Yeah, they’ll get in their truck, flip you off, and drive away.

    YOU are the expert. If you’re not, you soon will be, or should be.

    ALWAYS keep an eye and and ear out for “what’s the best platform, approach and solution,” and resist “this is what everybody does, so I should do it, too.”

    3. Resist buzzwords. This is a derivative of Nos. 1 and 2 above. “We should be social! Is your app gonna be social? My buddy at the club said we have to be social!”

    Well, not everything has to be social. Not everything has to be antisocial. Or dynamic. Or even interactive. Dig a little and find out what the client really NEEDS, not what they think they want. If the client knew what they wanted and knew how to do it, they wouldn’t need you, now, would they?

    4. Seek simplicity. Avoid situations where a large committee of nontechnical people try to dictate a technical approach or solution. They hired you to be the expert, but if some dumbass whose VCR is probably flashing “12:00” at home tries to dictate a technical approach in which they are neither experienced nor capable, you are gonna get old before your time. Way before your time.

    5. Be inventive. The last thing you want to do is make your development look like Apple/Google/Yahoo/Facebook/Reddit/Wired/Fark. Those have already been done. In fact, they’ve been done better (or worse) than you as an individual could ever do on your own. Write honest, simple code. Seek durability, not flash (no pun intended). Code that works pwns code that looks cute every single time… EXCEPT in meetings with pinheaded clients who don’t understand deployment.

    6. Understand deployment. When I was a kid I drew the most beautiful race cars you ever saw. Somewhere in a landfill, on old paper notebook covers, those race cars still exist. They never actually had to roll up to a starting line. Your code must. Learn about the environment that underpins the code you’re writing. This could warrant an entire book unto itself, but hey, you’re a developer, right? Right. So, eff all that.

    7. Get friendly with the administrators of the environment in which it will run. Get REALLY friendly with them. Take them to Vegas and get them strippers-dancing-in-the-limo-drunk if you have to. They will tell you truths about the environment (see #6) which will keep you from writing code which will blow the servers to smithereens the moment your client lights it up. In turn, you can explain to them what you have in mind, and they can adapt their service environment to accommodate the sudden massive influx of happy, expectant users it will doubtless attract. Admins are your friends, if you let it be so.

    8. There is no Rule 8.

%d bloggers like this: