You may have experienced this in the past; you submit all the information you’ve painstakingly put together to your development team thinking everyone understands there are likely things that will need to change as we move forward.
Then, you receive the developed product and it’s not what you envisioned or even complete.
Now you go back to development with more information about the missing pieces only to be met with obvious frustration and push back that they “delivered what was requested and what you’re requesting now is a HUGE change requiring a complete re-code.”
Now you’re frustrated because you feel like you have to defend why it needs to change, everyone is frustrated and no longer on the same page.
Situations like these happen all the time, and it’s mostly due to a lack of collaboration and communication.
Sometimes, though, it simply comes from the misconception that changes to design or functionality won’t affect things that much. I’m here to tell you they certainly do.
For you developers reading this -- yes, I’m looking at you -- marketing’s role is to ensure the website you launch is as tailored to your core customer as humanly possible -- sometimes inhumanly possible.
They also drive everyone to ensure that accurate details regarding site visitor behavior be readily available in order to be able to pivot and adjust strategies as needed.
They’re there to ensure that Sales has a leg up and the leads it needs to increase the overall bottom line.
They push developers to innovate and strive towards that end goal.
That’s a good thing! Anyone that knows me has heard me say, at some point, that “anything is possible with enough time and pressure.”
That said, there are almost always misconceptions about what a developer actually does which lead to delays in production, complete rebuilds and, ultimately, frustration for everyone involved.
We’re going to tackle some of these today and, hopefully, help provide some insight into the process which will help guide everyone to a more symbiotic relationship.
It’s Definitely Not Like You’ve Seen in the Movies
If you’ve seen any movie depicting a developer at work and aren't familiar with the field, you may be really confused about what it takes to arrive at an end product.
In an effort to ensure every viewer understands what’s going on, Hollywood will sometimes oversimplify what a coder/developer/programmer sees or does when executing something on the screen.
They make it look like a programmer can simply sit down at a keyboard and go.
Even worse, they illustrate the actions of a few keystrokes as a graphic representation that any viewer will understand.
Essentially they’re dumbing it down -- and that makes real-world developers like me cringe.
Developers, coders, and software programmers essentially look at text the whole day and all the construction happens in their imagination.
In that sense, development could be considered an art form.
Every single element you see on a web page starts out as a plain old box -- white background and black text. That box has a handful of elements to play with -- padding to give you some space inside it, a border, margin and the content width and height. That’s it!
Using those elements only, a developer encodes values -- which is just another way of saying types out the values -- in order to achieve a predetermined look-and-feel.
How those individual boxes are laid out, what happens when the screen width is reduced, and what happens when other inherent events occur (like a mouse hover, for example) also have to be manually specified.
Now, that only represents the work of the front-end developer whose primary role is to take charge of coding the aesthetic representation of the site.
Usually, they'll be the person that takes an approved design and architects it for the web. Some cross over a bit into other areas, but this is their primary function.
There are all sorts of other considerations when trying to program functionality that deals with data.
When working with data, depending on the platform you use, there are security implications, software efficiency and rendering at play, too. The best part, sarcastically speaking, is that it rarely works the first time.
Now, it’s true, nowadays there are standardized frameworks and a ton of open source -- meaning free and community supported vs. coming from a big software company -- solutions available to a developer that will streamline and facilitate this process.
Still, those frameworks are only meant to provide a base on which to build on.
As for the libraries available, those come with a speed-related price.
Whether you link out to a resource or funnel it into your own code base, an excess use of these will typically result in page speed penalties in some way, shape or form.
The Top 3 Myths Marketers Believe About What Developers Actually Do
1. Development doesn't require much planning.
Some people think that developers can take an idea and simply begin to write code which will turn that idea into software.
This misunderstanding often leads to misguided expectations about timeline and scope.
Before going to work, a developer must always understand the purpose, goal, and worth of such idea that will guide them into the most efficient ways to handle its creation.
Even then, expecting a developer to just “Go! Code!” is fundamentally impossible.
There are so many ways to architect functionality and sometimes it takes time to sit back and think.
They also must take into account any specifications or limitations you may have. For example, perhaps your web host doesn't support certain types of styles. All of this needs to be considered when implementing a solution.
2. The little details just work themselves out.
This is one of the most misguided ideas about what developers do.
Specifics related to your project, what the goal is or, even, anything that’s missing from the information you’re providing are essential from the outset because each facet of the functionality has to be programmed line by line.
One little detail could result in a complete shift in approach from a development standpoint.
To illustrate, if someone sat you down at a computer and asked you to “Write something!” you might have some questions.
What am I writing? Where will my writing be used? Who is meant to enjoy my writing?
And if, after you’d written your masterpiece with all of these questions answered, you were asked to simply change one part of it, you might not be able to fix it without starting all over.
This is because you laid elements leading into that detail they want to remove that no longer work without it. It no longer feels natural.
Development and programming is the same way.
3. Once a developer launches the site, traffic should start to pour in.
This is not the case at all. In order for your brand new website to start driving the traffic you envision, there’s still so much more work to do post-launch.
This usually takes a whole team of other people to market, promote, and optimize the site.
Most marketers who lean on outsource dev firms already enjoy the benefit of having these items taken care of, but for those of you going it alone, here are some tips:
“Google isn’t finding my website!”
In order for Google to know your website exists, a sitemap and a crawl request has to be submitted through their search console. Here is an awesome article to help you get started with Google Search Console.
What about SEO?
Even after you’ve submitted everything to Google, you still may not end up on the first or even the second page of search results when one of your industry keywords are searched. If you’ve not laid out a solid plan for this, it’s going to be very difficult to increase your rankings. Again, this is something you might want to research and sometimes it takes a little further investment.
For the super competitive industry categories, all the SEO and planning in the world may not be enough and an online paid media campaign may be necessary to help promote your site and increase your position on those search result pages. This isn’t organic, since that needs time to build, but it just might be the nudge you need to get going.
Bridging the Gap
These are only three of the most prevalent myths or misconceptions I’ve encountered over the years, both, as a freelancer and as part of a development team. I truly believe that communication and buy-in from all parties involved is the solution to most problems that arise in any endeavor.
Now that you know a little bit more about our process, it may save you from further uncomfortable situations and promote a healthier overall culture. It’s the perfect time -- every time -- to reach out to someone in your development team and pick their brain before the outset of any given project.
Not only will this action provide you with the tools you need to get the right kind of information from the very beginning, but it will also give you an opportunity to convey the intent and drive the outcome with the buy-in you’ll receive.