Battles of a front-end developer
Tags: design, testing
Published: 2020-02-11 13:45:28

Life(and work) as a developer is tough and we all deal with issues that many people outside of the field don't. Below I’m just going to list a few things I’ve experienced over my short term as a front-end developer that caused me some trouble and maybe some of you can relate to.

Non-descriptive issues, yeah, I’m hitting with the big guns first. There are very few things that can compare than when you’re opening an issue tracker and all you see is “Clicked button, doesn’t work”. Which button? Which screen? How did you navigate to the screen? What result did you get? Do I need an ouija board to decrypt this message? So some tips to pass along to whomever is logging issues. Ask the user to add these details as they can, Which button? Which Screen? How did you navigate to the screen? What was your input? Can you send screenshots? Can you add video? All information is valuable. I don’t have access to your device and I can’t see in the console what your issue is. It’s also the responsibility of you as the developer to go through rigorous testing before passing of a build to your QA team (whomever that may be, whether it’s an individual or a team)

Designs.
We (or I) might be front end developers but we (or I) are not designers. Yes we picked up a thing or two here and there but nothing on the level that a professional can do. Having clear and professionally done designs by those who know UI/UX saves us a ton of time. We don’t have to worry about how something looks, about what the interaction is, about what wording we should place where and which colours to have where. Having designs takes a load off and allows us to focus on what we need to get the product done. Designs that change every five minutes are hell too. Having spent hours designing screens only to be told that something that didn’t need to be in or wasn’t important, suddenly needs to be in and is critical to the app. At best it’s a small change and doesn’t take more than a few minutes, at worst it changes some part of the interaction of the app and could cost you plenty of hours(possibly having to delete a bunch of work you’ve already done) especially when the feature was not planned in your use case.

Lack of communication. There have been many times when lack of communication between front-end and back-end devs causes needless issues. Variable names are changed, end points are changed, results from calls change and these have a direct impact on the product you’re building. If you have tests set up you’ll catch these before release, if not… oh boy, your nights and weekend is about to disappear as you try to find out why things are breaking. Ask your backend developer to always inform you of changes, this causes less problems on your side and catches it before you run through testing or worse, the client or uses catches it.
Not everything is our fault. This is a bit understandable when a user’s only interaction is your product and it relates to the point above. If the client or user’s only interaction is your product, most likely all issues will be assigned to you, this can get extremely frustrating and even disheartening at times. So what can be done about this? Honestly I’m still struggling with this myself, we can’t expect users/clients to have the same technical knowledge we have all we can hope is that the people creating issue tickets have enough technical knowledge to know who to assign them to.

Finally, not everything is an issue. Issues are bugs or unintended results. If a user clicks a button and the app crashes? Bug. Take you to the wrong screen? Bug. spelling and cosmetics mistakes? Bug. Adding a payment system? Not a bug. Features, results and anything that needs to be added are not bugs, it’s a feature. If current systems and features are not working as intended and causes some sort of error whether it’s logical or runtime, that is a bug.

I’m sure there are a wider variety of things that plagues us but these are just a short compiled list that maybe you could pass onto your team to better your work flow and making your job just a bit easier. If you’re reading this and can relate to any of this maybe take the initiative to speak to your colleagues, managers and maybe boss about how you could work out these pain points and make a small difference in your day to day