"i only speak liquid" #27: Better development decisions

Written by Billy Noyes 🆕

Hey all 👋!

Welcome to 'i_only_speak_liquid' by Storetasker, where active Shopify developers like me (Billy) share learnings we face daily. This is my 3rd edition!

PS: I'm a developer on Storetasker; Apply here if you want to join Storetasker's gated network of vetted Shopify developers.

What I've been thinking about

At the end of my last post I mentioned that my next post would be about how impactful the decisions we make as developers can be for our clients and their business.

When I first transitioned to being a Shopify developer I had to adjust my mindset from seeing my clients as ‘customers’, to seeing them as business owners, representing themselves in front of thousands of customers

Here are my main tips to adopt a ‘business owner mindset’ when dealing with your clients:

Test Your Work

Test our work is a given (features, bug fixes etc). But I’m talking more specifically about testing the impact of your work with tools such as Google’s Lighthouse. Learning about site speed, accessibility and SEO helps you not only solve problems but without ever harming your clients’ business.

The benefit to highlighting the impact of your work on things like Site Speed also generally opens up more conversations for additional work.

Stop Hard Coding

Something that I see happen all too often is developers' hard coding values. Even just before writing this post, I was working on a project to update some icons that the previous developer had hard coded using the image file’s CDN URL. The client was paying different developers each time they wanted a new icon to be displayed. The client just believed this was the way it worked.

If you happened to read my first post you’d recall me saying how powerful sections and blocks can be, and in this particular situation it was no different. I was able to create a new block type for the section, which allows the client to upload images and use them as the icons.

When I explained the issue with the original hard coded solution and the updates I had put in place to the client, they were so happy to hear that this problem was finally resolved once and for all. They were so happy that they actually decided to send over a much longer list of additional work. Whilst I definitely spent a bit of extra time updating the icons to use blocks instead of just adding the URL in the code, that little bit of extra investment of my time actually benefited me greatly.

I also see a lot of text being hard coded into themes, even despite locales and theme/section settings being so easy to set up - This is a really quick change that prevents further issues in the future.

Clean Code

Recently I was asked by a client to help them get ready for launch. It was a completely custom theme that had been built on top of Dawn and immediately the client expressed that they were worried the code was bad.

When I started getting into the project, some of the more complex code was really hard to understand and even the developer that wrote it was having a lot of problems understanding it. This took extra time to understand the code, and even more time to rewrite it.

Each piece of code is different and writing clean code is a whole skillset on its own, however I wanted to share some common problems that I see all the time and can be fixed really easily to improve the development experience for everyone involved:

  • Having lines of code that are really long make it nearly impossible to read, If a HTML tag is starting to get too long, separate the attributes and even the attribute values onto new lines

  • Don’t be afraid to create new variables, not only will this reduce repetition but also give some context on what that particular value is

  • A common thing that’s always mentioned, but definitely something very important is good comments because even you will come back to code you wrote and completely forget what it does

  • Get rid of commented code! If the code was needed, it probably wouldn’t be commented out. If you’re using version control for development, you could just put this code on another branch for future reference

3 links you can't miss

  1. Godly Website (https://godly.website/)

    • If you’re looking for another source of inspiration, this website is definitely one to take a look at

  2. Bytes Dev Newsletter (https://bytes.dev/)

    • This is a great newsletter that gets sent out every Monday and Thursday, I’ve been subscribed since 2021 and love always learning something new about JavaScript

  3. Workspaces Newsletter (https://www.workspaces.xyz/)

    • Whilst we’re on the topic of newsletters, another great one that I really enjoy is Workspaces. I love seeing other people’s setups and would love to be featured at some point!

One app I like

I recently found this great app by Ecologi that allows you to plant a tree for each sale, order or even set a dollar amount. It’s a great incentive that merchants can advertise on their sites, which will likely help to increase sales and lead to more trees being planted!

One learning as a freelancer

Sometimes it can be hard as a developer when you find an issue with the current solution a client is using but you’re maybe not being paid for that additional time to provide an alternative solution that works better.. As I mentioned with the example above about the icons and fixing the hard coding, delivering solutions above the clients’ expectations can be really impressive and help build trust with your clients.

Of course each client is different and it might not be the right thing for certain situations, however it’s a great way to show the level of service you provide and can lead to more work.