I work for a small company that manages software for the parking lot industry. The software that we produce is accessed online and users pay a monthly fee for the service. The term for this is called Software as a Service (SaaS). In theory, we're taking advantage of the ever-growing reliability of broadband Internet connections, the ease of HTML markup, and the continuous revenue of monthly payments. In practice, however, a multitude of interesting -- and sometimes frustrating -- considerations often leave us in a nearly constant rush for project deadlines, bug fixes, and version updates.
My job as a Web developer is to keep up to date on as many emerging technologies as I can so that we can use the full power of the Internet. Core technologies, like a server-side language (in our case, PHP), SQL, and HTML are always in use, but other technologies like Ajax, Dynamic HTML and Web services also come into play. One handy skill set is the ability to work with developers who are outside of our company.
My day often begins by checking email to see if any of our customers have found a lethal bug in our product or have just requested something new. My manager might also add a thing or two to the list or just further prioritize what's already there. However, the operative word here is prioritization. Fixing smaller stuff first is good if it calms a restless customer, but sometimes even the small things need to make way for a heavy-duty project that has to get done. The telephone is never quiet for long.
Because we're positioned on the Web, we're able to transfer data to and from other Web sites (currently implemented via a hodgepodge of legacy and modern methods). So, there are times when I'll need to call up developers and discuss the setup or maintenance of these systems. Some are much better versed in protocols and technologies than I am, while others much less so. It helps if you have a basic familiarization with the languages and setup of other platforms. Also, it's good to be able to understand and troubleshoot code that was written by someone else years ago.
In a smaller company, you really have to pull your weight. If an API needs to be learned, it's a sure bet that you'll be the one learning it. In many cases, you'll write the code, check it for errors, test it, assist when it's deployed, and refractor it when bugs are discovered. You will personify the software development cycle. A day that isn't hectic will cause you restless unease.
Working for a small software company means that I get to learn a lot. I get to play with things, test them, and often choose my own path. I end up making important decisions, although I am relatively new to the field. It’s the greatest feeling in the world when something major that you built ends up really working. A perfect candidate for a job like mine would be someone who is enthusiastic about learning new things and not mind taking the initiative to create new project ideas or direction. You also need to have the stamina to work with end-users. If your significant other says that you play on the computer too much and you have too many computer books, then you're probably on the right track.
If you would like to submit an article providing an insider's view of your tech or engineering job, please send your article to us at ITtrenches@dice.com.
Many hiring companies who use Dice search our resume database before posting jobs. That means many of the best jobs are never even posted. Post your resume now, and be sure not to miss any opportunities.