The Tools I Use: Erin Marchak

Our passion lies in making everyday work experiences better, so a big portion of our work is devoted to examining what people use every day to get their jobs done.

We constantly examine and reexamine how we can make employee tools and experiences more efficient, more user friendly, and ultimately, better.

It is perhaps unsurprising, then, that we have some fairly strong opinions about which tools serve our own needs best.

With that in mind, we decided to get some of our developers and designers to tell us about their favourite work tools. We’ll be sharing their recommendations in a series we’re calling The Tools I Use. What we’ve found so far is an interesting mix of popular tech solutions, lesser known but highly specialized tools, and even some analog choices that just can’t be beat.

Throughout the series, we’ll be highlighting why the tools were chosen and trying to get a better handle on what to look for when choosing new tools. After all, you know what they say: Understanding employee tools starts at home. (Fine, they don’t actually say that. But they should!)

For our first installment, we’ve enlisted Erin Marchak, Drupal Practice Lead and Senior Developer here at Myplanet on the tools she uses.


So the tools that I use are divided into two areas: As a technical architect on a project, I’m given a lot of time and responsibility for the DevOps process, so I have a handful of DevOps tools that I really enjoy using. And for my own personal stack, I develop in Drupal — which is PHP — so I have specific tools geared towards that.

Tool 1: PhpStorm IDE with Xdebug

The first tool I’ll mention is PhpStorm IDE, which I have set up with Xdebug. Setting it up properly and having a fancy IDE actually gives me a lot more guidance and assistance. Better stated, it assists me in developing code, so I can develop faster.

If you have your IDE set up properly and if you know how to use type hinting correctly, it can autocomplete and hint code for you.

Let’s say I’m going through a process and I have a class I know I need to perform some kind of action on — if I have my IDE set up for proper type hinting, it actually gives me the whole selection of methods and properties available in the object. I could actually go and explore!

When you’re in a new stack, adopting new technology, or you’re in something that doesn’t have a lot of documentation — such as new work with Drupal 8 — this can be incredibly helpful because you can start really pulling things apart.

Now, in my experience, if you’re a developer that has a proper debugger such as Xdebug, you’re going to speak highly of it, and if you don’t have it you probably don’t understand why it’s that useful to set it up. But being able to step through the code and look at everything at every point and manipulate it as you go really helps you catch those edge cases.

We do a lot of data import. With my Xdebug and PHPstorm, I can easily inspect what I need to without dumping the whole feed in and going through each individual option one by one, but also still flag different points for interest. It really helps with inspecting the code.

In addition, at least with PHPStorm, you have automated code clean-ups and suggestions on how to properly tidy, clean-up, and document your code. You’re able to hook that in to Drupal standards, so it’ll actually give you warnings when you’re not writing perfect code. Basically, it takes a lot of the stuff that should (or could) be automated when writing code and allows you to get on with the creative parts, such as inspecting and thinking of really interesting ways to build your application.

Many of the lighter, more front-end options such as Atom and BB Edit are missing the strength of the IDE. The comparison I make would be somebody that is drawing with just a pencil versus somebody that is drawing with a full set of different textures of charcoal. There’s just more power to it and that helps you really pull apart more complex code.

Having an IDE — especially one that’s specific to your environment — is really helpful, because there are different caveats. And having the pleasure of knowing what’s going on and not being stuck because you’re confused about what’s happening behind the scenes is really, really nice.

Tool 2: WebAIM WAVE Web Accessibility Evaluation Tool

In terms of other development tools, I do a lot of work in accessibility driven development and there has to be a component of manual testing for that. If you’re trying to test a screen-reader or you’re focusing on somebody that uses zoom, there’s a human aspect to it that you can’t get rid of. You simply can’t automate that.

But… Tools that do automate the easy things, such as the WebAIM WAVE Web Accessibility Evaluation Tool, allow you to catch really simple things. It’s about automating the work that can be automated, so that you as a developer can go in and do the creative work that you need to do.

You want to have your full attention on solving the complex problems, not getting bogged down solving the simple ones. Catch all of the stuff that can be easily caught and fix it faster so you can go back and look at the creative problems, the difficult ones that are only caught through manual testing.

It bears repeating that with automated accessibility tools — if you use only them — then you are missing out on the actual problems that the users are dealing with because there are a lot of behavioural concerns with accessibility.

How do things work? Is it obvious what’s happening on the page to the user? All of that needs to be done by an actual person — either using assistive technology or being very empathetic in the process (probably both). If you don’t manually test that yourself, then you’re going to be missing out on all of those nuances of the site.

It’s the same way that we do user testing with people, not robots, to see how users are actually using it. Accessibility testing is just a specific variant of user testing. The easy stuff that you can catch by automation will help you dive into that human component better, because you’re not sorting through stuff that can easily be caught by a computer.

Tool 3: Drupal Console

For specific Drupal development — and I’ve talked a lot about this in the past within our organization and at Drupal and Dev events I’ve been to — I really enjoy Drupal Console for Drupal 8.

It’s a command line tool that allows you to bootstrap or scaffold code. So, again, it’s taking the stuff that can be automated off of your plate. It generates template code for new pages, for forms, for configurations, for different entities — all of the stuff that is fairly standard and repeatable — and it generates that for you as a scaffolding, which is a template code. That way you can actually get in there and start doing the interesting logical bits without having to define all of your classes and dependencies.

As a PHP developer, the tools I recommend often centre around helping to automate your development process and helping you become more efficient and effective. Bear in mind, however, the specific tools that I suggest are ones I haven’t personally tested out in a javascript environment, so they may be totally different or ineffective in those deployments.

The important thing is to find the tools that allow you to simplify your process and remove some of the more tedious or thought-less tasks associated with development work. That will allow you to open your brain space (and free up your time) to the bigger, more complex, and frankly more interesting parts of your work.

Tool 4: GitHub

Aside from the nitty-gritty work of coding, there are tools I rely on for knowledge share or to help with personal development — for myself and for the people I work with.

We use GitHub heavily, and within that we use GitHub issues and GitHub pull requests. When a developer is finishing code and they have it ready to be merged in, we do a peer review. Then people on the team do a peer review and we comment and discuss the code.

Within GitHub issues and pull requests, you’re able to do in-line comments, you’re able to link issues, you’re able to discuss different things. And being able to have visibility into the code and discussions around it is really helpful, especially when you’re working with a team that might not be as experienced with the particular tech stack you’re using, or that’s switching into different concepts.

For example, we had a lot of excitement switching from functional PHP to object-oriented PHP from Drupal 7 to Drupal 8. Within GitHub, just having the visibility to discuss different options, to discuss approaches and to have people ask questions about “why is this the best way?”, that was really helpful from a learning perspective.

And since everybody on the team has access to the pull requests and the issues and can see all the comments going around, it’s very easy to share knowledge between people. It’s not a silo between the developers and whoever does the code review.

Even having somebody who’s more advanced and comfortable with their code being reviewed by somebody who’s not is really interesting and helpful. We’ve found that when someone is unclear about what’s happening with the code, that’s a great opportunity.

In that scenario, it may be that the questioner needs to learn something and we’ve identified a gap in their knowledge base we can begin to fill in. Or it may be that the developer is writing very obtuse and confusing code and needs to simplify it. If it’s not immediately obvious to somebody what’s going on, then perhaps there’s some unnecessary difficulty in there and it’s something we should be aware of. Having visibility and discussions about code is important on both fronts.

Final Recommendations

The first question I usually ask is, “Does it work with my current tool set?” If there’s a new technology stack that means I have to abandon previous options, that’s a risk, because it means I’m learning two new things.

The other question is the “what happens if I get hit by a bus?” (or the more positive question “what happens if I win a million dollars and leave the company?”) Is it going to be obvious and easy for other team members to be onboarded to that technology, or is there going to be a big risk if I have to leave the project? Are they going to be stuck trying to find the access or solutions to use the tools?

Using siloed tool approaches instead of standardized tool approaches can really negatively impact velocity and the ability for people to switch between projects, because they’re learning something new each time. We’ve tried and ultimately rejected really interesting, specific tools in the past because of this. The cost was just too high, even if it fit the need really well.

A tool is only helpful insofar as it provides value. If you’re using a tool or technique and it doesn’t actually improve your process, your team, or your happiness, then really question its value. Because even though, as developers, we are presented with a handful of tools — and goodness knows people who make tools love to make tools, so there’s lots out there — having a critical eye to make sure that it’s actually helpful to your team is really, really important.

And helpful can mean a handful of things: it can increase productivity, it can automate, it can post cat gifs at the end of each pull request that gives your team pleasure… These are all things that are valuable! And having something that provides that value is important. But, if it’s causing problems, if it’s slowing your team down, if people are getting frustrated with it, really look at critically abandoning it. Because in the end these are all just items that are built to help us and if it’s a hindrance, then it’s not useful.


Portions of this article were taken from an interview conducted by Cahill Puil for Myplanet.


Written by

Leigh Bryant

Leigh Bryant

Sign up for our newsletter