It's Not Always Sunny in Philadevelopment

I truly love being a developer. What started as a hobby has become a core foundation of my identity. It's given me a sense of accomplishment, a catalyst through which I can constantly strive to improve, even changed the way I think in everyday life. But as much as I love it, there are definitely downsides to the craft. So today, I'm gonna step away from hyping Python or teaching you development terms to help you sound smarter. Instead, I'm going to tell you what I loathe about my career. Warning: It's going to be a rant blog.

Browser Differences

Every browser has it's own 'default' set of styles. Some are simple, like margin or padding, font-size, maybe even the font themselves. Not all Sans-Serif are alike, after all. But a lot of them are pretty simple and easy to override by just setting up your own default rules in the top of your CSS file. And as for the differences in fonts, Google Web Fonts pretty easily take care of that. But then you have odd things like how Text input fields compared to Submit input fields can have different heights, even if the font, size, padding, border, and everything are all the same. Even Mac OS makes this more of a pain in the ass by doing these odd and obscure default styles for submit buttons. Which also brings this to mind. If you have a Mac or iOS device, that "Chrome" of yours isn't actually Chrome. It's basically just a re-skinned Safari in the end, which is why Chrome on Linux or Windows may not be styled the same as Chrome for Apple.Then we have weird things like how Microsoft browsers, including the new Edge, avoid sticking to conventions that literally every other browser in the world does, like accepting 8 (or 4) digit hex values to avoid the long-winded rgba(x, x, x, x) method when you want a color with some opacity. There are other examples of these kinds of issues where the 'fix' is to type the same rule multiple times, each one with a different property prefix, such as -webkit- or -moz-, etc. They get annoying when you want to have clean, simple code. Oh, and this gets even worse when you're building a website that needs to account for older browsers, like your grandma who hasn't upgraded her computer since Windows XP.A lot of these little issues can be fixed by using something referred to as a "reset stylesheet", but I personally have never been a huge fan of them. It's more effective to just build your own or use a CSS framework such as Bootstrap that already has it, as well as other features, baked into it. Though here at Red Shark, we build everything custom for each client.

Restructuring Markup

So I really don't have a quick yet reliable way to explain this for you to truly appreciate the frustration behind this, so I'll just skip it and vent anyway. Just play along. Sometimes, a client will want a change. And you think it's going to be easy. Maybe it's just a change to how a section of a page looks, perhaps adding a zoom feature to a background image. But you can't just slap a new CSS rule on it and have it work. These kinds of changes can be tedious when they require you to completely restructure the elements of the page, which then need to be restyled, which can then end up breaking other CSS rules, and it can get out of hand quickly if you're trying to be quick about it. There have honestly been times that I've just completely rebuild full sections of a site for seemingly-simple changes like this to avoid risking a headache.This can also be made a little worse when you're dealing with dynamic data that involves looping through information to display them, but they want certain ones to be displayed in a certain way, so then things have to be offset, or just have a lot of one-time exceptions to default rules. And as usual, they can be either a simple 10-second fix or something that requires thinking it through before you get started to make sure you've thought out every possible issue. But guess what, you didn't. QA team will make sure to find something that you missed. There is a remedy for these type of issues, and it's basically just experience. The more you do, the more you know. My grandfather loved to say that wisdom isn't knowing what to do, it's knowing what not to do.

Poorly Documented APIs

If you don't know what an API is, you can find a detailed explanation HERE. But not all API's are built in the same way. They'll all have different data, it will all be structured in different ways, they'll all have different methods of authentication, the list goes on and on. Fortunately, any GOOD API is going to be well documented, and even have examples for how to make calls in different programming languages so that you can skip all the trial-and-error from the get-go. Those are the ones that I personally love to see, at least when it comes to trying to do something quickly while still maintaining best practices. But for every well documented, properly built API, there's another that is poorly documented (if at all) and provides no real guidance on how to interact with it correctly. The latter is especially common with newer APIs that haven't yet had the time to fully mature.The frustrating part here is that you're effectively taking shots in the dark. And since they're blind guesses, you never know how long it's going to take. Maybe you get it within the first 10 minutes, maybe it's not until your 100th attempt to connect that you get it working appropriately. And some of them, once you've gotten to the end, lack details on how to make test submissions. To be fair, this is only really a major issue when it's an e-commerce API, such as a membership API where someone has to submit actual credit card information to get back the success message. If you're using a quality product like Stripe, they have test numbers you can use to avoid this, though there have been some that we've had to make numerous emails to the API providers to get some way to avoid being charged while we test out the full process from beginning to end.

I Say It's All Worth It

At the end of the day, I wouldn't change what I do for a career. The cure for most all of these issues is experience and confidence, the more of which you have as you continue to move forward in your career. I've worked with a handful of terrible API's in my almost-two-years with Red Shark, but each one taught me something new, often even helped me appreciate what goes into building a solid website or application.