This post was written by intern Ashu Ukey.
Javascript, CSS, HTML, back-end, front-end, databases, web servers. Chances are, if you are even somewhat connected to the field of software development, you’ve heard of at least one of these technologies before. Whether for current job holders looking to cross over to another field, or undergraduates swimming through the sea of the industry looking for shiny internships, these are some ubiquitous technologies you can find in projects of almost any size. Even people working tangentially in this field are probably curious about these versatile technologies. Instead of going into deep technical details of them though, a high-level overview of the culture of working with them is often more helpful for starters looking to get themselves dirty in a pond they enjoy.
In the months since I started interning at 4Degrees, it would not be an exaggeration to say that I have been exposed to almost a new field, even when the work I was doing for the company aligned almost exactly with my major. As in, switching over to the company wasn’t going from cake decorating to bank telling; I was still working with software (the IDEs, the logic, the syntax, the dominos of error), but the change in climate had a surprisingly large effect on my experience.
Acclimatizing to the sheer focus and personal responsibility needed when there is no uniform framework in the industry is definitely a daunting switch from quantization and standardization in academia. Sure, you have probably encountered projects in your academics that boast of having “a large scope” or “wide applicability,” but in terms of the liberation of skill, talent, and determination, working in the industry is a step of much greater magnitude. Even if similar in intensity, your trek through the fast-paced workload, the flexible personal schedules, and the immortal list of tasks in the endless expanse of a company requires a gear much different than that you used to get your degree; not only are you at the roots of the tree of opportunity you discussed at a high level in academics, but you also learn how to quickly cover that ground by getting thrown into large projects.
How much you lean towards industry or academia is a matter of personal preference, strongly linked to your need for direction. In my opinion, working in the industry is a lot more liberating and less standardized than academia (say research for example). In the former, the scale of what you can do so it is very much a game of ambition, where getting an A is replaced by working towards a higher position or being inspired to start a company; your goals have no limit. Certainly, part of this new potential is just the progression of ability; our journey to our degree will be more restrictive so that we can eventually get the knowledge to explore. But even in post-graduate academics, unification and concentrated efforts at a constrained scope still play a role. That is not to say the field of academics and research doesn’t have many opportunities to branch out, but more than the stem from which one branches out in this field is singular (both in terms of the actual subjects of the research, and the backgrounds of the people in them.)
But ah, the industry is a democratic field, and for the sake of breadth and advancement in this landscape, more liberty and less restriction is better. Sometimes it’ll be hard to swallow that someone from a non-tech background can build a leading world-class technological product, or that someone very new to the field has an outstanding knack for a particularly hard to grasp technology, but accessibility, mobility, and optimism for all members in a field is fertile ground to spawn large, innovative tech companies, which might help explain the success of the startups and innovation community in America.
But coming back to the matter at hand once more, having acknowledged that there are a lot of flavors, cultures, and rhythms in terms of what you choose to work on, consider that it is sometimes more important to be comfortable at the base level of your work than it is getting excited for what it stands for. Knowing that you are redefining intelligence by attempting to reconstruct the independent parts of the human brain through machines might be an enticing thought, but if repeatedly visiting the intricate models with large scopes of variables, only to get improvements that may seem trivial in short runs sounds morbid, then perhaps a different line of work would be better; being comfortable with the environment of your work is sometimes a bigger determiner of your success than is your satisfaction at a high level, especially in the tech field.
We could fill a whole book talking about the many dimensions of good career choice, but perhaps we should apply some of these principles to address a more sizable problem in the context of this article, an interesting question I, and many others, have considered in (web) app development: front-end or back-end?
For starters, let’s look at definitions (shamelessly stolen from the coursereport.com blog)
Front end: Front end development manages everything that users visually see first in their browser or application. Front end developers are responsible for the look and feel of a site. (Languages: HTML, CSS, and Javascript)
Back end: Back end development refers to the server-side of an application and everything that communicates between the database and the browser. (Languages: Java, PHP, Ruby on Rails, Python)
Keeping in mind that your view of what a role accomplishes does not guarantee your comfort with its environment, let’s look at the feel of each side in a bit more detail.
To begin, let’s start with front end development. One of its most marked characteristics is you get to see your results immediately. It is said to be cathartic to see the entire page change completely in a couple of keystrokes; the feeling of being able to do so much so quickly is empowering. In the front end, there are also many approaches to problems and more choices about how you structure code, which is not to say that good code structuring isn’t important, but more that there is tolerance for user preference. For example, to change how a component looks on a particular HTML document you can add a direct inline style, create a new CSS class, or inherit a previously defined CSS class that is a close match and only modifying certain aspects of it. Similarly, to generate a page, you can hard code a page as a template, use javascript to generate components, or rely on a combination of both. As another example, to handle different click states of an element, you can toggle between two different ones, or modify one already in place using javascript. The front end also certainly has more opportunities for those with an artistic knack to shine through than the back-end would, especially if there are no designers appointed to handle aesthetics of a page. In a place with a lot more freedom, a front end role could benefit from efficiency and organization skills more than the back-end depending on the size of the project.
In contrast to the front end, organizing code (i.e. where to place code with a certain functionality? in what files?) is sometimes much more clearly laid out for you in the back end, especially if you are joining in on an already large project. That said, debugging can be much harder in the back end; you don’t need an entire server to be running to test surface level code, so you may not need as many dependencies upfront as you do in the back. It can be the difference between rendering just a single HTML page and checking “is this how I want it to look?“ and having to boot up the entire app to see whether a variable is getting declared exactly how you want it. Such runs can get time-consuming, especially in data science, when we sometimes only realize after a run has finished that we missed an egregious error in our model! Back-end also requires a willingness to wait for your efforts to show up on the actual product, as they have to be implemented in the front to show up. It may be discouraging to some, even when the work of both sides is equally important, that when a front end developer hacks for a couple hours, and you suddenly have 20 new pages, but when back-end engineers grind, it seems like their work is taking place somewhere remotely in the clouds.
But, working with servers and databases also has its perks: What happens in the back-end are often those things we see as ‘magic’ in a product. What are the steps a server goes through in processing information? Or, how are continuous background processes managed? How do we make use of the information we capture in a way that would be useful to the user experience? If the prospect of figuring things like that appeals to you more than managing surface level navigation and cosmetics of pages, back-end handling might be the role for you. Classical code logic and efficiency also has a stronghold in the back end: storage efficiency, frequency of server pings, database queries, looping logic, and handling large amounts of data are all things to consider when working deep within a product.
Strong classical logic error solving for backend, that said, has its counterpart in the front in the form of asynchronous coding and variable timing. The only concern with the timing of things in the back end is efficiency, as in, are you querying the database in the least time-consuming way possible? But in the front end, you also have to account for when each component loads. For example, if you want to scrape a site for the profile pic of a contact in say, a chrome extension, you have to make sure to wait for the actual chrome site to load the picture before you take in the data. But then how much do you wait for the picture to load? How often do you check and when do you stop checking? If questions like these spark your interest more than the classical view of code efficiency, and the stress of having to deal with code that doesn’t always run from top to bottom doesn’t faze you (see asynchronous programming), perhaps front end may be the role for you.
Point is, we can compare and contrast the cultures of a lot of different fields of work. Even for things very closely related within a field, there can be marked differences that can really affect how much we enjoy what we do. Hopefully by now, you have gotten a brief overview of the differences between the different types of work you can do as web developers. Quite often, developers choose to contribute to both ends of the product, but the takeaway is to always consider the full stack before constraining yourself to one side, in any aspect of life.
