Category: Development

Posts specifically about programming and development

Optional Chaining: A Powerful Tool and Lethal Weapon

On September 22, 2023

Reading Time: 5 minutes

### Introduction

In the ever-evolving landscape of software development, engineers constantly seek ways to write cleaner, more efficient, and less error-prone code. One of the breakthrough features introduced in modern programming languages is optional chaining.

Optional chaining can be a game-changer, simplifying code and enhancing readability. If applied properly, it can also eliminate errors associated with null or undefined values. However, this comes as a double-edged sword, as it can also introduce risks that severely degrade the integrity of your code. We will go over the risks in a future section, but for now, let’s learn what Optional Chaining even is.

### What is Optional Chaining?

Optional chaining is a feature available in several modern languages, but I’ve seen it most in JavaScript and TypeScript. It is a way to decrease type errors by not assuming a given property will exist at all. In addition, it decreases errors thrown as a result of something being null or undefined.

However, this is a double-edged sword, as it can mask issues in stack traces or cause errors to throw too late, causing systematic issues that are larger than would otherwise exist.

The drawbacks of Optional Chaining make it a hotly debated topic among process steering engineers and code standards committees. I have been in a few calls and discussions that got quite heated due to optional chaining. Some call it an all-around risk, and others call for full adoption. There are inarguably safe ways to use Optional chaining, and we’ll discuss some in this next section.

### Using Optional Chaining

Here’s a basic example to illustrate optional chaining’s usage:

let user = {}; // user has no address
alert( user.address.street ); // (error)
alert( user?.address?.street ); // (no error)

No checks are made, and thus it throws an error in the first alert, as neither address nor street is defined under user. However, in the second alert, it would not throw an error, returning undefined instead. This is because the optional chaining broke at user?.address, due to it being undefined.

This is quite powerful, as you can essentially skip any error relating to properties if they may be undefined. That is also why it is so dangerous, as sometimes you’ll need them to be defined. There are some ways to mitigate these issues, but at certain times you also have to ask whether it’s worth using optional chaining if you’ll need to write out more code just to check it, when not using it will have you writing the same checks.

Here’s a snippet from a project where I safely used optional chaining, reducing lines and not compromising safety:

// without optional chaining
const currentPage = () => {
  if(router.pathname === '/') return 'Home'
  const entry = Object.entries(PAGES).filter(filterFunc)
  return entry[0][1].name;

//optional chaining
const currentPage = () => PAGES.find((page) => page.link === router.pathname)?.name || "Home"

There were a couple of other refactors that happened here, as entry[0][1].name means that you’d have to understand the filterFunc function to use it, and it likely isn’t designed in a human-friendly way, but ignoring that change, this function is much simpler with optional chaining than before. In addition, it only required one type check, and entirely rid itself of a secondary function full of other type checks.

These kinds of situations are where Optional chaining shines, and they aren’t super rare either. You just have to be wary that you fully understand the object you’re interacting with to ensure proper usage.

### Benefits of Optional Chaining

Code Conciseness: Optional chaining reduces boilerplate code, making your codebase cleaner and more concise. It eliminates the need for repetitive null or undefined checks, resulting in more readable code.
Error Prevention: By preventing runtime errors caused by null or undefined values, optional chaining helps improve the robustness and reliability of your applications. This is especially crucial in large codebases with multiple contributors.
Improved Productivity: Developers can write code more efficiently and focus on solving the actual problems rather than handling null-related edge cases. This leads to increased productivity and faster development cycles.
Better Code Maintenance: Code that relies on optional chaining is easier to maintain because it’s less error-prone and more self-explanatory. Future developers working on the codebase will appreciate the clarity it brings.

### Considerations and Best Practices

While optional chaining is a valuable tool, it’s essential to use it judiciously:

Keep it readable: Don’t use syntax you find hard to read. Longer code is not always worse, and if it makes it more human-readable with no major slowdowns, it is better to keep it readable than to make it optimal.
Avoid Overuse: Don’t blindly apply optional chaining everywhere. Use it when dealing with potentially nullable properties or methods to improve code readability and safety.
Maintain Code Clarity: While optional chaining reduces code verbosity, it should not compromise code clarity. Name your variables and properties with meaning to ensure your code is human-readable.

### My Opinion

I’m of the mind that optional chaining is not a tool that should be used often. I understand there are clear benefits to it, such as not throwing errors for issues that won’t break anything, or to shorten syntax. I have used it before, so it isn’t something I am 100% against, however, I have found that in many cases you end up doing as many – if not more – type checks just to use optional chaining.

I also feel that most instances I’ve seen of it compromised the integrity of the code, didn’t shorten it, or made it less readable. While I don’t agree with the “don’t fix what ain’t broke” mentality a lot of the time, it is my personal opinion that type checking most of the time should not be fixed unless it is longer than necessary (as in there are two ifs that could be broken down further, or merged with past statements, etc.).

Of course, you should always know the data you’re working with and know what is safe to optionally chain and what isn’t, and any senior+ developers will already be using it safely. The above opinion mainly applies to people who haven’t learned about it yet, as they are also likely Junior engineers, and I’ve seen it become a very hard to correct bad habit when not used with enough discretion.

All I’m saying is to be very careful that you know your data. If you don’t, rather than resorting to optional chaining first, read your docs and learn what you’re unsure of, or reach out to someone else who’ll have the answer you need.

### Conclusion

Optional chaining is a simple yet powerful tool. As with most powerful tools in modern engineering, it comes with some large risks and must be used with discretion.

When in the hands of an experienced and thorough engineer, optional chaining can level up your code by a large margin, so don’t hesitate to add it if you’ve determined it’s the best option (had to add at least one bad pun). If you’re a junior engineer, you likely can use this tool to help you get a deeper grasp of the consideration that working with variable data requires.

As software development continues to evolve, mastering tools like optional chaining will become more essential for staying competitive and building robust applications. So regardless of your opinion on it, make sure you learn it and can use it safely.

Browser Testing

By Morgan

On February 5, 2023

In Development, Updates

Reading Time: 4 minutesSince I got into web development I’ve been looking for the perfect browser. This is an impossible task, as the perfect software does not exist, browsers included. That being said, some are better than others.

I’ve been using the Vivaldi browser for the past couple of years, and I’ve loved it more than any other browser I’ve seen. However, recently I’ve been experiencing issues with the browser rendering sites partially, if at all. Whenever I start having problems in a browser I know it’s time to start browsing (heh) again to see if there are any alternatives worth using. Of course, there’s always Firefox, Chrome, and Edge, and they always work, but they’re also just a bit inoffensive, never really majorly shaking up the landscape, but always being reliable, if not for performance issues that seem to crop up every few months. If all you want is a browser that goes painlessly, then sticking with the big three is not a bad choice.

However I wanted more, and Vivaldi came through with that. It has a panel window with a whole lot of power, and for how much it has, it still performs better than Chrome does most of the time. It runs on a chromium base, allowing for chrome extensions to be added, and has cloud sync for your bookmarks so you can sync your info across computers. In addition, it comes with a built-in adblocker (better than any adblocker I’ve used on Mozilla-based browsers, and probably better than most chrome adblockers too. You can add RSS feeds to the side panel, checklists, email feeds, and a ton more. Overall it’s a great choice for casual browsing, however, you run into issues if you want to be a developer (you’re honestly best sticking to chrome if you’re writing code). Clearing the cache is a bit more difficult than most browsers, and you can’t hard reload. Also to not harp too hard on Vivaldi, some of the issues I’m experiencing right now started after my upgrade to Windows 11, so it could be a compatibility issue there, and a casual user may never experience them, however for me it happened frequently enough to start considering switching.

One of the browsers I looked into in the past while somehow having never used was Brave. I do like Brave a lot, it has a comfortable interface, built-in ad blocking, and is a baseline Vivaldi alternative out of the box. It doesn’t have all the extra robust features that Vivaldi did but is a solid alternative. I didn’t use it as I enjoy finding other smaller projects to use for my daily driver, while still having the big projects as backup browsers (although in this case I am considering just switching to Brave, still undecided).

A fun alternative I found while searching is the Pale Moon Browser, a goanna-based browser that is consistently updated, however, looks like it hasn’t been touched since vista.

The pale moon browser, looking as though it belongs in 2007

That being said, it doesn’t seem like a bad browser either and gives the vibe of Internet explorer without the clunkiness. If that’s what you (or your grandparents) are looking for then it is a viable option, receiving updates once to twice a month consistently.

The browser I’ve settled on for now though is Waterfox, another Mozilla-based browser with some of the things I wanted from Vivaldi, and in a light-enough package. To be honest, I did integrate into waterfox before testing Brave, hence why I’m considering swapping over to brave now, but waterfox is doing everything I need so far so I’m not yet sure if it’s worth the swap. To make waterfox do what I needed, I imported my bookmarks and installed an adblocker and a tab grouper. Those are all I require from a browser, but there aren’t any browsers I know of outside of Vivaldi that have all those features built-in (for instance Brave has adblock but not grouping). With minimal work, however, Waterfox was able to cover all my bases, where I know Chrome probably couldn’t. I also was biased towards Mozilla slightly, as when I swap browsers I do like to go to the opposite of what I’ve been using.

Simple Tab Groups, a plugin for Firefox Browsers

Another thing I’d like to add is I didn’t try out any of the Opera browsers. I just didn’t feel the need to, and while I know that Opera GX is out there and people like it, I haven’t been very enthused with Opera as of yet. I may make another post in the future reviewing them, however.

Post-Writing addition:
While I was still considering a swap to Brave while writing, I discovered that Brave is actually a Chromium Browser, not a Firefox browser, and thus could not have my Tab Grouping Plugin installed on it. That means that unless I find an alternative that works just as well, I’ll be sticking with Waterfox for the foreseeable future.

Elon bought Twitter

By Morgan

On November 23, 2022

In Development, Uncategorized

Reading Time: 2 minutesThis one’s just stream of consciousness, no editing or anything, so sorry if it sounds bad, it’s just what’s on my mind.

Apparently Twitter is on fire. I left the platform a while ago so I can’t confirm, but I can say I’m not surprised. When Elon bought Twitter, I was hoping he’d just let it go as is, and occasionally propose new ideas or updates. As the incoming Owner and CEO, I’d expect him to understand that he probably has a decent amount to learn about current operations and how ideas are experimented on and implemented. It does not seem like he did that though, instead opting to go in, tear everything apart, and reconstruct it in his image. The problem is that you can’t expect to rebuild a platform and also have it operational at the same time unless you’re running A/B tests for each feature, and it can’t happen all at once unless you take down that platform temporarily. That on top of having engineers print out their code to keep those who committed the most being a horrible idea just reeks of someone who thinks they know more than they do about what they’re working on. I don’t mean to say that like it’s just a him problem, of course all of us bite off more than we can chew occasionally because we assume we have a higher skill in an area than we actually do, but while he can run a car company fairly well, Twitter isn’t cars. I’ve also had a lot of people tell me “But he’s a developer, he sold a game he made and helped found PayPal, so he knows how this works”. I won’t discount that first part, but he wasn’t an active developer in PayPal either. He bought his way into the company post-founding and paid for his title, so I wouldn’t say that really counts towards his credibility. That on top of that he hasn’t worked on development in years should mean that he won’t have current experience of workflows and management structures for CI/CD that I’m sure are used at Twitter’s corporate level. Now with all the engineers leaving, I’m not sure if the site will fully recover. The user base is there, and I don’t think they’re going anywhere if it survives, but if I hadn’t already left, I’d be off the platform permanently now. I don’t want to unnecessarily bash him, as I don’t really like bashing anyone, but this really got under my skin as an experiment engineer and developer.

Paid Interviews

By Morgan

On October 11, 2022

In Development, Job Hunting

Reading Time: < 1 minutesI just wanted to bring attention to this concept. I’m in the process of interviewing for a job (I’m not putting details unless I get it, in which case I’ll probably talk about it a bit), and I’ve just been invited to a paid interview. This is not a concept I had heard of before but is a very good idea to incentivize applicants while also discovering more about them to ensure the best picks. Essentially, a paid interview is a 40-100 hr (at this firm) trial run of the applicant. You work on the same type of jobs as you would at the position, of course not the actual tickets though, just examples made by the team. They pay you a set hourly rate during this time and once you complete everything or the time completes they make their decision. This may be something common at other companies, but I’ve only ever done skill assessments and technical interviews. In my opinion, this is a much better way to hire, as it is much more selective and harsh in the interviews, but it only selects the best applicants, as you already have to be willing to pay them to get them that far, but if they are just very charismatic and lack the skill, you don’t get stuck with them. It also respects the candidates as they get paid, so even if they don’t get hired it makes their life a little easier. I feel this process should be expanded by more companies and made standard.

The problem with modern skill assessments

By Morgan

On October 5, 2022

In Development

Reading Time: 2 minutesHave you ever applied to a job and received a code assessment asking for something entirely outside the scope of your position? You give it your best shot, but since you’re an entry-level developer fresh out of a workshop, you cannot complete it within the time limit set for you.

It can be very discouraging when this happens, but it is a common experience, even with experienced developers. In fact, in forums for experienced developers, it’s common to hear devs with 5+ years failing these tests. That said, there are also many good assessments with challenging problems you have probably encountered previously. These tend to be created with a solution you can engineer using simple logic and knowledge of your chosen language.

Obviously, these problems vary widely depending on the position you’re applying to, and they are worse in some positions than others. In my experience, positions with the “software developer” title tend to be the worst for these problems, often requiring knowledge of specific algorithms which you may or may not know to solve the problem. I’ve also found that Front-End Developer positions have the most consistently relevant problems, likely because there are a few semi-universal plugins that don’t assist with logic, so proof of knowledge is much simpler and harder to make non-relevant in the first place.

This also provides a barrier for devs who want to hop over to another focus (i.e. web developers trying to move to Software Development). A common problem that I’ve seen is Dijkstra’s algorithm functions. They appear pretty commonly in software developer assessments, but it isn’t an algorithm that is very universal. It’s a very helpful algorithm for those working on maps, but most developers never use it, and this can also cause problems during assessments. It is possible these are taught in college, but as I didn’t attend college for CS, nor have I gone through any workshops, I have never learned it (or any graph theory associated with it). I’m not saying these being difficult is bad, as there need to be quality checks for people who are hiring, but I am saying that companies should be sure to make them relevant to the position. Asking a Front-End Developer who will be making react applications to understand graph theory is rather nonsensical, much like asking a database engineer to know how to manipulate the DOM with JQuery. Not only does it cause the applicants to lose morale, but it also prevents employers from finding properly qualified applicants.

A sample Dijsktra’s Algorithm graph

If you’re currently applying to jobs and you encounter one of these assessments, don’t get into your head about it. Just learn what you can, and use the good assessments to help round your skills more to become a better developer.

How to Handle Scope Creep as a Developer

By Morgan

On September 20, 2022

In Development

Reading Time: 2 minutesScope creep happens. Clients will always want more, and if you’re developing your own application, you’ll have new ideas to improve it. It is a magnanimous feat to finish an application, but what if adding to the scope is a great idea? Should you eschew all new ideas in favor of completing the app? Or should you add every new feature idea and hope you eventually finish? Luckily, there are ways to compensate for new ideas, and while it will take discipline not to edit the original scope for release, you can complete your app and ensure all ideas get through to the result.

You may have heard of Agile, CI/CD, Scrum, or other seemingly random terms in relation to development. It can be hard to understand how exactly these work, but the basic idea is that these ideologies manage feature requests and ideas to ensure applications don’t bloat too far out from their original scope. Agile is the most frequently used in SaaS contexts. It effectively sets a baseline scope for the application, and a backlog stores all new ideas so they are not lost. These tend to involve an active list, a review list, and a staging list. The active list holds what is currently in development, the review list is for queuing review of completed features, and staging is for features that are complete and awaiting release. Before the initial release of an application, a second backlog can be created to store the initial scope. This second backlog will set a set number of features that need to be handled for the initial release. It can only be changed if the application does not work without a feature that was missed in the initial creation or conception.

Most other management methodologies are similar and tend to differ in application and effectiveness due to complexity, size of initial scope, and the size of the team, but the backlog tends to be the most important part. The reason for scope creep is really just FOMO, so if you have something keeping track of ideas so you don’t forget them, you can both focus on the current tasks and ensure that in the future you can revisit all your ideas for expanding the scope. This, of course, is not necessary for small applications, such as quick calculators or scripts to rename large batches of files. If you are developing a website or extending a CMS, these systems will be indispensable to your efforts, so be sure to learn how to use them before diving in. You don’t want to get lost in the sea of scope.

Front-End, Back-End, and Full-Stack: Where you “end” up

By Morgan

On September 8, 2022

In Development

Reading Time: 7 minutes

It is no secret that the number and type of web development positions have expanded over the past few years. The longer the internet is around, the more intricate it will become – and we witness this growth of scale and complexity every day. In the beginning, a web developer did it all; They hand-coded each page and hosted them on a server somewhere. Naturally, they had to have the knowledge to do this, but the code of the site was simple – complex in presentation rather than technique. During my time at university (starting in 2018), I was also taught this process – code a page in raw HTML5 and CSS3, then host it. Unfortunately, this is an inaccurate view of the web development landscape as it currently is, and I was woefully underprepared by my formal education. I, and I am sure my peers, quickly learned this upon applying to jobs. Looking through job boards for open positions, you find condensed lists of terms you need to know as a professional, and the most common you will see are the three major titles: Front-End, Back-End, and Full-Stack. In this post, I will be delving into the differences between Front-End, Back-End, and Full-Stack – and how to determine where you may fit best.

Before diving into the ‘ends’ of it all, let’s get some basics down. In web development, there are primarily three language types: Markup Languages, Styling languages, and Programming Languages.

HTML (Hypertext Markup Language) – a language used to contain and display the content you see – is a markup language. These are often denoted by elements contained in greater/less than (<>) symbols. An example would look like <header>Insert Header Here</header> for the header of a page. These languages aren’t used for creating programs, but rather for displaying information. This means you cannot technically program in these languages, but you can use them to output processing performed with other languages. Of course, there are exceptions to this rule, but they are not very common (see Adobe ColdFusion for a prominent exception). Since HTML is used to display this content, if you press F12 on your keyboard, it should pop up a window for you to view and edit the HTML on this page. You can do this to any site, and any edits you make will be reset on refreshing the page, making it a good way to play around with the language. See the below image for a more detailed example of HTML5 in use.

An example of HTML5 for Front-End Development

An example of working HTML5 code

CSS (Cascading StyleSheets) is a language you hear almost as frequently as HTML. As you may guess by the unabbreviated name, it is a style language. These languages are used to change how the markup language displays its information. It can change backgrounds, font sizes, and even what is displayed and what isn’t. These often set default styles for the pages so they look a certain way upon loading, and then are changed by a programming language depending on what the user does on the page. For example, if you’ve ever had a pop-up ad, CSS is what was used to have it fade in, then fade back out when the X was clicked. While the CSS animated the fade-in/out, the programming language governed when it happened. Styling languages cannot do these things alone, and thus they suffer the same limitation that Markup languages do.

CSS3 code in VSC for the Front-End of my personal portfolio website.

An example of CSS3 code for a website

Programming Languages are how these shortcomings are resolved. JavaScript is one of the more commonly referenced languages for programming in web contexts. Programming is the process of creating algorithms (processes/solutions to problems) via logical expressions to determine function. That sounds fancy, but it is mostly “When x happens do y”. Despite its simplicity, markup and style languages are not built to do this, and thus a programming language is necessary. For example, when using HTML5/CSS3, it is very common to see JavaScript included for functionality. Many – if not most – new developers are taught all three concurrently by default. Other programming languages can be used for web contexts, and some start to blur the lines between Markup and Programming, but those specifics aren’t important for now. The two programming languages you (are most likely to) need to know moving forward are PHP (Hypertext PreProcessor), and JavaScript (sometimes abbreviated as JS). Side note: PHP does not match its unabbreviated form anymore, but it used to be called ‘Personal Home Page’, hence the abbreviation.

Some JavaScript &jQuery code in VSC for the Front-End of my personal Portfolio

An example of JavaScript used for Front-End Functionality

With that context in mind, we can move forward with defining each end of development, and their respective scopes.

Front-End is referring to the parts of the site visible to clients and the general public. This (typically) does not require any authorization to access, and should ideally be used to pull people further into the site. For example, the part of the site in which you are currently reading this post is the front end. This tends to primarily consist of HTML5/CSS3/JS or HTML5/CSS3/PHP and may be returned by a CMS (Content Management System). CMSs are widely used nowadays to make managing large amounts of content and pages simpler for the site admin. These tend to have a database in which they store pieces of information. This information is made up of broken down bits of the front end and may contain raw HTML5 to be recalled later. When you load a page, the preprocessor (such as PHP) will call the database to look for those pieces, and then they are returned and rendered for you to view. A Front-End Developer will not mainly deal with how the page is stored/returned, but rather what the page looks like, and what it does. They will develop the content and user-facing functionality, and will often be firefighters to put out the flames of disaster if a page has bugs. Front-End developers are sometimes paired with a Web Content Editor team so they can focus more on the style and functionality of the sites. This practice is more frequently seen in organizations with large sites and databases, like Wikis or Universities.

Keeping the bounds of Front-End in mind, you might be able to guess that Back-End is the rest of the site. They deal with the how of data-recall, will develop applications for employee-facing purposes, and might extend the CMS, or change how the data is broken down for storage. This often doesn’t have to do as much with the content that’s being broken down, but rather the general rules for its organization. They don’t have to worry as much about how things look unless they will be interacted with by non-developer employees, and more often than not, the Front-End team will design the interfaces for those apps anyway. They aren’t any more or less technical than the front-end despite how it may sound, but they are a bit more abstract. Abstraction in a programming context is referencing how broad something can be to still deliver the desired output. Front-End development tends to be less abstract because the user needs to see one specific output, but Back-End development tends to be very abstract to allow Front-End developers to get as much as they can out of the platform.

What then, is Full-Stack development? It doesn’t reference either end – and what is a ‘stack’? Full-Stack is a developer/engineer who can work on both Front and Back End Applications, as well as engineer databases around their needs. The ‘Stack’ refers to a tech stack, which is the sum of languages and technologies used to create an application or website. For example, YouTube uses a variation of the LAMP Stack (Linux, Apache Web Server, MySQL, and Python/PHP). Typically, developers are only on one end of this stack. However, for more abstract problems that may deal with either end, or for developing solutions for other internal developers, full-stack skills tend to be necessary.

Knowing what Full-Stack development is, why is it not just called Full-Application, or even Application Developer? In some cases it is, but most of the time it is called full-stack for a few reasons. First, every company will use different stacks. Just because you are a full-stack developer doesn’t mean you’ll be able to use their stack, but you may be able to use one end of it. You may be able to develop for MERN (MongoDB, Express.js, React.js, and Node.js), but not for LAMP. Alternately you might be able to develop for LAMP in conjunction with Node.js and Angular, but not for LAMP in conjunction with Python and React. Many times, companies look for full-stack developers not for larger flagship products, but for developing or extending smaller (potentially new) applications. This tends to be the case for large companies like Amazon. Their stack can be too large to expect a single developer to learn, and it is often simpler to manage two specific teams while having full-stack developers on reserve. Application development does not fit the full extent of what full-stack development is/can be, but full-stack could mean application development, similar to squares and rectangles.

Given these definitions, how can you decide where you end up? As a developer, you can fill any of these roles, but does that mean you should? This is a very subjective topic, but typically the answer is no, you probably shouldn’t just become a full-stack developer by default. It is good to have full-stack experience, but for most of the population, this experience should serve as a way to help you understand which you prefer. I have done full-stack development because I enjoyed delving into how the data breaks down and is reconstructed, but at the same time, I tend to enjoy the Front-End more. I decided that I should describe myself as a front-end engineer with full-stack experience, and people tend to understand what that means. If you enjoy the design and UI or prefer to work on things that directly respond to input, the front-end is probably where you belong. Else, if you enjoy mucking about in the data, really looking at storage and optimization, and creating data distributions and APIs, the back-end is probably more your speed. If you truly enjoy both, maybe you can be a full-stack developer, but do keep in mind these can be very specialized positions. You may need to work separate front and back-end positions to qualify if you don’t start your professional experience in full-stack. For some, this is more effort than the experience is worth, and if you are one, it may be best to look at one end in particular.

At the end of the day, where you end up in this web of technology is up to your preferences. It will take time for you to fully explore stacks and the functionality within, but eventually you will settle where you are best suited. Development is a complex but fun road to travel, and if you enjoy what you are doing, you will get to where you need to be. Don’t stress about these details too much, just put the effort in and see where you arrive.

Do You Need a Degree to Become a Developer?

By Morgan

On May 11, 2022

In Development

Reading Time: 11 minutesWhat are you wanting out of your job? Are you wanting money, satisfaction, expansion potential, or maybe a bit of all of them in one? A lot of jobs in tech have this potential, but the overwhelming majority of these opportunities seem to be looking for developers. Whether its web development, software development, full-stack or just front-end, there’s a lot you can do under the umbrella of development, both with and without an employer. With that in mind, many people are left asking if you really need a degree to land a job in development. There obviously are those who say no, that they landed a job with 9 months experience and a bunch of projects, but there are still others that call survivorship bias on that and say that a degree is the only reliable way to break into this industry.

My name is Morgan, I’m author for and owner of SleepyNova, and I want to talk about getting jobs in development. As a current Drupal developer for my state university, I feel I’m qualified to discuss this topic, partially because I’m graduating soon from university, but already have 2 years of professional experience from development jobs I landed without any degree. I do want to clarify for best understanding, I did not take any internships, this is purely professional development experience.

In my current experience, it seems to me that there are several factors that need to be considered:

Educational Quality
Problem Solving
Projects
Interview Skills
Developer Type
Where you are Applying

That is a bit of a long list, so I’m going to break it down and talk about one at a time. I would like to point out that nowhere in that list is university attended or degree obtained mentioned. That is because I don’t believe a degree is necessary, and in some cases I believe it can hold back otherwise competent developers. I will discuss that later in the post, but for now, let’s get started.

Educational Quality

The quality of your education is not correlated with what university you go to or what resources you have. I want to dispel that thought out the gate, as many people believe that external conditions manage how well they can learn. Now, I’m not saying you can simply manifest the knowledge into your head, but we are in the modern era, and you have internet access (I know since you’re reading this, unless someone printed it out and handed it to you, in which case, odd but acceptable I guess.), you have all the resources you will ever need. You may not be able to understand them all immediately, but there are some that are beginner friendly enough that given effort, anyone can learn how to develop with a high quality of education.

I know you must be asking a question though. How do I know this as a degreed developer?

My answer is simple. My degree is not in Computer Science or Software Engineering. I got a degree in Graphics Information Technology (GIT for short), and while that sounds similar, the focus was actually on design, at least with the professors who taught me. It had focus areas for Graphic Design, Videography, Commercial Photography, User Experience/Interfaces (UX/UI), and Front-End Development & Design. None of those are development heavy, ironically even the Front-End Development & Design, as the professors claimed you could just know HTML & CSS and get a job (This is blatantly untrue for those who aren’t in Web Development yet).

In other words, this was very low-quality education for someone who would later become a developer. At the time, I wasn’t even a front-end focus, but a Graphic Design focus in the program. I was dabbling in development due to COVID, when I found I had an interest (and could get paid more doing it). At that time I had only taken HTML & CSS, so I started practicing that again, but noticed a lot was missing. That’s when I found JavaScript was necessary to make things work, and after that I thought I was prepared again, until I found out about Libraries and APIs, and that was when I took my education fully into my own hands.

I proceeded to rebuild my understanding of Web Development from the ground up, using the W3Schools site as a guide. I taught myself all I could using the Internet and my belief that you can learn anything if you put the effort in. I restarted from level 0, reteaching myself HTML, and moving forward till I was building full web applications (not quite full-stack, but as close as I could get without databases & containerization). After about 6 months of learning, and around 3 months of interviewing multiple times a week while still expanding my skills, I landed my first official Developer Position.

I like to believe that this was due to my self-education being high quality, but I cannot neglect to mention I took a couple university classes on programming logic at the same time. I had always struggled with programming logic and felt that it would take me longer to learn it myself than to take a class, so I used the resources available to me. I also did not take any courses over 100 level, and once I was confident in my ability, I continued to teach myself via forums and documentation. I want to be absolutely clear on one point: I do not believe that classes were necessary for this step. What I do mean, is that depending on your situation and who you are as a person, university can mean a quicker education while maintaining high standards of quality. I would add the stipulation however, that doing this can create developers that are less capable, as they may not learn the skills that I will be discussing in this next section.

Problem Solving

Problem Solving is something you hear in almost every job to varying degrees. This is not something they teach in university (at least from what I have heard from other degreed developers, and from my own experience). The irony is that problem solving is 90% of a developers job. Algorithms, which are what developers produce, are defined broadly as “a step-by-step procedure for solving a problem or accomplishing some end”. Essentially, we create programs to solve problems, and in order to create a program to solve a problem, we first must solve the problem ourselves. If you cannot do this, it does not matter how many languages you know, or how acquainted you are with X framework or Y API, you will find yourself unable to keep a development job, even if you happen to land one. Problem solving is something that can be learned, as with any skill, but it takes time and practice. This is what I meant when I said that I feel most degreed developers (or at least developers who learned via college) may be less capable. In my journey to learn programming, I had to solve the problem of “I was taught wrong, so I need to reteach myself correctly”. Because I solved that problem before I executed the solution, I feel I was able to avoid the lack of problem-solving skills that normally come from learning programming via college. This problem will normally set in because the mindset becomes less of “how do I solve problems” as a general question, and more of “how do I maximize my grade” as a specific question, or even worse, “how do I pass this with as little effort as possible”. I also only took entry level courses and learned the rest myself, which forced me to keep solving the problem of “I know too little, and what I know is too basic”. This process, I believe exemplifies the phrase “The work works on you more than you work on it”. I would not be able to do what I do without having put the effort in, and the effort is what I feel made me a developer, and what makes other non-degreed developers into successful professionals. In interviews for development positions, something often seen are skills assessments. These often require some knowledge of the languages that were in the description, but they don’t tend to require knowledge of the industry-standard APIs, and sometimes to pass them you may not even need to use the language. These are fundamentally puzzles, not tasks you are going to submit a pull request to. Solving the puzzle simply requires you to understand its solution, the path to said solution, and the ability to articulate it. If you can do this, very often you will get hired, even if you can’t quickly translate it to code, because that skill is easier to learn than the actual solving process. Its why Google and Facebook hire non-degreed developers often: Because they recognize that to reach those developers skill levels, they already had to solve many problems.

Projects

Another very important aspect of getting a job as a developer is how many personal projects you have completed, and not just quantity, but complexity of each project. You could have one massive project with immense complexity, or three median complexity projects, and potentially have the same outcome. What you don’t want is a ton of single page applications with one page of HTML CSS and JS respectively, or what is an even worse alternative – no projects done. This is not just an exercise in solving the problems you are electing to take on, but an exercise of creativity, as you are either creating the problems you need to solve, using a process to find them preemptively, or at the very least able to create something to solve someone else’s problem when it arises. This is another area where college classes may help but are not necessarily the best route. Some professors will assign projects that can be used to demonstrate capability, but the problem is twofold with using these on your resume.

First, if someone else in your class applies to the same job and interviews, they will see that you have the same project and may assume you both downloaded it from a repo somewhere, especially if it looks the same/has similar styling, essentially marking you plagiarizers despite the fact that your code will likely be very different.

Secondly, these projects may not use best practices and self-made solutions if the student is either just trying to pass the class, or if the professor gives the ‘correct’ code and the student changes theirs to reflect it.

It is typically best to use your own projects, that way the likelihood of repeats is low, and when it does happen it will probably have enough differences to not look the same. You also won’t have to ensure your code looks like your professors/classmates, in case they have theirs in a repo somewhere and your code could be flagged as plagiarized.

Before moving on, I would also like to mention that exercises in creativity frequently sound daunting, especially to people who have temperaments that lend to development, as we often see ourselves as “not having the creative touch”. Creativity is not a trait like is often said, but is a process and a skill that can be learned and practiced. There are a lot of books on how to develop, and very often it does mirror traditional problem-solving processes. The oxford dictionary defines creativity as “the use of skill and imagination to produce something new or to produce art”, and development as “the process of producing or creating something new or more advanced; a new or advanced product or idea”. These are similar definitions, so you could say that creativity and development are synonyms: Similar in nature, not exactly the same, but in some cases interchangeable. Using that thought process lends to one end, that if one is learnable, then the other must be as well. Sit on that if you need to, and consider if you aren’t creative, or if you just haven’t learned/developed an intentional process yet.

Interview Skills

Another important aspect to getting a job as a developer is one’s interview skills, which conveniently (sarcasm) is not taught at most universities. If you can’t tell the interviewer your skills, they can’t know you have them. Communication is very important in everything, but especially to sell your skills to a company. You, in essence, are a salesperson, and they – the company – is your client, not your future boss. You need to be able to tell your clients what you can do for them, how effectively, and what your services are worth in a concise and effective way. There are also many books on how to sell and communicate, and these skills are invaluable for getting a job as a developer. These are not things that you can necessarily put on your resume to give you a bump above the rest, but you may be able to use better language in your resume, or it can give you a boost in the first interview to get a second.

Some universities do have a program for mock interviews, but without stakes there is not much weight to them, and as far as I know there isn’t much data to show these definitively help in any way. These programs may help for some, but a better way to learn according to most professionals is to apply to a lot of jobs, regardless of if you want them – preferably ones you don’t want – and get experience interviewing that way. I don’t see any potential downsides to going to a university mock interview program, but don’t feel disadvantaged if that opportunity is not available to you.

This does tend to apply to all job interviews, not specifically development, so if you are considering development but end up not going for it, its still useful to learn.

Developer Type

The type/title of the position can also change the necessity of a degree, as title can mean a lot in the minimum qualifications, even if there is a position with the same responsibilities and a different title. Almost anything with ‘engineer’ in the title is going to either require a degree or more experience than is worth transferring for the title. A good example are titles like ‘software engineer’ vs ‘software developer’. They are functionally the same, but one has more pay than the other, and may have slightly more responsibility. In reality, if you are a developer, you fundamentally are an engineer, so you may be qualified but not have the shiny piece of paper. That is ok though, as you can still get plenty of great opportunities without it. Google is known for hiring non-degreed developers, and even if you take a lower paid position (which for developers should be in the 60-80k range) for a couple of years, then apply, isn’t a bad trade, since you’ll be paid instead of paying for a degree, and you’ll have a real shot at big money in the FAANG.

Another thing to keep in mind is that certain areas of focus are easier to break into than others. As an example, web development is easier to get into than software development or server administration. This can mean you can go and learn the basics to web, get two years’ experience, then transfer that experience to learning and applying for software positions that may have been closed to you before. It may seem small, but understanding where to break in quickest and moving your way around titles to gain experience may save you a lot of money and time, especially if you can avoid paying for university classes that you wouldn’t want to take anyway.

Where you Apply

The final point, and a rather straightforward one, is where you are applying. FAANG companies – as I mentioned prior to this section – very often will take non-degreed developers who have experience over degreed developers who don’t, and in some cases even over degreed developers with experience. This is because they know the degree doesn’t create the process that is required to do the job effectively. However, if you are applying for the same positions at small businesses or at institutions that don’t deal primarily with development, you may get rejected regardless of experience due to the lack of degree(s). This is not something you can control, but do some research into companies to understand where their priorities lie so you save yourself time and frustration at being rejected for not having the $50,000 piece of laminated cardstock.

Depending on where you apply though, there is something that can give a major leg up to those with degrees. That is a loophole some companies put in the small text of their applications, and that will essentially say “we include the time it took to complete your degree as relevant experience to the minimum requirement, with a maximum of X number of credits equaling to 1 year experience”. This can mean people who have 2 years of development experience and a degree, like in my case, can count it for 6 years’ experience at certain places. Most do not offer this, but some – especially universities – do tend to count this loophole.

TL;DR

In case you are just looking for a final conclusion, here it is. You don’t need a degree to be a good developer, and in fact in some ways relying on a degree for education can hinder you but can give you a boost up in immediate job hiring. However, you can also just get a job developing for a couple years, and then get the same job, if not better, with that experience. A Degree will take 2-4 years, and in that same time, and for no money, you can get a job by just doing some projects instead of paying for classes from a university.

Keep in mind, this is all my opinion as a developer who got his start without a degree and received his degree within a year of starting his job, so I don’t have the true non-degreed growth story that some other developers have. So my experience may be different than other developers, so definitely talk to some other developers if you can to get more pointed advice to your situation.