Javel Rowe

About

I think about problems using a simple structure:

  1. Context about the current situation.
  2. A goal someone in that situation wants to achieve.

The impediment to that goal should be easy to infer. If not, the problem is not well understood or defined.

All my experiences over my career have helped me refine my intuition for what this looks like in practice.

How I learned to see problems

  1. Business Analyst Intern

    Stakeholders agreed on what needed to be done, but "value" meant something different to each group, and this tension could pull the project in different directions.

    Requirements gathering and specification · Stakeholder interviews · Technical documentation · Change management

  2. Backend Developer

    Each layer between the client & me could shift the meaning and intentions behind the specs, and this was compounded by the invisibility of the backend.

    C# / .NET Core · Node.js · PHP · Adobe ColdFusion · Python

  3. Frontend Developer

    You can't predict how a real person will use an interface, and it's easy to design for how you think rather than how they think. So things that can make sense to the builder can still confuse, exclude or lose the actual user.

    HTML, CSS and JavaScript · jQuery · React · Angular and AngularJS · Tailwind CSS · Bootstrap · Bulma · daisyUI · Linting

  4. Mobile Developer

    Features had to be designed around what could fail. Here, constraints ruled, since the device, network & platform set limits we couldn't negotiate with & users tend to expect an app to just work.

    Ionic with Capacitor · React Native (Expo)

  5. Full-Stack Developer

    Speed can increase the effects of friction. Trust, rapport & empathy are needed to balance it and maintain momentum.

    Next.js

  6. Data Engineer

    Manual, fragile tooling can lead to developer effort being spent keeping things from breaking instead of producing required insights. Also, a process that doesn't seem beneficial but lasts for years usually has invisible beneficiaries.

    Power BI · ETL pipelines · SQL Server · MySQL · PostgreSQL · Database performance tuning · Stored procedures, functions and triggers · Perl scripting · Data cleansing, deduplication and enrichment

  7. Systems Administrator

    The work that kept everything running was invisible to stakeholders, so care and maintenance competed with pressure for immediate results, and this led to manual processes feeling extremely risky.

    Firewalls (nftables, iptables, ufw) · Nginx · User and access management · Update and maintenance scripting · Networking

  8. DevOps Engineer

    Stakeholders interpret the work through their own lens, and tools tend to contain the assumptions of the groups who built them. Trusting either at face value can lead to gaps.

    Containers (Docker) · CI/CD pipelines · Kubernetes · Helm · Terraform · Ansible · Argo CD

  9. What's next?

    Proposed research

    Investigating DevOps and the SDLC through boundary objects theory

    Research questions

    1. How do the tools of the SDLC work as boundary objects between the groups that use them?
    2. What values, biases and goals of institutions and market forces do those tools carry?

    Case study

    Containers and virtualization: why the same problems kept coming back, the context around each solution, and the trade-offs and market forces behind them.