How'd we get here?

In the 2019 not-so-official state of Javascript report, I heard the undertones of anguish and grumbling towards the javascript ecosystem, but whats new right? People have been complaining about Javascript since its three week incubation and subsequent birth. For good reason.

Example, executing random type additions:

> "" + {}
> "[object Object]"
> {} + ""
> 0

But…somehow, through all the pain and chaos, we have come together as a community and have made this language somewhat bearable to work with.

In 2012, Typescript was born and all of a sudden you could add Types!.to!.Javascript! as ForSortaRealNow.

In 2015 there were whispers of something called the webpack and react and all you had to was provide a small sacrificial offering, followed by installing the universe of npm modules to use them. Only then, would you be on your merry way.

In 2016, 2017, 2018, and 2019 if you updated a package and something broke, there was usually at least one GitHub issue that would say something nonchalantly like “Breaking change, no take backs”, and then go on to explain why you would be spending the next three days upgrading all your dependencies and refactoring your whole application. By the way, if this was you, I personally want to say “You’re a hero”.

Jokes aside, 2015-present has really been a journey of intense growing pain, but I personally believe we are on the brink of a new era of Javasc–cough Typescript. Yarn V2 just came out, and I am seriously more pumped about the ecosystem than ever. I would put this change on the same level of importance as the move to ECMAScript 6. Yep I said it. Let me explain why.

Yarn V2

Workspaces

Workspaces were a concept in V1 of Yarn, they should be thought of like a module. You .NET devs can think of them like a project within a solution. They are a good solution for a monorepo, but in V1, a lot was left up to the developer to get all their dev tools (Typescript, Webpack, and VS Code, etc) all on the same page as to what was going on with those workspaces. I remember it took a week or two for me to just get file resolution sorted out between all of that, and I know for fact, that setup was custom…and not quite right. 🙂

After you have gone through the migration to yarn berry, you can set up a more realistic and safe monorepo without worrying (too much) about how those workspaces are going to get resolved. Workspace resolution is treated as a class one citizen now. It even has its own protocol.

Assume the following directory structure

root
 - packages
     - web
         - src
             - data
             - components
     - api
     - shared

To reference another workspace from the web workspace, use the workspace protocol . Example:

root/packages/web/package.json

"@repo/shared": "workspace:packages/shared"

example use:

import SomeSharedThing from "@repo/shared/SomeSharedThing"

Okay, but why was this a problem in V1 and why does it work better now?

Plug’n’Play, Plugins, and File/Module Resolution

The Problem: Resolvers.

Here is an excerpt from the yarn docs linked above that explains it well:

“Over the years that led to Plug’n’Play being designed and adopted as the main install strategy, various projects came up with their own implementation of the Node Resolution Algorithm - usually to circumvent shortcomings of the require.resolve API. Such projects can be Webpack (enhanced-resolve), Babel (resolve), Jest (jest-resolve), Metro (metro-resolver), …”

This means that if you wanted to combine and use different technologies that use different file/module resolving strategies, you would likely be dealing with configurations to make sure files are being resolved correctly.

But no more. No more tweaking aliases in configs. No more help from random third party resolvers, etc. No more.

The Solution: Plug,'n’Play(pnp.js)

Yarn V2 solves the file resolution issue through the use of the pnp.js file and their plugin strategy.

• They introduced the concept of the pnp.js file (If you have ever used webpack stats, it is similar to that). Basically it’s a file that declares explicitly what dependencies/workspaces depend on and where those packages are all the way down the dependency tree. It then during runtime(think webpacking) can intercept calls to modules, and provide a virtual link to where yarn is keeping those modules now which by default are zipped within its cache folder. For developer tools like eslint, typescript and vs-code they wrote a pnpify module that basically fakes the existence of the node_modules folder for the same purpose. This is temporary until those tools can support pnp out of the box.
• Yarn V2 is built primarily using a plugin strategy. Things like commands are even plugins(e.g yarn add). Along with commands, they have also built plugins to wrap how files get resolved from different mainstream file resolvers.

Together with the pnp.js file, and plugins, they can look to see what module resolution a package depends on (via the dependency tree) and then tell Node exactly where to find that module/package.

Zero Installs

Yarn berry has some great documentation around this topic. Zero installs is not a feature specific to yarn berry, but it is by far more possible because of it. Since, node_modules are no longer a thing, and instead the yarn cache is maintained through compressed .zip files, It is much more feasible to commit these to your repository. Zero installs is configured purely through .gitignore. You can choose to do so or not. Read more about it here.

I have decided to jump aboard, and have not regretted it one bit. It improves workflow all over the place, specifically around switching branches during the PR process and the build process itself.

Constraints

Yarn 2 has the option to provide constraints. Constraints are rules about your dependencies. Yarn has defined a few of their own constraints, but you can also create your own.

The yarn maintainers are using a programming language called Prolog to create these constraints. Prolog is a fact based engine. Think of it as a database of facts that we can query against and determine if something is true or not.

From what I understand…upon running yarn constraints yarn berry generates a database of facts using the projects workspaces, and dependencyTypes(dependencies, devDependencies, etc) and in plain english those sound something like

“fact: the workspace someWorkspaceName depends on Lodash version 4.4.2 in devDependencies” -yarn docs.

Then it gobbles that list of DB facts, the predefined rules yarn has provided, and the source file the end user provides for custom constraints(constraints.pro by default). After that it loops over a list of query results provided by tauProlog’s(JS wrapper around prolog) query method and generates an array of enforced Dependencies.

Now constraints like Uncle Bobs dependency rule are much more possible and more importantly, enforceable.

This rule says that: “source code dependencies can only point inwards. Nothing in an inner circle can know anything at all about something in an outer circle. In particular, the name of something declared in an outer circle must not be mentioned by the code in the an inner circle. That includes, functions, classes. variables, or any other named software entity.” - Uncle Bob

Constraints are still in newborn status, but I plan on using them.

To wrap up. I have a lot of hope for Yarn v2. The lead maintainer @arcanis is someone I have come to respect, and is someone who not only sees the issues of the JS ecosystem, but has solved those problems. IMO, Yarn V2 is the future of the JS/TS ecosystem. At least until Deno takes over.

I think it’s reasonably safe to say that when I first started at DeveloperTown in 2014 I was not expecting the following two things to become a reality: that I’d last in a software development consulting firm with no software development knowledge and that I’d eventually write a blog post about leadership in the midst of a global pandemic.

Both are true at the moment. I’ve come quite a ways from being clueless about what an API was or in the dark about things such as pull requests. (Quite naturally, as a 16 year old boy stuck in a now 33 year old’s body, I assumed a PR had to do with a rather gaseous bodily function and my index finger.)

But here we are. Slightly more knowledgeable about software and spending most of my time indoors as our brave medical men and women, delivery drivers, teachers, grocery store clerks, and city employees are on the front lines. It’s a scary time. A time where I often wonder what should we be doing? Who is going to stand up and lead? How should they be doing it? And what about us that are not guaranteed a future? What about our jobs? How are we going to make it?

These questions are undoubtedly floating through your head and the head of your bosses, coworkers, and employees.

And if you find yourself in a place of leadership, now is the time to answer those questions.

One of the many reasons I’ve stuck around at DeveloperTown is the fact that we have strong leaders. Leaders who are trying to answer those questions. Leaders who I trust will do the right thing, not only for the business but for their employees as well.

But what does the right thing look like now? I have a few suggestions that come straight from the DT leadership playbook.

1. As a leader, it’s more important than ever to communicate with honesty and empathy. People are going to create their own narratives if they don’t hear one from you. They may even create one if you share the truth over and over. But they deserve to know where the business stands and where you see it going. If you don’t know, that's okay too. Tell them what you do know. No sugar coating, no false hope, no unneeded dread.
2. The best way to reduce anxiety is to start thinking about what your organization can do for others. How are your clients feeling at this time? Serve them with grace and care. Demonstrate this to your team. Vocalize it over and over. There’s never been a better time to revisit your mission statement and remind yourself and your team that now is the time to serve others. It’s really hard to worry about yourself while you’re helping someone else.
3. Samuel Johnson was quoted as saying, “People need to be reminded more than they need to be instructed.” I happen to agree with him. Set up recurring touchpoints with your team to celebrate their wins and check in. Be available. A great example of this would be a now weekly virtual coffee social via Google Hangouts at DeveloperTown. An employee put it together and it’s been a highlight of this time in quarantine. It’s a weekly reminder that we’re in this together...and that some of us have very fun coffee mugs.

Leadership in the time of COVID-19 doesn’t have to mean a monumental, solo effort for only those at the top. But for those who find themselves in or identify with a leadership role, now is the time to communicate, serve others, and regularly remind our teams that we’re in this together.

When things get tough, it’s up to good people to stand up and do our part. Luckily, that means all of us get to help.

Even those of us who start blog posts with a fart joke.

With the unemployment rate hovering below 4% nationally, companies all over are fighting to snag the best candidates on the market. To win the talent war, you've got to get creative on how you attract the talent your business needs to grow and succeed. But how can recruiters and talent management folk do just that? Well have no fear. We’re going to cover a few different tactics you need to be using to make the recruiting process as efficient and painless as possible.

First, let’s talk communication. This sounds like a no-brainer but thorough communication and follow through can be your competitive advantage against your fellow recruiting peers. I can’t tell you how many times a candidate tells me about a bad experience they’ve had with a recruiter, and usually it's always focused around poor communication. From first look to first day, it’s imperative to set expectations as to how and when communication will occur. Sometimes, even text check-ins are sufficient, but whatever you and your candidate agree to, don’t let them fall into the forbidden resume black hole. Even if you simply check in to say that you don’t have an update, that will go a lot further than radio silence. It’s important to have empathy for your candidate, as you certainly wouldn’t want to be forgotten about.

Next, let’s discuss candidate applications. Majority of candidates are applying to jobs from their mobile devices. Have you taken the time to test your company’s career page and apply to an open role via mobile? How long does the process take? Are there tons of questions/forms needing to be filled out? If the mobile application process takes over two minutes, it’s time for a change. Once you’ve simplified the mobile application process, look at the job description you or the hiring manager has written. Essentially, candidates want to know three main items: an overview of the company (culture), an idea as to how they’ll impact the business and the expertise needed for the role. Provide four to five bullets per section, no more is needed. Ideally, you are trying to cast a wider net, and if you have an abundance of “requirements” even some of the most qualified applicants may not feel they’re qualified for the role, thus won’t apply at all.

Last, be ready to battle the dreaded counteroffer. Companies know how hard it is to find talent, and subsequently they don’t want to lose that talent. Educate your candidates on why accepting a counteroffer is never a good idea. I read a few years ago a study which said 80-90% of candidates who accept a counter offer from their employer end up leaving within the following twelve months. Currently, I’ve found money is not the most pressing factor for candidates to want to leave their organization. Career growth/opportunity and feeling of purpose are on the top of the list. Remind your candidates as to their motivating factors for wanting to leave, and why you started the conversation with them in the first place. Being their sounding board builds trust in the recruiting process, and proves you are truly their advocate.

Winning the talent war doesn’t have to be a monumental task. With the right mindset and preparation, your organization can win the battle and set yourselves up for long term recruiting success.

Hiring an Expert

On our blog, we’ve talked about several aspects of what to look for when looking for delivery partners, and today we’re going to take some time to dig into what it means to “Hire an Expert”, and how to identify one. This is a critical skill that really needs to be sharpened if you’re going to be working with someone to facilitate and accelerate your projects. We’re going to look at why you should or shouldn’t hire an expert, and what makes an expert, well... an expert!

We Need Help (Resources)

You’ve decided that you need help with your project and that’s a huge step. The next phase is when it gets challenging. You have to find out WHO can help you. Do you need more resources to do more work or do you have bigger decisions to make? If you just need resources, you’re probably not looking for an expert. Don’t get me wrong, you may need very Sr-level resources with huge skill sets, but you’re looking for delivery and that means you’ll want to screen contractors or use a trusted partner to supply you with proven resources to get the job done.

We Need More Than Just More Resources (An Expert)

When more input is needed to your process than just solid delivery resources, you’re probably going to need an expert… at something. The What and When and Why of that decision is a topic for another post, right now we’re going to dive into what you’re looking for in an expert.

An Expert Is...

An expert is a thought leader, which means that they are well-equipped to engage in your process at levels broader than the nuts and bolts of delivery and can contribute meaningfully across a broad range of team activities. They also have three key characteristics that can make or break an effort:

1. Experts can communicate with the team

   We specifically chose the word “communicate” instead of “talk” or “engage” because communication implies that the concepts that they are conveying are understood more or less intact by the team at all levels, so that aligning everyone happens naturally through the course of regular communication.

   Some teams are resistant to outside input, we’ve seen some pretty hairy conversations develop around hot project topics, but part of communication is wading into the mess and working to sort it out.

2. Experts have opinions and rational, defensible reasons for them.

   An expert will present a cohesive vision for how delivery looks in their ideal world, be able to tell you why this is a good option for your business, and be able to answer the “Why” behind their vision.

   We’ve been in many situations in software development where someone has presented a path forward to me and given me options for two to three different implementation stacks, along with a nice list of pros and cons for each. That’s great, it really is, but doing research and pro/con lists for a tech stack is something we would expect one of our delivery people to be able to do.

3. Experts will know (and tell you) when you don’t need them

   Sometimes the expertise doesn’t match the need or is at the wrong point in the process, or… whatever else. For some reason things just aren’t matched up right. An expert will come to you with these concerns and let you know when the fit isn’t right. In many cases they may even be able to recommend someone in their network who could be a better fit.

   This can be a hard pill to swallow on both sides, but it’s a matter of knowing where personal limits are and understanding that not everything can work out every time. When a mismatched relationship is forced, the stress eventually fractures the relationship, and oftentimes leaves the project in an uncertain state of success or failure. An expert will do everything they can to prevent that.

There are many, many more characteristics that make experts valuable, but the core value around it all is that they will all be dedicated to your success because they know that’s how they achieve success as well.

To Hire, or Not To Hire… That is the Question

Whether or not you need an expert is a highly situational and business-driven decision that will need careful consideration whenever it comes up. It’s important to make sure that when you do engage, that you maximize the value of your expert by taking advantage of their skills and outsider perspective and be open to the ideas they bring to the table. They are opinionated, but flexible, and can shed invaluable light on parts of your process or plan or implementation that we in the trenches are often too close to see clearly.

SAP FIORI Design System for Figma

Google has rolled out the newest update for Android. Android 10 update brings with it some big features including Live Caption, Smart Reply, Dark Mode and much more. The OS is available in general release now. We’ve created the Android 10 UI Kit to help designers crank out beautiful designs with the most up-to-date Android UI! UI Kits are now available for both SketchApp and Figma, and you can download them all below.

WHAT'S IN THE KIT?

As with our last kit (Wear OS), we have vector screen designs created based on extensive research of the OS, including a ton of reusable symbols. This kit includes all of the main updates in the new OS, as well as some default app screens, and vector app icons. You’ve got everything you need to show off your awesome new app designs!

UI KIT REQUIREMENTS

You'll need the latest version of Figma or SketchApp and Google's Android System fonts, Roboto and Roboto Condensed. You will also need Google’s Product Sans font (aka Google Sans), which we, unfortunately, cannot provide for you. You can find a copy of the font relatively easily online, or you can replace it with Avenir Next, which matches it very closely and is included in Mac OS.

DOWNLOAD THE KIT

Download the Android 10 UI Kit for Sketch here.

Or for Figma, just go here: https://www.figma.com/file/sPtWiyISe38J78ydGdq4rN/Android-10-UI-Kit?node-id=0%3A1

DISCLAIMER

Check out DeveloperTown's handcrafted Material Design 2 Kit and Apple TV UI Kit. You can also follow us on Dribbble!

WANT MORE UI KITS?

Check out DeveloperTown's handcrafted Material Design 2 Kit and Apple TV UI Kit. You can also follow us on Dribbble!

At DeveloperTown, we constantly refine and optimize our workflow between design & development. We evaluate and kick the tires on any and every new tool that could help us blend the gap between our designers and developers.

Currently we rely on our trusty vector design tool of choice, Sketch for design. Invision is our go to for prototyping, but Sketch Cloud is looking very interesting these days as well. Lastly, we use Zeplin for developer specs and hand-off. This workflow has served us well but it’s not perfect.

• Developers have to replicate pages that designers layout in a vector tool.
• Our developers still have to translate design components into code
• Iteration and design changes repeat the entire process over again
• Interaction design tweaks can get lost in the process

Our current process.

Blending (not bridging) the Gap

For a long time, we were looking at tools to help bridge the gap between design and development. The problem with a bridge is that there's inherently still two separate sides of the process. The gap still leaves too much room for ambiguity. Instead of bridging, we want to blend the gap in order to bring design and development closer together. Closer teamwork makes the digital product design dream work.

Which new tool will blend the design / development gap?

.   .   .

Where we want to go…

Every time we have brought designers and developers closer together we have seen dramatic increases in speed and quality. The ultimate goal is for our designers and developers to work from a single source of truth. We turned our UX microscope on ourselves and came to the obvious conclusion that the design team and development team need to be able to look at the same problem in a way that naturally relates to how they tackle a project. When we adopted Zeplin back in 2015, it shaved a ton of time off of our handoff process and brought us closer together. We believe that one of the upcoming “single source of truth” tools will have an even greater impact on our productivity and team collaboration.

• Developers build the right custom components as needed
• Designers use components to layout pages precisely
• Designers now own the interaction experiences
• Faster prototyping and user feedback loops
• Developers can focus more on optimization
• Designers can maintain focus on user experience

In the end, this allows our developers to focus on crafting code perfection and designers to create a more perfect experience for the users. Everybody wins.

Consulting Hurdles in This New Era

All of these new tools and processes are really exciting, especially if you’re a company with a single product and cohesive design language. Since Developer Town and DT Starts serve a variety of clients from start-ups and scale-ups to Fortune 100 companies, we have to be cognizant of not creating a process that backs us into a one dimensional corner. Our process needs to be optimized with a common design language, yet flexible enough to accurately represent the individual identities and personalities of each client.

As Kilian Valkhof elloquently pointed out in his post “What Design tools get wrong,” future design libraries need to work for us agency designers too. This is where design tokens come into play in a big way.

Will our current favorite tools still have a place
in our workflow?

• Do you need Invision when you’re already prototyping in code?
• Does Zeplin’s role get reduced to only new custom components?
• Do we need versioning tools like Abstract if the source of truth is in a repo?

The Contenders — Tools We’re Keeping an Eye On

So what does the coming wave of new tools mean for our future stack and how will it drive Design and Development even closer together? In Part 2, we’ll take a look at the contendors we’re considering for future workflows. Stay tuned!