Forem: Ellen Macpherson

First Job Tips: Overcoming the Anxiety of a Large Codebase

Ellen Macpherson — Wed, 05 Feb 2020 16:22:44 +0000

When I started my first role in software development, it didn't take me long to realise that you can do all the study in the world, but it will never prepare you for a professional codebase. This is especially true if you work at a big organisation with established or legacy code.

Sometimes the code will be lacking in comprehensive documentation. This can happen when teams have been there so long that their understanding of the code is just innate, and they haven't thought to put on a wiki page. Sometimes it just won't look like any other code you've encountered.

The unfamiliarity of a new project might make some people excited, but it can also cause anxiety. We're in an industry where bootcamps and influencers promise the world when it comes to learning. They often fail to take into account that a company's software can look very different to a todo list or blog built by a single person.

Getting to grips with a professional codebase can take weeks. Sometimes it can take months. However, there are some things you can do both before your first day on a dev team and in your first few weeks to speed up the process.

Take a look at some large open source projects.

Before I had my first day on the job, I wished that I'd seen a production codebase before. It wasn't until months after I started that I discovered the open source community.

Contributing to open source is a great way to get used to the kinds of tasks you'll be asked to do in a company's development team. You learn about working with other contributors, following design specifications, report bugs, prioritising tasks and fixing issues. You'll likely be working remotely as well, which is a fantastic experience to have.

Yet even if you don't feel like you can contribute, taking a look through some of Github's most popular open source projects will reveal some commonalities between them. You'll likely see the same test frameworks, task runners and frameworks being used across a number of projects. Being able to identify these on your first day at work will be incredibly helpful.

Find out all the tech that's being used and read the docs.

Make a list of anything in the code you haven't seen before and bookmark the documentation. This will take you a while, but it's a crucial part of working in a new codebase. It can be tempting to watch tutorials instead, but video courses will probably using the technology very differently. Get used to the documentation first and identify how the tech is being used in your codebase. If you're interested in learning more after that, watch some videos.

Start with tests.

After reading the documentation for whichever test framework your company's codebase uses, take a good look at the tests themselves. These will tell you what the most crucial functions are and what data formats you're working with.

Most importantly, tests should give you a high-level overview of how the code flows.

Make diagrams of everything. And then share them.

Speaking of the flow of code, it's a good idea to document any meaningful interactions you find between files and functions while you're looking at the test code. For instance, if you're working on an e-commerce website, diagram how the the user's order journey works in the code. If you're working on a straming service, visually document how the data gets displayed on each carousel in the app or browser.

Whether you're contributing to a legacy project or a brand new product, breaking down the codebase like this will help immensely when you're debugging or adding new features later on. Eventually, you'll end up with a decent skeleton of how the app or website works, and that's the first step to diving in and start making code changes.

There may be existing diagrams on your company's wiki pages, so make sure you take a look. If there isn't, share the ones you've made to make a future developer's life easier (and to make sure you don't lose your own notes!).

Use the knowledge of your fellow developers.

Software development is always a team effort. There's no one person who will know everything about the code (or there might be - but those folks are, in my experience, very rare!). Find out the experts are for each part of the development process and pick their brains.

You might get to the point where you feel like you're asking too many questions, but no-one will expect you to know everything the second you walk in the door. Make sure you tap into your teammates' knowledge by asking to pair program, getting them to explain the technical choices they've made, and to review your underderstanding often. Asking informed questions about the things you don't understand is the fastest way to progress in your role.

Just fix it!

Throwing yourself in the deep end can sometimes be terrible advice, but there's a grain of truth in it. Perhaps wading into the water is a better metaphor. You might be in your first job feeling overwhelmed by the code and unsure whether you belong in the team. The best way to overcome this is to give yourself a quick win.

Once you understand a bit about the technology being used and the flow of the code, look for a bug that you think you can fix. If you can't see an obvious one, talk to your team and ask if there's a manageable issue you can tackle. You don't have to understand everything, but the feeling of that first closed ticket might help with everything seeming so huge and indecipherable.

Have you got any advice for early-career developers transitioning from study to work? I'd love to hear some other suggestions!

Learn D3.js with Me: Bind Data to DOM Selections (Post #2).

Ellen Macpherson — Wed, 04 Dec 2019 20:37:51 +0000

It's Welcome to the second post in this D3.js fundamentals series - a place where we're all learning together. If you're new to this series, please see Part 1 before you keep going.

To recap last lesson, we learned:

What D3 is and why you would use it. 🤔
Setting up D3 in a new project. 👩‍💻
How to select DOM elements using select() and selectAll(). ☝️
How to append elements to the DOM using append(). ➕
How to add HTML attributes to elements using attr(). ➕
Saving selections to a variable. 💾
Using the text() method to add text to an element. 📝

Today we'll be learning how to bind data to DOM elements. This is really the crux of D3:

D3 allows you to bind arbitrary data to a Document Object Model (DOM), and then apply data-driven transformations to the document.

Binding data means later on we can eventually interactively update our charts and graphs. Exciting, right?

Grab yourself a cup of your preferred brain-fuel and let's get going.

Setting up

Last time, we worked with an unordered list and appended three li elements to it. Our code looked like this:

d3.select("body")
  .append('ul');

const ul = d3.select('ul');

ul.append('li').text('first');
ul.append('li').text('second');
ul.append('li').text('third');

Today, we'll be sticking with the unordered list, but we'll be dynamically generating the li elements. Go ahead and delete the last appending those li elements.

To bind data, we first need a dataset. This can be anything. Unlike pre-built visualisation platforms, the power of D3 is that it's really up to you what data makes it into the browser and how.

We'll explore a few different datasets later in this series, but we'll keep things simple for now with an array of numbers:

const dataset = [6, 18, 58, 4, 23, 10, 74, 30];
d3.select("body")
  .append('ul');

const ul = d3.select('ul');

Getting data to the browser in D3 works a little unconventionally. First, we have to select elements that don't exist yet. And because we have more than one number we want to deal with, we need to use the 'selectAll()' method we learned in Part 1:

const dataset = [6, 18, 58, 4, 23, 10, 74, 30];
d3.select("body")
  .append('ul');

const ul = d3.select('ul');

ul.selectAll('li')

This might seem odd, but think of it as a preparation step. It's a similar concept to declaring an empty variable in JavaScript before assigning it data in a loop.

Binding the data

Right, time to deal with the data. To pass the dataset to d3, we need to use the .data() and enter() methods. And remember, we can chain these together.

const dataset = [6, 18, 58, 4, 23, 10, 74, 30];
d3.select("body")
  .append('ul');

const ul = d3.select('ul');

ul.selectAll('li')
  .data(dataset)
  .enter()

data() counts and parses our data. When we have more data in the dataset than there are DOM elements, we need to use the enter() method. It creates a placeholder for each extra element we need in the DOM. So right now, it's created eight placeholders for us. Later on in the series we'll have a look at the update() and exit() methods.

If you run this code now, you won't see anything. That's because we've selected our li elements, but we haven't appended them.

ul.selectAll('li')
  .data(dataset)
  .enter().append('li');

At this point, we've got eight list elements on the page.

It's progress, but D3 won't automatically add the text values to the DOM because we might not always want to visualise our data that way. To get text showing up, we need to use the text() method we learned in the last lesson that allows you to set any text value for the elements in the DOM.

ul.selectAll('li')
  .data(dataset)
  .enter().append('li')
  .text('New list element!);

Here, we've essentially said 'append the text 'New list element!' to each li element we've created in the DOM. It doesn't seem very useful, but there might be a reason one day why you want a static value for each element on the page. For instance, you might have designed a visualisation simply counts how much of something there is.

To get the the correct corresponding dataset values for each element, we'll need to do things a bit more dynamically and loop through our dataset. To do this, we use a simple function to tell D3 to show the matching value for each element.

function(d) {return d};

ul.selectAll('li')
  .data(dataset)
  .enter().append('li')
  .text(function(d) {return d});

And voilà! We've got our dataset showing on the page.

It's not the most exciting output, but the building blocks of D3 are starting to take shape. Using our imagination and the lessons we've learned so far, we can start thinking about how to use functions to not only change text, but colour, shapes and animations.

Recap

Again, not the most exciting output, but we've learned the true building blocks of D3:

How to bind our data to the DOM using two new methods: data() and enter().
How to use a function to get your dataset values visually represented in the DOM.

Follow along next week for a crash course in SVG where we'll be making a simple bar chart. 📊

Learn D3.js with Me: Selecting and Appending elements to the DOM (Post #1).

Ellen Macpherson — Tue, 26 Nov 2019 14:33:56 +0000

Welcome to my beginners series covering D3.js fundamentals where you can learn D3 along with me! This series of blog posts will be for categorising my own learning as well as sharing knowledge with all of you. So please feel free to discuss your own tips and tricks in the comments.

Introduction

Today we'll be covering what exactly D3.js is, why you might use it, how to set it up, and some basics on how you can use it to interact with the DOM.

What is D3.js?

D3 stands for Data-Driven Documents. It's a frontend JavaScript library built for data visualisation. It leverages HTML, CSS and SVG to help you create brilliant interactive data visualisations capable of running in any browser.

Why would I use it?

Because it's largely built around making use of CSS and SVGs, D3 is probably the most flexible tool out there for visualising data. You can make graphics as interactive or animated as you like - the only limit is your creativity.

Mike Bostock, the creator of D3, has a lot of examples in this gallery on Github.

What should I know before I start?

Before diving into D3, you should have a solid understanding of HTML, CSS and JavaScript basics. Some experience in jQuery isn't strictly necessary, but it could be helpful. The syntax of D3 is very similar. Finally, a basic understanding of geometry and SVGs won't steer you wrong. I'll be doing a very rudimentary crash course on creating SVGs in this series, so don't worry if it's not something that's currently in your toolbox.

Getting set up

The easiest way to use D3 is to use its CDN.

Create an HTML boilerplate with a few paragraphs:

<!DOCTYPE html>
<html lang="en" dir="ltr">
  <head>
    <meta charset="utf-8">
    <title>D3 Fundamentals</title>
    <link rel="stylesheet" href="master.css">
    <script src="https://d3js.org/d3.v4.min.js"></script>
  </head>

  <body>
    <p>First Paragraph</p>
    <p>Second Paragraph</p>
    <p>Third Paragraph</p>
    <p>Fourth Paragraph</p>
    <p>Fifth Paragraph</p>

    <script type="text/javascript" src="index.js"></script>
  </body>
</html>

Make sure this script tag is pasted into the head:

<script src="https://d3js.org/d3.v4.min.js"></script>

You can also download a local copy from here and point the script source attribute to the local path.

Create another script tag just before the end </body> tag. I personally like to keep my scripts separate from my HTML code, so I've linked to an external index.js file. I'd recommend doing this as our code gets more complex. For now, however, you can write your JS in the script tag if you prefer.

First steps: Understanding how to select and append elements in the DOM

Before we dive into making graphs, charts and maps, we should understand how to interact with the DOM. You'll largely be doing this through selecting and appending HTML elements.

Selecting elements

D3 allows you to select elements in two ways using:

d3.select()
d3.selectAll()

The select methods take one parameter - the element you want to edit. This can be in the form of a tag name, a class name, or an id.

Let's go ahead and add some very basic styling to our paragraphs so we can see the effect of using the different selection methods. Don't worry too much if you haven't seen styling done in this way before. I'll be talking more about it later.

Using d3.select('p') will only target the first paragraph element in the DOM. Note: if you want to target another one of the other paragraphs, you can use the CSS nth selector in the D3 select method. To select the third paragraph, I can run d3.select('p:nth-child(3)').

Of course, selecting an element doesn't show us anything, so let's add some styling to prove it's worked. To add styling to our selected element, we use the style() method. It takes two parameters: the style attribute (in this case, color), and the value (in this case, teal). D3 supports method chaining, so all we have to do is continue on the same line as our select() method.

Running d3.select('p').style('colour', 'teal') should give you the following result:

The selectAll() method, however, allows us to select all the targeted elements.

To make all our paragraphs teal, we can run d3.selectAll('p').style('color', 'teal').

Both methods will probably form the basis of most of the graphs you create. But we won't often be working with hard-coded elements from the DOM. It's more likely that we'll be selecting specific elements based on the data they reflect. To create those dynamically elements, we'll need to first know how to append them to the DOM from our JS file.

Appending elements

Appending elements to the DOM will eventually allow us to dynamically create elements based on our datasets. The function we'll be using to do this is:

d3.append()

Let's get rid of our paragraphs for the moment so we have an empty HTML boilerplate again. First, we need to select the element we want to append something to - in this case, it's just the HTML body.

Let's make a list this time.


d3.select("body")
  .append('ul');

We can also save the ul element to a variable to make our lives easier when appending several li elements. This will be useful down the line to keep things clean when our code becomes more complex.

const ul = d3.select('ul');

ul.append('li')
ul.append('li')
ul.append('li')

At this point, you should see three bullet points. But they don't have any text - to add some, we can use the text() method, another handy function that we'll be using often. You can also use this to update any existing text in an element.

ul.append('li').text('first');
ul.append('li').text('second');
ul.append('li').text('third');

The end result should be this pretty boring looking list.

Adding attributes

One of the most widely-used methods in D3 is the attribute method, used to add HTML tag attributes:

ul.attr()

The attribute method takes two parameters: the attribute you want to add (e.g. class, id, width, height etc) and the value.

This will come in particularly handy when we start working with SVGs and need to specify x and y attributes to our visualisations. It's also great for styling. For example, we can add a class called 'list' to our unordered list by running ul.attr('class', 'list'). You can then give it specific styling in a separate CSS file or select it in your JS file using d3.select('.list')for further editing.

Recap

Boring as our end result might have been, we've covered some crucial first steps in learning D3:

What D3 is and why you would use it.
Setting up D3 in a new project.
How to select DOM elements using select() and selectAll().
How to append elements to the DOM using append().
How to add HTML attributes to elements using attr().
Saving selections to a variable.
Using the text() method to add text to an element.

Next time we'll be covering how to bind data to your DOM elements. This is where is gets really exciting, because it means dynamically loaded data! 😱

Feel free to have a play around with creating and styling different elements.

Part 2

Two ways to create an image with a colour overlay in CSS

Ellen Macpherson — Sun, 29 Sep 2019 16:12:58 +0000

Using an image with a dark overlay is one of the quickest ways to make a beautiful hero header for a blog, landing page or portfolio. It's a trick I use constantly.

Why should you add an overlay to your image?

An overlay on an image not only improves aesthetics but it makes text much more readable.

Consider this hero header I've mocked up. It's not great, is it?

The text here is readable. But only just, and it's because I've used H1 and H2 headers. Yet, it's not very accessible for people with reduced vision, and it's also really busy to look at. Overlays vastly improve readability, along with making your design much more sleek. In this post, I'll be showing you a couple of ways to code them up.

There are, of course, many ways you can get to your end goal here. These are the two methods I find easiest to remember. Which method you choose will depends on the purpose of the image. If you're only after a pretty background, you can go about this any way you like. Alternatively, if your image isn't just decorative and you want people to notice it, you should use an image tag with an alt description for accessibility.

Using an image tag and a section background.

Again, this is your best option if your image isn't just decorative. This might not be in a header; it might be in an image aside or as part of an article.

First, place an img tag in a section.



<header>
   <img src="https://bit.ly/2rlzaXi" alt="Five developers at work.">
   <section class='hero-header-text'>
      <h1>Ellen Macpherson</h1>
      <h2>Just another tech blog.</h2>
      <button>Read more.</button>
   </section>
</header>

I've purposely avoided a div here. If you're creating a header, make sure you're using semantic HTML to define it as such. This will help with both accessibility and SEO considerations. For more on why you should use semantic HTML elements, see this helpful blog post.

Now for the CSS. Make sure the image fills the header, either by using height: 100%, width: 100%, or by using object-fit: cover.

Set the background to your desired colour. In this case, i've just kept it black, but you could also make clever use of a linear gradient to really make things pop (see the next section for details). Set the opacity of the image somewhere between 0.3 - 0.5.



header {
    height: 600px;
    width: 100vw;
    background: black;
    overflow: hidden;
}

img {
   object-fit: cover;
   opacity: 0.4;
}

And viola! You've got a much nicer looking background that draws the eye immediately to the text and call-to-action button.

Pros: Allows you to set alt text for the image. Browser-friendly.

Cons: Involves more HTML and styling than other methods.

Using a linear gradient

This is my preferred method. There's less styling and thinking involved around the layout. Often, you won't be using these images for descriptive purposes, so it seems more intuitive to handle the background in CSS.

In this case, you don't need to reference the image in the HTML at all, so the code only involves the header (or whichever tag you want to style) and any text or buttons on top:



<header>
    <section class='hero-header-text'>
        <h1>Ellen Macpherson</h1>
        <h2>Just another tech blog.</h2>
        <button>Read more.</button>
    </section>
</header>

Remember, you can't set alt tags without HTML, so make sure the image you're using is purely decorative.

Although CSS linear gradients is well-supported now, I'm going to use a fallback colour along with the webkit prefix to make sure I cover all browser possibilities. This also gives you a fallback if, for any reason, the background image is slow to load. Remember the C in CSS; everything cascades. Therefore, your foolproof fallback colour and alternative webkit prefixed styles should always come before the least-supported solution. In this case, that's linear-gradient().



header {
    height: 600px;
    width: 100vw;
    background: black;
    overflow: hidden;
    background: #C33764;  /* fallback colour. Make sure this is just one solid colour. */
    background: -webkit-linear-gradient(rgba(29, 38, 113, 0.8), rgba(195, 55, 100, 0.8)), url("https://bit.ly/2rlzaXi");
    background: linear-gradient(rgba(29, 38, 113, 0.8), rgba(195, 55, 100, 0.8)), url("https://bit.ly/2rlzaXi"); /* The least supported option. */
}

img {
   object-fit: cover;
}

Here we are with a more colourful interpretation of an overlay:

In this example, I've used the RGBA colour format to make the gradient transparent and set the opacity to 0.8 for a bold finish. However, colour gradients will never look the same on different images. Play around with the opacity to make sure it works well with your design. For more impact, make the image underneath grayscale and alter its contrast.

Pros: Uses fewer lines of code. Easier to implement.

Cons: Issues around browser support mean you'll have to remember to set a fallback image or colour for your background.

That's it! If you have any other great ways to implement an overlay, let me know in the comments. Let me know your favourite gradients, too 👇

The UX Honeycomb: Seven Essential Considerations for Developers

Ellen Macpherson — Fri, 27 Sep 2019 20:05:06 +0000

When we're looking so closely at code, it can be difficult to keep our users' needs in mind, no matter how much we talk about them in retrospectives or planning meetings. However, our technical solutions become immensely more successful when we keep our users in mind. Particularly for organisations with little to no specialist UX presence (trust me, they exist), it's important that developers fight the good fight for our users.

Peter Morville's User Experience Honeycomb is a classic UX diagram outlining the seven essential aspects of UX. Like any classic text, it's been argued over, but I think it's a great starting point for everyone involved in creating innovative products and services for humans. Which should be...all of us.

I've used Katerina Karagianni's optimised diagram of the honeycomb, as she draws useful connections between its disparate parts to convey how users use products, as well as how they think and feel about them.

Useful

Does the product, service or feature serve a purpose for your target customers? If it does, it's useful.

Remember, usefulness is in the eye of the beholder. It's all about your target market. A particular feature of a video game (like character customisation options) might not seem useful to everyone, but to a gamer, it might be an essential sticking point that will define whether they play a game or not.

Consider Spotify's personalised playlists. One of the reasons people pay for streaming services is for content that's personalised for them. Most people will open Spotify for a particular purpose: to find new music, or to listen to their existing favourites. Spotify caters to both with personalised daily playlists, as well as a 'new releases' one. I don't have the stats on me, but I'd wager a guess that these playlists serve the purpose of a lot of the platform's users.

Usable

Usefulness does not equal usable. Usability concerns your users' ability to effectively and efficiently achieve their end goal. How many clicks, for instance, does it take a user to reach their desired page?

Everything from the server, to the HTML to the visual factors of a website or app should be optimised for ease of use. Tools such as Usabilla, Webpage FX and Pingdom can help you test for usability.

Furthermore, websites and apps should be intuitive enough for users to become experts at using on their first visit. This should iterate through each release, so if you release a new feature, or do a major redesign, there should be some tutorial help for the user to familiarise themselves.

Findable

This is all about navigation. Is the information your user seeks easy to find? Is your navigational structure intuitive? If you're designing a music or video streaming site, the quicker I can get to the content I want, the happier I'll be.

Many UX and UI designers will talk about the 7 ± 2 rule, which comes from one of the most highly-cited papers in psychology, written in 1959 by George A. Miller. It's often interpreted by designers to argue about the size of navigation menus. That's not strictly applicable in today's world where menus can be deep and complex, but it's still useful to keep in mind when you're designing navigation. If you're designing a site with lots of sections, make sure you're using headings or dividers to denote structure.

To bring us back to our Spotify example, lead designer Andrea Limjoco redesinged navigation on the app to include music and podcasts with a user's library. She successfully condensed what might have been a complex menu to be a sleek, simple and intuitive swipe motion, optimised to take advantage of users' natural actions on mobile devices.

Credible

Credibility refers to the ability of the user to trust in the product you provide, in terms of your ethics, durability, and accuracy. As a developer, you won't have direct control over every aspect of this.

However, development teams are responsible for delivering a product which lives up to what it promises. For instance, companies like Spotify or Netflix promise a seamless streaming experience. In a highly-competitive market, any consistent failures on their part will lead to people leaving the service and moving to another company.

Accessible

Your product or service should be accessible to users of a full range of abilities. There is lots of literature out there on accessibility. Start with a11y and make sure you're conscious about auditing for accessibility constantly. If something seems off to you, don't be afraid to bring it up.

There is a considerable business case to be put forward here, even if your employers aren't receptive to the moral argument that everybody should be able to access the internet. In the UK alone, disabled people and their families have estimated £212 billion to spend.

Lastly, basic accessibility is a legal requirement in many countries, so the failure to take it into account is serious.

Desirable

This aspect might seem like it's all about branding. But branding doesn't come from nowhere. Apple isn't successful just because their products are aesthetically pleasing, though it's certainly an edge for them. They back it up with quality. Spotify and Netflix are largely comparable to several streaming services out there, but because they were first in the game, and have the investment to funnel into innovation, they're seen as the cream of the crop. This is something a reputation that development teams contribute to and have responsibility for.

When you're developing a new feature, ask yourself if it's adding to the worth of the product? Is it something that people will talk about? If it's not, consider questioning it.

Valuable

Your product or service must deliver value to the business and to the customer. Like all aspects of UX, this is dependent on your users. Some user groups will value desirability over accessibility, and vice versa. It's up to you to work with the balance between customer wants and business priorities, but we should always question decisions that prioritise profit over seamless experience.

Final mention of Spotify, I promise. In July 2015, the company launched their 'discover weekly' playlists. By December of that year, they had been streamed 1.7 billion times. This generated huge value for the business, but it was also of immense value to users who, like me, were often too lazy to search out new music, but relished the chance to have it presented to them.

Conclusion

We don't all have to be UX experts. However, it's important that we keep focus on the bigger picture, even when we're developing small features or fixing bugs. By keeping these seven key aspects in mind during development, and communicating them to our teams, we can ensure we're doing our best for our end users.

Got any other tips to keep good UX in mind during development? Share below!

Ten Things I've Learned in Six Months of Being a Junior Frontend Developer

Ellen Macpherson — Mon, 19 Aug 2019 17:28:45 +0000

Unbelievably, it’s been six months since I started my first professional role in software development. It's been incredible, and while some days I don't think I've learned anything, there are definitely a few small lessons I've picked up along the way.

I work for a really large organisation, but I think most things in here are common experiences in smaller companies, startups, and even freelancing. Not everything in this list will apply to everyone, but these are the things I think of daily in my tech journey.

You will spend weeks, if not months, understanding a codebase. And that's okay.

My colleagues and I, CS degree or not, are all in unanimous agreement that the hardest part of your first development job (or any new job, really) is feeling at home in the code. Our project at work involves nearly 400 files. I spent the first three months of my job writing very few lines of code and instead drawing a lot of diagrams. It's easy to worry that you're not contributing or bringing value, but this is valuable learning time in the long-term. The more time you spend understanding a project's design patterns and structure, the more productive you'll be later down the line.

It's okay to neglect your side projects.

Some people are really motivated and energised by their first role in tech. Personally, I found myself so exhausted that the last thing I wanted to do when I got home was to code or study more.

It can seem a little strange transitioning away from a bootcamp or self-taught lifestyle where you're building projects daily or weekly. It might feel as if you're not learning or contributing to your Github as much. All of that is perfectly normal. Take time to celebrate the wins you're having at work, and don't worry so much about the Github contribution grid or your portfolio. The energy will return, I promise.

Don't underestimate your "softer" skills.

There is power in them, trust me. I vividly remember attending a UX meet up where many of the designers and researchers there had negative experiences with trying to talk to developers. And while I was sitting there thinking “Surely we’re not so different, are we?”, I realised the problem was one of communication. I’m sure there are misconceptions of each others personalities and roles on both sides, but communication, empathy and good listening skills are crucial to being part of a successful technology team. So it's important to work at it.

The stereotype of the anti-social hacker is a misleading one. In most modern workplaces, you will have to liaise with fellow developers, product owners, management and designers. Try your best not to be that developer that people are afraid to approach to ask a question.

I’ve learned the most useful everyday skill is being able to explain my code in everyday language, even if I’m talking to fellow developers who uare familiar with the tech stack. We all code so differently that it can take a minute to understand what someone has written, even if it's something as generic as parsing JSON. It saves so much time if you’re able to simplify your code through talking through it concisely.

Your value is in the different perspective that you bring. Take risks. Be vocal.

Say what you see. All the time. It could be a as simple as a line of code you think isn’t right, or a feature that hasn’t been thought through. It could also be something about company culture. You’re an individual with opinions and perspectives. Don’t repress them just because you think “that’s the way things are done around here.”

Also, an important side note: be vocal with positivity. If someone has done a good job, mention it to them. Development can be stressful and isolating. It’s nice to hear a compliment sometimes.

You don't have to go it alone. Find your community.

This might seem a cliched piece of advice, bit I have to remind myself of it often.

There will come a point where you might think you shouldn't need to ask for help; that you should be able to figure things out on your own. From experience, that's the ideal time to ask. Nobody was born with programming skills. Take advantage of your colleagues' experiences and knowledge to learn and develop.

There's a less technical side to this too. I work, as many women (and particularly women of colour) do, in a very white, male office. Many of the men in my office went to the same universities and came up through the same graduate programme. I felt work was a pretty isolating place to work as a woman from the other side of the world, no matter how great my colleagues were at trying to make me feel included.

I'm lucky enough to work in the same office as two other amazing women who have similar non-technical backgrounds to mine. But I also found reaching out to vibrant, passionate online tech communities to be really rewarding. Sites like Tech Ladies, Elpha, Twitter and Dev.to have made me feel less isolated as a junior in the industry and in the company I’m in. Now at work, I’ve started sharing ideas and perspectives I’ve picked up online. it’s a small shift to company culture, but it’s a shift nonetheless.

If you're in the unfortunate position at work where you lack a sense of community, take your search online. There's plenty of connections and inspiration to be found.

Empathy isn't requirement for the job, but you need to be able to listen to what your user wants.

There has been a lot of great things said recently on the value of empathy in tech. But it's unrealistic to expect everyone who codes to have an innate ability to empathise with an end user they will very rarely interact with, if they even do at all.

The world of software development has become so big now that there are a plethora of different careers in UX alone. So it can be a daunting subject to broach if you've never really considered design your thing. It might seem easier to pass off a problem to a dedicated UX professional, but there are many small decisions to make on a day-to-day basis that have a direct effect on your users' experience. There really is no way to get around the fact you have to know your end user well. At the very least, every development change you implement should start with "why?"

Work slow.

The greatest aspect to being a developer is that you'll never be bored. There are an endless stream of new languages, frameworks and job titles for you to get stuck into. In my experience, this is also the most overwhelming part of being a developer. It makes me want to rush everything. It's easy to think you have to know it all right now - or at least know way more than you do - to get ahead.

When I first started learning JavaScript for my role, I wanted to get through the fundamentals as quickly as possibly so I could start working on meaningful contributions to the project. I learned the hard lesson that I should have slowed down. This goes for your first bug fixes too. Don't worry about the pace your colleagues are moving at. Focus on your own journey. If you only fix one small bug in a day, but you've taken the time to understand what went wrong and why, rather than seeking a quick fix, you'll be a better developer because of it.

Prioritise sleep and regular breaks over coffee.

We all turn coffee into code, and that's cool. But it's not a replacement for taking care of yourself.

Regular breaks can be whatever you want them to be - not everyone loves a break every 90 minutes. If you're someone who gets deep into the code for eight hours, that's great! But make sure you're putting a big chunk of your day aside to get away from the screen.

And honestly, get those eight hours. Your mind will be so much sharper for it.

Remember, the possibilities are endless.

You've got your foot in the door of a huge, exciting industry. Don't be afraid to explore it. Take every opportunity you can to learn and grow. Just because you're a frontend developer, it doesn't mean you shouldn't explore customer data or UX design or information architecture.

You’re not limited to the role you have, but you’re also not limited to the company or the clients you work for. The tech community is huge and the opportunities to have your voice heard are everywhere. Get amongst it.

Write down your motivation for becoming a developer. Refer to it when you're having a bad day.

Most of us got here because we're motivated, and that motivation will really help you out of a rough spot. There are so many days when I've felt useless, but been reenergised by remembering that someone like me could see my journey and think "hey, I can do that, too."

What are some of the things you've learned in your professional journey? I'd love to hear them in the comments!

Beginner tips for developers with no design background.

Ellen Macpherson — Tue, 13 Aug 2019 20:58:11 +0000

I'll be honest - the world of design intimidated me when I first started developing websites. I stuck to clean minimalism for most of my early projects, because I became too afraid to do anything bolder.

We can't all be graphic design experts. However, as front end developers, it's important that we can at least recognise good design. Today I'll be sharing some of my favourite design hacks and insights that are easy to remember and implement. I'm hoping some of you will also share your own!

Have a good understanding of UX fundamentals.

If I were to pick one thing from this list to drill into everyone's brain, it would be this one. Aesthetically beautiful design means nothing if it's difficult for your user to interact with.

Firstly, your organisation will hopefully (but - and I can't stress this enough - not always) have a team of UX designers and researchers to handle most of the big design decisions. So why should you learn it?
It makes communication with designers and researchers easier, gives you a better understanding of the design architecture decisions, and helps you keep your end user in mind at all times when you're developing the product.

Do you need to be able to create beautiful prototypes? No, of course not. But an understanding of low-fi prototyping (i.e. sketching things out on paper) will get you further than you think. It will help you work through why you're placing elements in a certain way.

This might seem like common sense, but I've worked with plenty of developers, scrum masters and product owners who don't know the value of good UX, and it shows.

For a quick crash course, I'd recommend heading to YouTube or Google Developers.

Think you've got enough whitespace? Double it!

There is nothing that will make a page more aesthetically pleasing and easy-to-read than whitespace.

It doesn't just make a site look pretty, either. It makes for better navigation, increased legibility, more meaningful content engagement, and more obvious calls-to-action. It's not all about padding and margin, either. Have you ever been working with a really nice font, but it just didn't look right? Try adjusting the line height or letter spacing to give a bit of breathing room.

One of the best design tips I ever received is not to think of adding whitespace; get into the habit of thinking that every element you add to your site removes it. This will help you make conscious decisions about your layout and use of components.

Choose a font pairing and stick to it.

Websites shouldn't have inconsistent fonts - that means sticking to two or three that work well together. And yet, the world of typography is vast and can be deeply overwhelming, even if you're only looking at Google Fonts.

The most important thing to remember is readability. Is your font choice easy to read? More importantly, can someone who is time-poor skim read a long paragraph and still get the necessary details? You've picked well.
If it sounds like I'm talking about accessibility issues here, I am. The easiest way to ensure your site works visually is to choose an easy-to-read font and space it well. All those things I was saying in the above whitespace section about increased legibility and more meaningful content engagement? They apply to font, too.

Luckily, there are places to turn to if you feel out of your depth. Typing 'font pairings' into Google will give you lots of articles, generators and design guides. Depending on what you're creating, you might want to look into different sites.

For text-heavy sites and blogs, I like to head to Fontpair, which has a lot of great font combinations, optimised for readability. The Canva ultimate guide to font pairing is another great resource. It has a list of suggestions to cover everything from sports websites to resumes. If you're interested in tips on how to make your font accessible, check out Four features of accessible typography on the Fathom UX blog.

And remember, if all else fails: Montserrat.

Use a colour palette.

Unless you've done an art or design degree, colour harmony doesn't come naturally to most of us. Sticking to a can really elevate a website or app.

When I first began to design websites, someone gave me the advice that using a colour generator meant I would always have a great looking website. There's obviously more to it than that, but it's a good start. As is the case with font pairings, there are plenty of places you can turn to for help. My personal favourite is Coolors which gives you seemingly endless options.

Over time, you'll develop your own preferences and learn to recognise which colours just look right together.

Don't be afraid to explore depth.

The feud between flat design and material design rages on in designer corners. If you aren't aware of the difference between the two, first of all, I don't blame you. Essentially, flat design (used most famously by Apple) makes a conscious decision to avoid 3D rendering. Things like such as gradients, drop shadows or textures aren't Apple's style. Material design on the other hand, makes interaction a little more obvious, with edges, shadows, and seams that seem more tangible, mimicking non-digital products.

The difference that this makes to user experience design might seem minimal, but there's an important point to be made here:

Flat design is great for users who are highly attuned to digital interaction, while material has more of a reactive response to a user’s action. Material design brings the design a step further in its ability to communicate. (Source)

While it may be tempting to default straight to flat design (it's easier to do and faster to load, after all), consider who your user is before you jump in.

Material design was invented with the intent to represent the expected response to a user’s action. Therefore, it's more intuitive for users who aren't as attuned to digital devices. A small box-shadow, for instance, is an easy way to draw someone's attention to a button.

If you're new to CSS, things like gradients and box-shadows can be a little tricky to get your head around. But current popular 'semi-flat' design styles might be the better choice for your user, depending on your product. So it could be worth taking the time to look at Google's Material Design documentation to understand it a little better. That way you can make the right choice for your users.

Research often and learn from others

The world of design is ever-changing. If you can, spend some time every month doing some research on what's out there on Codepen, Dribble, and in individual designer portfolios.

Before we go any further, I'd like to take a second to say I really don't advocate the theft of designs.

But there is something to looking at what others have done before you and taking inspiration from it. If something's good, why break it? Well created designs often aren't totally unique. If Material Design works for your project, use it. It doesn't matter that plenty of other apps use it: it's a foolproof way to get a design out quickly.

My favourite way to start a project is to take a look at what's already out there in a similar field. This helps understand the general conventions of particular websites and apps (which helps ensure a better user experience), but it also might give you some good UI ideas.

If you like the look of something on a site, open the dev tools and see how they implemented a design trick. If you want to learn more about the ethos behind a site's design, get in contact with the developer or designer who produced it! Keep in mind that if you borrow something directly from another developer, you must credit them. But if it's a widely-used animation or a font you're after, make a note of it for later use. Put your own twist on it, and people will soon be looking at your projects for inspiration.

On that note, don't forget to steal from yourself! There will be parts of every project you like. Look back through your code and reuse/recycle them.

Share your tips and tricks in the comments.

I'd love to hear what your foolproof tricks and resources are. What have you picked up throughout your career? Share below!