6 Red Flags That Signal the End of Your Career

Bob is the best developer at work.

His code is pristine. It's well written, and done quickly — he's incredibly consistent. He's a model employee, routinely praised by HR as "the best developer in the building." He's quiet and unassuming, described as "someone you wouldn't look at twice in an elevator."

And he's about to be fired.

His employers were hacked, or at least that's what they thought. They saw an incredibly large amount of network activity from China. Fearing the worst, they contacted Verizon to investigate.

What they found stopped them in their tracks.

Bob, a senior developer making six figures, was outsourcing his work. Bob wasn't particularly interested in working. So he decided to pay developers in China $50,000 to do his job for him, spending the rest of the day on Reddit, eBay and YouTube.

At the end of his workday he'd send out an "end of day update" to management, then go home.

Bob's Career is Effectively Over...

As it should be. He was exposed via the invoices for his Chinese subcontractors and his web history. His habits created serious red flags so, naturally, he was fired for his deception.

Most developers won't make the same mistakes Bob did. Most developers are hardworking professionals who take great pride in their work. That's the good news: there's still a level of respect that developers have for themselves and those around them.

The bad news? Many developers are still making serious mistakes.

These mistakes create red flags; the kind of red flags that tell your employer, your co-workers, that your career is over. These mistakes aren't instant career enders. They create disaster slowly. Ignore these red flags long enough and they'll end your career.

The End of a Career is Tough to Predict...

Because the end can come at any time; I'm not talking about the serious mistakes that can get you fired. I'm not talking about layoffs, insider politics or the circumstances that are out of your control.

I'm talking about the mistakes that slowly destroy your career.

The mistakes I'm talking about are built on the back of all the good things you've done. You do something great and it goes bad; you create something positive then it's poisoned.

The frustrating part about each of these red flags is the fact that they're unexpected, they live in our blind spots.

What's worse, the end of your career can be triggered by different things.

1. A better employee comes along. If you're making mistakes and an all-star employee offers to fix problems you've created, you've triggered a career ender.
2. You make a bigger mistake. A mistake that leads people down a path of destruction and loss. When people lose money, influence, friends, security, etc. they hold someone responsible. Make the right mistakes and that person is you.
3. People stop caring. Make mistakes and people give you a pass, at first. Keep making them and they get angry. Make them long enough and you create apathy. People tell themselves "I'm done, I'm moving on."

These aren't the only triggers. What's worse, a combination of these triggers and red flags actually accelerates the end of your career.

Which red flags am I talking about?

Red Flag #1: Believing Mastery is Transferrable

Celebrities are famous for a reason. They're able to find success doing what they do best. The best ones are exceptional — they're able to command the success, respect and financial rewards they want. But almost inevitably, they start believing their own hype.

They believe mastery in one area is transferrable to another.

How do I know?

They tell us. David Hasslehoff started a fashion line, which failed in less than a year.

So did Lindsay Lohan, Lil Wayne, Miley Cyrus — you get the point.

These celebrities weren't willing to pay the price of success. But here's the thing. Developers struggle with this problem too.

"That's ridiculous, Andrew."

Is it?

How many times have you seen a brilliant developer who's skilled in one language (e.g. Python) decide they're going to learn a new one? Then, after a month or two of work, the very same developer believes they're suddenly a master of their new language?

Here's the truth.

Mastery is not transferrable.

You can reduce the learning curve dramatically. You can learn anything quickly, moving yourself to the top 10 list in many industries. But competence isn't the same thing as mastery and mastery is not transferrable.

Making this assumption leads believers to take unnecessary risks.

• Believing that your skill with one IDE will automatically transfer to another
• Demanding that your team take on something new, expensive or unfamiliar, simply because you feel it'll be easy
• Telling your boss or a client you can do the job because you've done something "similar" in the past
• Recommending Nginx because you're familiar with Apache and, "how hard can it be?"

Remember those triggers I mentioned earlier? Yeah... Make enough of those mistakes, push the right triggers and your career is over.

Red Flag #2: Ignoring the Success Half-life

Success has a shelf life.

Contrary to popular belief, success doesn't last forever. People forget, lose interest, stop believing. But why?

Doing great work creates conflict. Remember how I said these problems hide in your blind spots? This is what I'm talking about. When you do anything good, anything at all that's helpful, positive, good, supportive, etc. It creates a conflict.

Here's why.

Receivers depreciate, Givers appreciate.

When people give something to others, the value of their gift goes up. Not in reality, of course but in their heads. When you hear people say:

"I gave you X, and this is how you repay me?"

or

"Look at all I did for you!"

You know you're dealing with appreciation. The value of their gift or good deed has gone up. They expect you to be grateful. No, more than grateful. They expect you to be indebted to them. To sing their praises, and offer recognition for their gift.

Receivers, on the other hand, move in the opposite direction. The value of the gift they've received from you goes down. If they feel indebted to you, it's common for people to have a desire to reciprocate, to satisfy their debt. If the debt is too high they may become resentful, bitter or angry.

Do something good and the countdown starts.

Developers, by definition, are givers. If you're good at your job you're a giver. That makes your - boss, manager, employer - a receiver. In the near future, they're going to forget about what you did.

Here's the problem.

If you're not aware of success half-life, you're going to feel hurt when your awesome work is forgotten. This also means your boss is far more likely to forget your work. Coast on your past success and you're both headed to an unhappy place where you feel unappreciated and unrewarded, and your boss feels neglected, believing you're an entitled jerk.

See how this blind spot ruins careers?

Red Flag #3: Measuring Success the Wrong Way

Are you successful at your job? Some developers respond with an enthusiastic Yes! And there's the problem. What would your boss say? Would he agree with your assessment? Or, would he feel that you weren't working hard enough?

This is how the disagreement starts.

You know you've done an amazing job. You can list all of the things you've accomplished. As far as employees go, you're successful.

Does your boss know that?

What were they looking for when they hired you? Did they outline the business or political reason behind their decisions to bring you on?

No?

If you haven't accomplished the goal they had in mind are you successful? See the problem?

The way you define success isn't necessarily the way your boss would define it. Here's the reality of things:

Your boss, manager, client - has high level goals of their own. You have your own goals. Both of you use your goals to measure success, but, if you're like most people, neither of you share these details with the other.

Do that long enough and eventually, your career will come to an end.

Red Flag #4: Using Idealism to Resist Change

These developers are idealists who believe things should be done a certain way. They push for what they consider to be the ideal. When these developers get what they want they're at peace. Life is as it should be.

Continue reading %6 Red Flags That Signal the End of Your Career%

by Andrew McDermott via SitePoint

10 Node.js Best Practices: Enlightenment from the Node Gurus

In my previous article 10 Tips to Become a Better Node Developer I introduced 10 Node.js best practices you could apply to your code today. This post continues in that vein with a further 10 best practices to help you take your Node skills to the next level. This is what we're going to cover:

1. Use npm scripts — Stop writing bash scripts when you can organize them better with npm scripts and Node. E.g., npm run build, start and test. npm scripts are like the single source of truth when Node developers look at a new project.
2. Use env vars — Utilize process.env.NODE_ENV by setting it to development, or production. Some frameworks will use this variable too, so play by the convention.
3. Understand the event loop — setImmediate() is not immediate while nextTick() is not next. Use setImmediate() or setTimeout() to offload CPU-intensive tasks to the next event loop cycle.
4. Use functional inheritance — Avoid getting into mindless debates and a brain-draining trap of debugging and understanding prototypal inheritance or classes by just using functional inheritance like some of the most prolific Node contributors do.
5. Name things appropriately — Give meaningful names which will serve as a documentation. Also, please no uppercase filenames, use a dash if needed. Uppercase in filenames not just look strange but can cause cross-platform issues.
6. Consider using CoffeeScript — ES6/7 is pathetic addition which was born out of 6 years of meetings when we already had a better JavaScript called CoffeeScript. Use it if you want ship code faster and stop wasting time debating var/const/let, semi-colons, class and other arguments.
7. Provide native code — When using transpilers, commit native JS code (result of the builds) so your projects can run without the builds
8. Use gzip — Duh! npm i compression -S and sane logging — not too much not to little depending on the environment. npm i morgan -S
9. Scale up — Start thinking about clustering and having stateless services from day one of your Node development. Use pm2 or strongloop's cluster control
10. Cache requests — Get maximum juice out of your Node servers by hiding them behind a static file server such as nginx and/or request level cache like Varnish Cache and CDN caching.

So let's bisect and take a look at each one of them individually. Shall we?

Use npm Scripts

It's almost a standard now to create npm scripts for builds, tests, and most importantly to start the app. This is the first place Node developers look at when they encounter a new Node project. Some people (1, 2, 3, 4) have even ditched Grunt, Gulp and the likes for the more low-level but more dependable npm script. I can totally understand their argument. Considering that npm scripts have pre and post hooks, you can get to a very sophisticated level of automation:

"scripts": {
  "preinstall": "node prepare.js",
  "postintall": "node clean.js",
  "build": "webpack",
  "postbuild": "node index.js",
   "postversion": "npm publish"
}

Often times when developing for the front-end, you want to run two or more watch processes to re-build your code. For example, one for webpack and another for nodemon. You can do this with && since the first command won't release the prompt. However, there's a handy module called concurrently which can spawn multiple processes and run them at the same time.

Also, install dev command line tools such as webpack, nodemon, gulp, Mocha, etc. locally to avoid conflicts. You can point to ./node_modules/.bin/mocha for example or add this line to your bash/zsh profile (PATH!):

export PATH="./node_modules/.bin:$PATH"

Use Env Vars

Utilize environment variables even for the early stages of a project to ensure there's no leakage of sensitive info, and just to build the code properly from the beginning. Moreover, some libraries and frameworks (I know Express does it for sure) will pull in info like NODE_ENV to modify their behavior. Set it to production. Set your MONGO_URI and API_KEY values as well. You can create a shell file (e.g. start.sh) and add it to .gitignore:

NODE_ENV=production MONGO_URL=mongo://localhost:27017/accounts API_KEY=lolz nodemon index.js

Nodemon also has a config file where you can put your env vars (example):

{
  "env": {
    "NODE_ENV": "production",
    "MONGO_URL": "mongo://localhost:27017/accounts"
  }
}

Continue reading %10 Node.js Best Practices: Enlightenment from the Node Gurus%

by Azat Mardan via SitePoint

Responsive Parallax Drag-Slider With Transparent Letters

A tutorial about creating responsive drag slider with parallax effect and transparent letter effect by using javascript, css.

by via jQuery-Plugins.net RSS Feed

Java-Free Android

Android finds itself in interesting times. Google has begun creating it’s own ‘premium’ versions of the operating system (OS), Cyanogen have ceased development, and many feel that Android will change name or shape in the near future.

As the future of the OS remains uncertain, so does the language that developers use to develop for the platform. Traditionally developers have written apps for Android in Java, a language with a long established history and ecosystem, but that has always felt forced upon Android, lacking the most up to date features, and unwieldy for developers who come from different language backgrounds.

In this article I will round up some of the likely contenders and see how easy, realistic and plausible it will be for them to replace the Java behemoth. The added bonus for some of these languages, is that you can often use to also target other mobile platforms.

A long term solution for developers has been to use different techniques to turn JavaScript and HTML into pseudo applications. I wont include any of these hybrid options in this round up such as React Native, Cordova or NativeScript. I don’t want to begin flame wars on native vs hybrid app development, but in this article I am only interested in covering languages that could become ‘native’ code.

Google took an interesting decision when deciding that Java would be the programming language to create apps for Android. Whilst it’s portable and popular, it also restricts developers as there is no official support for using ‘native’ and more efficient languages such as C or C++.

Continue reading %Java-Free Android%

by Chris Ward via SitePoint

Laravel and Braintree, Sitting in a Tree…

Subscriptions to services online are something extremely common - from subscribing to music streaming services to tutorial sites to access premium content.

With Laravel 5, we saw the introduction of Laravel Cashier, an official Laravel package to help developers manage Stripe's and Braintree's subscription billing services without writing most of the boilerplate subscription billing code.

Stripe and Braintree are payment platforms that make it easy to accept payments in your app or website.

In this tutorial, we will be building a dummy Courses site with Braintree subscriptions. In the process, we will learn how to use the various methods offered by Cashier.

In the first part of this extensive two-part series, we are going to:

• Set up Laravel Cashier
• Sign up to the Braintree sandbox (For production apps we use the main Braintree service)
• Create plans on Braintree
• Create an artisan command to sync the online plans with our database
• Allow users to subscribe to a plan

In part two, we will:

• Add the ability to swap plans
• Create middleware to protect some routes based on the subscription status
• Protect premium courses from users with basic subscription
• Learn how to cancel and resume subscriptions
• Add Braintree notifications to a variety of the application's events via webhooks

The complete code for part one can be found here.

Creating the Application

We will start with a fresh Laravel installation.

composer create-project laravel/laravel lara-billable

Preparing the Database

Next, we have to set up the database before running any migrations. Let's use MySQL - it's easy to use, easy to configure, and included in a well-built development environment like Homestead Improved. After setting up the database, I have my .env file looking like this:

DB_HOST=localhost
DB_DATABASE=homestead
DB_USERNAME=homestead
DB_PASSWORD=secret

Scaffolding Auth

The next step is adding authentication to our application.

Continue reading %Laravel and Braintree, Sitting in a Tree…%

by Christopher Vundi via SitePoint

Build Native Apps in the Browser with Configure.IT

This article was sponsored by Configure.IT. Thank you for supporting the sponsors who make SitePoint possible. Creating a modern and feature-rich mobile app has never been a simple task, but is now more complex than ever. There are a plethora of platforms, programming languages and strategies to consider, and knowing where to start and what […]

Continue reading %Build Native Apps in the Browser with Configure.IT%

by Chris Ward via SitePoint

Scrum Rituals: Daily Standup

The following is an extract from our book, Scrum: Novice to Ninja, written by M. David Green. Copies are sold in stores worldwide, or you can buy it in ebook form here. Daily Standup The daily standup is probably the first ritual that comes to mind when people think of scrum. The daily standup provides […]

Continue reading %Scrum Rituals: Daily Standup%

by M. David Green via SitePoint