Programming as Language
Since pretty much the beginning of time, programming has been considered something akin to alchemy or black magic to anyone who considers himself “not-so-nerdy”. But in reality, programming doesn’t differ all that much from learning a new language: you learn grammar, then you start to speak rudimentary phrases, and once you get a grasp of it, you feel more confident about speaking and eventually you start adding slang, jokes, etc.
Programming is pretty much the same, although there are some additional levels to these languages since you also have to know about different roles such as Backend, Frontend, and UI devs. You see, with programming, there are certain paradigms you have to learn before choosing one way of doing things over another (which may also work, but not as well). And then once you’ve tasted all the flavors of the various programming roles and their specific languages you are able to pick the role you liked the most.
A Brief History of Programming
In a programmer’s world, If you stay with what you know longer than you should, all that programming knowledge you worked hard to obtain will rapidly depreciate in value. This of course is due to the daily-changing, ever-evolving nature of the industry. It wasn’t always like that, however. Early programmers were just that: programmers. The Backend and Frontend concept was around but was nowhere as developed as it is today, since most of the programs ran on a single computer, and it was offline, or connected in a local network. This concept maintained a separation between the user and the data access layer, and was mostly done by the same person or group of people.
But then the world wide web appeared, bringing new concepts along with it. Code was executed on a computer, and then served to another which had to render it in different browsers (the programs that allowed our home computers request and execute these new so-called websites).
Thus the server and client concepts took a new approach, and we had a whole new area of concerns to worry about, including running extraneous code in our computers, and the security breach that implied. That’s when browsers started to develop some standards, which aimed to ensure security and portability between different platforms.
Now programming was divided in two main parts: the business logic, executed on the servers, and the User Interface rendering, executed on the clients. The Frontend-Backend concept made more sense than ever.
The Scene Today
A lot of water has flowed under the bridge since then. Now we have single page apps running mostly client-side, doing tiny AJAX requests that refresh only a portion of a website.
Taking this into account, the Frontend language and its vast selection of frameworks aimed at specific types of web content had become a world significant enough to demand its own specific role.
Enough chit-chat, let’s talk about UI developers. We’re a new breed of programmers who love to code.
In order to maintain a healthy development environment the Frontend-UI separation was a natural decantation.
This is how we do things at Making Sense, and specialized roles make an impact on the final products delivered. Quality improves with precision, and these clear-cut responsibilities provide an environment in which everyone is a key player, and they feel that way, so developers become highly motivated to be more productive.
What do you need to be (or become) a UI developer?
First of all, love what you do. In this case love to code. That’s always a must. But then again love isn’t responsible of doing all the heavy lifting: you are.
Start by learning the latest and greatest implementations of HTML (which is HTML5 by the time this article is being written) and CSS selectors level 3, keeping an eye on CSS selectors level 4.
Responsive layouts are required knowledge and text hierarchy (as in vertical rhythm) is optional but very welcomed. Any grid system will do the work, but you have to test several of them to know which is best suited for the work you’re intending to do.
CSS preprocessors as Sass, Less or even Stylus form a great knowledge base for keeping up with the agile methodologies being employed in the software development process.
They allow us, the UI devs, to use variables, functions, mixins, and most important of all: divide and conquer our, until now, indomitable code. Here is where the architectural principles appear and we start to divide our code into several files which have specific responsibilities. There’s also Inverted Triangle CSS, Object Oriented CSS, Block Element Modifier naming convention, and CSS modules.
After the preprocessing wave has passed, a new wave comes: the postprocessing one, which takes CSS and generates CSS. However, instead of being a monolithic tool it breaks down to smaller do-one-thing-but-do-it-well modules.
See? The UI is far different from the Frontend, and even further in the distance we can see the Backend or the Databases. We all share the same environment, and may share some of the tools we use on a daily basis, but the way we use them, and what we do with them couldn’t be further apart.
It is really important to be comfortable doing everyday tasks and to excel in whatever you do, you have to be specialized. Once again, do one thing and do it well.
We build up our own toolkit of infallible resources as we go down the path we’ve chosen, and we get better at what we do when we’re glad we’re doing it.
The UI path is stripped from the Frontend responsibilities and because of this the final product we deliver is more robust, all the tools are used in their maximum potential, the tasks are estimated separately, the hierarchy of the different roles is equal, and the developers are happier because they are doing the part they like the most about programming. Epic win!