I'm also a co-panelist on a little podcast called Greater Than Code
Experiencefull resume (PDF)
- Maintain ePublishing’s main legacy system, Jade. Track down mysterious bugs, write documentation and refactor code for cleaner design and maintainability.
- Collaborate with team to develop a complete overhaul for ePublishing’s admin panel (React, Typescript, Graphql). Write code with careful consideration for maintainability years down the road. Consult with team lead on architectural decisions.
- Lead company in adoption of Typescript for new and legacy systems. Advocate for the benefits of type safety. Consult with team members on Typescript related questions.
- Mentor junior developers with software design, style and architectural decisions.
Co-Owner and Lead Software Developer
- Deliver customer success by developing, maintaining and administering web applications for clients using Ruby on Rails and React.
- Build team productivity by collaborating closely with a distributed, remote team to deliver valued features to clients.
- Enable flexibility and agility in client applications by maintaining a complete test suite (RSpec) with continuous integration service.
- Ensure consistent production environments by creating Ansible playbooks to enable consistent server provisioning and configuration. Maintain deploy toolchain (Capistrano) for seamless deploys.
Technology and Data Systems Analyst
- Overhaul organization’s culture surrounding evidence based decision making by leading the development and operation of Ruby on Rails based accreditation web app.
- Enable agile based development by maintaining a robust test suite and deployment tools (Capistrano) to automate frequent deployments.
- Mentor and lead team of student developers to provide timely client support and quickly develop new features.
- Enable evidence based transformation by generating insightful analysis of organizational data using Python.
Building software is primarily a human endeavor. Any code that we happen to generate is merely incidental. The real challenge then is how we build sustainable systems of humans who can effectively interface with each other and the required technology to get stuff done. For that reason, software development must be a values driven profession. Here are mine.
Take care of your humans
There is a prevailing narrative among developers that we are like Vulcans, perfectly logical and free from pesky emotions. In reality, emotions are at the core of the human existence -- they drive our basic neurological functions. If someone on your team is made to feel unworthy, unintelligent or unappreciated that has tangible consequences for your team. It's not something they can just "get over" or "grow a thicker skin" about. To say otherwise is to deny basic psychology. We are all responsible for taking care of our fellow humans.
Speaking of which, I am a co-panelist on the Greater Than Code Podcast. Each week we delve into discussions surrounding the human side of tech.
Tech is changing fast. The people that make it are changing even faster. Whether it's a new front end framework, a deployment tool, or your co-worker's favorite new TV show, we need to have the curiosity to absorb new knowledge and skills to adapt to a quickly changing world. Not because our boss told us to, or because we're chasing a bigger paycheck. Because we are genuinely curious. Because we have questions about the world that follow us around until we find the answers.
Creative and Independent
This is related to the above. Systems are way too complicated these days for teams to function in a top down manner. The problems still left to be solved do not have copy/paste solutions. We need to creatively identify the problems and chase them down without constantly being supervised or told exactly what to do. With that said, when we are working with other humans, we need to be kind, humble, attentive, and receptive to feedback.
Not having the necessary skills is a challenge that can be solved. Assuming you have nothing else to learn is an intractable and dangerous problem in this industry. There is always more we have to learn. When we assume that our learning is "done", we open ourselves to making mistakes. Worse than that though, lack of humility makes us difficult to work with and spreads a toxic energy across our team and organization.
Productive Argument, or Hit the Horseshoe, Not the Anvil
Arguing can be productive when it pushes a team forward but it can also come with some nasty side effects. A team might work out the best solution by arguing, but if someone leaves the meeting feeling ignored or unappreciated its a net loss. If we're too harsh with our team when we argue they might not speak up the next time. I heard a fantastic analogy once that arguing should be like a horseshoe on an anvil. If we place a horseshoe on an anvil and whack it with a hammer, the conflict between the hammer and anvil is the force that can shape the horseshoe. Conflict works the same way. If we focus on attacking the subject at hand and not each other, we'll get the best results. Likewise if we miss the horseshoe and hit the anvil directly, all we get are sparks. Not very helpful.
Productivity is good. Generativity is better.
This one comes from Jessica Kerr's blog. In summary, its great when developers can be productive by shipping clean, maintainable code, fixing bugs, etc. Its ten times better though when developers can be generative, or when their efforts are a force multiplier that can help other people on your team also do better work. This could include contributing to documentation, mentoring new team members, or collaborating with other teams in your org. Think of it this way: would you rather do great work, or empower your entire team to do great work?
I work on side projects in my spare time primarily to learn new concepts. Here are some of my more recent ones.
I've been learning more about design patterns by creating toy examples and then reflecting on how design patterns can improve their design.
I'm practicing refactoring katas with a focus on Fowler's refactoring patterns and SOLID design.
A simple Active Record library for storing temporary orphan records.
An experiment in React hooks to create a general web form. Let's see how general we can make things!
Critical Response Talk
What does an innovator from the dance world have to teach us about code reviews? It turns out quite a lot! This is a talk about the Critical Response Process by Liz Lerman. Check out a video of it from Ruby Conf.
Generate a todo list of eslint errors. Enforce strict linting standards while letting existing ones pass until you can get to them.
A mad science experiment to automate setting up Google Tag Manager containers using React Ink. Describe your GTM containers in code rather than config files!