Q&A with Developers from Blackboard and Zoomph

I interviewed two professional web developers in an effort to get two different perspectives. Some overall takeaways are: both guys have amazing jobs that they really enjoy; both were somewhat self-taught and recommend continuous learning to keep up with latest trends; both are advocates of agile/scrum processes; and both provide great insight about working with communications/marketing professionals.

Hardian Muljadi, Senior User Interface Designer at Blackboard Inc.
Lee Kohn, Lead Developer at Zoomph

1. What is your professional background? Why did you want to become a web developer?

Mulijadi: My background was in computer science and business administration. My first job out of college was as a web designer, having experience in both website content management and development. I was very comfortable working in code, but I knew that I wanted to do something more that involves working with people; gathering requirements, figuring out what makes user tick, and designing a solution that solves their problems. Additionally, the web development field was on the rise, and with my background it felt like the right industry to get into.

Kohn: I became a developer because I’ve always liked building things and tinkering with computers.  Doing web development allows me to get paid to do something which has always been a hobby of mine.

2. Did you invest in formal training, or were you self-taught?

Mulijadi: I took some courses back in high school and college to learn the basics, but for the most part of my professional career I was self-taught. I followed many web design blogs and attended conferences to gain more knowledge on the field and meet some of the key players in the industry.

Kohn: I have a BS in IT from GMU which prepared me for a lot of the infrastructure and business related topics however most of my software development expertise has come from a lot of reading on my own time and on the job training.

3. What advice do you have for writers/marketers/project managers that would help make your job easier? Any tips for a more effective working relationship?

Mulijadi: Most are advice for project manager:

  • Don’t schedule unnecessarily long meetings; especially when it involves a lot of people, it’s a lot of wasted manpower and cost to the company. When facing critical issues, facilitate a smaller group with only the key people to tackle the issue at hand; stay with this group until the issue is resolved.
  • Be conservative at estimation; it’s better to deliver a working feature on time than to promise something more robust that is impossible to accomplish.
  • Update the team as often as you can on progress and due dates; in my company we have daily scrum meetings where everyone on the team shares 1) what they’re working on and 2) what’s blocking. Take advantage of scrums to get a sense of everyone’s progress and where you can intervene to help unblock issues so work can continue and project stay on schedule.

Kohn: I could go on for days about this one, but the top ones would be:

  • Computers are dumb.  They are only as smart as the requirements for the software and the person implementing the requirements.  It is of utmost importance to be very specific in requirements since details which are left out will require the developers to guess as to what the author meant.
  • Scope creep is very bad. Developers generally like to be flexible when it comes to changing requirements however the desire to be flexible usually comes at a cost to quality since last minute changes are generally poorly thought out and are rushed through development leading to bugs and poor overall quality.
  • The difference between can and should.  Software development is very open ended, computers can do just about anything you ask of them.  This doesn’t necessarily mean that you should do it. When developers say that something is possible they usually mean it is feasible; not necessarily that it is a good idea to do.  For example something may be possible but could require $100,000 worth of servers.
  • Please understand the difference between (web) developers and web designers.  Web designers are generally graphic designers who happen to know enough HTML and CSS to create a static web page.  They cannot make a website interactive (at least not well).  Developers are for the most part engineers who are focused on more ‘backend’ types of work such as databases.

4. What are some best practices you can share regarding web development?

Mulijadi: Technology is always changing. Everyday somebody figures out a better and more efficient way to do something. Keep up with the latest trends so you can anticipate market direction and cost of building things. Blogs, books, podcasts, and conferences are some of the best way to keep up with the latest and greatest.

Kohn:  This is another one that I could go on for days about.

  • Security within web applications is something that shouldn’t be taken lightly. Most non-technical people don’t even think about security related issues until they’ve been hacked. As developers it is our job to point out any security risks and develop secure software even if we are not explicitly asked to do so.
  • Plugins are a great way to get a site built quickly but will very often make tweaking functionality very difficult if you can’t read/understand how the plugin works. Also plugins can a lot of the time interfere with each other. Using them can be very tempting but in my experience they tend to be more trouble than they’re worth in the long run.
  • Code organization and quality are very important. You can get away with sloppily written and un-organized code while a piece of software is small. Once the size of the codebase starts getting large having a properly architected codebase becomes very important to maintainability and extensibility.
  • Comment your code. You may remember what that line of code does right now but in six months you won’t.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.