Full Stack Developer Skills and Technologies for 2019

Here are the specific technologies and skills that go with being a full stack developer in 2019.  Full stack development has two sides, front end and back end.  A full stack developer is someone who can work on both sides. This does not imply they suck at everything because they are too general or spread too thin.  Everyone has specific strengths and weaknesses based on their brain, education and experience.  Some people have the bandwidth to do both, others prefer to be masters of a specific area.  I like to say I have experience on the front end but mainly do back end work because I enjoy that the most.

Front End Development – Fundamental Skills and Technologies:

The front end on the web is built with HTML, CSS, and JavaScript to varying degrees. A webpage can work without JavaScript, or it could have several megabytes of minified JavaScript doing all kinds of fancy stuff.  A basic knowledge of computer graphics (images, svgs, fonts) also comes in handy.

Front end work also involves setting up all the user interface interactions that can happen (like loading external data, making dialogs appear, showing validation errors, etc).

Here is my list of front end development concepts:

• HTML5 / CSS – this is your entry point to start doing basic coding.
  • HTML (hyper text markup language) defines the page structure and content. The elements on the page make up the document object model (DOM).
  • CSS (cascading style sheets) addresses formatting and positioning of the elements in the html.
  • A popular front end CSS library is Bootstrap but there are many to choose from.  Here is a list of popular front end css frameworks.
  • Some people do without a CSS framework and instead start with a more basic “CSS reset” which normalizes how things look across browsers.
  • CSS itself is rather clunky. It does not support variables or nesting of elements.  Most modern sites use a CSS pre-processors such as SASS or LESS which gives handy syntax, variable support, mixins and other neat things so writing CSS is much cleaner. During development they require a task running in the background that rebuilds the SASS or LESS into CSS each time a file is changed. That is because browsers only understand CSS.
• Request/Response, AJAX, Sockets and HTTP – the web runs over HTTP (hyper text transfer protocol).  Full stack developers understand the difference between request/response, AJAX (asynchronous loading), and web sockets.
  • When you visit a website for the first time and the page loads in the browser that is a request -> response. The entire page’s HTML, CSS, JavaScript, images, are pulled in.  If you click another link that makes a new request to the server and the response is another full page load.
  • With AJAX, JavaScript calls the backend and gets a piece of data to add / replace on the current page.
  • A full page refresh is expensive and slow where AJAX calls are lightweight and fast, but if there are several happening at once it can really bog down the page (and the server).
  • Web sockets are a way of leaving a connection open to the server and streaming updates (like stock quotes or a feed).
  • It helps to understand DNS, basics of the http protocol, and request headers.
• Forms – web forms have been around since the beginning of the web and are still used in great numbers for submitting data to the backend.
  • Front end developers setup the layout and behaviors for form controls including text inputs, checkboxes, radio buttons, drop downs, etc. Getting web forms to look good and function the same across all platforms, screen sizes, and desktop vs mobile devices is tricky.
  • Front end form validation involves checking to make sure inputs are valid and showing appropriate warning messages before they are sent to the server.
  • Date pickers, auto complete drop downs, and other fancy widgets can be pretty fun to setup.
• jQuery – a JavaScript library that is great for simple sites where you need to sprinkle in a few dynamic behaviors like event handling, front end form validation, etc.
  • jQuery is pretty old but still viable for simple sites. Lots web applications use it, and many frameworks have it as a dependency.
  • jQuery makes it easy to get at elements in the HTML either by id or class name, and manipulate them (show, hide, change their content) and wire click/keypress events.
  • jQuery can also do ajax calls, animations, and has tons of community add ons (although finding one that is actively maintained is getting harder).
  • Knowing jQuery is useful because it isn’t as magical or obfuscated as the more advanced javascript frameworks I’ll talk about next.
• React / Angular / Vue – these JavaScript frameworks are useful for complex pages involving multiple interactions on the page at one time or SPAs (single page apps).
  • Attempting to use jQuery to build a complex page results in a lot of spaghetti code. With one of these frameworks, if you do it right, everything gets organized into classes / components that are reusable.
  • React is the most popular of the three and has the best plugin eco system. It is more of a library than a framework and can work with things in the jQuery world if it has to.
  • Angular is the biggest of the three. It is a fully fledged framework. You must do things its way or beat your head against the wall until you cave in. Angular wants to take over the entire page and isn’t as easy to get working with existing systems.
  • Vue is the light weight new comer and popular with developers because it lets you do things your way.
  • With any of these as the version count relentlessly goes higher keeping up with changes can become a burden.
• Npm (node package manager) – where you configure the JavaScript dependencies for your application, handle asset minification, etc.
• Graphics – Images (png, gif, jpeg) and SVG (scalable vector graphics) are important to know about.
  • As a developer I don’t produce art or designs, but I do end up resizing, cropping, color correcting, and compressing images all the time.
  • Photoshop is your friend.  Paint.NET is a free alternative for Windows that mostly does the job.  Gimp is a free alternative but I find it to be a major pain to use.
• Fonts – your web app will likely need to load external fonts unless you want to stick with the vanilla fonts that are installed across windows, mac and linux (arial, times roman, etc).
  • Fonts can also be used for icon libraries – font awesome, giphicon convert the letters in a font into symbols like (plus, minus) and provide a huge number of icons in one download to the browser instead of having to create individual SVGs / PNGs for each icon.
• Responsive design – using one set of HTML/CSS to make a site (or app) look good from 320 pixels wide up to 4,000 pixels wide.
  • Responsive design is done with CSS media queries which apply styles to an element based on the browser window size.
• Other things to know about on the front end:
  • ADA compliance – it is 2019 and everybody should be building sites that work for people with visual impairments but a lot of developers are not aware of this.
  • SEO (search engine optimization) / Schema.org tags
  • Page load time considerations YSlow, CDNs, site speed testing tools.
  • Linting, a command line tool that checks to make sure your code meets quality and formatting rules for the project.

Back End Development – Fundamental Skills and Technologies:

The backend handles the flow of data, business logic, authentication and authorization, connection to third party data feeds, etc.  You’ll love backend coding if you like data, organizing things, algorithms, boolean logic, command line tools, etc.  The backend is my bread and butter (though I do a lot of front end work too).

Here is my list of backend development concepts:

• Design patterns (OOP, encapsulation, abstraction) – how to structure code so it models the domain (subject area) you are working on.
  • For the big picture think in terms of the entities (people, objects), their properties (name, address), and what operations can happen (user signs up, user initiates process X…).
  • At the coding level think in terms of the basic inputs and outputs to a function.
• Quality Coding – write code that works in the real world.
  • Code defensively in case inputs are not what you expect.
  • Create functions that do small amounts of work vs huge monolithic functions that do everything. This is called the “single responsibility principle”.
  • Unit tests are your friend. Writing good unit tests hopefully makes your system design better because it help you to think in terms of “one function one task”.
  • Don’t take external resources for granted. When you connect to a resource (database, API, file system, etc), always setup try/catch or promise failure blocks so your code gracefully handles problems on the other end.
  • Add logging as appropriate so it is possible to piece together what went wrong when an error happens.
  • Use transactions when doing multiple writes that need happen all at once or not at all (like transferring money between bank accounts).
• MVC pattern  – model, view, controller – a popular way of organizing websites.
  • Model – classes that allow you to interface with the tables / rows in the database
  • Views (aka Actions, Templates) – nobody can seem to agree on the name for this, but there are two parts, the backend actions and the front end template that renders the output.
  • Controller – handles the relationships between the layers, has a set of routes that map URLs to actions on the backend. For example going to  /myreport calls the report action which would get some data and pass it to the template layer.
  • Forms – not always a fully fledged element to an MVC (though Django has an excellent forms module). On the backend forms need to be validated before they are fed into a save/update operation. Generally forms mirror models in terms of the associated fields. But it is not always one to one. A lot of glue code needs to handle processing form data and mapping it to the database. Unit tests come in very handy here.
• Data Storage – full stack developers need to know how to store and retrieve data, typically done using a database. There are three main types of databases, relational, NoSQL, and graph.
  • Relational databases excel at storing things that need to be related (for example a customer and an invoice).  The vast majority of business systems use relational databases. Most MVC frameworks are designed to sit on top of a relational database.
    • SQL (structured query language) is the language used to interface with a relational database. Each platform has its own ‘flavor’ of SQL with custom functions and special tricks, but the core of the SQL language (SELECT, INSERT, UPDATE, DELETE) works the same across most platforms.
    • Popular relational databases: MySQL, PostgreSQL, Microsoft SQL Server, Oracle.  Here is a list of relational databases.
  • Non relational / NoSQL databases have different performance characteristics from relational databases (redundancy, replication, raw speed, flexibility).  They are best suited for free form data that can change or evolve.
    • Popular NoSQL databases: Redis, MongoDB, Cassandra. Here is a list of nosql / document databases.
  • Graph databases uses nodes, edges, and properties to store data where the relationship between the nodes (called edges) is the primary thing of interest. Relational databases are good at relating A -> B, but if you need to relate A -> B -> C -> D -> E… in a relational database the SQL gets really ugly really fast.  Graph databases are useful for analysis of large data sets to find patterns in the relationships. For example product recommendation systems, medical databases, and social media.
    • Popular graph databases:  Neo4j, Amazon Neptune, ArangoDB.  Here is a list of graph databases.
• API Integrations – full stack / backend developers are often tasked with interfacing between systems using APIs. There are two main technologies used for APIs:
  • REST (restful, representational state transfer) – uses JSON as the data format.  REST is common for AJAX calls from the client and also between more modern backend systems. The JSON format can be adhoc (one off) or support a more formal set of operations against an entity (get, create, update, delete, list). With REST your system talks directly to a URL and the data is passed as url params, query string arguments and or in the request body.
  • SOAP – uses XML as the data format. SOAP is much more rigid than REST but also seen as secure because the XML is ‘typed’ meaning the structure of the data and the values are ‘guaranteed’ to adhere to a pre determined format. With SOAP your system calls a ‘wsdl’ endpoint with a specially formatted SOAP envelope, header and body.
  • Other common integration patterns:
    • OAuth – a standard that allows a user to give permission for application A to access their data on platform B.
    • ETL jobs – ETL stands for (extract, transform, load) and is used for moving data around and manipulating it in between if needed.  You can DIY code an ETL job, use libraries to help, and there are countless enterprise grade suites available.
    • HTTP POST – this is like a crude form of REST where you code programmatically submits a web form.
    • Flat files – using CSV or other text based data format to transfer data. Newer systems don’t do it this way (I hope), but a lot of older systems require it.
• Message Queues / Asynchronous Processing – large systems that have a lot of different types of events happening benefit from a message queue approach.
  • Message Queues allow sending messages on one end and subscribing to them as events on the other. A message can be anything, typically an event with a bit of data attached to it. For example, a user signed up and here is their information.
    • Queues can be configured in a number of ways to support one or many clients reading messages, message expiration, and message redundancy (durability) in case of a system crash.
    • Flexibility is gained because the number of systems pushing or consuming messages can be adjusted and messages can potentially be leveraged by other systems.
    • Popular message queue systems are RabbitMQ, Kafka, AWS SQS.
    • Message queues are generally platform agnostic so many types of systems can participate in the message flow.  Service oriented architecture (SOA) and enterprise service bus (EBS) technology can rely heavily on messages queues (although some implement “messages” as API calls or flat file drops).
    • It is beneficial to think about a system in terms of the messages that go through it and how those messages are processed.
  • With asynchronous processing, the client is not waiting for the action to finish. It can be ‘fire and forget’ which means the client sends it and moves on (regardless of the outcome), or it can have a callback attached that gets triggered when the action completes.
• Background Jobs – doing work behind the scenes to keep data moving, up to date, backed up, etc.
  • Background processing / task frameworks are similar to message queues but they integrate directly into a programming language /  framework.  Django/Celery, Java/Spring Batch, Rails/Sidekick are examples. With these libraries a function that looks synchronous can easily become asynchronous. The framework handles creating the message and processing it elsewhere. Dependencies such as Redis or a full scale message queue backing the background processing framework are generally needed for complete solutions.
    • A good use case for this is a web server sending an email.  Small scale sites block the client response while an email is being sent, but that can be slow or even fail. It is better to queue the email and return success to the client immediately. The job that sends the email can be setup re-try if the email server is unavailable.
  • Cron jobs / scheduled tasks –  these run on a schedule (every minute or once a month) to clean up and process data. While not as scalable as a distributed message queue they come with simplicity and ease of setup. However, making sure they do not stack on top of each other, log properly, and recovery from problems is key to making sure they run smoothly.
  • Daemonized processes – some systems need a custom program that runs in the background continuously. Memory management (preventing of memory leaks) is important here.
• Language and Framework Specifics – backend developers must have a solid grasp of best practices for the language and framework they are using!
  • Here are a few popular backend languages / frameworks in 2019. You can browse the full list at the Stack Overflow Developer Survey.
    • Python – (Django, Flask)
    • Ruby – (Rails)
    • PHP – (Laravel, WordPress)
    • JavaScript / Node.js (Express)
    • .NET (C#, MVC.NET, etc)
    • Java – (Spring, Grails, Blade, GWT)
  • In general you’ll find .NET and Java being used in established corporate environments, while Python, Ruby and PHP get used more by agencies and smaller businesses. Python is also good for data analytics and research projects. Node.js has been the hot item for startups but companies across the board use it.  Up and coming languages like Go and Rust get a lot of attention these days.
  • The core concepts show up in each language and framework in different ways. There is an endless variation of jargon and structure as things are “re-invented” every ten years or so.
  • Knowing multiple languages and frameworks gives full stack developers the context need to sift out core knowledge from the jargon and trivial design decisions that go with a specific language and framework.

Closing Thoughts:

Nobody can master everything mentioned above. However I think the best full stack developers have at least a general grasp of all the topics mentioned above plus a genuine interest in everything software related (except enterprise software which you have to be paid $$$ to use or work on).  Pure dev skills aside, all full stack developers should have a good chair and sit stand desk.

The person who grunts every time someone mentions JavaScript, cloud hosting, or NoSQL is going the way of the dinosaur.

If I left something out please let me know.  In my original post from 2012 I didn’t mention any specific technologies because I wanted it to be buzzword free and timeless. This time I took the opposite approach.

If you’d like more in depth explanation of the topics above, please check out my book on fundamental software skills.