6 Unexpected Mistakes That Keep Developers from Getting a Raise

Getting a raise

Good performance is never enough.

Imagine working hard. You have an “above average” track record. You’ve never heard complaints — you even won the coveted “best employee” award last month.

So, your company decides to reward you by…

Demoting you.

Sounds bizarre and untrue, doesn’t it? Who’d be thick enough to punish an employee for doing a great job?

Doing a Great Job Isn’t Enough

AntarcticGorillas, a StackExchange user, shared the story above. He was genuinely frustrated because he did everything he was supposed to do, but ended up getting demoted instead.

Another StackExchange user dishes out some advice.

“Wow sounds like you failed to play the office politics game effectively. Good performance is never enough. You don’t play the game and you lose, 100% of the time if you are in management.”

He takes his bad advice even further.

“Ok now you have to salvage what is left. First, and I know you are going to hate this one, you have to make friends with your new boss. You have to get him to mentor you. You have to help him and not show your resentment. Yeah I know you resent him, you wouldn’t be human if you didn’t. But this is the time to take the high road. This guy clearly has the office politics down pat, you need to learn from him.”

His advice is partially true. Good performance isn’t enough. It’s the baseline.

His advice to lie and manipulate? That stinks. But it isn’t the worst part. It’s the belief behind it.

I’m a _ Worker, I Deserve a Raise

As employees, we have the tendency to think we “deserve” it.

Developers do a great job. Most of us do everything we’re supposed to do. Still, many are disappointed with the money they’re making.

We know that many employers do their best to underpay. They walk a fine line, giving just enough to keep us on board, without affecting the profit margins they want.

It seems like your boss takes advantage of you.

You’re working your hands to the bone. You’re doing everything you’re asked to do and more. When your company’s in a bind, you deliver. Last minute updates? You get things done. Issues with scope creep? You handle it masterfully.

When you don’t get the raise you deserve, it feels like an insult.

More often than not, the issue has less to do with your work performance and more to do with the intangible details. Behaviors and counterproductive decisions that alienate allies, partners and opportunities. These mistakes make it harder to get the raise we’re hoping for.

Social conditioning leads many to ignore this stuff. “Ugh! Soft skills,” you might say. But these unexpected, common mistakes impact raises every day.

Mistake #1: What I Deserve vs What I Want

There’s a growing problem that’s slowly eroding good will in the developer community.


Open source entitlement is a great example. It goes like this:

  1. Developer needs code to solve a problem
  2. Developer finds open source code. It solves the problem
  3. Code creates problems
  4. Developer becomes angry, demands authors fix now. (For free!)

It’s an oversimplification but it conveys the point. These open source authors aren’t at our beck and call. It’s a terrible idea to demand extensive tech support, then write angry letters when we don’t get our way.

Mattias Petter Johansson over at FunFunFunction dives deeper into “developer entitlement.”

When we feel entitled, we overestimate our abilities and our contributions. We swallow the lie our ego feeds us. “You deserve this. You’re a senior developer after all.” Developers with this mindset are bargaining on the wrong side of the tracks.

Here’s how your boss thinks about raises.

“Holy crap, this is the guy that 10x’d our leads and sales in 18 months. The app he developed turned things around for us. We’re going to need to spend more if we want to keep this guy.”

See the difference?

They’re not operating from an entitled mindset. They’re approaching your raise from a transactional mindset, namely…

What am I getting for my money?

We’re not entitled to a raise. We’re not entitled to a promotion. Yet developers continue to approach salaries and promotions from an entitled mindset. I did a good job this year so, you “owe me.”

They usually make their approach like this.

Which is the part where managers give their blunt and unsatisfying answer.


Mistake #2: Being Right vs Being Respectful

Justin Keller, entrepreneur, developer and founder of San Francisco startup Commando.io wrote an open letter to the mayor. He was upset about the homeless in his community.

He didn’t want to see them on his way to work.

“The wealthy working people have earned their right to live in the city. They went out, got an education, work hard, and earned it. I shouldn’t have to worry about being accosted. I shouldn’t have to see the pain, struggle, and despair of homeless people to and from my way to work every day. I want my parents when they visit to have a great experience, and enjoy this special place.”

Maybe he didn’t mean to convey feelings of contempt and condescension. But, his words were still hurtful and disrespectful.

He had a point.

No one wants to live in a neighborhood filled with homeless people. Homeless people don’t want to live the way they do. We’re human, it’s normal to dislike these things.

Those who can avoid it, do so. Those who can’t, endure it.

The general thrust of his argument is this: He doesn’t want to deal with the problems that homeless people bring. Okay. But that’s not really the problem here.

It’s the othering of a group or type of people he views as beneath him.

That’s the problem.

Developers struggle with the very same issue. As a developer, you’re typically sure about your views. You’re logical and precise. You’re right and you know it, which is part of the problem.

You have a choice to make.

  • Be right. You can show everyone that you are, in fact, correct. That your way is right. This comes at a steep price if it’s handled poorly.
  • Protect the relationship. You can treat others with respect, avoid humiliating them and allow them to save face when they’re wrong.

Developers who focus on being “right” tend to be disrespectful. They burn allies and earn enemies.

Developers who focus on relationships first, discover their influence grows with those around them. They’re viewed as trustworthy, and more people listen when they have something to say. Being right is easy when everyone values your feedback.

Getting that raise or promotion is tough if you’re viewed as a snobby, know-it-all jerk.

Mistake #3: My Career vs My Loyalty

Google has been at the top of Fortune magazine’s list of best companies to work for every year since 2007. The job perks are legendary. For many, a spot at Google is a dream come true.

So why is Google struggling to keep its employees?

A recent report by PayScale states the median employee tenure at Google is a little over one year. Its workforce has grown, but it’s struggling to keep its people.

It’s not because Googlers are unhappy.

84 percent of their 28,500 employees state they have a high level of job satisfaction which, as you’d expect, is one of the highest among the Fortune 500.

Other tech firms aren’t having the same problem. The average tenure at Yahoo! and Microsoft is 2.4 and 4 years respectively.


The problem is loyalty. Loyalty is quickly becoming a thing of the past.

It’s not entirely our fault; We’re given bad advice. The strategy is:”Don’t ask for a raise, get a new job instead.”

It’s a destructive strategy that results in less trust. Employers limit the responsibility they give you because they believe you won’t be here that long anyway…

Work has become this cutthroat environment where we all pretend to look out for the team, when in reality, we’re looking out for ourselves.

If you’re a sophisticated developer, you know.

At many companies, project managers and other developers are all too eager to throw each other under the bus for more money. When an opportunity comes along, these employees will eat each other for the chance to win.

Jumping from job to job only works for so long. Disloyalty catches up with you as your market value drops. There’s no reason an employer should go out of their way to keep a disloyal developer.

Here’s what loyalty looks like to them.

Continue reading %6 Unexpected Mistakes That Keep Developers from Getting a Raise%

Source: Sitepoint

6 Tools to Stop Your Devs and Designers Strangling Each Other

If you’ve been working in product development, web development, web design or most other areas where designers and developer work together, you’ve probably seen or heard at least one of the following (or something similar to it):

From the designers:

“We came up with a really beautiful design, but the developers really mucked things up. It’s nowhere near what we designed.”

“How can we create a beautiful design if the developers will just screw it up?”

And from the developers:

“This design is impossible to replicate in HTML/CSS, this is as close as we can get.”

“Designing in Photoshop is easy, you don’t have any limitations imposed by code. We can’t fit this design into the development framework we are using”

Although you’ll frequently hear comments such as the above, in my eyes, they’re stemming from two main problems

  1. A lack of good tools / communication frameworks in place leading to …
  2. …a serious breakdown of communication between the designers and developers

In reality, designers and developers are very different from each other. Designers are right-brained, developers are left-brained. Those who think creatively need to establish a way to communicate correctly with those who think rationally / logically.

Right brain vs Left brain

A way which works well for both.

The communication problem is made that much harder in today’s environments, where remote working, different geographies, cultures, and languages, different timezones are all business-as-usual.

Having designers in one country and developers in another is the order of the day.

But designers and developers need each other. They need to communicate well if you want to create a good end product.

Start dating before living together

So, let’s think of the developer-designer as a relationship.

Partners in a relationship need to understand what works (and what doesn’t) for both of them before they can make more serious commitments.

The key to a good end-result: developers and designers need to start working together from the get-go.

Simply put, if a designer creates a design without the involvement of a developer, they’re bound to have to go back to the drawing board often and get frustrated that their work as been ‘destroyed by the developer”.

If a developer is given a design which they had no involvement in, they’re going to say that this design is impossible to implement and will have a hard time achieving the required end-result.

To create a design that works the developer should be present during the design brief to make sure that things are designed to an appropriate developer specification.

The following questions (and no doubt others) need to be figured out during the design brief and require input from both the developer and the designer.

  1. What responsive framework (grid) system will be used to implement the design?
  2. Are there any design elements which cannot be implemented using the selected framework?
  3. Which elements can afford to be hidden at smaller screen sizes and what will that look like?
  4. What text styles and fonts sizings are to be used?
  5. Create actual videos or specifications of micro-animations to be used.
  6. What imagery will be used and what kind of cropping will happen on smaller screens?

This is an exercise which needs to be done internally by your team. Figure out where you communication breakdowns are happening and then develop a set of questions which need to be fully specced (from the designer to the developer).

In essence, your designers and developer need to ‘date” such that they both understand each other, before actually committing to a design which needs to be developed.

As the design is being created, the developers should get involved frequently, such that potential development problems are identified early and resolved during the actual design.

Now that we’ve defined the theory, let’s actually show you the tools we actually use to improve our communications between designers and developers.

How to get designers and developers to start working together

1. Use a constant communication process

Continuing with the need to have constant communication, you should implement SCRUM or another agile methodology.

Agile methodologies like Scrum emphasise the need for constant communication. All stakeholders agree on what is going to be built and they meet regularly to ensure everything is being developed to specifications.

We’re not going to recommend or go deeply into the methodology to use, but, one thing is surely necessary.

Develop a process of constant communication.

For example, in Scrum, you have Daily Scrum 10 minute meetings which are meant to show the progress of the previous day and set a path for the current day. Any issues will be identified immediately and resolved separately from the daily meeting.

The Sprint Review – usually when a sprint is complete is a milestone – where both the developer and designer can actually see that progress on the design/development is according to the original vision.

By having both the designers and developers in constant communication, problems are identified and resolved quickly, before they get out of hand.

2. Use a good mockup tool

While PSDs are going to be necessary for the development, you won’t be needing pixel-perfect designs for each and every screen in your project.

When the basic designs have been developed in Photoshop, you can then hurry things along with a good mockup tool.

Now, let’s make one thing clear, mockup tools may be used by designers, but they’re more likely to be used by your UX guys and developers. The favorite tool of choice for designers is an actual design tool, not a mockup tool.

Your mockup tool should be used as a bridge, between the people designing the requirements, the developers and the designers.

One thing to keep in mind – let everybody use their own favorite tool, don’t force anything down anybody’s throat.

Let the designers use their favorite design tool, Photoshop or whatever they prefer. Let the UX designers, the product managers, the business analysts use their favorite tool (typically a mockup tool). And then let the developers do their thing with whatever they want.

As long as there is a good line of communication, the tool they use is not very important.


Mockup of a one page application

Mockup of a one page application

There are plenty of good tools out there, but the one we absolutely favor by far is Balsamiq.

Balsamiq has a full library of components and design elements which can be used to quickly create screens which need to be sent to the developers for implementation.

Balsamiq is available both as a desktop application for Mac or Windows and a cloud-based service.


UXPin screen shot

Mocking up a mobile design in UXPin

If you’re looking for a cloud-based service which is pretty much good for mocking up any design, UXPin has all of your bases covered.

Again, based on a comprehensive library of elements, you can web designs, Android or iOS apps, Bootstrap based screens, Material Designs, interactive UIs or micro-animations. It’s as comprehensive a tool as it can get.


Moqups used for developing mobile app mockups

Moqups used for developing mobile app mockups

Whilst my preference is still with Balsamiq because, honestly, I like my mockups be just that – mockups, rather than near pixel-perfect designs, Moqups is another great wireframe tool.

With Moqups, you can create very high-fidelity mockups. Using the extensive libraries available within the tool, just like UXPin, you can go into quite a lot of detail into the design of your actual mockups.

3. Manage your project + tasks

Once your designers, developers and all the stakeholders have agreed on a way forward, it’s time to actually start doing the work. When your start the actual job, job management software is great for quoting, time-tracking, billing and all the essentials of tracking your job.

Besides the actual job management (the easy part), you need to manage your project and the work which needs to be done.

It’s during the actual project work where the problems often start to crop up, so there another few things which are critical to the success of a project.

First of all, each project must be broken into its parts and each step must be monitored for completion.

Secondly, your management tool of choice must be a single point of contact.

The biggest headache you can get is having ‘decisions” spread over multiple means of communication, email, Slack, your project management tool, face-to-face communication, phone calls. Always make sure that decisions taken anywhere all eventually end up in noted ‘in writing” on your project management tool.

Project Management Tools: Asana, Basecamp, and Trello

The most popular project management tools

Ok, so rather than waste your time going through all of the most popular project management tools out there, I’ve bundled them all up into a single paragraph. Diving deeply into any of these specific tools has been done to death, so we’ll leave this up to you to decide which tool is best for you.

All of the above tools have their strengths and drawbacks – it’s a question of choice.

I’ve used all of them to varying degrees and all of them work well as long as you apply them well to the problem at hand.

Continue reading %6 Tools to Stop Your Devs and Designers Strangling Each Other%

Source: Sitepoint

Moving From Photoshop And Illustrator To Sketch: A Few Tips For UI Designers



I’ve been a long time Photoshop and Illustrator user. Both programs are really useful and powerful, and they’ll remain a key part of any digital artist’s or designer’s toolset, including mine. However, for all user interface, web and icon design workflows, I recently converted to Sketch. Here is why.

Moving From Photoshop And Illustrator To Sketch: A Few Tips For UI Designers

While Photoshop is awesome at what it does, defining what it is might not be so easy anymore. I remember watching a storyboarding tutorial by Massive Black’s El Coro (unfortunately, it doesn’t seem to be available for sale anymore). In it, he says that 17 or so years ago, Adobe had no idea that digital artists were using Photoshop to digitally paint pictures! So, it had to catch up with its own user base by adding more — you guessed it — painting features.

The post Moving From Photoshop And Illustrator To Sketch: A Few Tips For UI Designers appeared first on Smashing Magazine.

Source: Smashing Magazine

Editorial: Is Smartphone Addiction a Problem for Developers?

Is smartphone addiction a good thing for developers?

You know the directive: ” make great apps that users love. “

And what’s the sign that a user _loves_ your app? They use it _frequently_. Frequent relations with your app are a sign of commitment, and commitment is a sign of love. But how does this scale?

As it turns out, a recent report has found that a third of British children are not able to achieve a good balance between screen time and their other activities. Elsewhere in the world, “smartphone rehab” centres (yes, really) are opening up to offer recovery programs for people whose use of electronic devices is excessive. In other, cruder, words, they are smartphone addicts.

A smartphone dependency might not be as flagrant as you’d think. It’s a dependency when it prevents you from adequately engaging in other activities. Consider the simple activity of having a dinner with friends or family. If you see a smartphone placed on top of the dinner table, with attention automatically diverted to it whenever its screen periodically flashes up, then its owner is not fully engaging with the rest of the diners. They are in two places at the same time.

Continue reading %Editorial: Is Smartphone Addiction a Problem for Developers?%

Source: Sitepoint

7 Deep Work Tips That Will Dramatically Boost Your Productivity

Deep work

Being busy is more often than not a trap — an illusory euphemism for poor time management. By doing deep work you’ll get rid of distractions, gain more focus, get more things done and, unexpectedly, have more time for other things.

Take Cal Newport, the author of Deep Work: Rules for Focused Success in a Distracted World — in just a few years he earned a PhD from MIT, published 4 books and lots of academic papers, all while leaving the office by 5:30PM and rarely working on weekends. Oh, and he’s also a professor at Georgetown University, married, and a father of two.

In a more familiar example, I’m a musician, software developer, entrepreneur, and — as of recently — a contributor to online publications (and I’m sure I’m not a multidisciplinary exception among SitePoint readers). I love pursuing all of my goals while learning something new (like a language or a dance), and exercising. I’ve found that I’ve never made more productive use of my time than since I adopted deep work practices.

What is Deep Work Anyway?

Cal, who coined the term, puts it this way:

Deep Work: Professional activities performed in a state of distraction-free concentration that push your cognitive capabilities to their limit. These efforts create new value, improve your skills, and are hard to replicate.

Cal also defines the counter-side of deep work — shallow work:

Shallow work: Non-cognitively demanding, logistical-style tasks, often performed while distracted. These efforts tend to not create new value in the world and are easy to replicate.

While staying focused and doing deep work, you’ll find that you multiply your output by 2X, 4X, or even more, every day or week. You’ll also feel happier and more accomplished.

Whether you are figuring out the business plan for your startup, doing some programming, or writing content, deep work is a valuable, rare and meaningful asset that will enable you to produce more of what actually makes your business, program, or publishing shine. You get all of this while cutting the clutter and freeing more time for other matters.

So let’s get to it!

1. Schedule Your Entire Week Ahead

This may seem daunting at first, but you’ll get better at it with practice. You’ll see that trying to plan the whole week will force you to actually think and define in detail what it is that you need to do. Also, while you put these tasks in your calendar, you’ll need to allocate time for them, also forcing you to be realistic.

Doing this is critically important as you don’t want to be wandering through every workday, thinking about what you have to do and making decisions all the time — just check your schedule for today, and execute.

Again, it doesn’t need to be perfect. You’ll get better at it. Since this is a big one, let’s expand a little:

Define Tasks the Right Way

Ask yourself: if I get one thing done this day and feel satisfied, what would that be? Yes, that “one thing” is deep work, and you’ll be amazingly productive if you can get one of those tasks done every day (just like the Seinfeld Strategy).

Be specific. “Write article” or “program app” won’t do it. You’ll have to think in terms of actionable sub-tasks. For writing an article, that could be:

  1. Write an outline
  2. Write the draft
  3. Proof-read and edit

For a program, this can vary wildly, but one possible course of action may be:

  1. Define scope and pick a component
  2. Research and reference documentation
  3. Code
  4. Test, debug, and refactor
  5. Document
  6. Repeat

Be small. Small tasks are more actionable and less intimidating than big ones. While “1 hour of workout” is specific enough, you could end up exhausted and discouraged if you’re not used to that level of exertion. Two different blocks of “30 minutes of exercise” could be more approachable (besides, it turns out that even just 30 minutes of daily exercise does the trick). While planning your week, go through this mental process: am I intimidated by this? If the answer is yes, try breaking it into smaller, more actionable sub-tasks.

At the Beginning of the Workweek

Brainstorm the current state of your project. Take a moment to think about what you want to accomplish, and try to deconstruct or reverse-engineer the process so that you can see what its components are.

Review “for later” tasks. You might have a mix of deep and shallow tasks that you’ve been leaving for later. Review them all and see if they fit somewhere in the week.

Leave some room. I normally schedule about 75% of my work week. This makes it possible for me to move things around and handle unexpected events.

You could schedule every minute, and that would be incredibly productive if you’re good at it. For most, this isn’t realistic — go easy on the scheduling at first.

At the End of the Workweek

Ask yourself (and be sincere): am I labeling shallow work as deep just to feel more accomplished?

Evaluate. Did it go well? Did you over-estimate or under-estimate time assignments? Keep all of this in mind for next week.

Shut down. You’re done. Close all of your browser tabs, apps, and everything work-related. See you next week.

2. Don’t Multitask

Multi-tasking is a myth. As I mentioned in one of my articles, changing from one task to another not only has a cost in time, but more importantly, it comes at a very high cognitive expense. That is, it makes you less productive because you let your limited focus and mental power drain as you switch from one task to another. See these articles for more info about this:

Do one thing, and one thing only. Don’t attempt to write a report while talking to your peers, or code PHP routines while checking the news. It’ll easily take you double the time.

In fact, unless it’s your actual job, don’t surf the web. This has been happening to me a lot — I’m coding something and some random thought crosses my mind, and I just take a minute to check it on the Internet. Or I take a little break and go check the news for five minutes… don’t do it.

One day I was working in a tiny room with no TV, no phone (more on this later), and no Internet. Since I had my computer I decided to focus on tasks I didn’t need the Internet for, and I had my most productive day in years.

I hear what you’re saying — “if I don’t check this right now, I’ll forget about it!” Fair enough, make a “for later” note on a piece of paper and put your focus back on what you were doing.

3. Ritualize

The more you can go on auto-pilot for the mundane tasks (cooking, eating, hygiene, relaxing, choosing what to do next), the more focus you’ll be able to maintain.

Something you can use the Internet for: search for “morning rituals”, read a couple of articles to see if one routine makes sense to you. Put it in practice and you’ll see how it pays off after a week or so.

Extra tip: don’t do email first thing in the morning. Your brain is at its best after a coffee and a shower, and you want to save this very valuable state for things that actually require this capacity. With some exceptions, replying to email isn’t the most mentally demanding task, so leave it for later.

4. Take Breaks from Focus, Not from Distractions

With YouTube, instant notifications, podcasts, and more, we live in a distracted world. If you want to gain more focus to get more done, there will have to be a change of paradigm in your life. You’ll need to make deep work the most important part of your activities, with breaks scheduled around it rather than through it.

Continue reading %7 Deep Work Tips That Will Dramatically Boost Your Productivity%

Source: Sitepoint

How to Organize a Large React Application and Make It Scale

This article is by guest author Jack Franklin. SitePoint guest posts aim to bring you engaging content from prominent writers and speakers of the Web community

In this article, I’ll discuss the approach I take when building and structuring large React applications. One of the best features of React is how it gets out of your way and is anything but descriptive when it comes to file structure. Therefore you’ll find a lot of questions on StackOverflow and similar asking how to structure applications. This is a very opinionated topic, and there’s no one right way. In this article, I’ll talk you through the decisions I make when building React applications: picking tools, structuring files, and breaking components up into smaller pieces.

Build Tools and Linting

It will be no surprise to some of you that I’m a huge fan of Webpack for building my projects. Whilst it is a complicated tool, the great work put by the team into version 2 and the new documentation site make it much easier. Once you get into Webpack and have the concepts in your head you really have incredible power to harness. I use Babel to compile my code, including React-specific transforms like JSX, and the webpack-dev-server to serve my site locally. I’ve not personally found that hot reloading gives me that much benefit, so I’m more than happy with webpack-dev-server and its automatic refreshing of the page.

I also use the ES2015 module syntax (which is transpiled through Babel) to import and export dependencies. This syntax has been around for a while now and although Webpack can support CommonJS (aka, Node style imports), it makes sense to me to start using the latest and greatest. Additionally, Webpack can remove dead code from bundles using ES2015 modules which, whilst not perfect, is a very handy feature to have, and one that will become more beneficial as the community moves towards publishing code to npm in ES2015.

Configure Webpack’s modules resolution to avoid nested imports

One thing that can be frustrating when working on large projects with a nested file structure is figuring out the relative paths between files. You’ll find that you end up with a lot of code that looks like this:

import foo from './foo'
import bar from '../../../bar'
import baz from '../../lib/baz'

When you’re building your app with Webpack you can tell Webpack to always look in a specific directory for a file if it can’t find it, which lets you define a base folder that all your imports can become relative to. I always put my code in a src directory. I can tell Webpack to always look in that directory. This is also where you need to tell Webpack about any other file extensions that you might be using, such as .jsx:

// inside Webpack config object
  resolve: {
    modules: ['node_modules', 'src'],
    extensions: ['.js', '.jsx'],

The default value for resolve.modules is ['node_modules'], so you have to add it too else Webpack won’t be able to import files that you’ve installed with npm or yarn.

Once you’ve done that you can always import files relative to the src directory:

import foo from './foo'
import bar from 'app/bar' // => src/app/bar
import baz from 'an/example/import' // => src/an/example/import

Whilst this does tie your application code to Webpack, I think it’s a worthwhile trade-off because it makes your code much easier to follow and imports much easier to add, so this is a step I’ll take with all new projects.

Folder Structure

There is no one correct folder structure for all React applications – as with the rest of this article, you should alter it for your preferences – but the following is what’s worked well for me.

Code lives in src

To keep things organized I’ll place all application code in a folder called src. This contains only code that ends up in your final bundle, and nothing more. This is useful because you can tell Babel (or any other tool that acts on your app code) to just look in one directory and make sure that it doesn’t process any code it doesn’t need to. Other code, such as Webpack config files, lives in a suitably named folder. For example, my top level folder structure often contains:

- src => app code here
- webpack => webpack configs
- scripts => any build scripts
- tests => any test specific code (API mocks, etc)

Typically the only files that will be at the top level are index.html, package.json, and any dotfiles, such as .babelrc. Some prefer to include Babel configuration in package.json, but I find those files can get large on bigger projects with many dependencies, so I like to use .eslintrc, .babelrc, and so on.

By keeping your app code in src, you can also use the resolve.modules trick I mentioned earlier which simplifies all imports.

React Components

Once you’ve got a src folder, the tricky bit is deciding how to structure your components. In the past, I’d put all components in one large folder, such as src/components, but I’ve found that on larger projects this gets overwhelming very quickly.

A common trend is to have folders for “smart” and “dumb” components (also known as container and presentational components), but personally I’ve never found explicit folders work for me. Whilst I do have components that loosely categorize into “smart” and “dumb” (I’ll talk more on that below), I don’t have specific folders for each of them.

We’ve grouped components based on the areas of the application that they are used, along with a core folder for common components that are used throughout (buttons, headers, footers – components that are generic and very reusable). The rest of the folders map to a specific area of the application. For example, we have a folder called cart that contains all components relating to the shopping cart view, and a folder called listings that contains code for listing things users can buy on a page.

Categorizing into folders also means you can avoid prefixing components with the area of the app that they are used for. As an example, if we had a component that renders the user’s cart total cost, rather than call it CartTotal I might prefer to use Total because I’m importing it from the cart folder:

import Total from 'src/cart/total'
// vs
import CartTotal from 'src/cart/cart-total'

Continue reading %How to Organize a Large React Application and Make It Scale%

Source: Sitepoint

The Ultimate CSS Survey 2017

CSS Survey 2017

Last year SitePoint released The Ultimate CSS Survey, the first of what we hope to be an annual event to help us and the community understand the habits and practices of modern CSS developers.

The 2017 version of the survey is ready, and you can fill it out now. Or read on for more info on the survey and how it differs from last year’s.

What’s Covered in the Survey?

For those who didn’t take part last year, here’s a quick summary of some of the things the survey covers:

  • CSS coding practices and preferences
  • Use of CSS-related tools
  • Use of popular frameworks
  • Code maintenance habits
  • Learning habits

As you can see, the survey seeks to gain an understanding of CSS developers from the learning steps right down to code maintenance and habits on big projects.

Continue reading %The Ultimate CSS Survey 2017%

Source: Sitepoint

Let The Content Delivery Network Optimize Your Images



Sometimes you have to step back and ask why a tradition exists. In mobile-first design, serving an image in three sizes — one for smartphones, one for tablets and one for desktops — using media queries and responsive images has become a tradition. But is it the best solution?

Let The Content Delivery Network Optimize Your Images

It’s most likely better than doing nothing, but how well does it actually work? And is there room for improvement? In this article, we’ll look closely at how well the one-size-per-form-factor approach really works and how we can use smart content delivery networks to improve image performance.

The post Let The Content Delivery Network Optimize Your Images appeared first on Smashing Magazine.

Source: Smashing Magazine