DEV Community: Cole Turner

Lessons Learned in Freelancing

Cole Turner — Sun, 20 Sep 2020 19:34:47 +0000

From 2004 to 2018, I was a freelance web developer and worked on dozens of projects in spaces including tech, retail, advertising, community engagement, software development, and more. These spaces have taught me a lot about how the internet has become the center of our lives and the people who run them.

What is freelance web development?

Freelance web development is when a software engineer performs a web development service on-demand, without committing to a full-term engagement. Developers working in freelance are self-employed and have the flexibility to organize their contracts and schedule at their own discretion. These contracts are an agreement between the freelancer and the client, to perform the job at agreed-upon terms. It can be an empowering experience that allows you to have an impact on a variety of projects.

If you're thinking of becoming a freelance web developer or learning more about freelance, then this article is for you. In this post, I'll share with you the lessons that I've learned and how to have a great time as a freelancer. Moreover, I'll tell you how to work more effectively with clients, deal with complications, and what red flags to keep in mind. Here are the lessons that I've learned in my freelancing career.

#1 - Always Sign a Contract

A contract provides guarantees for both the freelancer and the client. Those guarantees include the scope of the work performed, the terms of payment, deadlines for delivery, and any additional maintenance or followup. As a freelancer, you want to over-clarify every aspect of the work performed and the work not performed, in order to have a healthy relationship with your client. Any ambiguity can cause tension, as these aspects are more difficult to negotiate later on. When I was a freelancer, I used Bonsai (hellobonsai.com) to create contracts and send them to clients for signing. Another option is Stuff & Nonsense's Contract Killer, an open-source contract.

Remember to include in your contracts:
1 Work you will perform.
2 Clarify explicit tasks that are out of scope.
3 Terms of payment including deposits, termination fees, delivery of payment, and late payment fees.
4 Responsibilities and liabilities for both parties, including if either party changes their mind.
5 Ownership, intellectual property, copyright, or other legal concerns. Upon full payment of services.

A contract is going to make the biggest difference in your relationship with clients, and how effective you are as a freelancer. These stipulations protect both you and the client and guarantee you'll have a good time. If you're unsure about your contract, reach out to lawyers and go for consultations. A lawyer who specializes in intellectual property and information technology can provide better guidance, and many offer free consultations.

#2 - Be Clear about Work (Not) Performed

When negotiating a contract with a client, the work performed should be clearly outlined. As part of this process, you will also want to rule out any ambiguity and clarify the work that will not be performed. This is for your protection in the event that later down the line, the client makes a request that is outside of the scope of the contract.

A previous client of mine brought me on to clean up the front-end design for a project. It was a reasonable project that I could deliver in the short-term, about a month and a half. Two weeks later, I started receiving requests to develop new features. This would have delayed the time to complete the contract and made it impossible for me to begin a contract I had already queued up thereafter. Using the contract as a reference, I denied the request as it was outside of the scope that I was able to perform to deliver in time.

#3 - Charge More

Freelancers are self-employed which has additional costs than a full-time employee. They pay self-employment taxes which is about 15.3%. Moreover, freelancers must pay for their own health insurance. The market rate for a freelance job should be at least one and a half times (1.5x) what a full-time employee would make. This will cover your additional expenses.

Your rate will largely depend on what you're able to negotiate. Freelance jobs depend on supply and demand, and what value you're able to bring to a job. A client is paying you for more than your time: they're paying for your experience too. So while it may take 8 hours to create a webpage, your rate also takes into account the years of experience you have in honing your craft.

#4 - Deposit is Non-Negotiable

Deposits are protections for both freelancers and clients. They also help cover expenses to smooth out time in between paydays. A contract deposit is an insurance that the client is able to pay you for performing the work. For these reasons, I've learned that a deposit is non-negotiable.

Clients should want to pay you a deposit because it also demonstrates your commitment to getting the job done. A client that does not want to pay the deposit, will give you trouble later. If they try to negotiate, they will give you trouble later.

In conclusion:
1 The deposit is non-negotiable.
2 The deposit is non-negotiable.
3 The deposit is non-negotiable.

#5 - Always Have a Next Next Plan

Freelancing carries an additional responsibility to manage the pipeline for contracts. You will want to have another contract lined up before your current contract ends. When it's time to start the next contract, you will want to have already made plans for thereafter.

Sometimes a contract doesn't work out. There may come a time when a freelancer finds themselves wanting to void or otherwise not renew a contract. In this situation, it's helpful to have a backup plan to bridge the gap. Short term contracts that are easy to pick up and complete are a great way to fulfill periods of time in between contracts.

#6 - Know When to Walk Away

Money does not replace happiness. When a job doesn't feel right, trust your gut and instincts. If the terms of a contract are not happening as expected, there are a few options:

Talk to the client to try and resolve the situation.
Absolving the contract amicably.
Seek legal consultation.
Walk away.

It's important to understand that above all, communication is important. Talking to the client to resolve the situation requires deep introspection into what is working and what is not working. If there is a shared sense of wanting to absolve the contract amicably, that requires communication. Ideally, there's no need to involve legal representation. The legal route requires balancing the potential loss in the contract stipends versus the loss from time spent in the legal process. When all other options are exhausted, sometimes the best option is to walk away.

#7 - Know When to Run

Knowing when to walk away from a contract is important, but knowing when to run from a bad client is even more important. There are some behaviors I've observed in my freelancing career that are definite red flags.

Want to know all the red flags to watch out for?

Continue reading about Lessons Learned in Freelancing, and all the red flags to watch out for when you're freelancing.

Bon Voyage

These are the lessons that I've learned from my freelancing career. I hope this advice was helpful. Freelancing is a great way to earn money and build a business on your own terms. The most important takeaway is to have an effective contract. Be clear about the work performed (and the work not performed). Charge more for your work than you would if you were a full-time employee. Deposits are non-refundable or negotiable. Freelancing requires being proactive, and so you should have a plan for what to do next. And lastly, it's important to know when to walk away and how to avoid a bad contract or client. In all of these endeavors, trust your gut when your lizard brain is telling you that something feels right, and when it doesn't.

I'd love to hear from you. Let me know what lessons you've learned by sharing with me on Twitter (@coleturner).

How to Grow as a Software Engineer

Cole Turner — Thu, 27 Aug 2020 03:24:18 +0000

Software engineers will spend years looking at code, without thinking about their communication skills. However, software engineering is more than just programming. The reality is that technical ability can only take someone so far. Once you hit the technical ceiling, it becomes about communication.

In this post, I'm going to talk about communication and why it's important. I'll share with you the three domains of communication and decision-making. These domains will give you the tools to take your problem-solving skills and apply them to matters of communication.

Does Communication Matter?

Of course! An engineer can only get so far with technical ability alone. When we look at a job description from Google for a Software Engineer, we see the following:
1 Degree or equivalent practical experience
2 Experience in working with the following: ...
3 Working proficiency and communication skills in ...

Now let's look at the added requirements for a Staff Software Engineer position:
1 Experience architecting and developing distributed systems design.
2 Hands on technical leadership experience leading project teams and setting technical direction.

From these postings, we can see that technical ability can only get you halfway there. Communication skills are required for basic tasks like code reviews and collaboration. These are just the minimum skills required.

Beyond entry-level tasks, higher-level tasks require more strategic and tactical communication. Architecture requires strategizing a systems design through research, implementation, and working with others to oversee the process. Technical leadership requires essential communication skills to be able to direct and influence the group. Without developing these skills, an engineer can only go so far.

That's why we need communication: to grow. We need communication to take our technical abilities to new heights. These essential skills increase our ability to work with others and broaden our impact. To build these skills, we need to be more thoughtful, and we need to know which domains to think over.

The Domains of Engineering Thoughtfulness

Thoughtfulness and decisionmaking for software engineers can be broken down into three domains:
1 Technical
2 Organizational
3 Operational

Engineers are already familiar with the technical domain. Many find their ceilings here because it's easy to be distracted by matters of code. However, to break past that ceiling, an engineer needs to exercise critical thinking in all three domains.

The Technical Domain

Writing code is easy, but figuring out which code to write is not. For any given feature, we could write it a hundred different ways. And while there is no "right" way to write it, we can strive towards writing code that is easier to read and maintain. Every line is a choice that makes tradeoffs to strive towards a healthier codebase.

So what makes a healthy codebase?

Clarity
Direction
Consistency

A healthy codebase has clarity, where new changes are easy to implement against a known path. Implementing new routes, creating new interfaces, and deploying new APIs; tasks like these are straightforward. Struggles in clarity happen when a codebase has too many layers of redirection, multiple mechanisms for the same task, or insufficient tooling and documentation. These together can help make the codebase more accessible to all contributors.

A healthy codebase has a path forward, called **direction. **When considering _tech debt, _the deferred cost of a short-term solution, a healthy codebase is well-documented and guarded by tooling that helps the developer to be productive. A good sense of direction is when tech debt is easy to silo so that it does not impact the rest of the codebase.

Lastly, a healthy codebase has consistency in its use of patterns. This means that what happens in one place of the codebase, is expected to happen elsewhere. Consistency is a spectrum where patterns align together. When there are many contributors over time, multiple patterns can emerge. Inconsistencies can also emerge when introducing new tooling or patterns. On the other hand, these are only problems when there is a lack of clarity or direction in the codebase.

A healthy codebase has a healthy balance of all three devices: clarity, direction, and consistency. When talking through the technical domain, these devices are useful tools for expressing the impact of technical decisions. However, engineers also need to think beyond the codebase. After all, the choices we make have an impact on the whole team.

The Organizational Domain

An organization is a group of people or a company. In engineering, an organization could mean multiple groups of people: the whole company, a specific team, or a group of code owners. The decisions that engineers make affect more than the codebase — they affect these groups of people too. Being thoughtful about the organization is helpful for making better decisions to benefit these groups.

The **organizational domain **is where thoughtfulness and decisionmaking can impact these groups. An engineer exercises this domain when starting inward and reflecting outward on how decisions impact their peers and collaborators. Consider a codebase as a product of its own. Reflect on the users of this product, contributors to the code.

To reflect in this domain, we can ask the following questions:

Who will maintain this decision in the short-term?
How will this decision be adopted by external contributors?
What impact does this decision have to make future decisions?
When is the right time to make this decision?

The final question to ask, considering the inputs above, is: why? When we ask why we're considering the tradeoffs being made in the organizational domain. Finally, when we ask this question we also need to ask the inverse: why not?

Thinking through these problems is how engineers elevate their problem-solving skills to the organization. Reflecting on how decisions impact these groups of people, is how engineers become more effective. The organizational domain is how engineers apply their problem-solving skills to the needs of the group. This takes us into our next domain, where we apply problem-solving skills to operations.

The Operational Domain

The final domain we will cover is the operational domain. This domain is where problem-solving skills are applied to the impact on processes. The previous domains (technical and organizational) have so far focused on things and people. In this domain, we focus on the impact on things and people over time.

When working in product development, we often talk about how to build a minimum viable product. The first process is the one in which we brainstorm and plan before building. In this process, we talk about the scope of the development, meaning what's included. In this process, it's also helpful to ask: what's not included? Through this process, engineers collect a list of requirements, the needs of the development to fulfill the scope. Together, scope and requirements are useful tools for talking about the development process.

What about the processes that happen after the code is written? Writing the code is easy, however, engineers should be mindful of the following technical process that happen afterward:

Code Review
Building and Deployment
Integration into the Mainline

In addition to these processes, our thoughtfulness and decisions can have latent effects that impact how we implement and integrate in the future. Moreover, there can be effects on the organizational and operational processes, such as:

Who needs to be involved in the decision-making process?
How does the scope today affect the requirements for tomorrow?
What requirements can better prepare any incremental efforts?
Are there opportunities to generalize the approach to scale for other initiatives?
After the decision is settled, who needs to be informed?

Questions like these are effective tools for communication and reflection. When communicating in product development, asking these questions can help make an engineer more effective in the process. Reflecting on these answers will also make you a more critical thinker that can influence others at the table.

Conclusion

This framework of thinking is effective for software engineers to become more thoughtful and productive. Being thoughtful about the technical, organizational, and operational domains — will give you the tools to level up as a developer. Effective engineering is not writing the perfect code, but rather identifying how to apply problem-solving skills throughout the entire process. Harnessing communication in your career will help you become more impactful and influential beyond technical ability. The T.O.O framework reconciles these two areas to help you think through the domains and harness communication as a skill.

Photos by Joshua Aragon, Kate Sade and Isaac Smith.

Should I become a Web Developer?

Cole Turner — Mon, 17 Aug 2020 06:02:10 +0000

So you want to know more about web development, or how to become a web developer. Web development (and design) can be a rewarding career for many who enjoy building applications that serve the entire world. Here's what you want to know about web development, whether it's a good career path, and when's the best time to break in.

What is web development?

Web development is a kind of software engineering where the product is an application that is made to be run in a web browser. In contrast to back-end engineering, web development is an umbrella of front-end and sometimes back-end engineering, where the application needs to run against a variety of clients (Chrome, Firefox, Safari, etc).

You might find yourself asking: is web development just HTML, CSS, and JavaScript?

Those are the programming languages that are used in web development, however the facets of web development span multiple categories. Those categories include:

User interface and User Experience
Accessibility
Search Engine Optimization
API, such a GraphQL
Bundling and Delivery (Webpack, Serverless, etc)
Performance and Testing
and more!

You don't need to be an expert in all of these categories, however, having an understanding of how each category factors in the scope of building web apps can broaden your skillset and impact.

User interface and experience are the processes of designing and developing how a user makes meaning from your web application. The structures and flow of the interface come together to guide the user to where we want them to go.

Accessibility is how we make our interfaces easier to use by everyone. This is essential for creating applications that can be used by people with various impairments, including: visual, auditory, cognitive, and motor impairments.

Search Engine Optimization is the process of making web pages more accessible by a certain kind of user: robots! This area of expertise is centered around helping crawlers better understand how to index content in your web application.

API is the way in which your web application gathers data from external sources, and how it interfaces with the services that power the application.

Bundling and delivery are the domains that deal with how the web application reaches the client from the server. This includes packaging the HTML, CSS, and JavaScript. Understanding this domain will also have an impact on how well your web application reaches a global audience, where some users may have limited bandwidth or hardware.

Performance and Testing include some of the topics listed above, however, I've called it out as a separate category. To be effective in these categories requires some deeper understanding of the entire picture - from broad strokes to fine details. These areas of knowledge help keep our applications running smoothly and easier to maintain.

Does web development have a good career path?

Folks worry too much about whether they should start out as a front-end engineer, back-end engineer, or try to make the leap to full-stack. Other folks worry whether Machine Learning or GPT-3 will put us all out of business. There is an understandable concern about whether front-end development is hard to break into.

However, it's always been difficult to break into this industry. Up until just recently, having a computer science degree was a requirement for many job postings (and it still is sometimes). Job postings will also say they accept equivocal years of experience in the industry. If you are a self-taught engineer or don't have some kind of educational background in the industry - then finding that first job is a struggle.

To break into the industry today, there are several paths:
1 Have a computer science degree, or relevant education (bootcamp, internship, etc).
2 Build a portfolio of freelance or contract projects
3 Work in open source or community developer relations

All three of these paths take a lot of hard work. Newcomers are often afraid of these options because the hustle requires a large upfront investment. You don't need a degree, or to go to a bootcamp, to make that happen. Try taking a few online courses for free to gauge your interest. There's a lot of work that you can do on your own.

Once you get that first job, it becomes easier and easier over time. Similar to any other industry, web development is a mixed bag of really great jobs to not-so-great jobs. I spent a lot of time in the realms of freelance, contracting, startups, and now corporate development. Any of these realms can be rewarding, depending on what you're looking for and the effort you put in.

The trouble is that many of the not-so-great jobs are front-loaded, which discourages many bright minds from continuing into more rewarding roles. Once you move past that junior role, your compensation can increase by anywhere from 50% to 100%. Everyone starts as a junior.

What I love about web development are the challenges, the rewards, and the impacts. Building a web application is a thoughtful process as described in What is Web Development?._ _That process opens the door for a web application to reach millions to billions of people around the world. It's a very rewarding process when you build a web application that reaches people and has an impact on their lives.

What is the right age to start a career in web development? Am I too old?

The tech industry often attracts a younger crowd because as an industry, it often contributes to the evolving cultural moment. Tech fuels our lives: from shopping to entertainment, health and fitness, and the world around us. But there's no upper limit on breaking into the industry. People join the industry in their 30's, 40's, 50's, 60's. The world's oldest programmer, Masako Wakamiya, was 82 when she released her first app.

Maturity will be your compass, and will actually help you stand out from some of the younger developers who require more experience in communication and essential skills. While there are some jobs that bias towards younger crowds (because youth can be exploited), the paths described above still apply to anyone.

That first job will still take some hustling, and so choosing a path that aligns with your goals and expectations will help guide you. People of all ages expect that when they get a job in the industry, they will start somewhere in the mid to senior levels. They expect this because they are following the folks who have already broken that first ceiling. Patience and persistence will get you where you want to go.

Every age is the right age to start a career in web development.

Why become a web developer?

If you've made it this far into this post, then it's likely that you are on the fence and leaning towards becoming a web developer. That's the first step. If you're still deciding, here are some great reasons to become a web developer:
1 You enjoy learning and solving problems.
2 You want to create things that are used by people around the world.
3 It's a good source of income and livelihood.

Or maybe you have your own reasons. Let me know what your reasons are, or if this post was helpful. Message me on Twitter (@coleturner).

Hard to Read: Coding, with Communication

Cole Turner — Sat, 08 Aug 2020 22:04:17 +0000

Have you ever opened your pull request and then received this comment?

This is hard to read, could you change this?

Why has this happened to everyone?

Source code is just like any other kind of language: it's a construct of symbols and grammar that make up meaning. When people say "that's hard to read," what they mean is one of a few things:

It's hard to make sense of the symbols.
It's not easy to follow the grammar.
This is not something I have seen before.

Source code is a diverse language just like any verbal language. We each have our own code dialect. In JavaScript, we do our best to normalize the inputs through tools like ESLint, Prettier, and TypeScript. They establish a common language of symbols, grammar, and sometimes a dictionary and thesaurus. And we make sense of it all, through the use of symbols and grammar in the code.

Sense of Symbols

There's a great Cingular commercial from 2007, where a mom and her kid are communicating about their texting bill.

Watch Cingular Commercial - 'bff Jill'

If you immediately recognize the symbol idkmybffjill, then you might not find that hard to read. On the other hand, if you've never seen that symbol before or you recognize some of the contents, you will find that symbol hard to read.

Let's look at some code examples.

Hard to Read: Sense of Symbols - Variable Names

// https://davidwalsh.name/javascript-debounce-function
function db(f, w, i) {
    let t;
    return function() {
        let c = this, args = arguments;
        let l = function() {
            t = null;
            if (!i) f.apply(c, args);
        };
        const n = i && !t;
        clearTimeout(t);
        t = setTimeout(l, w);
        if (n) func.apply(c, args);
    };
};

This function is hard to read because all of the meaning has been obfuscated through obtuse variable names. All of the meaning is encoded in the implementation, without any content words. This confusion stems from a lack of recognition.

Did you guess that this function is a throttle? If so, then I'm sorry because I took this opportunity to trick you. This function is actually debounce.
I won't do that again! But I do want to share another example.

Hard to Read: Sense of Symbols - Unfamiliar Syntax

class Houseplant {
  // private fields
  #name = "Untitled";
  #species = "Unknown species";

  constructor(name, species) {
    this.#name = #name;
    this.#species = #species;
  }

  // from upcoming tc39/proposal-record-tuple
  toRecord() {
    return #{
      name: this.name,
      species: this.species
    };
  }
}

In the example above, I am referencing some unusual syntax, from a new class properties functionality called Private Fields. The toRecord function also makes use of a current proposal for Records and Tuples.

Both instances are making use of the # sign to represent different functionality. This is confusing, and potentially hard to read because it lacks familiarity.

Confusion by Sense of Symbols is primarily an issue for folks who are new to the industry or new to the language. Due to a lack of recognition or a lack of familiarity, they might find themselves saying "that's hard to read."

Sense of Grammar

Once a developer has become more familiar with a language, the struggle with code becomes a matter of grammar. It is the same struggle with learning any kind of verbal language, where the words start to make sense and the trouble becomes acclimating to the grammar.

Let's look at an example:

Hard to Read: Sense of Grammar - Overloaded Example

function pickColor() {
  return isTimeOfDay >= evening
    ? theme === 'light'
      ? Theme.colors.light
      : Theme.colors.dark || Theme.colors.default
    : theme === 'dark'
    ? Theme.colors.light
    : Theme.colors.dark || Theme.colors.default;
}

When the time of day evening, when the theme is light, what is the color?

For most people, it will take more than ten seconds to find the answer to that question. Most developers will say this code is hard to read and repeat a tactical answer about nesting ternaries, instead of highlighting the communicative issue at hand.

Confusion by Sense of Grammar is when the structure goes against the expected rules of grammar. What one developer thinks is "hard to read" is another developer's groove.

Who gets to decide?

Some might say Brendan Eich, who in 1995 invented the scripting language Mocha that would later be known as JavaScript. Others might say TC39, the committee that oversees the evolution of the language today. That is a view on linguistics called prescriptivism.

But we know that a language, even for programming, is defined through its usage. Languages we have today evolved because someone made a change. This is a view called descriptivism.

The answer is...

"It's harder to read code than to write it"

—Joel Spolsky, Things You Should Never Do, Part I

If you're soloing it, then what's easy to read is whatever choices make you feel more productive. When you're a part of a team or a community - the code language is the sum of all the inputs, that which makes the group feel more productive and effective.

If it cannot be enforced with tooling or documentation, then it's a matter of preference. That is where tools like ESLint, Prettier, and Typescript excel at what they do: enforcing consistency. They keep developers in their lanes. The code language then becomes "what made sense when we configured our tooling." Preferences aren't usually helpful to leave as a comment to someone else's work unless it can be expressed in terms of semantic and cognitive weights for our uses of symbols and grammar.

Most developers only talk about familiarity. What matters is how much effort is spent mentally following the code. For example, abstractions (moving the symbols away) can lead to disproportionate indirection (distributing the grammar), making it harder to follow the code. Symbols can be used in place of grammar. All of this adds up to code language fluency. This kind of feedback is something we need to grow away from, and trust in tooling and documentation.

We should be vulnerable and empathetic instead. It's on us to try to understand and trust the coder who already did the work. As reviewers, we can describe the impact it has on the semantic and cognitive weights. Saying "that's hard to read" is no different than telling someone their verbal language is difficult to understand. When working with others, we have to understand that the common language is the lowest common denominator among the group, not the average familiarity.

Codebase language is an evolving negotiation. Sometimes boilerplate is boilerplate. Other times it's keeping the semantic and cognitive weights balanced. It's important to understand that our familiarity with syntax, symbols, and grammar — isn't dictated by who wrote the code first. It is through the continued and evolving use amongst all using that codebase language.

Photo by Agence Olloweb.

Optimize SVG images for the Web

Cole Turner — Thu, 06 Aug 2020 08:27:25 +0000

Scalable Vector Graphics (SVG) images are the bee's knees, that cat's meow. For those unfamiliar with those idioms, what I mean to say is that I love to use SVG images whenever possible.

There are a few reasons why SVGs are great:

They can be scaled up and down without distortion.
Vector graphics are usually smaller in file size.
The ability to use animations and transitions on layers.

How to Optimize an SVG

As you develop your web application, the SVG files are usually exported from programs like Sketch or Adobe Illustrator. On the other hand, you could also be using icons from websites like Iconfinder or Flaticon. These files usually contain a rich set of metadata and paths that include points used by designers. Unless you are using those specific paths and points in your application, they can be optimized to further reduce the file size.

There is a really awesome tool called SVGO which will process and optimize your SVG files. It can remove excessive markup and metadata, optimize and clean paths, and minify the output. It can be included in your build process, or run independently.

Even better than the command line interface, is a website created by Jake Archibald (@jaffathecake), called "SVGO Missing GUI" or SVGOMG.

From here we can upload or paste our source code into the REPL, toggle the options, and easily gather the output for use in our HTML and JavaScript.

In the example above, we can see how it saved 68% for such a small icon. When you're working with a lot of icons, or larger vector graphics, it can make a noticeable impact on your overall application.

Better bundle sizes mean your web app is faster, more responsive, and reaches more customers around the world. 68% is great!
Try it for yourself!

Optimizing an SVG for React

If you're building your web application with React, it is not as easy to copy and paste the SVG output into your application. React uses the naming convention from JavaScript objects to create HTML elements. Instead of stroke-width, we use** strokeWidth** in JSX.

Fixing all of those attributes takes too much time, and so enter: React SVGR

Similarly, React SVGR is also a node API, command line client, and most importantly - a GUI playground. Using this tool, we can paste our SVG output from SVGO and it will output a React component.

Optimize with SVGO or SVGR Playground

In the example above, we can see that SVGR does have an integration with SVGO if you have a JSON config object on hand. However, I rarely carry that around with me as I am developing - so I generally optimize with SVGO first and then paste the output into SVGR.

Copy, Paste, Copy, and Paste Again

With these tools, you can deliver the most optimized version of vector graphics in your web application. Whether you're using React.JS, or vanilla HMTL and JavaScript - these tools have you covered.

Now we're cooking with some gas - You

Photo by Andrej Lišakov

How to Write a Software Engineer Resume

Cole Turner — Thu, 06 Aug 2020 06:07:15 +0000

Your resume is the key to the door for your next job. If you're looking to land that next role, here are the awesome tips you need to know to make your resume stand out from the rest.

Before You Write the Resume

The most effective resume speaks to the audience. Before you start on your resume, ask yourself: who is my audience? In most cases, that audience is a recruiter, a hiring manager, and ... robots?

The Resume Funnel

That's right, robots are reading your resume! Before a recruiter or hiring manager sees it, a robot will parse and read the resume. When you submit your resume in a form online, via LinkedIn, and even sending it via email; it all goes through a robot. It's super helpful to know how your resume makes it through the funnel so that we can optimize it to make it further.

This graphic visualizes just how many resumes make it from the initial submission down the funnel. When a company is hiring a software engineer, a recruiter will screen submissions using an Applicant Tracking System (ATS).

These systems parse a software engineer's resume to fit in the system. In addition, it will highlight the keywords that fit the job description. Recruiters have one of the hardest jobs of all, finding the best submissions. When a recruiter is trying to find software engineers, this is how they're looking for leads to reach out to:

Wow, that's a lot of resumes!
Once your resume makes it here, it's all about the content of your resume. A recruiter will prioritize the candidates with the best resumes and set up an initial call. To get there, you will need to format and write a kickass resume.

Formatting Your Resume for Success

Software engineer resumes need to be ATS-ready. To get there, here are the top tips you will want to know:
1 Use .doc format when uploading, PDF when emailing.
2 Avoid complicated layouts, such as tables or columns.
3 Use standard fonts and bullet points.
4 No images
5 One page, no more or less.

These tips will help you format your resume in a way that the ATS systems understand, to get through the top of the funnel.

Here is an ATS Resume Template you should use to get started, created by an ex-recruiter who worked at top companies and screened thousands of resumes.

How does a software engineer get their resume further down the funnel?
Let's talk about how you can leverage ATS-formatting, and write a kickass resume that will get you more attention from the top of the funnel, to increase your chances of getting an interview.

How to Write Your Resume

This is your moment to wow the recruiter and the hiring manager. Resumes are all about selling yourself - describing your abilities and your impact.

Before we get into some specifics, here are some general tips you should know:
1 Use a new bullet point for each responsibility, role, or other ability you're describing.
2 Be specific, use action verbs.
3 Be honest! Do not embellish or lie on your resume.
4 Include metrics or statistics that can demonstrate impact and value.

With that in mind, let's get into some really helpful specifics.

The STAR Method

When you are describing your position, you will want to use the STAR Method.

Situation: Your role and responsibility.
Task: Demonstration of applying your expertise in that role.
Action: The efforts you made, whether acting alone, collaborating, or delegating.
Result: The outcome of that action, including the value and impact it had on the team and the company or business.

Using this framing method, we will extract the most value out of our resume and create meaningful statements that are great conversation points when talking to recruiters and managers.

Let's Look at an Example:

Wrote code in HTML, JavaScript, and CSS for website application.

That's a good start!
We could do better to capture the STAR power of this resume item. Almost every software engineer with a resume will have something like this on their first draft.

To add that STAR power, ask questions like:

What is unique or influential about the situation?
How does the task relate to the job description?
What actions are the hiring manager looking for?
Why does the result matter to the company I want to work for?

These questions will help you frame your resume items, so that you can say something like this:

Developed a single-page front-end application using HTML, JavaScript (JS), and CSS - to optimize the responsiveness, which increased conversion rate from 2% to 7%.

Much Better!
With this change of wording we can see how this stands out from the example we saw earlier. Bring STAR power to all of your experience.

Be Mindful of Your Language

Mirror the Job Description Language

When you're writing your resume, you will want to use the keywords that appear in the job description. So for example, if you are applying for a "Software Engineer" position, you will want to say that somewhere in your resume. On the other hand, if the position is titled "Web Application Developer," then you will want to incorporate that as well.

Sprinkle in some Synonyms

So from our example above, "Developed a single-page application," we will also want to expand on the word "developed." Here are some other words that you will want to capture in your descriptions to broaden the appeal:

Implemented
Architected
Engineered
... and so on!

Using synonyms in addition to the keywords will allow your resume to match as many job descriptions as possible.

Don't Sell Yourself Short!

A description that is too vague or too short can come across as uninspiring. When in doubt, use the STAR method. A resume doesn't need to be ten pages long, however, it does need to be long enough to evoke curiosity.

If your resume is shorter than a page, you will want to create more experience before you start sending that resume out.

Leave Some to the Imagination

Similar to the point above, a resume is meant to be used to match against a job description and fulfill a recruiter's requirements. From there, the purpose of a resume is to inspire and evoke curiosity from a hiring manager and the interview panel.

One Page is the optimal length for a resume. You only need to highlight the last few positions that are relevant. Even if you have decades of experience, your resume needs to be compelling enough to leave an impression **within ten seconds. **When you're at the top of the funnel, that is about how long someone will glance at your resume before moving on to the next one.

A description that is loaded with responsibility and impact, or runs on more than a sentence or two - can actually have the reverse effect! Too much of a description can come across as appearing to know too little or give the impression of overselling.

Here's an example:

Designed a webpage using Photoshop, creating multiple layers and exporting them via a PNG. Collaborated with engineering to deliver the PNG in a ZIP file. Planned and coordinated the delivery before the agreed upon timelines. Communicated with the team to revise the delivery throughout the project.

A statement like this can undervalue your position. Why this happens is because when we look back at the STAR method - this description is mostly a given. It is expected that a designer would perform these tasks, and it doesn't add much value to those expectations.

Let's look at that, with a little more STAR power:

Designed a webpage in collaboration with engineering, working cross-functionally with the project team to deliver ahead-of-time. This resulted in us reaching the market before our competition.

Now that's a star! The difference here is how much value the designer brought to the role, exceeding the expectations.

Avoid Skills Lists

Many of the resumes that get filtered out at the top of the funnel will have a giant cloud of keywords that are meant to fool the ATS robots. This is called keyword stuffing. What happens is that an innocent software engineer will create a skills list that they used at a position, and the robot will interpret this as keyword stuffing.

Skills: React, Photoshop, Microsoft Word

What you want to do instead is take the most important skills that are relevant to the hiring position, and express those at bullet points in your resume items.

Developed a React web application to display order inventory.

Optimized web assets using Photoshop to reduce application size.

Collaborated on project specifications using Microsoft Word.

In some cases, a particular skill can be so ubiquitous to the role that it's not worth including at all. If the skill is very common, it is only worth mentioning if it added value or made an impact on the result.

Get the Job

You've written your resume, formatted it to be ATS-ready, and demonstrated your STAR power. Now it's time to submit your resume, right?

Before you submit your resume, do one final check. Find the job description and compare it with your resume. You should have included similar keywords such as:

The Job Title
Situation and Action Words from the hiring position
Keywords from the hiring description

Once you've done that, review your resume and submit it! You've done everything right, and your resume is ready to go.

If you found these tips helpful, or you have some advice you would like to add - you can reach out to me on Twitter (@coleturner).

Photos by: Markus Winkler, Gatis Murnieks, Brett Jordan

JavaScript ES6 Symbols

Cole Turner — Sat, 01 Aug 2020 03:37:25 +0000

The JavaScript Symbol is a primitive data structure that has a unique value. They can be used as identifiers since no two symbols are the same. Unlike strings, Symbols can be used to create properties that don't overlap with other libraries or modules.

Example

const sym = Symbol();
const namedSymbol = Symbol('javascript');

sym === namedSymbol // false
typeof sym // "symbol"

console.log(namedSymbol); // Symbol(javascript)
console.log(namedSymbol.description); // javascript

Pretty neat, now our JavaScript app can uniquely identify properties without any risk of colliding with another identifier. But what if we want to share symbols across the codebase?

Shared Symbols

const sym1 = Symbol.for('javascript');
const sym2 = Symbol.for('javascript');

sym1 === sym2 // true

When we use Symbol.for we can leverage shared symbols that are available in the global symbol registry for our codebase.

Why use Symbols?

Now that we understand that Symbols are unique identifiers, we can understand the potential for what a software engineer can do with them.

Symbols can be used for metaprogramming

const UserType = Symbol('userType');
const Administrator = Symbol('administrator');
const Guest = Symbol('guest');

const currentUser = {
  [UserType]: Administrator,
  id: 1,
  name: "Cole Turner"
};

console.log(currentUser); // {id: 1, name: "Cole Turner", Symbol(userType): Symbol(administrator)}

console.log(JSON.stringify(currentUser)); // {"id":1,"name":"Cole Turner"}

currentUser[UserType] == Administrator; // true
currentUser[UserType] == Guest; // false

In the example above, a symbol is used to type the object. The property is only available when referenced through the symbol reflection. This is great for when we want to add properties to an object that we don't want to appear in non-symbol reflection, such as JSON formatting or object iteration.

Symbols are separate from string keys

const languages = {
  javascript: 'JavaScript';
};

// Extend an object without conflict
const isLocal = Symbol('local');
const localLanguages = {
  ...languages,
  [isLocal]: true
};

// Detect if we're using local or the original languages object
[languages, localLanguages].map(obj => {
  if (obj[isLocal]) {
    console.log('Local languages:', obj);
  } else {
    console.log('Original languages:', obj);
  }
});

In the example above, we can extend objects without conflict with their original properties. This also means that when we are stringifying, the symbols are not included.

Symbols can be used as ENUM

A great use case for Symbols is when there is a need for enumerated values.

**JavaScript Symbols - ENUM example

const Tree = Symbol('🌴');
const Flower = Symbol('🌻');
const Leaf = Symbol('🍁');
const Mushroom = Symbol('🍄');

const plantTypes = [Tree, Flower, Leaf, Mushroom];

function createPlant(type) {
  if (!plantTypes.includes(type)) {
    throw new Error('Invalid plant type!');
  }
}

Here we are using Symbols to control behaviors without those properties leaking into the typical reflection, and preventing runtime errors from typos.

JavaScript Metaprogramming with Symbols

With Symbols we can dive deep into low-level JavaScript to change behaviors for various use cases. This lets us create powerful objects that can do more than meets the eye. Here are some examples of how we can use Symbols for JavaScript metaprogramming.

Symbol.asyncIterator

const tenIntegers = {
  async* [Symbol.asyncIterator]() {
    for (let i = 1; i <= 10; i++) {
      yield i;
    }
  }
}

for await (const i of tenIntegers) {
  console.log(i);
  //  1
  //  ...
  //  10
}

Symbol.hasInstance

const Loggable = Symbol('loggable');

class LoggableError extends Error {
  static [Symbol.hasInstance](instance) {
    return instance instanceof LoggableError || instance[Loggable] === true;
  }
}

class ApplicationError extends Error {
  [Loggable] = true;

  logError() {
    if (this instanceof LoggableError) {
      return;
    }

    fetch('/log', { message: this.message });
  }
}

class DatabaseError extends ApplicationError {
    [Loggable] = false;
}

Symbol.iterator

const users = {
  1: { name: 'Cole Turner' },
  2: { name: 'Anonymous' },
};

function toValuesArray(obj) {
  return {
    ...obj,

    [Symbol.iterator]: function* () {
      for (const value of Object.values(this)) {
        yield value;
      }
    },
  };
}

// toValuesArray will now change the spread of our object
const arrayOfUsers = [...toValuesArray(users)];

Conclusion

The Symbol is a new primitive that can unlock a lot of potential with metaprogramming in JavaScript. They make great enumerated values, allow software engineers to extend objects without collision, and can separate concerns when working with data across the codebase.

For more information, check out the MDN documentation on Symbols.

Ask Me Anything: Career Development

Cole Turner — Thu, 30 Jul 2020 05:07:05 +0000

What questions would you like to ask a Software Engineer about Career Development?

Ask your questions here:
https://cole.codes/posts/ask-me-anything-career-development

I will also answer questions posted in this thread.

Ask Me Anything: Front-End Edition

Cole Turner — Tue, 28 Jul 2020 07:32:17 +0000

What questions would you like to ask a Software Engineer about Frontend Web Development? I will try to answer your questions via the following URL:

https://cole.codes/posts/ask-me-anything-front-end-edition

Photo by Jon Tyson.

When do I need a CSS Framework?

Cole Turner — Mon, 27 Jul 2020 02:54:51 +0000

Cascading Style Sheets (CSS) frameworks do the heavy lifting when you're starting your web application. There are a number of options to choose from, which begs several questions: which framework do I use? When do I need a CSS framework? How do I choose a CSS framework?

What is a CSS framework?

A CSS framework is a collection of styles that can be composed together to create a user interface. A CSS framework gives web developers the presets to handle layout, forms, buttons, theming, and common interface patterns.

Here are some of the CSS frameworks you will hear about today:

Many of the presets among these frameworks will overlap. Where most CSS frameworks stand out is how the developer (you!) will use the framework. Let's look at some brief comparisons, and how they relate to markup (HTML), styles (CSS), and scripts (JavaScript).

The CSS Framework Showdown

Bootstrap vs Pure.CSS

Both of these CSS frameworks have much in common. Bootstrap is a UI toolkit that uses markup, styles, and scripts to create re-usable interfaces. Pure.CSS, on the other hand, is mostly styles and just markup.

So how do they stack up? While Bootstrap is designed to do the heavy lifting for you, Pure.CSS is designed to be a base for your common interfaces. This can make a huge difference in the amount of effort it will take for the developer. When it comes to bundling size, Bootstrap will be much larger (over 100kb) while Pure.CSS only uses less than 4kb. This can make a huge difference in your web app and how fast it will load.

Most people will choose Bootstrap for user interfaces that are not accessible to the public, or otherwise when there is no need for a bespoke design. Developers will reach for Pure.CSS when they're looking for less theming and want to have more control over the UI. This is because Pure.CSS is a great starter for building styles on top of the framework defaults.

Bootstrap vs Tailwind CSS

Bootstrap and Tailwind CSS are great options that fulfill different needs. In our last comparison, we discussed how Bootstrap is designed to do the heavy lifting as a pre-designed user interface toolkit. Tailwind CSS, however, doesn't provide any user interface components.

Tailwind CSS is a strictly CSS-only framework with only styles that are used for composition. It provides utilities that the developer can use to compose styles to build custom designs. Tailwind CSS also has a much smaller footprint, coming in at 37kb.

When choosing between Bootstrap vs Tailwind CSS, the decision comes down to whether you need an opinionated framework or not. If you want all of the building blocks to build something bespoke, go with Tailwind CSS. Otherwise, if you need to build something quickly and the design doesn't matter, Bootstrap can help.

Pure.CSS vs Tailwind CSS

Pure.CSS and Tailwind.CSS have more in common than the previous options. Both of these frameworks are centered around building blocks, while Pure.CSS is a sorta half-way point between Bootstrap and Tailwind.CSS.

Pure.CSS is a great option when you need just the basics covered. But if you find that does too much, Tailwind CSS will give you all the utility without the fuss. Both of these frameworks have smaller footprints than most, so either choice can fit into your web application without too much bundle guilt.

When do I need a CSS framework?

With plenty of choices at your disposal, the choice to use a framework will depend on the requirements, and your needs. Here are some common requirements and need to consider when you're starting your next CSS project.

CSS Reset

Web browsers each have unique styles, and in order for the design to be consistent, you will sometimes need to consider a CSS Reset. This will override the browser's default styles to normalize the styles across browsers. There are some great options for a CSS reset.

Design vs. Delivery

This is one of the major reasons to consider a framework. A framework can do the heavy lifting and free the developer up to prototype and build. On the other hand, some frameworks are overly opinionated and can get in your way when you need to build something custom. In some cases, it can be a matter of both design and delivery. Then there is bundle size to consider.

Bundle Size

Another important factor that cannot be overlooked is bundle size. Developer experience is important, but its importance is always weighed against the performance of the web application. A web app is no use if it's easy to build but cannot run adequately on target devices. So when considering a CSS framework, measure how much of the framework you would be depending on - and whether that justifies the bundle cost.

You stylin'

CSS frameworks are a great option for software engineers who want to focus on building and shipping. They can do the heavy lifting for you, or weight down your application - so choose wisely. Front-end developers in 2020 are fortunate to have a number of options, and resources to help decide which one to pick.

Here are some other resources if you are still deciding:

How I Migrated to JAMStack: Next.JS, Vercel, and Contentful.

Cole Turner — Sun, 26 Jul 2020 22:50:00 +0000

Migrating your React web application can be painful, but JAMStack makes that easy.

Fast and secure sites and apps delivered by pre-rendering files and serving them directly from a CDN, removing the requirement to manage or run web servers.

https://jamstack.org/

I've recently taken the plunge on JAMStack, using Next.JS, Vercel, and Contentful. Here's what you want to know if you're considering migrating your web app.

Why Next.JS?

Next.JS is an exciting framework for React. The main advantages of Next.JS include its file-system routing (for both user interface and API), automatic code splitting, data fetching, pre-rendering and server-side rendering, static exporting, the developer experience.

If you aren't already drooling over Next.JS, let me tell you why I prefer it over create-react-app, and why you will want to migrate your application.

Contentful: Flexibility without the Fuss

Contentful is a headless CMS and API that is used to manage content behind the scenes. It's a great platform for modeling user interfaces and content. Instead of building one-off admin panels to manage content, leveraging Contentful's platform and API is the perfect solution for building, previewing, and shipping quickly.

When I want to start writing a Blog post, I open Contentful and just write. The preview mode allows me to easily view my changes before publishing. And when it's ready, I hit publish - and it's live in minutes. Almost any user interface you can dream of, can be abstracted into a model which makes it easier to re-use and innovate.

Creating a React App Isn't Easy

In 2020, there are so many options for starting your application. Do you choose JavaScript or TypeScript? Reach Router or React Router v3 (no wait, v4, err v5.. v6)? Do you start with Webpack or Parcel? This is why toolkits like create-react-app are so popular, because they aim to solve the bulk of the mental guesswork.

If you are starting your own application, NextJS hits that sweet spot, where it gives you enough to start and very little reason to eject as your needs evolve.## Static Site Generation, Server-side Rendering, and Dynamic Routing
Many JAMStack frameworks includes these features out of the box. What makes NextJS nice to work with is the flexibility to easily customize any route to build statically, use server-side rendering, or enable dynamic routing.

My new cole.codes website** is using statically generated pages.** Next will generate all the pages ahead of time and serve them from multiple CDN locations. The result: pages load instantly fast, and the critical path renders without any perceivable flicker.

It does this by connecting to Contentful, which is a headless CMS. It pulls all of the blog posts to decide which pages it will need to calculate ahead-of-time. And when you do need more, Next provides APIs for using server-side rendering. This enables dynamic routing, and powers the application to render pages that have not yet been statically built. With all of that in place, I am free to write new blog posts without having to change any source code.

Deploying to Vercel

Whenever I push to my main git branch, the continuous integration process will automatically build and deploy my website to Vercel (formerly ZEIT). This process is pretty neat, and takes less than a minute for it to be live, and accessible from the public internet. Super neat!

The entire process from end-to-end took very little setup and configuration: initializing my project, connecting to Github, and deploying to a free placeholder host. I was able to share my new site with friends to get their feedback before finalizing the migration.

Multiple Deployments, Fast and Free

This is by far one of my favorite features about Vercel: multiple deployments. Whenever I push a change, it creates an instant deployment that is assigned to a disposable URL. I can review a deployment, compare side-by-side, and even revert in case of an emergency.

Publishing with Contentful and Vercel Hooks

Once everything was setup, I was able to change my nameservers and move on to publishing. An important element to any dynamic JAMStack application is incremental builds. When new content is created, the build process generates the new markup and deploys it to the web server or CDN. While Next.JS is investigating incremental static regeneration - there is a short term solution offered when using the Git integration through Vercel.

Using Deploy Hooks, I've wired my Contentful space to ping the deploy hook everytime I publish an article. While I'm able to preview a new article anytime, after publishing it is live in less than a minute! That's super convenient.

Live in less than a minute.

Conclusion

I'm a fan! The migration process was relatively painless: I moved the UI components from my old Node web app into the new NextJS app. Setting up dynamic routing and integration with Contentful was a breeze. Deploying my app to Vercel's CDN was a piece of cake.

And as an added bonus, this entire process was free. For the past few years I have been paying $5/month to rent a virtual private server. Contentful and Vercel both offer free plans for personal use. You can checkout the source code for my website here.

Next.JS + Vercel + Contentful = ❤️