From Woozle Writes Code
Jump to navigation Jump to search
Woozalia Nicola Staddon
Durham, NC — cv2019@woozalia.com

Executive Summary

How I can help you:

  • I design software/business systems and subsystems, either solo or as part of a team.
  • I can create documentation to any required level of detail. (I like documentation; it makes my job easier.)
  • I'm deeply into PHP and fluent in SQL (especially MySQL, though I have also worked with other variants)., with at least 5-10 k hours of coding time (best guess).
  • I am intimately familiar with Linux system administration, especially the LAMP stack[1]
  • I typically learn new technologies by using them, so am willing to attempt whatever other tools you might need me to become familiar with; in return, I will let you know if I see any better options.

Job interviews: I no longer do initial interviews via phone.


Immediate Long-term
  • Workplace must be a safe space with a culture that is supportive of diversity and the practicalities of getting work done.
  • I enjoy making people's lives better by solving problems. I also like being paid a living wage or better. I am willing to do work that primarily benefits shareholders and therefore aids in the concentration of wealth, but it will cost extra.
    • I will obviously want to know more about how your company or work is beneficial, how any profit is shared, etc.
  • I prefer to work remotely, but am open to other arrangements if there is a good reason for doing things differently.
  • I am not open to relocation on a permanent basis, though I might consider temporary relocation for a span of time.
  • Generally, I do not make or receive phone calls.Business communication belongs in non-ephemeral media. It may be nice to converse vocally on occasion, but this should not be the primary means of conveying important information or agreements.
  • No silly hoop-jumping, please.[2]

These are not deal-breakers, but if they are a problem I will agitate whenever I bump into them:

  • I am allergic to BS, especially the authoritarian varieties.
  • No cube-farms, no compulsory meetings for no apparent reason, no power-games or headgames.
  • Must use good collaborative software (project management, wiki, chat, etc.) and have good channels of communication.
  • No deep/sacred hierarchies. No "performance"-worship. There must be respect for the long-term sustainability of the enterprise.
  • Needs and requirements for any given project, or the impetus for evaluating needs and requirements, must be stated clearly and must not arbitrarily change.


  • 2018.05 - 2019.02 -- PaperDemon: creating and maintaining features for an art-sharing web site written with PHP, MySQL, and Smarty templates.
  • 2018.01 - present -- hosting/maintaining toot.cat, a popular (1000+ users) Mastodon instance
  • 2011.07 - 2014.11 -- Swashbuckler Interactive: creating and maintaining features fur multiple web sites in PHP and MySQL, often using Drupal.
  • 2007.09 - 2010.04 -- ResearchBuy: created MediaWiki skin to match PhotoShop images, integrated with PayPal to support content paywall; web site maintenance
  • 2007.09 - present -- Sage & Swift / Watts Grocery: network, web, email, and software maintenance for a catering business and a restaurant
  • 1998.11 - 2001.06.13 -- Carrier Transicold: writing and maintaining business applications using MS Access, Visual Basic, MS SQL Server
  • 1997.09 - 1998.10.19 -- Pierce Manufacturing: developing user interfaces in C++ for computer control of auxiliary systems in fire engines
  • 1990 - 1991 -- Duke University Humanities Computing Facility: developing neural network simulations for natural language processing applications in Pascal and C++
  • 1985 - 1989 -- Brown University: developing data collection and analysis programs in FORTRAN and Pascal for behavior research

A full history of my computing experience is here.

Further Reading


  1. ...though I'm still struggling with proper configuration of SMTP servers such as Postfix.
  2. Don't ask me to produce flawless code on a whiteboard or piece of paper. Whiteboard coding tests are silly and ineffective. I took one once, thinking it was just a basic test of familiarity with code – but apparently it actually mattered to someone that I made a syntax error. When writing freehand code. Seriously.