DEV Community: Ken Swearengen

Dev Discussions: How to Reduce your Angular Bundle Size with Google Developers Expert Santosh Yadav

Ken Swearengen — Mon, 18 Jul 2022 11:24:40 +0000

If you ever have questions about Angular, Santosh Yadav is the person to ask.

Not only is he an Auth0 ambassador and a GitHub Star, but he’s currently certified as a Google Developers Expert for Angular.

Santosh jumped into the deep end with Angular early in his career—building apps, teaching others, and attending conferences in his spare time. That dedication to Angular worked out, as he’s now a leading MEAN stack trainer and developer, with his own popular Angular-focused YouTube channel to boot.

Santosh recently sat down with CoderPad Developer Advocate Corbin Crutchley to discuss one Angular topic that’s particularly popular these days – reducing the bundle size of angular apps.

Bundle sizes impact the performance of a website. If you have a bundle of greater than 1MB, then your user has to wait longer for the browser to:

Download that bundle
Parse the bundle
Display contents of the bundle

While this might not seem like a big deal, each MB can take an extra second, which can easily cause a user to lose interest and navigate away from the site – not exactly a good business practice.

Santosh loves using Angular to reduce bundle size and points out four ways Angular can help you do this:

Tree shaking via Angular Ivy
Lazy loading
Source map analyzers
Standalone components

Bundle reduction tip #1: Use tree shaking

A typical library will ship with hundreds of functions, but rarely will your application need to use all of them.

This presents a problem in that importing the entire library can drastically increase your bundle size.

Tree shaking is a way to only import the functions of a module your application will use.

via Aaditya Sharma on StackOverflow

Depending on the size of the library you’re utilizing, you can drastically cut down on your bundle size. As a bonus, you don’t need to do anything to do tree shaking in your Angular application – it’s been a part of Angular Ivy since Angular 8.

If you’re not familiar with it, Ivy is – at its simplest – an ultra-efficient rendering pipeline.

The steps Angular Ivy takes to render updates to the DOM. Via AngularMinds

In addition to reducing the bundle size, you’ll also get the following benefits with Ivy:

Faster testing
Better debugging
Improved CSS class and style binding
Improved type checking
Improved build errors
Improved build times, enabling AOT on by default
Improved Internationalization

Bundle reduction tip #2: Lazy loading

While tree shaking will prevent completely unused pieces of code from making it into your bundle, you’ll often have functions that are not used when a user first logs into your application but will be used later.

Lazy loading creates multiple chunks of code that are only loaded when that particular code is used in the application.

This can really reduce the size of the application, especially if you split libraries into different feature modules that are only used when needed by the application.

Example component structure with lazy loading. Via 9lessons.info

While lazy loading isn’t just limited to Angular (you can use it in React via React.lazy as well), when paired with the other bundle-reducing technology it makes Angular quite an attractive framework for creating smaller applications.

Bundle reduction tip #3: Source map analyzers

A source map analyzer is precisely what it sounds like – it analyzes the different files, components, and modules of your application to show you how big they are.

You can then use this information to see where you can improve your code base’s efficiency to reduce its size. Santosh found source map analyzers particularly useful to reduce the size of a component with a large bundle size due to a CSS issue.

Example results of a source map analysis. Via DigitalOcean.

As demonstrated in the example above, you can see which dependencies take up the most space. If they’re configured wrong, you’ll be able to tell immediately.

Alternatively, it may help you decide to migrate away to different dependencies to reduce the bundle size further.

Bundle reduction tip #4: Standalone components

One of the newest Angular features to help you reduce bundle size are standalone components:

“Standalone components, directives, and pipes aim to streamline the authoring experience by reducing the need for NgModules,” according to the Angular developer documentation.

Angular is unique in frontend frameworks because you must register your components.

Standalone components force you to have more explicit imports, which enables you to side-step the need for tree-shaking in some places because you’re just not manually including what you don’t need.

How to avoid Angular overdose

As much as Santosh loves working with Angular, he’s also a big advocate of work-life balance. He has advice for would-be workaholics and how managers can help prevent employee burnout – and you can watch him talk about those in the Twitch playback video here.

Interested in more conversations with developers about their tech stacks? Check out these other Dev Discussions:

Dev Discussions: Everything You Need to Know about Monorepos with Juri Strumpflohner of Nrwl

Ken Swearengen — Wed, 13 Jul 2022 13:29:26 +0000

As the Director of Developer Experience for Nrwl (pronounced “narwhal,” like the sea creature), Juri Strumpflohner knows a thing or two about monorepos.

Nrwl is the company behind Nx, perhaps the most popular monorepo management tool. Juri’s job is to ensure developers like you have the best possible experience using Nx.

If you’ve never heard the term monorepo, you’ll want to pay close attention to this post. Monorepos have become increasingly popular as organizations look for more efficient ways to manage and collaborate with their code bases.

At its simplest, a monorepo is a repository that contains all aspects of an organization’s code base – different projects, applications, and libraries all live together in the same repo. This is in contrast to a polyrepo, where everything lives in its own separate repository:

Via monorepo.tools

Pioneered by tech giants like Google and Meta with tools like Bazel and Buck, monorepos are seeing widespread adoption across companies of all sizes and industries.

CoderPad Developer Advocate Corbin Crutchley recently sat down with Juri to discuss what it is about monorepos that are making them so popular – and possibly heading to a code base near you.

Monorepos – more than just a single repo

While the word monorepo comes from mono-repository, the term itself can be misleading.

Yes, one of the defining features of a monorepo is that two or more applications or libraries reside within the same repository or workspace.

But that alone doesn’t make a monorepo – it makes it a messy monolithic repository that generates more problems than it solves.

A good monorepo is defined by the relationships and connections between the components of the repository.

This means that the relationships the development teams would build outside their repository – between applications, libraries, configuration files, etc. – are instead built inside a single repository. Each component has ready access to the other members within the repository.

Compare this to the more traditional polyrepo, where each application and library has its own repository. To connect, they have to pull packages from the outside using something like node package manager (npm) registries.

ℹ️ Despite the name, most companies don’t have just one repository for the entire company. Many large enterprises will have a few monorepos, each dedicated to a particular domain or department. The key is that within these monorepos, the barrier to collaboration is lower than it would be in a polyrepo.

You can now start to see some of the benefits of monorepos:

Since everything is accessible to everything else, all applications have access to the same libraries. That means you’re drastically reducing the amount of redundant code.
You only need one Continuous Integration/Continuous Delivery process, as opposed to one for every repository.
It’s easier to catch dependency errors. Since everything is integrated into the same build, the monorepo build tool will catch any downstream errors resulting from the change during compilation rather than when the dependent application or library consumes the change.

Often, companies will start building out their monorepo management process themselves. After all, it’s simple enough to throw a couple of applications and libraries into a repository and write the scripts to link them.

But scaling them can be a whole other issue. As the monorepo grows, builds take longer. Testing slows down as you wait 20, 30, or 40 minutes for the build to finish. So developers start throwing changes into every build, so they don’t have to wait for the next one, which adds more code to the build, which slows it down even more – you get the picture.

That’s where tools like Nrwl’s Nx come in.

How a monorepo management tool boosts your performance

While you could spend significant development effort creating scripts for managing your monorepo builds, it may be easier to stick with a monorepo tool like Nx or Lerna.

Nrwl, in collaboration with other major monorepo management tools, has put together a great website documenting the features of these tools. Among the more notable features that monorepo tools have to offer:

Detecting downstream changes

Many management tools will automatically detect what changes were made and any downstream dependencies on those changes.

Not only is this a much more efficient way to process your builds, but you also don’t have to worry about breaking any dependencies because you forgot to update it when you pushed your changes.

Restricting access

In many monorepo management tools, you can utilize code owner files to restrict access to different projects within your monorepo.

If you’re using a folder structure to reflect the different domains and libraries within your project, you can easily apply permissions to the various folders to control project access. These folder restrictions are usually enforced by CI/CD using a runner like GitHub actions.

Task scheduling

Perhaps the most ubiquitous feature of monorepo management tools is their ability to schedule build tasks. This allows you to control what gets built and when (i.e., sequentially, in parallel, etc.) to ensure your application and libraries are built efficiently and error-free.

Code generation

Some monorepo tools, like Nx, contain plugins and integrations that make code generation much more effortless.

You can use these plugins to create a basic app structure (like what you’d get with the npx create-react-app command) or set up testing. With these plugins, you can customize the code generation to create the code for your particular use case.

Consistent tooling

One of the most significant benefits of utilizing a monorepo management tool is that the same tools are used across all projects in the repository. So instead of balancing three different contracts and hiring a DevOps specialist for each tool, you just have to worry about paying for and managing one toolset.

You also keep redundant utilities and tools to a minimum. Since the different parts of your repo are connected, you can easily share things like types or libraries between your front and back end.

What’s next for monorepos

If you’re interested in following the development of a specific monorepo management tool, monorepo.tools is an excellent place to start. There you can find a list of seven of the most popular monorepo tools, along with the contact information for developers for each of those tools.

As for Nrwl, Juri mentioned that they recently just took over stewardship of Lerna.js, a popular open-source monorepo management tool. He hopes to have Lerna supplement a lot of Nx’s functionality.

For example, Nx helps ensure different components in your repository link together nicely and that the tool creates a great developer experience for managing your monorepos. When you combine this with Lerna’s great versioning features, you have a powerful management tool.

Interested in more conversations with developers about their tech stacks? Checkout these other Dev Discussions:

Dev Discussions: Creating Fantastic User Interfaces with Esther Agbaje of Chakra UI

Ken Swearengen — Mon, 11 Jul 2022 11:20:20 +0000

Scaling user interfaces (UI) is hard.

While a simple application can be thrown together, there’s a surprisingly deep level of complexity once you grow. You need tests to validate functionality and consistency in UI elements across all app screens. And don’t forget to consider edge cases.

When an application gets large enough, front-end teams will regularly reach for a UI component system to make development more streamlined.

However, not all off-the-shelf tools are perfect for every scenario. Many teams end up writing their own UI component system to solve these problems.

Unfortunately, building your own UI component system comes with its own set of challenges.

CoderPad Developer Advocate Corbin Crutchley recently sat down with Developer Advocate Esther Agbaje of Chakra UI, an open-source component library, to discuss the challenges of making UI design systems that can scale.

One of the most significant benefits of using component libraries is that it’s easier to build accessibility into your application than pinning it on as an afterthought.

The Importance of Accessibility in UI components

Web accessibility is not a side issue or a nice-to-have. It’s essential for our modern digital lives.

From making web pages readable for colorblind users to allowing pages to be easily translatable for readers whose first (or even second language) is not English, accessibility opens up the web experience for those traditionally excluded from it.

However, it’s not only a case of “this is the morally right thing to do” – many countries also have legal requirements for creating accessible web pages.

These requirements are often driven by the standards and specifications outlined in the Web Content Accessibility Guidelines (WCAG) established by the Web Accessibility Initiative (WAI).

While these guidelines attempt to make the accessibility process more manageable, it can be overwhelming for new developers or anyone unfamiliar with web accessibility.

Things like right-to-left (RTL) text support, color contrast, and assistive technology support are just a few of the accessibility considerations developers have to contemplate while designing their sites and applications for accessibility.

That’s where component systems like Chakra UI come in.

One of the first points that Esther brought up was the accessibility of Chakra – Chakra wants to make design systems available for everyone to use, no matter their circumstances.

It follows the Web Accessibility Initiative’s Accessible Rich Internet Applications Suite. This internet standard defines ways to make web applications more accessible for people with disabilities and across different cultures.

Meeting the specifications for this standard is not easy, as Chakra had to consider how their application would work not only on various browsers but also across various languages.

One example of this is Right-to-left (RTL) text support. Many of the world’s languages – Hebrew, Arabic, Persian, and Urdu, to name a few – are read from right to left rather than left to right, like with English and other European languages.

UI developers often need to code these different language structures into their application, but with a plugin like Chakra UI, they can automatically flip the margin based on the language type.

As Corbin has discussed previously with accessibility expert Ben Myers, an excellent accessibility experience isn’t added like ice cream on the top of apple pie – it’s baked in like the cinnamon sprinkled in the apple filling itself.

Using components that already have the accessibility standards baked into them, like Chakra’s components, not only improves the experience for users who have disabilities but also for everyone else.

Advice for maintaining project documentation

Open-source documentation can be challenging for many reasons:

Inconsistent contributions – getting people motivated to contribute, especially when you need it most during a new feature release or update, can be challenging.
Communication difficulties – you have a limited number of subject matter experts and contributors who may be working across multiple time zones and in various languages.
Inefficient processes – not having a thought-out formal process for how contributors should add to the documentation can prevent timely and regular updates.

Esther and her team at Chakra UI ran into some of these obstacles. Initially, their documentation was in the same repository as their code base, but they were having trouble getting contributors to help with the documentation – the process of cloning the repo and then pushing documentation changes was too cumbersome.

So they moved to have two separate repositories, one for the documentation and one for the Chakra UI code base. This not only helped get more people to contribute, but it also made translating the documentation into other languages a lot easier.

Some other tips for overcoming those obstacles listed above:

Use a library to generate automatic changelogs every time your code is updated. Chakra UI used Changesets.
Create a formal update and review process for your documentation. There is no one-size-fits-all approach, so you should tailor the process to what works best for your team of contributors and maintainers.
Similarly, do what you can to make it as easy as possible for contributors to update the documentation.

Design advice: Popovers vs. Modals

After discussing their documentation process, Corbin then asked Esther about a UI topic he had been thinking about recently – when do you use a popover versus a modal to notify a user within an application?

Popovers and modals are tools to display information to the user. A popover is simply a box that pops up when you click on an element on the webpage. However, a popover still allows you to scroll up and down the page while the popover is active. On the other hand, a modal freezes scrolling until you click on an action on the modal.

Esther recommends reserving modals for alert dialog where you want a user to take (or not take) a critical action or to inform them of something important before they continue scrolling.

Popovers can be used for less urgent messages where a user’s action will have minimal impact on the future state of the application.

For example, if a user wants to delete a vital piece of information from their account, such as a bank account number, this would call for a modal where a user has to confirm that they want to delete their bank account number.

Everyday use for a popover would be linking users to a website for more information – for example, linking a form to a documentation page that explains what all the fields of the form are for.

What’s next for Chakra UI?

Corbin ended the interview by asking Esther what was next for Chakra UI.

Esther mentioned that they completed their first successful hackathon and had a whole list of initiatives to make the web development experience even easier for front-end developers.

Among the things they’re working on now:

React 18 support
Improve color mode
Adding even more components, like pagination and carousels
Integration with web component API provider Zag

If you’re looking for more information on how to use Chakra UI, you can start by checking out their web page here.

Dev Discussions: Intro to the Jamstack with Salma Alam-Naylor of Netlify

Ken Swearengen — Wed, 06 Jul 2022 12:49:39 +0000

Salma-Alam Naylor can trace her love of Jamstack to her time as a music teacher.

Before she spread the joy of learning web development, she was a musical comedian and music teacher who taught kids how to play in a rock band.

She ended up falling in love with technology later in life. As someone who came to development from a non-traditional career path, she developed a special place in her heart for technologies that removed people’s barriers to developing their websites.

Now she’s a staff developer experience engineer at the Jamstack-native cloud platform Netlify, where she continues to preach the cause of web development for everyone.

For Salma, Jamstack helps open up a world of possibilities for people who want to create their own websites or get into web development.

Wait, what is Jamstack?

Most people vaguely familiar with Jamstack think it’s a set of specific technologies – notably JavaScript, APIs, and Markdown (JAM).

That’s a big misunderstanding that Salma was quick to correct: Jamstack isn’t defined by your tools. Instead, it’s an architectural decision about how website requests are processed and the responses rendered to the user.

To understand this new architecture, it helps to take a step back in time to the early days of the internet.

Back in the early 2000s, every time someone made a URL request to access a website, the request would go to a server, the server would run code to build the .html document, and then the server would send the document back to the requester.

Not only was this a long process – imagine a server in Beijing having to render a page in Cairo – but early websites relied on massive monolithic tech stacks to carry out this process.

There was no real front end/back end separation. Front-end developers were often an afterthought, forced to use the templating systems that came with the monolithic tech stacks.

Because these systems were so complex and intertwined, there was a lot of overhead with unused technology sitting idle and maintenance issues a pain to troubleshoot.

That all changed around 2010 when companies started to decouple the front end from the back end – that’s when we saw the emergence of front-end frameworks like Angular.js and Backbone.js.

As front ends started to develop their own ecosystems, another advancement in web dev technology was occurring – the creation of static site generators like Jekyll and Gatsby.js.

The premise behind static sites is simple – you use a static site generator to generate the .html page and then publish them to a Content Delivery Network (CDN).

The beautiful part about publishing them to CDNs is that the CDN comprises various distribution nodes worldwide. So the CDN distributes them to all the nodes around the world where they are cached.

When a user wants to access the website, they are directed to the nearest CDN node – and not a server halfway across the world – which drastically reduces the time it takes to serve up the page, making for a much better user experience.

That, in a nutshell, is the Jamstack architecture: Serving pre-generated assets that are bundled up at build time and then put onto a CDN which distributes them to users.

Jamstack lowers barriers for beginners

The only thing you have to worry about as a Jamstack developer is creating the static HTML file that will be published to the CDN. How you do that is up to you – you can use any Javascript framework, Ruby, or even write the HTML all by yourself.

You don’t have to worry about anything related to the DevOps of your web application. In other words, you don’t have to know anything about how to spin up and manage the server to which your application will be deployed.

That’s because Jamstack is generally managed using a serverless cloud platform like Netlify, Cloudflare, or Amazon CloudFront (to name a few).

This removes any need for you to know how to manage servers and code deployment. It also allows you to push your web pages to production quickly and roll them back to previous versions if you accidentally push an error.

Therefore Jamstack drastically lowers the barrier to entry for new web developers – it’s much easier getting a web page live than developing a page and then worrying about setting up the infrastructure it will live on.

Take the YOLO approach to get started with Jamstack

The great thing about Jamstack is its simplicity. You only really need to know HTML (Salma argues you don’t even need to know CSS) and how to connect to a hosting provider to get started.

That helps enable what Salma calls “YOLO” (You Only Live Once) publishing, which is a web dev “technique” she recommends for new web developers.

One problem with new developers – especially when they’re only exposed to more complex web development – is that they’re so overwhelmed with different ways of creating a web page that they don’t know where to start. And if they do start, they want it to be so feature-rich and perfect that they never end up pushing the page to production.

YOLO is a form of rapid iterative development where you quickly create a page and push it to production, warts and all. You then promptly learn – both by using the website and by getting feedback from others – about what went right and wrong and how to improve the latter. In the words of Confucious, “Better a diamond with a flaw than a pebble without.”

If you made a big mistake, you can roll back to the previous version, make your corrective changes, and publish the page again.

You don’t need to spend time learning the inner workings of the cloud service’s infrastructure or how they deploy your code to the CDN – they take care of all that so you can focus on creating excellent web applications.

You don’t need to spend hours learning the newest React features or use complex build tools to make a good web page. You just need to get started building something that you can quickly publish.

Once you get your first pages published and become comfortable with that process, then you can start implementing more advanced Jamstack features. The key to not getting overwhelmed here is to only focus on learning the features that are essential for you and your web apps.

It’s easy to get distracted by new features, so it will take some effort to separate yourself from the “I need to learn everything” bug that often infects new developers.

As long as your page is readable, usable, and accessible, it doesn’t matter what it looks like. Sometimes simple is better, especially if you’re learning something for the first time.

Jamstack: A force for good

Ultimately Salma’s goal for preaching about Jamstack is accessibility – she wants to live in a world where technology allows everyone to do something good.

Jamstack does this by making it easy for people to create and publish beautiful content.

If you want to get started with Jamstack, the place to begin is Jamstack.org.

Once you get through those introductory readings, you’ll probably want to:

Learn HTML if you haven’t already (unless you’re going straight to a static site generator like Next.js or Jekyll).
Create your HTML file or generate it using your static generator of choice
Select a hosting company to host your page and distribute it to a CDN
Publish your page using the hosting company’s tools.

That’s it! That’s all you need to do to publish your first Jamstack-powered page.

P.S. Are you a woman interested in, or already working with, Jamstack? Salma currently leads the Women of Jamstack group and would love for you to check it out!

Dev Discussions: Breaking into Open Source with GitHub Star Ruth Ikegah

Ken Swearengen — Thu, 23 Jun 2022 11:41:45 +0000

Did you know you don’t have to know how to code to contribute to an open source project?

Ruth Ikegah first started contributing as a technical writer – fixing typos, creating tutorials, and writing how-to guides for projects she was interested in.

She’s now an experienced Python developer who is a maintainer on a handful of open source community projects and a contributor on many more. She also has her own blog, regularly speaks at open source conferences, and advocates for increasing open source contributions from developers across Africa.

Ruth readily admits this was not an easy path for her – finding open source projects to contribute to as a beginner was a struggle. Instead of giving up, she focused on figuring out ways that beginners could contribute (like documentation), which led her to become an advocate for beginners.

This advocacy propelled her to be nominated as a GitHub Star in 2020 – a program that recognizes GitHub contributors who are particularly inspiring or great community educators.

She recently sat down with CoderPad Developer Advocate Corbin Crutchley to give some tips on how beginners can break into the open source space and balance their professional growth with mental care.

Getting started with open source contribution

Often the most common path to open source contribution is through your development skills.

For beginner developers, this could be something as simple as cloning the repo of a project you like and running the code to look for bugs. Submitting bug reports is a great way to start contributing to OS projects.

Do you think your dev skills need to level up before you’re comfortable with that? Or simply want to help out in a way better suited to your skillset?

There are several non-coding contributions that Ruth highlights to help you get started:

Improve documentation: Documentation is often the last thought of developers. It can be outdated, riddled with typos, or full of errors – or it may even just be completely absent. If you have strong writing skills, this may be for you.
Help organize conferences: If you’ve got more of an organization bent, you can help organize one of the many get-togethers that bring open source communities together. Getting speakers, doing administrative work, helping with logistics, and even giving a speech yourself are all ways to contribute to community events.
Sponsor a project: Even all-volunteer projects need money! Providing the funding to help maintain a project is another noble way to contribute to the open source community.
Lend your design skills: Those open source logos didn’t design themselves. Neither did the UIs. Designers can help make the product beautiful and usable.

You can use the GitHub Explore page to locate a project you may want to work on or an event you want to help out with.

Getting paid to contribute

Yes, there are ways to get paid for contributing to open source projects.

Ruth mentioned that for many people – parents, full-time students, etc. – the time commitment needed to work on open source projects could be a deterrent, especially if that time takes away from being able to earn money.

Open source internships hope to solve that problem.

They’re exactly what they sound like – you work on an open source project for a short period, and you’re compensated for your work in return.

Perhaps two of the most well-known are Google’s Summer of Code for developers and Season of Docs for technical writers. In these programs, open source projects apply for a grant from Google to hire an open source intern.

In return for your work with these projects, you’ll get a stipend–the exact amount will vary depending on your location and the project size, but it’s generally in the thousands of dollars.

If you’d rather be an open source bounty hunter, BountySource.com may be more up your alley.

Here open source projects will list issues that need to be solved, with a bit of monetary incentive to help motivate you:

Some bounties on BountySource.com

Even if you’re not in it for the money, contributing to open source projects can be extremely rewarding. For some, it can even be downright addictive.

Maintaining mental health for developers

Both Corbin and Ruth have struggled with burnout while working as maintainers and contributors to open source projects.

It’s easy to want to do everything and take on too much. It can feel like you’re letting the other contributors or users down if you take a break and step away to rest. You don’t want the project to fall apart, so you make sacrifices in all the wrong places.

Ruth readily admits it takes courage to step back and make time for yourself when you have that pressure to deal with.

But she does have some tips to make taking a mental health break more manageable, and it all starts with project maintainers setting the example. They have to realize that:

1) burnout can happen to anyone and actually decreases productivity, and

2) the project won’t fall apart if they take a break.

Now, this might take some planning – like delegating some of the work to some of the project contributors – but by taking a break themselves, project maintainers let the contributors know that it’s okay not to live and breathe the project every day of their lives.

The maintainers should also be aware of pending burnout in their contributors, like a drastic drop in activity. Additionally, maintainers can:

Have regular check-ins with contributors to ensure they’re getting rest and taking care of themselves.
Encourage them to take breaks and let them know that their health is more important than the project.
Discuss the possibility of burnout with them and the steps they can take to prevent it.
Make sure they don’t overload new contributors with work, as they may not yet know how to say “no” to you.
Set a formalized roadmap or list of goals for new contributors so that they can more easily pace themselves.

Ruth emphasizes that maintainers should act as mentors to project contributors.

Not only is this important for creating healthy working relationships for the sake of the project, but it allows contributors to feel more comfortable talking with the maintainers about burnout. It also helps maintainers to be able to take breaks and hand off work to contributors for their own mental health.

Nevertheless, the responsibility for turning down work isn’t only on project maintainers – contributors too need to know when they’ve reached their limits and be willing to have a conversation with the maintainers to let them know that they need time to recuperate or hand things off to other people.

Parting tip: Always be learning

It’s not uncommon for open source contributors to become maintainers themselves after gaining some experience.

But Ruth recommends continuing to educate yourself outside of your contributions to a particular project.

She’s currently taking courses in open source management to help improve her community management skills. When it comes to sources of learning, she recommends a few free or low-cost sites:

Open source project conference videos on Youtube
Linuxfoundation.org
Opensource.com
GitHub Learning Lab
The All Things Open conference

No matter where you take your courses, the important thing is that you keep improving upon your skills and growing yourself as a developer, designer, technical writer, or any other career path.

And before you know it, you’ll be maintaining your own open source project.

CoderPad too believes in continuous learning – so please enjoy these informative articles we’ve published to help keep you on top of your engineering game:

Dev Discussions: Eradicating Whiteboard Interviews with Jon Nguyen of NoWhiteBoard.org

Ken Swearengen — Tue, 21 Jun 2022 17:47:57 +0000

Raise your hand if you’ve ever had to do a whiteboard interview for a job. 🤚

Now raise your hand if you like doing whiteboard interviews.

... I’ll wait.

If you didn’t find your hand waving in the air, you’ll enjoy the insights Jon Nguyen of NoWhiteboard.org provided during his discussion with CoderPad developer advocate Corbin Crutchley.

Jon’s website is a goldmine for people fed-up with having to jump through hoops to get a job. It’s a job board for companies that don’t do whiteboard interviews and are transparent about their interview process.

Inspired by the “Hiring Without Whiteboards” repo on Github, Jon wanted a job board as candidate-friendly as possible. His goal in starting it was to help candidates who don’t have the luxury to spend months preparing for interviews or days carrying out whiteboard tests.

He also posts the salary (when possible), the recruiter’s contact information, and the needed skills, so you have all the essential information when you’re ready to apply.

What’s wrong with whiteboards?

Jon’s journey to NoWhiteboard.org stemmed from the frustrations he and many other developers encountered while looking for a new job.

First, there are the companies that put you through eight rounds of interviews – including hours-long coding tests – only to ghost you near the end. That’s a lot of wasted time and effort.

Second is the time of the actual coding/whiteboard tests. They take time, some more than others.

If you already have a full-time job or kids – or like many others, both – finding the time to take these tests can be difficult. These developers may not have time to take them at all, and you eliminate many developers from your pool. You are also biasing your candidate pool towards those who have lots of time to work on a test.

Not to mention the issue in point #1 again. How would you feel about spending your weekend on a coding test to not move on to the next round while also not getting any feedback about what they were looking for?

Third is what companies typically use them for and what they’re actually good at measuring.

Looking for a new job is already nerve-wracking enough. Spending your relaxation time on overly-long take-homes or coding in front of people you don’t know can leave you with a bad taste in your mouth – especially if they’re not measuring anything meaningful.

Companies often use these to “test” your coding skills with an algorithm question. They don’t test coding skills more than they test your ability to remember things from your university or early career that usually don’t have any bearing on the actual job. How often are developers actually coding standard algorithms in their day-to-day job?

That can be annoying for junior candidates – especially if they don’t come from a computer science background – and downright insulting to more senior developers.

If the question is something that a candidate can easily Google and find the answer to, it’s probably not a good question. It’s not a practical way to evaluate the thought process or problem-solving skills of how someone would actually work within your company.

A better way

So what are the things that interviewers should be evaluating, whether they use whiteboard interviews or not?

Corbin and Jon both agree that communicating well with others is one of the most significant measures of success for employees.

You can easily add this into a live coding interview by doing a paired-programming exercise with the candidate, asking them how they document their code or asking them what they would do if they found a bug in another developer’s code.

Additionally, you can gauge how a candidate thinks by giving them a difficult choice to make – for example if you’re a tech lead leading a team behind on feature development with a looming deadline, what do you sacrifice? Do you miss the deadline to get all the features in? Do you request your devs to work overtime to meet the deadline?

Corbin stresses again that whatever question is asked should represent an issue the developer candidate would face on the job; the question should also be clearly written with explicit requirement criteria.

Jon adds there are ways companies can show respect for a candidate, and the time they’re investing in the process:

Allow the candidate time to read the question and collect their thoughts before the timer starts, whether in a take-home test or a live interview.
Pay the candidate for completing any project or test that is part of the interview (MindsDB does this).
Create a time limit for the test so that the candidate isn’t spending their entire weekend working on the project.

Keep in mind: Good developers and engineers will often stay in their current roles because of how bad the tech interview process is these days. If you want to increase your talent pool, you need to fix any broken processes you have in your interview process.

What was your worst interview experience?

Corbin and Jon then shared their best and worst interview experiences, which should serve as a list of do’s and don’ts if you find yourself interviewing anyone anytime soon.

Corbin’s worst interview experience started well with a take-home test he enjoyed and did well on. It went downhill when he was asked an algorithm question about reversed linking. He fumbled through that as he was self-taught and didn’t take the traditional computer science degree path to become a developer.

To add insult to injury, they went deeper into theory – rather than into practical application – by asking him “tech trivia” questions like the difference between async vs. defer keywords in <script> tags. You know, the kind of questions one could easily Google.

His best interview experience was with Hilton. He did both a take-home test and a live interview coding exercise, and where Hilton shined was during the exercise. Instead of the standard “code anxiously in front of the interviewer,” Hilton turned it into a peer programming exercise where Corbin coded side-by-side with the interviewer.

The interviewer turned it into a conversation about the different ways to solve the problem and the pros and cons of each. Corbin felt that it was so informal, and he learned so much that he didn’t even realize he was being evaluated for his problem-solving skills.

Jon’s worst experience happened near the beginning of the interview process when the recruiter gave him an update on the process. Five minutes into that phone call, the recruiter started asking him “tech trivia” questions out of the blue.

What made matters worse, the questions were asked by a recruiter with no technical background, only looking for Jon to give the correct keywords. They didn’t understand much of the nuance of Jon’s answer, and he ended up stopping the phone call early and not finishing the interview process.

His best interview experience was with his most recent company. He had a take-home assignment to create a REST endpoint, and it was short enough that he didn’t feel like he had to give up his weekend to work on it.

After that, he had a live interview with a question that was built upon the work he did for the take-home assignment. That helped him feel more prepared for the interview and more interested in it. He got to talk about the tradeoffs of his solution versus others, and it felt more relevant to the job.

Wrapping up

Jon is so passionate about eliminating whiteboard interviews that he recently resigned from his job to pursue NoWhiteboard.org full-time. He has more tidbits on questions he asks as an interviewer and why he thinks side projects are an excellent way for junior developers to stand out – and you can watch him talk about those in the Twitch playback video here.

Interested in more conversations with developers about their career? Checkout these other Dev Discussions:

Dev Discussions: A Primer on Accessibility with Inclusive Design Expert Ben Myers of SomeAntics

Ken Swearengen — Wed, 15 Jun 2022 12:10:02 +0000

Have you ever been on a website where the text is gray and the background is a slightly darker shade of gray?

Or tried to read an article on your phone where you weren’t able to magnify it?

Hopefully the answer to both of those questions is a loud “No,” and the reason for that is accessibility standards.

For some people those standards – contrast specifications and magnification capabilities – are conveniences, but for many others they are a necessity for web browsing.

And for others still those standards are a cause they advocate for to make the internet a better place for everyone. Ben Myers is one of those.

He started as an engineer implementing accessible frontends with React before moving to a large tech company where he’s responsible for “ensuring that [the] developer documentation is accessible to all, regardless of disability or language.”

When he’s not working on making apps more accessible, he’s showing others how to build great user experiences that focus on accessibility in his SomeAntics Twitch stream or discussing inclusive design on Twitter. He got into content creation for accessibility because he saw a lack of practical application for the content that was out there.

In a recent conversation with CoderPad’s Corbin Crutchley, Ben gives the low-down on what it means for an application to be accessible and what you can do to make it happen.

What is accessibility?

Ben defines accessibility as the subset of usability that focuses on creating equitable experiences that include users with disabilities.

Due to the vast reach of the internet, you have to assume that a significant portion of your users have some disability – and it may not necessarily be in the traditional sense.

Ben points out that there is a whole spectrum of disabilities and how people experience them. It could be that they have vision or hearing issues, a temporary loss of physical capacities like a broken arm or leg, short term memory loss due to a head injury or cancer, a learning disability like dyslexia, a mental health disorder like depression – the list goes on and on.

Each person will experience these disabilities differently, and often people will experience more than one at a time or within their lifetime.

Some disabilities also may only reveal themselves in specific environments. For example, someone may stumble on a website that over-stimulates them, which exacerbates focus issues that impact their short-term memory. Disability and environment interact with each other.

That’s why it can be challenging to pin down the particular access needs of any given person at any given moment. If I’m visually impaired, I may be fine viewing a web page as long as I have my glasses, but if my glasses were to break or get lost, my accessibility needs would change until my glasses are repaired.

When you develop for accessibility, everyone benefits

After discussing what accessibility is, Corbin and Ben go into why people should care about accessibility.

Outside of the fact that it’s just the right thing to do, studies also show that even people without chronic disabilities benefit when you design for accessibility.

To illustrate this, he brings up the curb cut effect.

Curb cut on a residential street

Curb cuts are the ramps you see at sidewalks that lead into the road (usually into crosswalks) that were initially designed to make crossing streets less dangerous and more convenient for people in wheelchairs. They were initially implemented in Kalamazoo, Michigan, and Berkeley, California, in response to efforts from disabled World War 2 veterans and paraplegic university students.

But what researchers found was that it wasn’t just people in wheelchairs who were using the curb cuts. Parents with strollers, travelers with wheeled suitcases, bicyclists, skateboarders – even workers with wheelbarrows – were using the curb cuts.

A more modern example of the curb-cut effect is closed captions. Initially intended for deaf users, closed captioning is also used by people with temporary access needs: non-English speakers may use them to translate what’s being said, bar patrons may use them to comprehend what’s going on in a noisy environment. And lots of us just don’t want to play sound on our devices if we can help it.

Accessibility should not be a separate experience

For accessibility to work, it has to be a fundamental part of the application experience. If you tack it on as an afterthought, lots of users endup with a sub-par experience.

Overlays are a common type of these afterthoughts. They’re a type of automated application that claim to scan – and sometimes fix – your website for accessibility issues. The issue is that they 1) don’t fix the source code generating the HTML, 2) often miss important accessibility criteria, and 3) can hinder your website's performance.

Companies often buy into them because they don’t care or understand accessibility – usually, it’s just lip-service to accessibility to cover themselves from possible legal issues.

Accessibility should be baked into the product from the beginning of the design process – and there is a strong business incentive to do so.

Ben cites the Purple Pound study, which highlights the purchasing power of people with disabilities and their friends and family in the United Kingdom. They estimate that web pages inaccessible to people with disabilities lost around £17.1 million – about $22.3 million per year.

Better browsers with the accessibility tree

Corbin and Ben then dive into the modern marvel of the web browser – and just how much work browser developers have put into making the browsing experience more accessible.

Chrome and other browsers create an “accessibility tree” – it’s a representation of the website compiled primarily from the semantic markup. It’s what assistive technologies use to present an accessible experience to users.

You can access the accessibility tree in Chrome’s Dev Tools:

Accessibility tree in Dev Tools

Semantic markup is an entire discussion in and of itself. Still, Ben briefly describes it as using the tags, elements, and attributes to best reflect the intended purpose and behavior of the content. For example, using the different levels of header tags (<h1>, <h2>, etc.) to create the hierarchy of the content or using anchor tags to take you somewhere when clicked.

An example of semantic markup used in assistive technology is the <nav> tag. This tag registers a shortcut for screen readers so that visually impaired users don’t have to listen to the entirety of the contents being read to get to the section they want to get to.

Every web experience is device mediated – it’ll differ whether you’re using a screen reader, laptop browser, mobile browser, etc. The goal of the accessibility tree is to curate the content of a page to give each device – and hence each user – the best foundation for understanding the page.

Using Web Content Accessibility Guidelines (WCAG)

If you have no idea where to start implementing accessibility, Ben recommends looking at the Web Content Accessibility Guidelines (WCAG).

These are a set of guidelines developed by the World Wide Web Consortium (W3C), which sets the standards for pretty much the entire internet.

WCAG are basic industry standards and are often the legal standard in places where accessibility is mandated.

The guidelines are broken out by the general criteria that an accessible web page should have – perceivable, operable, understandable, and robust.

Under each criterion are more specific pass/fail criteria that must be met to meet the standards for the general criteria. These criteria include actual implementation steps under the “How To Meet” link and explanations about why they are essential for accessibility in the “Understanding” link.

Some of the “Understandable” criteria

Ben points out that there are three levels of accessibility that go from A (the least strict) to AAA (the most stringent). While AAA is the ideal, most companies and compliance organizations aim for AA since it reaches most people and the difficulty of being 100% compliant with the AAA level.

Ben says that he is always learning something new regarding WCAG. For example, one criterion states that a web page should be viewable in every orientation. While this may sound trivial, it helps people who use wheelchairs with mounts for their devices since they often cannot freely rotate their devices due to their disability.

More ways to be more accessible

When Ben advocates for accessibility, he talks a lot about user choice – what can you do to allow the user to tailor the experience to their needs?

Inclusive design allows users to create this optimal experience for themselves. In particular, Ben mentions the user settings of Discord as a great example of this. Discord provides a lot of visual settings that are incredibly beneficial for people with color blindness or other visual impairments.

You need to continuously test your product for accessibility. Test it across browsers, devices, and assistive technologies.

Ben talks about the saying “Nothing about us without us,” which is another way of saying that it’s essential to involve people with access needs in your user testing.

If user testing isn’t available to you for some reason, reach out to disability activists on Twitter or other social media sites. Ask them questions or read the insights they produce in their content.

If you’re interested in watching the whole accessibility discussion between Ben and Corbin, you can find it on the CoderPad Twitch channel here.

Dev Discussions: SQL vs NoSQL with James Quick of PlanetScale

Ken Swearengen — Mon, 13 Jun 2022 18:48:36 +0000

We recently shared some excellent job advice from YouTuber and Developer Advocate James Quick.

But Corbin and James’ conversation didn’t end with that – they also covered some great information about the differences between SQL and NoSQL and how to choose the proper database for your particular use case.

The difference between relational and non-relational databases

Developers have traditionally stored data in the form of a series of tables that relate to one another through a combination of primary and foreign keys – also known as relational databases. The main way we interact with relational databases is through Structured Query Language (SQL).

For example, two relational database tables might look like this:

hero_table:

name	superpower
Flash	Really fast
Storm	Controls weather

villain_table:

name	superpower
Magneto	Great with magnets
Bellatrix Lestrange	Powerful witch

A SQL statement to merge two tables would look something like this.

SELECT name, superpower FROM hero_table
UNION
SELECT name, superpower FROM villain_table;

SQL and relational databases work great when you have structured and orderly data. However, as data capturing has increased on such a massive scale – think of the terabytes of real-time data captured on users cruising the internet every day – issues with scaling and tracking data that don’t have a consistent structure have become rampant.

Enter Not Only SQL (NoSQL) and non-relational databases. Instead of using tables consisting of rows and columns to store data, a non-relational database generally uses a JSON object stored with similar objects in a collection. All relationships between collections are informal.

So rather than having a bunch of different tables that need to link to one another, you can store all the information you need in the collection of objects. So our superheroes and villains data collection might look like this:

[
    {
        "name": "Flash",
        "superpower": "really fast",
        "type": "hero"
    },
    {
        "name": "Storm",
        "superpower": "Controls weather",
        "type": "hero"
    },
    {
        "name": "Magneto",
        "superpower": "Great with magnets",
        "type": "villain"
    },
    {
        "name": "Bellatrix Lestrange",
        "superpower": "Powerful witch",
        "type": "villain"
    }
]

The actual syntax of the NoSQL queries you make to a NoSQL database will depend on the database provider. For example, if you were using MongoDB, you’d use this query to list all the objects from your “supernatural characters” collection:

db.supernatural_characters.find()

So when should you use one and not the other?

SQL vs NoSQL? It depends on the data

As we mentioned earlier, SQL is great if you have lots of structured data that won’t have too many regular schema or column changes.

An excellent example of structured data is a database that tracks baseball statistics. Generally, you’ll always have a player table with a player name, team name, homeruns, at bats etc–as well as a number of calculated averages like batting average and earned run average. You’ll also probably have a team table with the team’s name, team home runs, location, etc.

There is a risk to having data structured like this, however – if you have a set of data that regularly has empty or null values for specific fields (e.g., a calculated field like batting average for a year when a player was out on injury), then you’re unnecessarily increasing your disk space, storage costs, and data retrieval time because the database has to store and recall those empty fields.

NoSQL objects can contain whatever you want –or don’t want – them to have. For that reason, NoSQL databases can be a bit more performant than SQL databases when it comes to reading data.

You may want to use NoSQL over SQL if you need to scale your data across many machines horizontally.

Horizontal scaling allows you to spread processing power across multiple machines, increasing the speed of your CRUD operations. Because of the way relational databases are designed, it’s challenging to get them spread across multiple processing nodes.

On the flip side, NoSQL databases can fall apart if a data access pattern changes since there is no way to enforce schemas and relationships like there is with SQL databases. Without carefully managing what data gets logged and where, then it's very easy to make a mess of the data.

For example, you could have a collection that tracks user demographics like their name, location, and age.

After three years the product pivots to track health data for users and stops tracking demographic data, so now the product is collecting height, weight, and birth date in the same user collection.

A month after that the product owner decides they want the birthday collected as a UTC string instead of a normal date string.

Now you have not only a collection with two different schemas (demographics and health info), but you have a field (birthday) that has two different data types. This can cause lots of processing issues and is one of the reasons you may want to have the schema-enforcement that SQL provides.

The Power of Object-Relational Mapping (ORM)

James dove into object-relational mapping (ORM) towards the end of the database discussion.

If you’re unfamiliar with ORM, it’s a way for developers to interact with both relational and non-relational databases that doesn’t involve generating complex SQL statements – or any SQL at all.

ORMs are an abstraction layer that sits above a database and takes human-readable function calls and translates them into SQL or NoSQL. This is a considerable advantage to developers as it reduces errors from having to write complex queries and the same function definitions can be used to manage multiple different databases.

Here’s what it would look like to insert a row into a relational database with Prisma, an ORM for JavaScript:

2  await prisma.user.create({
3    data: {
4      name: 'Alice',
5      email: 'alice@prisma.io',
6      posts: {
7        create: { title: 'Hello World' },
8      },
9      profile: {
10        create: { bio: 'I like turtles' },
11      },
12    },
13  })

You can find an ORM for just about every language; Hibernate is a popular one for Java, and Django ORM is often used with Python.

Serverless computing, horizontal scaling SQL with PlanetScale

James discusses more or his database knowledge with Corbin along with a brief introduction to serverless computing.

You can find those conversations in the Twitch replay video here.

Dev Discussions: How To Get a Great Job at a Great Company with James Quick of PlanetScale

Ken Swearengen — Wed, 08 Jun 2022 18:11:53 +0000

It’s not often you’re glad you got rejected from a job.

But for James Quick, it turned out to be a pretty good thing. He had interviewed for a software engineering role at Microsoft, where he didn’t quite make the cut. Still, the interviewers saw enough skill in him to suggest he interview for a “technology evangelist” role with them. He landed it.

There James was able to gain some valuable public speaking experience – and more importantly, he learned how much he liked talking with others about technology.

James left Microsoft for a stint as a developer with FedEx, but his calling was clear – he missed the conferences and content creation he was doing as an advocate. He started creating videos on YouTube and speaking at conferences again and then got back into tech advocacy, first with Auth0 and more recently with PlanetScale.

When he’s not promoting PlanetScale, you can often find him creating content for his 100K+ subscriber YouTube channel and advising others on how to find a great job in technology.

James discusses some of these job hacks in a recent conversation with CoderPad Developer Advocate Corbin Crutchley.

Great Job Hack #1: Create Content

James believes that his content helped him to get the jobs he’s had – and considers it a great way for anyone who wants to get into the tech industry. Even if you’re not super technical or don’t want to get into a super-technical role like engineering, content is a way to share your learning journey with others and prove your knowledge.

So how do you get started creating content?

Just write or record! Find a topic that interests you and blog or talk about it. Too often, beginner content creators want their first piece of content to be perfect – so they never end up getting anything published. It may sound scary, but the only way you’re going to become a better content creator is to start creating so you can get the feedback you need to improve your work.

For example, when James wanted to get into blogging, he made it a goal to publish one post per week. It wasn’t pretty at first, but he got feedback every week and got better.

He uses feedback to continually refine his methods with other content mediums as well. With YouTube, he admits that he doesn’t create the prettiest videos, but he’s consistent and speaks on topics that people care about.

James has found diminishing returns when it comes to polishing his YouTube videos. After a certain level of editing, the views don’t increase enough to warrant the time spent on editing the video further.

He also recently started creating content on TikTok. He uses Tiktok to be less formal and more “himself” compared to the tutorial content he creates. But while this content is less formal than his YouTube courses, they still allow him to position himself as a subject matter expert, making him a more valuable employee.

Creating content is a great way to get noticed by hiring managers and recruiters. If your content is relevant to their business or open roles, you may be one of the first people they reach out to.

And let’s not forget that those same hiring managers and recruiters often will also Google your name before an interview to check your online presence.

Good companies should like that you are active in online communities. If they have a problem with it, they probably are not a place you want to work.

Great Job Hack #2: Maintain work-life balance

If you’ve worked in software for the past two years or plan on doing so in the near future, there’s a good chance you’ll be doing it from the comfort of your home.

While working from home can promote flexibility and productivity, it isn’t without its downsides, one of which is that it becomes harder to separate work life from home life. While the hustle-and-grind culture may bring you short-term gains in your career, it can also quickly lead to burnout and bad health.

For that reason, James is a big proponent of work-life balance; he promptly ends his day at 5 pm to focus on his family and hobbies outside of work. When requests come in after 5 pm, he holds them until the next day to make self-care a priority.

Corbin added that he was doing double overtime without pay when he first started working in tech because he thought that was what one did to become a successful developer. But promotions were also harder to come by because everyone was working 80 hour weeks. Nobody thought to question the psychological toll this was having on the workforce.

If finding balance is difficult for you and you’re starting to suffer because of it, James offers two pieces of advice:

1. Set up boundaries: If you want people to respect your boundaries, you have to set them up and enforce them.

2. Look for companies that prioritize work-life balance: This is something you’ll want to ask about during the interview process. Corbin adds that while job hunting can often be anxiety-inducing for people who may desperately need a job, it’s essential to remember that interviewing is a two-way street.

Great Job Hack #3: Be confident in your skills

The job advice discussion then moved on to something that many new – and even veteran – developers deal with when looking for a new job: confidence in their skills and talent.

There’s a reason the term “imposter syndrome” is thrown around so much these days. Most of us have struggled with the feeling that we weren’t good enough at some point in our careers.

But there’s a difference between acknowledging your weak points and deprecating all the hard work and experience that got you to where you are today.

Companies will hire someone who admits they don’t know something but are willing to learn – they’re a lot less likely to hire someone who isn’t confident in themselves and what they do and do not know.

James teaches coding classes with LaunchCode and regularly advises his students to acknowledge the skills and talents that they bring to a job. It takes a lot of hard work and dedication to get into software development, and you should be proud of that no matter what path you’re taking to get there.

Another way you can improve your confidence in your skills is to teach someone what you just learned. Not only do you reinforce what you’ve learned, but James often finds that the best teachers are those who just learned a topic, as they know what it’s like to be a fresh learner and can more easily help people who struggle to grasp what’s being taught.

Before You Go: Databases and Serverless Computing

James and Corbin didn’t limit their discussion to just job advice – they also dove deep into the differences between SQL and NoSQL and touched on the benefits of serverless computing. You can find more on that in the full Twitch stream here.

Dev Discussions: Getting a job in Fortune 500 Companies with Brad Garropy

Ken Swearengen — Mon, 06 Jun 2022 13:00:13 +0000

Brad Garropy didn’t start his career thinking he’d work for some of the biggest names in technology.

He didn’t even develop a taste for coding until he got to the University of Texas and took two classes on programming while earning his degree in electrical engineering. As a teenager, he was more interested in using computers for cruising the internet than writing software applications.

Once out of college, he knew he wanted to get into coding, and luckily his university had a recruitment pipeline with Dell that allowed him to land a job there writing firmware in C. But it wasn’t long before he was itching to work his way “up the language stack.”

That’s when he started to pursue web development by teaching himself the fundamentals of the front-end. Once he built up his portfolio, he started applying for web dev jobs and eventually landed a role with Adobe, where he worked on their Magento e-commerce platform.

After his stint at Adobe, he now finds himself as a web platform engineer for Trello, owned by the software giant Atlassian.

Quite a path for someone who started writing firmware in C and now uses React to grow one of the world’s most famous project management applications.

So how did he do it?

Tip #1: Take advantage of university or bootcamp partnerships

If you go to a school that has a recruitment partnership with a company that even vaguely interests you, then jump on it!

Brad said that the process for getting the job was pretty straightforward, and a lot of that has to do with the fact that it’s an established company with an established recruitment program with the university.

It may not necessarily be something you want to do long-term, but it’s an excellent way to get some experience. Brad was able to get some programming experience – even if it was in C – and it helped motivate him to learn more about more advanced programming languages.

It’s worth noting that even if you don’t go through the university path to become a developer or engineer there are similar options available. A lot of coding bootcamps also partner with companies to funnel students into software careers.

And if neither one of those options work for you – if you’re self-taught, for example – following tip #2 will help push you to the front of the pack when it comes to getting an interview.

Tip #2: Show initiative with independent projects

When Brad was teaching himself web development, he started creating and maintaining open source libraries to have a portfolio of projects to show to prospective employers.

While that number is now hovering around 20-30 open source projects he’s working on, he credits his initial portfolio with helping him get his job at Adobe. Portfolios can make a big difference for people who are coming to a role from a non-traditional background – like in Brad’s case where he was self-taught and switching from firmware to web development.

But he didn’t just throw everything on GitHub and then through the link to every interviewer.

He wanted to prove he could do web development. So first, he made his own website. Then he started creating open source projects to solve problems he was running into. As he began developing these solutions or discovered these problems, he would blog about them.

So not only did Adobe and other interviewers get to see what he was capable of technically, but they also got an insight into how he thinks and his communication skills.

“It’s great for show-and-tell,” as he puts it.

Tip #3: Know the role

When asked about how the interview process went with Dell, Adobe, and Atlassian, Brad commented that it was a little different for each one.

While he calls his job with Adobe a “stroke of luck,” he mentioned a couple of things he did to make himself the ideal candidate. Keep in mind that this role was for a brand new team working with newer tech.

As an external candidate, he could bring a new perspective to the project.
He regularly read up on new technologies to show that he grasped the tools available to the team.
A lot of his interview was conducted by backend engineers who were less familiar with front-end tech, so he could position himself as a knowledgeable resource on front-end matters – even though he was wholly self-taught and new to the job field.

His next job search would take him through 60 applications and 20 interviews, so by the time he wound up interviewing with Atlassian, he had a good idea of what interviewers were looking for. But just as importantly, after over a decade in tech, he knew what kinds of questions the interviewers should be asking.

So when he was asked about algorithms as a senior developer, he pushed back – these weren’t relevant questions to the position. He focused on the role’s needs and positioned himself as someone who could fill those needs.

Brad readily admitted to using Github Copilot during some of the algorithm questions – and he didn’t feel bad about it. Copilot allowed him to focus on the higher-level business tasks that his role would generally be working on rather than something that a simple AI can solve.

Some advice for content creators

Of course, Brad didn’t just stick to talking about his career path.

He and CoderPad Developer Advocate Corbin Crutchley also went deep into content creation and how to get started talking about the problems you’re solving. If you are interested in creating a podcast, blog, or Youtube/Twitch channel, you’ll want to watch the entire live stream right here.

Dev Discussions: James Perkins of RollYourTweet on How to Create a Successful SaaS

Ken Swearengen — Tue, 31 May 2022 19:31:02 +0000

Developer advocate and software engineer James Perkins of RollYourTweet.com has some sage advice for anyone looking to create the next big app:

”Your users don’t care about your tech stack.”

In a recent discussion with CoderPad’s Corbin Crutchley, James talks about his experience with creating a SaaS application and the lessons he learned from creating RollYourTweet.

He doesn’t mince words – the people who think your tech stack is cool probably are not going to be the people who are going to use it. More importantly, they’re not going to be the ones paying for it. The only reason users care about the technology you use is that it improves the product and their experience.

James – who regularly works with content creators as a Developer Advocate with Tina.io – added that “the content teams don’t care about tech, they just care if it solves their problems.”

Feedback before optimization

The conversation then delved into the time and place for optimization – and both Corbin and James agreed there were higher priorities for getting an app off the ground than optimization.

"Does the code work? Do we need to spend the time to optimize it now, or can it wait? It’s more important to get it in front of the users for feedback."

Additionally, code can be too optimized and over-engineered. Frequently this kind of code can be complex, leading to readability issues.

This may not be an issue if you’re the only one working on the application. Still, if you ever plan to scale your application and bring in more developers to your team, it can quickly become a maintenance issue nightmare. Consider what would happen if you were hit by a bus (aka the bus factor) – would your teammates be able to maintain the code without you?

The “bus problem” is also an issue in Open Source Software Security, which we explore in this blog post.

That’s why James reiterated that a successful application focuses more on rapid iterative development than optimization.

You can’t please everyone

Corbin then asked James how he deals with both growing his product and the increased criticism that comes with that growth.

James's answer? “Thick skin.”

James started his career in tech support, so he is no stranger to being yelled at by angry customers for ridiculous reasons.

He mentions that there are two types of angry people who call customer support:

The people who are upset at the moment that something isn’t working. These folks usually calm down with time and reasonable effort to fix their issue.
People who are chronically unhappy and will never like the product.

The former may be able to give you valuable feedback on the product (once they calm down). The latter are probably not worth your time.

SaaS success is 90% marketing and 10% code

While negative feedback can be helpful, James makes it a point to encourage his users to provide positive feedback – and he uses that process for marketing the product.

He has a “public roadmap” where users can suggest improvements to the product and then see as those suggestions are implemented. Not only does it show them what’s being worked on, but they also become involved in the development process, which makes them more invested in the product.

James will be the first one to tell you that marketing is hard, so one of his go-to strategies is “self-marketing” by just publicly answering questions about the product or just discussing a challenge he had to overcome.

For example, James recently took some feedback that he had received on Roll Your Tweet and turned it into a Twitter thread:

A note on analytics

Even though James doesn’t put a ton on emphasis on your tech stack, he still recommends using an analytics tool to inform your marketing efforts. Analytics will help understand how your users are using your website or application, and those insights should help you figure out how to convert people to take the action you want them to take.

James recommends using a couple open-source or privacy-focused options like Plausible and Fathom, but he encourages using them in a very particular way.

First, be your own user tester. Run through the pages as if you were the customer you want, and watch what’s happening in your analytics dashboard.

Once you get that initial understanding of how the analytics work with your use case, move on to the “Mum test” (or “Mom test” if you’re from the west side of the Atlantic Ocean): Show your mom or any other friend or family member your website or application. Would they know what to do with it?

Again, look at your analytics dashboard as they’re going through your service. Where are they pausing? Where are they clicking? Are they using the back button a lot? Are they drawn to a particular feature?

Answering these questions can help you figure out what to fix and where to focus your marketing efforts.

Wrapping up

SaaS creation was just one of many topics that James and Corbin discussed – other hot topics included James’ work with content management systems (CMS), including his time at Tina.io, and a brief discussion on JAMStack and the JSX/Markdown hybrid known as MDX. The entire Twitch stream is worth watching, and you can find it here.

Interested in more developer stories? Check out these three from our coworkers over at CodinGame in celebration of Women’s History Month:

Dev Discussions: Ryan Carniato of SolidJS on Building “The Tesla of JavaScript UI Frameworks”

Ken Swearengen — Tue, 31 May 2022 19:15:57 +0000

CoderPad’s Corbin Crutchley recently sat down with Ryan Carniato to discuss his work on the hyper-performant UI library, SolidJS – which Ryan dubs “The Tesla of Javascript UI Frameworks” for its efficiency and performance.

It’s not often you come across a programmer who used to be a touring musician – but Ryan has experience both slinging code with SolidJS as well as some sweet tunes with his band Mr. Solid (both named after a tasty Canadian treat).

Ryan has been coding since he was 10 years old and started his software engineering career working .NET. It was during these professional years that Ryan discovered Knockout.js and his passion for creating reactive user interfaces; he’s been working in the JavaScript space “solidly” for the past decade. He learned JavaScript by “going to other websites and viewing the source code,” a method that’s become more challenging with the advent of minifiers and obfuscated code.

What is SolidJS and what is it used for?

Boiled down to it’s essence, Ryan calls Solid a “state library” that has slightly different primitives than React. Ryan built Solid to have “[blazing-fast performance, declarative nature, feature set, and a] small bundle size,” all while supporting most major features in React.

Solid is heavily influenced by Knockout.js, which came out around 2010 and was made for creating declarative UIs; it has often been compared to React Components. Both React and Knockout have been strong inspirations for SolidJS – down to Knockout’s tutorials that let you run the code in the browser.

> Interested in learning more about the history of front end web components? Check out our blog post on Web Components 101: History

Solid’s reactivity is based on the concept of a “signal” – per Solid’s documentation, “Signals are the most basic reactive primitive. They track a single value (which can be any JavaScript object) that changes over time.”

The signals are associated with a set of subscribed listeners; when the tracked value changes the signal notifies the listeners and they carry out their respective processing actions. This is a lightweight way to improve reactivity and performance in Solid.

Here’s an example of a “Hello World” in SolidJS:

function HelloWorld(props) {
  const [first, setFirst] = createSignal("JSON");
  const [last, setLast] = createSignal("Bourne");

  createEffect(() => console.log(`${first()} ${last()}`));
  return <div>Hello {props.name}</div>;
}

<HelloWorld name="Solid" />;

Front end frameworks may be a dime-a-dozen, but Solid lives up to it’s jet-speed reputation:

SolidJS process speeds compared to competitors

SolidJS is also smaller than a lot of its competition. In an implementation of the RealWorld Demo SolidJS was able to bundle to just 11.1kb – about 8% the size of the same implementation using Angular.

According to Ryan, it’s also fully featured and “supports most React features like Fragments, Portals, Context, Suspense, Error Boundaries, Lazy Components, Async and Concurrent Rendering, Implicit Event Delegation, SSR and Hydration(although there is no Next.js equivalent yet). It supports a few things not yet in React like Suspense for Async Data Loading, and Streaming SSR with Suspense.”

Differences between SolidJS and React

SolidJS can be thought of as a faster and lighter-weight version of React. They both are declarative and support JSX, but Solid cuts out a lot of overhead processes that allow it to render much faster than React.

Bye Bye Virtual DOM

You read that right – instead of updating a virtual DOM like React, SolidJS updates the DOM itself. Ryan designed this to increase the speed of rendering as there is now less overhead pushing changes from the virtual DOM to the real DOM.

You can find more on how Solid does this and more differences between SolidJS and React here.

Web Components Not Included

While Solid is a great fit to integrate into web components, it actually does not use web components “under-the-hood” to generate component instances. Ryan’s reasoning is that while there are certainly uses for web components, they come with performance trade-offs. He found that for Solid he wanted the lightest possible abstraction for a component, which is simply a function that runs once.

If you’re interested in learning more about the pros and cons of different web component frameworks, check out this article from CoderPad Developer Advocate Corbin Crutchley here.

More Differences With React

Because of Solid’s ability to utilize functions as the reactivity system, you don’t need to rely on dependency arrays like you do with React’s hooks. That means stale closures are dramatically reduced in the Solid ecosystem.

What’s more, because Solid has a non-JSX method for declaring UI elements, you don’t need to have a compiler in order to use SolidJS. Even when using JSX + Babel, you only ever compile the Babel instructions to vanilla JavaScript instructions to create HTML nodes – no React.createElement here!

For example, our HelloWorld might look like this before being transformed with Solid’s JSX transform:

import { render } from "solid-js/web";

function HelloWorld(props) {
  return <div>Hello {props.name}</div>;
}

render(() => <HelloWorld />, document.getElementById("app"));

And after the transform, looks like this:

import { template, render, createComponent, insert } from 'solid-js/web';

const _tmpl$ = template(`<div>Hello </div>`, 2);

function HelloWorld(props) {
  return (() => {
    const _el$ = _tmpl$.cloneNode(true);
        _el$.firstChild;

    insert(_el$, () => props.name, null);
    return _el$;
  })();
}
render(() => createComponent(HelloWorld, {}), document.getElementById("app"));

Notice how it’s using all vanilla JavaScript APIs like cloneNode and firstChild.

Hackers Wanted

Want to earn some cash and learn more about Solid? They’re hosting a Solid-based hackathon where winners can end up with a few thousand dollars in their pockets to help improve the SolidJS ecosystem. Anybody of any skill level can enter and you don’t have to give up your weekend to participate – entries aren’t due until April 7th.

To find out more about the hackathon, check out the info page here.

Wrapping Up

Ryan has a very unique and substantial development background which is why it's no surprise that Solid definitely hits its mark in being an extremely fast and lightweight frontend library. If you’re interested in watching the whole discussion between Ryan and Corbin you can find it on the CoderPad Twitch channel here.

Happy Coding!