Drupal 8 Interviews: Spotlight on Jill Cohen from Autodesk

Jill Cohen is a Senior Software Application Engineer at Autodesk Inc. Autodesk is a global company that empowers users to design and create just about everything on this planet - and in virtual worlds. She works with the Digital Platform and Experience Organization on the Digital Help team, which manages the Autodesk Knowledge Network and Services Marketplace. She is also on the board for Autodesk Women in Leadership.

How long have you been at Autodesk?

I have been at Autodesk for 4 years; before that I worked at various other startups, web shops, and worked freelance since about 1995. I have been a programmer, project manager, front-end developer, architect, designer, and database administrator. I was doing DevOps before there was DevOps. At my last job before Autodesk, I was hired as a Java engineer for a small nonprofit which evolved into build and release engineering as well as what has become known as DevOps.

I have spent most of my time working in Java.

How long have you been working with Drupal?

My programming background is primarily Java. I have worked a lot in JavaScript. One of my first applications that I wrote was taking MySQL and turning it into server-side JavaScript. That was about 1997 when JavaScript was on the server. It's on the server now in the form of Node.js, but back then it was very different.

I started working with Drupal with a company called SoundVision. They were producing The DNA files and their first website was a static, plain HTML site. They decided they needed a content management system. We started using Drupal 5. I managed to design and architect it without having to build any modules. There was enough out there to put it all together. The Drupal Admin was a hot mess and a disaster to work in, but I trained the team as to what to do. 

After that I designed and architected another site for them, but I didn't implement it since I left the country. Both sites are still going, they are Drupal 7 sites now. Other people came in and upgraded them. I did the two projects on Drupal 5, and skipped Drupal 6 completely.

I stopped working on Drupal after those two experiences and went back to Java after traveling around for a little while. Four years ago, a friend of mine asked me if I wanted to work with him at Autodesk. It was for Autodesk’s new Knowledge website built on Drupal 7, and I said yes. 

I was given a lot of time to get up to speed. It was a heavily customized site. It was managed by an outside vendor, and they had basically built and customized a lot on their own.

I am more of a full-stack engineer, so it was easy for me to get into the workflow and process. Once you figure out how hooks, menus and views work, you pretty much get it down. It's not super complicated.

When did you start working on Drupal 8 sites?

I started in December 2016. In the beginning of 2017, I put a prototype together for Services Marketplace. It took a lot to build the first module; to figure out all the moving pieces and parts and understand the new object-oriented framework, which I really like and prefer in some ways.

It took about 9 months to actually launch our site - which is pretty good, considering people had tried to put up other Drupal 8 sites and were not successful. I think we did a pretty good job in learning everything we needed to learn, while implementing someone else's vision. Other people's visions can be a moving target.

Plus, we implemented React inside of it which made it more complicated. We were learning both Drupal 8 and React at the same time, it was a pretty tall order. I think it's really challenging moving toward to what Dries calls progressively headless. It's in the middle where you’re still supporting a site for administrators and other users in Drupal, and you want to use Drupal headless.

Decoupled and progressively headless... I would recommend if you are going to go headless, go all the way. It's really hard to implement all the business rules you would need in a React app and make sure the administrator side has all the business rules.

Drupal does really well if you want to work headless, if you have engineers that want to work in JavaScript, Node.js, or some other area of the rendering system and go all the way headless.

Why did you decide on Drupal 8 for the Service Marketplace project?

There was really no point in going back to Drupal 7, and then thinking about having to upgrade it in a year or so. Drupal 8 had enough traction, sites were coming out, and there was enough support. Our hosting provider didn't have everything set up; however, they were getting there. We were on the cutting edge for them and we assessed it and decided "now is the time". 

I am lucky enough to work in a place that takes risks, encourages us to try new things, and expand our knowledge and learning. I felt if all else failed, we could have re-built the site in Drupal 7 pretty quickly. It wouldn’t have been fun, but I felt if something critical happened we had a backup plan.

What were some of the challenges you had working with Drupal 8?

There wasn't a lot of documentation beyond the basics. Menu items, routings, tasks... everything I wanted to do had a learning curve. I would write everything by hand or re-read some of the files in core, I had to reverse engineer in order to move forward.

I think some of the issues that were brought up were around using Composer. How to work with more than one person, people adding modules... I really like using Composer, but it did take us awhile to figure out the proper usage of it.

My biggest challenges have to be working with entity references. Drupal doesn't really clean up after itself. Removing a taxonomy term that is referenced on a node, breaks the node completely - you cannot view it until you re-save it. It doesn't work really well in production. I forgot that we had some barriers to removing entities in the Drupal 7 site. We were doing this one-to-one relationship, and we made sure someone had to remove one piece in order to remove another piece. We didn't hard code that in Services Marketplace, and it definitely is a place where we need to make sure we don't blow everything up.

I love entities and the object structure is great. If you don't understand the relationships, it's a huge stumbling point.

What are your favorite things about D8?

I like all the yaml files. I love the configuration setups and how you can export and import. It takes a while to have the trust that the system will do what you want to do when you want to do it.

Composer: I would use patch management, there's a way to do that.

Configuration: there's a new module for splitting the config per environment, but I haven't been able to implement it yet. 

I love the REST API, it’s really clean. It makes so much more sense the way you create web services. And how the packages and the classes are structured. I think if you haven't come from object-oriented programming background, it's a little disarming, especially when you're writing more functional and everything is in a module or include file. It’s nice to separate things out where they logically belong although it takes a little while to get your head around that.

Debugging is little bit easier. I like the controllers, and the way forms and blocks make more logical sense.

If you could improve something in Drupal 8 what would it be?

There is still a dependency on hooks, and I think if we cut the dependencies it would be much better. For instance, you can set behavior and overrides in a controller only to find that later it gets overridden by a hook. It's not immediately apparent what's going on, why you're setting something where it should be set and your interaction is still not working.

Maybe you can't get rid of all hooks, but I think it's time to let controllers own all the work.

Hook init is gone. We used it on our Drupal 7 site to make sure something always happens on every page request. They are now event managers and subscribers, but there wasn't a lot of documentation on how to use them and how to use it the way I needed to use it. I struggled a lot figuring out “do I want one on request”, “do I want one on response”, “what do I want it to do”, “why isn’t it consistent”? But in the end, it makes so much more sense.

How has Drupal 8 improved over Drupal 7?

The cleaner architecture and organization. I really like the use of yaml files and configurations for everything. I haven't had to use Features. I don't know if we can get into a perfect CI/CD where we don't have to do anything after you deploy. It takes far less time to deploy the new site... even when there are lots of changes. We just drop things into configuration and click one button and it's done. Everything is updated, that aspect is very masterful, and they have done a great job on making it work.

Yaml files are great, they're totally readable. Once you understand how they work, which ones you need, and why and where... it just works.

What advice do you have for people new to Drupal 8?

Don't be afraid to roll up your sleeves and dive into it. You don't have to be a master of object-oriented programming. If you want to be a JavaScript engineer, you're already working in objects and modules and it’s not going to be much different than working in PHP and Drupal.

Get a debugger, work in your IDE, look at all the objects, it makes it so much easier what functions to call on the objects. When you have it there, you can evaluate it, you can see how it's structured and it demystifies things. 

We all do console log, but once you actually get into a debugger, the game changes - even if you're not doing anything complicated. 

Be open minded, and remember that the skill set you're using for Drupal will stay with you and be useful in any other environment you want to work in.

Try to be an end-to-end programmer, there will be times when something is wrong in the database and you will need to figure it out. Drush, Drupal Console... they are your friends, don't be afraid to play. It's going to be a lot of trial and error, but totally worth it.