Mr Branding

Wednesday, April 6, 2016

How to Get the Most out of Your Freelancers

The way we work together is changing, with technology making it faster and easier than ever to collaborate with virtual and local teams. Any time a project manager or entrepreneur wants to build something beautiful, they just need to go to an online freelance marketplace, find the right contractors, give them access, and work together to deliver something amazing...

If only it were that simple.

You know it doesn’t quite work that way in the real world. No matter how good a team you have, how powerful your technology is, or how efficiently you work, issues always crop up. These problems are even harder to solve when you’re working across multiple locations.

[author_more]

Fortunately, there are several practical steps you can take to create better working practices, build stronger team relationships, and ultimately help your project to deliver successfully. As a former project manager and an active freelance writer, I’ve seen these techniques work from both sides. It does take effort and commitment to make these changes, but it’s undoubtedly worth it in the long run.

In this article we’ll explore:

Why it’s vital to value your freelancers.
Foundations — hiring for attitude.
Expectations — the importance of writing stuff down.
Habits — effective project management.
Bringing it all together.

Why It’s Vital to Value Your Freelancers

You might be wondering why you need to think about this stuff. After all, you’re paying for a freelancer’s time and skills. You have expectations and needs, they have talent and services, why isn’t it just a simple exchange of money for work?

The simple reason is that when people feel valued and engaged, they work harder, faster, and produce higher quality deliverables. That's good for you, your business, and your freelancers.

Speaking as a freelancer, feeling valued isn’t just about paying my invoice. It includes:

Being treated fairly.
Sharing autonomy, feedback, and trust.
Working to agreed practices.
Knowing what you expect.

I know that many of my colleagues feel the same way. Spend a little time on those areas and we’ll repay you with outstanding deliverables, a great working relationship, and peace-of-mind. It all starts by finding freelancers with the right kind of attitude.

Help freelancers feel valued

Foundations: Hiring for Attitude

Hiring the right people is an art and science all of its own. One thing to remember when you’re building any kind of team (but especially a remote one) is "Hire for attitude, as well as competence." While many contractors and freelancers can demonstrate competence — a strong portfolio, the right skills and talents, industry experience — attitude is harder to define. To make things easier, it can be useful to focus on three areas: communications, ownership, and being proactive.

Communications

A good freelancer should be a good communicator. This isn’t just about responding to email or Slack chats. It includes contributing to discussions, sharing ideas, taking the lead in their area of expertise, and demonstrating their thinking. In short, they shouldn’t be afraid to speak up.

Ownership

Although ownership is partly about confidence and self-management, it’s also about accountability. This means completely owning the work, understanding your business and project processes, letting you know about any difficulties, and delivering to your scope, budget, and timescales.

Being Proactive

You don’t have time to constantly chase down work and milestones. A good freelancer will keep you informed, manage your expectations, and actively enhance your working relationship.

The best way to hire for these attitudes is to interview your potential freelancers. Ask questions that help them demonstrate these values and listen carefully to the answers. Ultimately, a freelancer’s attitude should build trust and give you confidence that they can do the work and meet your needs.

Remember that with a remote team, communications, ownership, and being proactive are even more important, so hire people with outstanding qualities in those areas. Once you’ve found the right people, you need to set expectations. The best way of doing that is to write things down.

Combine competency and attitude

The Importance of Writing Stuff Down

Project managers and freelancers have something in common: they both like clarity. Working to a common understanding, agreed guidelines, and fair contracts keeps everyone happy. That’s why you should write everything down, communicate it to your contractors, and make sure they agree to it. There are three main areas you and your freelancer should be documenting and agreeing to:

Contracts.
Briefings and scope.
Anything else.

The Contract: Protecting Freelancers and Businesses

A contract is essential to any working relationship. A good contract should define all of the terms, conditions, and expectations from both the freelancer and the business. This includes areas like roles and responsibilities, a brief outline of the work, rates and pricing, what’s in and out of scope, breakpoints, and anything else that needs to be defined.

As a freelance writer, I provide the contract about 90% of the time (here’s a link to my standard freelance writing contract, minus my personal details). Most good freelancers should have a standard freelance template that they can adapt for a client’s needs. As an entrepreneur or project manager, you might have a contract of your own. If not, and you want to develop one, there are lots of good templates and examples just a Google search away.

Because contracts are so essential, many freelancers won’t start work until there’s a signed, agreed contract in place.

Continue reading %How to Get the Most out of Your Freelancers%

by Paul Maplesden via SitePoint

Immutable Data and Functional JavaScript with Mori

This article was peer reviewed by Craig Bilner and Adrian Sandu. Thanks to all of SitePoint’s peer reviewers for making SitePoint content the best it can be!

Functional programming and immutable data are a current focus for many JavaScript developers as they try to find ways to make their code simpler and easier to reason about.

[author_more]

Although JavaScript has always supported some functional programming techniques, they've only really become popular in the last few years and traditionally there's been no native support for immutable data either. JavaScript is still learning a lot about both and the best ideas are coming from languages that have tried and tested these techniques already.

In another corner of the programming world, Clojure is a functional programming language that's dedicated to genuine simplicity, especially where data structures are concerned. Mori is a library that allows us to use Clojure's persistent data structures directly from JavaScript.

This article will explore the rationale behind the design of these data structures and examine some patterns for using them to improve our applications. We could also think of this as the first stepping stone for JavaScript developers interested in programming with Clojure or ClojureScript.

What Is Persistent Data?

Clojure makes a distinction between persistent values that can't be changed and transient values that have temporal lifetimes between mutations. Attempts to modify persistent data structures avoid mutating the underlying data by returning a new structure with the changes applied.

It may help to see what this distinction would look in a theoretical programming language.

// transient list
a = [1, 2, 3];
b = a.push(4);
// a = [1, 2, 3, 4]
// b = [1, 2, 3, 4]

// persistent list
c = #[1, 2, 3]
d = c.push(4);
// c = #[1, 2, 3]
// d = #[1, 2, 3, 4]

We can see that the transient list was mutated when we pushed a value onto it. Both a and b point to the same mutable value. In contrast, calling push on the persistent list returned a new value and we can see that c and d point to different to discrete lists.

These persistent data structures can't be mutated, meaning that once we have a reference to a value, we also have a guarantee that it won't ever be changed. These guarantees generally help us write safer and simpler code. For instance, a function that takes persistent data structures as arguments can't mutate them and therefore if the function wants to communicate meaningful change, it must come from the return value. This leads to writing referentially transparent, pure functions, which are easier to test and optimize.

More simply, immutable data forces us to write more functional code.

What Is Mori?

Mori uses the ClojureScript compiler to compile the implementations for the data structures in Clojure's standard library to JavaScript. The compiler emits optimized code, which means that without additional consideration, it's not easy to communicate with compiled Clojure from JavaScript. Mori is the layer of additional consideration.

Just like Clojure, Mori's functions are separated from the data structures that they operate on, which contrasts against JavaScript's object oriented tendencies. We'll find that this difference changes the direction we write code.

// standard library
Array(1, 2, 3).map(x => x * 2);
// => [2, 4, 6]

// mori
map(x => x * 2, vector(1, 2, 3))
// => [2, 4, 6]

Mori also uses structural sharing to make efficient changes to data by sharing as much of the original structure as possible. This allows persistent data structures to be nearly as efficient as regular transient ones. The implementations for these concepts are covered in much more detail in this video.

Why Is It Useful?

To begin with, let's imagine we're trying to track down a bug in a JavaScript codebase that we inherited. We're reading over the code trying to figure out why we've ended up with the wrong value for fellowship.

const fellowship = [
  {
    title: 'Mori',
    race: 'Hobbit'
  },
  {
    title: 'Poppin',
    race: 'Hobbit'
  }
];

deletePerson(fellowship, 1);
console.log(fellowship);

What is the value of fellowship when it is logged to the console?

Without running the code, or reading the definition for deletePerson() there is no way to know. It could be an empty array. It could have three new properties. We would hope that it is an array with the second element removed, but because we passed in a mutable data structure, there are no guarantees.

Even worse, the function could keep hold of a reference and mutate it asynchronously in the future. All references to fellowship from here onwards are going to be working with an unpredictable value.

Compare this to an alternative with Mori.

import { vector, hashMap } from 'mori';

const fellowship = vector(
  hashMap(
    "name", "Mori",
    "race", "Hobbit"
  ),
  hashMap(
    "name", "Poppin",
    "race", "Hobbit"
  )
)

const newFellowship = deletePerson(fellowship, 1);
console.log(fellowship);

Regardless of the implementation of deletePerson(), we know that the original vector will be logged, simply because there is a guarantee that it can't be mutated. If we want the function to be useful, then it should return a new vector with the specified item removed.

Understanding flow through functions that work on immutable data is easy, because we know that their only effect will be to derive and return a distinct immutable value.

Flow through functions that work on immutable data

Functions operating on mutable data don't always return values, they can mutate their inputs and sometimes it's left to the programmer to pick up the value again at the other side.

Flow through functions that work on mutable data

Continue reading %Immutable Data and Functional JavaScript with Mori%

by Dan Prince via SitePoint

What is the Definition of a “CSS Hack”?

If you’ve been writing CSS for at least a couple of years, then you’ve most certainly used a CSS hack. But if you’re relatively new to CSS, it’s possible you’ve heard the term but aren’t sure exactly what it means.

In this post, I’m going to explain what exactly the term CSS hack means and how a CSS hack is used. But first, some background to explain why I felt this post was even necessary.

Many Developers Seem to Misunderstand the Term

As many of you are aware, SitePoint recently published the results of a large CSS survey that I put together. One of the questions the survey asked was the following:

Which of the following Microsoft Browsers do you currently write or include CSS hacks for?

When I first studied the results, I seemed to have missed an oddity in the results for this question. Fortunately, David Storey, who is an engineer working on Microsoft’s newest browser, pointed it out. Of the 1,418 people who answered this question, the results went like this:

IE9 - 62%
IE10 - 61%
IE11 - 57%
Edge - 45%
IE8 - 35%
IE7 - 9%
IE6 - 3%
IE5.5 - 1%

It’s bad enough that more than 60% of developers are claiming to write CSS hacks for IE9 and IE10 – but 45% for Edge? Although there are some published hacks for Edge, they aren’t yet on the Browserhacks website, so it seems unlikely that so many people are using hacks for that browser. But the more important question is: What problems are developers running into with rendering CSS in Edge that they’re requiring hacks?

At first, I thought it might be that many of the participants are confusing hacks with browser detection via User Agent sniffing. But even that wouldn’t explain why the number is so high for Edge.

Then I realized they must have misunderstood the question completely; they think ‘writing CSS hacks for browser x’ is the same as ‘supporting browser x’. There’s really no other logical explanation, especially when you consider the high percentages for the other browsers that also shouldn’t need hacks.

So let’s define exactly what a hack is, for those who might be confused by the term.

What is a CSS Hack?

For something in your CSS file to be considered a “hack” it must apply its styles only to the browser(s) being targeted while all other browsers ignore it.

Let’s consider an example. This is a CSS hack:

[code language="css"]
* html .sidebar {
margin-left: 5px;
}
[/code]

The CSS in the above example (often referred to as the “star-html hack“) will target only Internet Explorer versions 6 and below. Most developers who support IE6 don’t really care about anything before IE6, so this usually works as an IE6-only hack.

The part that is the “hack”, is the asterisk followed by the “html”. This is a combination of the universal selector and the element type selector. At some point, someone discovered that these two selectors together preceding another selector work only in certain versions of IE while having no effect in other browsers. This means that the left margin on the .sidebar element defined in the above code example will apply only to IE6 or earlier. In this case, the CSS is actually valid, so you won’t get an error or warning about it (more on this later).

Here’s another example taken from the Browserhacks website, this time targeting IE11:

[code language="css"]
_:-ms-fullscreen, :root .selector {
margin-left: 5px;
}
[/code]

I’m not going to go into the specifics of why this is a hack (partly because I’m not entirely sure I understand it), but the above CSS will apply only to Internet Explorer version 11. Technically, Browserhacks says ‘IE11 and above’, so I’m assuming this means it will also work in Microsoft’s Edge browser, but I haven't verified that.

The important point here is not which browsers are targeted, but that we’re all on the same page in understanding what is a CSS hack.

Continue reading %What is the Definition of a “CSS Hack”?%

by Louis Lazaris via SitePoint