How to Work Remotely and Still Be the Best


Written by Irina Papuc Topics: Self Improvement 14898304299_ba230273d4_o

The Remote Worker’s Tool Belt

Starting a new remote or work from home gig, be it a contract project or a full-time job, can be a little intimidating if you’re used to going into an office day after day.

But this style of employment is growing in popularity, with some very notable companies lending it their endorsements.

I’ve successfully worked remotely using these tools for years now on projects of various scales and durations. With this post, I hope to enumerate some of the best practices that I’ve picked up for working in a variety of situations. The remote and work from home guide here ranges from specific recommendations for software and hardware, to tips for hitting your team’s deadlines.

The Remote or Home Office Setup

I can’t stress enough the importance of having the right office setup. It will both make you more productive and appear more professional. For example, a headset is crucial for avoiding echo during online calls; little things like this go a long way when working as a remote.

Here are some toolsfor working remotely that I consider essential within my own home office:

  • Headset. I really like wired headsets in particular because they don’t run out of battery at critical times. You’ll be wearing it a lot, so make sure you get something comfortable. I have two iMicro headsets: one for my desk and one that I pack in my laptop bag. As a laptop bag headset, it has two great qualities: because it’s USB powered, I don’t have to worry about keeping the batteries charged, and it’s very cheap to replace if it gets broken in my bag. Actually, I find this particular headset a little uncomfortable for long conference calls; if you’re doing a lot of those, then I recommend the Corsair Vengeance 2000: a comfortable, wireless headset with battery capability, allowing you to work all day. (By the way: none of these are referral links.)
  • Quiet place to think, with a door that shuts–especially if you live with other people, and especially if you have a family.
  • Stable Internet connection, or good backup connection. For example, I have DSL and have setup tethering on my phone if the DSL goes out. If you’re constantly having Skype issues or dropping calls, you’re becoming both less reliable and less professional in the eyes of others who might be trying to manage several remote employees.
  • Skype. This is good for adhoc conference calls, instant messaging with clients, or even creating low ceremony chat rooms.
  • SkypeOut, which lets you take and make calls from your phone to Skype contacts. This is awesome, especially for times when you’re away from your computer and (you’ve miscalculated a time, client has an emergency, etc.).
  • Electric kettle. Sometimes I want hot coffee but, don’t want to disturb my flow to get some.
  • Gallon jug of water. For the kettle, or for drinking. For long coding sessions, or long conference calls.

A depiction of an ideal remote or work from home office set up.

Some of these sound obvious, but you’d be surprised at the number of remotes who don’t hit all the marks here. As developers, we need a quiet space to think, uninterrupted. And as remote workers, we need a quiet place to host conference calls, meetings, pair programming sessions, etc., uninterrupted. Just working on your couch is probably not a good long-term remote work solution.

Software Tools

There are a bunch of good software tools out there to supplement your typical development environment and help you overcome the challenges associated with remote work. Here are a few that I really like:

  • AwayFind, which is good for urgent emails, particularly last minute messanges from an attendee of a meeting, as it forwards their messages to you via SMS.
  • Time Zone Converter, for working with clients and colleagues around the world. I like Time And Date’s World Time Clock, Every Time Zone, and World Time Buddy.
  • Chat/IRC rooms for everyone on the team. This could be formal (e.g., a Campfire room) or just a Skype chat room (in Keep It Simple, Silly) style.
  • Bug tracker–this deserves its own section, so see below.

When planning meetings, always confirm both time zones. And when you get an invitation, you should always do the math backwards and make sure you come up with the same numbers. If the meeting involves multiple time zones, I like including the UTC time also. Since everyone should know their offset from UTC, this is yet another check to make sure everyone’s on the same page.

I was on a decently-sized Rails team a few years ago. Several team members worked remotely for at least part of the time, and the team culture was that much work would be done in the evenings. I proposed setting up a chat room through the offical team leader at the time, pointing to Campfire or some other paid chat service. Several weeks went by with no action and I decided to setup a Skype chatroom with just the developers, to test my theory that a chat room would be an asset for the team. This experiment proved very successful – so successful that we just kept using Skype chat instead of another solution. This Skype chat room was still in use when I left the project almost a year later. Sometimes, simple can be the best option.

Later on, during a critical deadline for the same project, we set up a Skype chatroom that included the developers, business analysists, the project managers and the client, so questions could be addressed quickly by the general group. While not as active as the developer-only chat room, it still worked really well. Skype chats can be moderated and controlled by some group chat commands, setting chat roles and setting access permissions, which allows you to really customize the chatroom to your use-case. Even a setup of such simplicity can improve remote productivity.

Remote Work Best Practices: Bug Tracking

I like to know three things from a bug tracker I’m using:

  • What am I working on right now?
  • What’s on my plate for the next release of this software?
  • What are the entire team’s deliverables for this release of the software?

Each of these has a purpose.

First, “What am I working on right now?”: When you work in a traditional office, you have background chatter–this gives you have a general idea of what everyone else is doing. An explicit marker in the bug tracker system stating, “Yes, I’m actively working on this right now”, can introduce a similar pattern and feel to remote work.

Secondly, “What’s on my plate for the next release?” means, “What bugs I’m responsible for” or “What bugs I’m handling”. There’s certainly some back-and-forth in every team, but it’s also good to know who to ask if you want to grab a bug, or need some help with finalizing your bugs for the release.

It’s also possible your team doesn’t work like this at all: for example, your workflow might be where each developer is only assigned one bug to start with and picks off the unassigned pile when their one bug is done. This can be productive as well.

The “Next release of the software” doesn’t have to be anything big–I’ve been on teams where the “next release” meant, “3 days from now, we’re going to release a new alpha build for the client”. But it’s still good for everyone to know what’s coming up in this new release. Especially if you pick off unassigned tickets when your current ticket is complete.

I’ve included some recommendations for specific bug trackers at the bottom of the post.

Remote Work Best Practices: Team Communication

For some, team communication is the most intimidating part of working remotely or from home. But this will only be an issue if you let it be.

In an office, as you stroll by everyone on the way to your seat, there’s a bit of banter, people saying “Hello”. Your coworkers know you’re at work because they see you, over there, at your desk, working.

Remote workers need to be slightly more explicit–nobody knows that you’re working unless you tell them. But if you establish the right communication practices, your colleagues will be available at the press of a button, rather than a stroll across the office, down the elevator, etc.

These tips apply more for a remotely managed employee as part of a bigger team, but may be useful if it’s just you as the sole developer.

Making Your Presence Felt: Don’t Go Invisible

I picked up several of these ideas from the Wide Teams Podcast Episode 48.

At beginning of the day, get on IRC (or whatever tool your team uses) and say “Hello”, chat about how people’s days are going, etc., etc. Even if it means getting on IRC and asking about kids, weekends, sports teams, or weekend hacking. When people know you’re currently hard at-work at home, you don’t become invisible. Build a relationship and let people know that you are there.

Chat with people on chat and make sure you stay involved with your colleagues. This is different then when you bump into people in the coffee room, etc., etc. You need to explicitly reach out and stay in touch so that when you commit code or need assistance, people are ready.

‘Starting day’, ‘Lunchtime’, and ‘Be back’ Messages

Along with making your presence felt, you should also let your remote teammates know when you’re notworking. Just like in a traditional office setting, you don’t want to disappear for the rest of the day and leave your colleagues hanging.

If you’re on a team with a number of other developers or managing remote employees, it makes sense to check in when you start your work day. A simple “Good morning, everyone” to let people know that you’re at your desk ready to start work on the project, and no longer at home or in bed.

Sending “Be back in 1 hour” messages for lunch or work breaks during the day is nice too. Remote work is great for many things, but one worrysome scenario is that you ask your colleague a question and receive no response. Are they not responding because they’re away for 30 minutes? Or because they are deep in the zone and not listening to chat? Maybe in a meeting? “Be back in…” messages can alleviate these concerns and smooth out the workflow.

When you’re done for the afternoon, let people know when you’ll be back. Maybe it’s “See you all in the morning”, or “Be back later this evening to get [x] done”. But like the “Back in 1 hour” messages, they set a certain expectation to which your team can adapt.

There’s an interesting startup called Sqwiggle that may solve some of these problems (although I haven’t tried it myself yet). In addition to taking a picture of you every few seconds, it also lets team members click on your picture to start video/audio chatting, as well as providing a text chat component. The idea behind the picture is to see, at a glance, if you’re at your computer or not. (There’s nothing worse than trying to chat with someone online and not hearing back quickly. Are they caught up with something else? Deep in the zone? Don’t see the chat notification? In the bathroom right now?). I heard about Sqwiggle on the Wide Teams Podcast Episode 83.

On Projects Where You Can Setup the Best Practices

Remote freelancing gigs are always different. (That’s part of the appeal!) Sometimes you’re brought into an existing team of developers purely as staff augmentation. Maybe this team has been together for some time and, in that case, they’ve already established communication practices.

On the other hand, sometimes you’re the only developer on the project, working with a non-technical client. You can setup your own software development best practices and have some control over how to run the operation. Below are some best practices from my decade or so of remote work experience. Mostly, these are targeted at half-week (20 hours/week) or full-week schedules (40 hours/week).

Standup Meetings

There’s something to be said about holding standup meetings to talk about the state of the project. These arevery common in traditional offices, but there’s no reason why they can’t be productive for the remote team: they’re just another way to enforce communication between the two parties: client and developer.

A traditional stand-up meeting asks what you were working on yesterday, what you’ll be working on today, and if there are any obstacles in your way. This format may or may not work given the size of your team: if it’s a single developer project, then these actual questions make no sense.

How often you should have a standup meeting is really dependent on team size and culture. However, here are my recommendations:

  • 1-3 developers: 2 standup style meetings a week
  • 4+ developers: daily standup meetings

With 1-3 developers, these questions are mostly self-evident: you know what each developer is doing because it’s easy to track their individual work as they plow through tickets: everyone knows what everyone is doing, because there’s just not that many people doing work.

With larger remote teams, there are more parts in motion: you want to make sure that nobody is stepping on anyone’s virtual toes by replicating work, or making incompatible changes.

Given Toptal’s per-week payment structure, two meetings a week gives the client enough time to express concerns about the project before they feel cheated out of a weekly rate. Just having one meeting a week could mean that the client is unhappy about the quality of work, and the developer has no time to adjust the deliverables.

Advanced remote teams may have other methods of keeping all the stakeholders on the same page without scheduling an actual meeting while they work from home. I still like getting on the phone/Skype/Hangouts with someone and having a meeting that way.

For small teams, two standup meetings a week works really well: course corrections are made quickly, but developers still have something substantial to report during each meeting.

Delivering on the Next Release Remotely

Depending on the size of the project, I like deliverables sent to the client weekly for small (1-2 developer), and bi-weekly for larger (3+ developer) projects. This rhythm gives developers enough time to complete sizable chunks of work, including an interface (or improved user experience) for the client to see.

For non-technical clients, the only metric by which they can guage progress is what they can see on the screen.

It’s important for developers to remember, especially with non-technical clients, that progress you can visualize with a user interface is often the only thing that matters to the client. Non-technical clients don’t care that you pushed out 500 lines of code this week, or that you had a hard time interacting with some web service; the only metric by which they can gauge progress is what they can see on the screen. That’s not to say that doing good work on the back-end is irrelevant, but rather that you need to make all this good work tangible in the eyes of the client.

This image depicts the importance of deliverables, especially in a remote work situation.

Which is why I like weekly or bi-weekly deliverables. Anything shorter than that often puts the developer in a hard place: maybe they get stuck doing back-end work for two days and don’t have time to finish the interface, so they have nothing to show the client.

Depending on the type of software project, not all of these client releases will be released to the public. For example, if you’re working on a Rails project, you may want to deploy approved changes immediately; on the other hand, with a mobile app, you may call a release “1.3a10”, but the current release is just part of the bigger feature set of a new 1.3 version of the software that will be deployed later.

This is where the remote bug tracker best practices come into play. With bug tracking, the client knows:

  1. What’s on the team’s plate for this deliverable
  2. If it’s been completed
  3. If the work has been approved by the client.

The client knows what to expect from this release, and developers know what work is ahead of them.

If your remote team is mature enough to use continuous deployment and/or Kanban then that’s fine. However, these are both very advanced techniques that are more suited towards organizations with a strong, developer-based culture. Most organizations, where custom software development is seen as necessary but costly, are probably not ready for either of these techniques. Why’s that? Two things I’ve seen is that the client can’t keep up with the number of changes developers want them to review, or priorities change too rapidly for development to get any one thing done.

Recommendations

If you do happen to walk into a team where you’ll be establishing the best practices, I’ve listed some tools below for managing your remote work. Keep in mind that these are just my recommendations: certainly, this guide isn’t for everyone; and if you don’t like these tools, there is probably a tool that fits your needs better.

  • Planscope.io, in weekly mode. This is a time tracker + bug tracker + project estimation tool that sends clients daily emails when you work on their project and lets them see how things are going in terms of progress and budget. This is great for projects of 1-4 developer/months in size.
  • App Trajectory is a bug tracker for small teams with a focus on estimating and breaking the project down into one-to two-week chunks (iterations). App Trajectory can tell you how much work you’re completing in an iteration, and how many iterations until all the known work is complete. This is great for projects 2-12 developer/months in size.
  • Pivotal Tracker is a bug tracker tool for clients with a focus on Agile methodologies. This is great if you are doing formal Agile iterations or have a project size measured in developer/years.
  • FlowDock for chat. Flowdock offers some advantages over plain IRC or Skype chat: in addition to integrating with popular services, it also lets you tag conversations for quick reference later. FlowDock also keeps a list of status activities (code checkins, etc.) which are separated from general chats. (I.e., in the web interface, automated status updates are on the left, while chats are on the right.)
  • Again, Campfire is also great for chat.

Conclusion

Getting started with remote or work from home can be quite an adjustment, both for you and the client. I’ve had it go very right, and very wrong. But, when it goes right, it can be an excellent way for clients or employers to solve the “talent crunch” problem, and create a wider range of opportunities for developers who live outside major technological centers or “startup” hubs. There’s a whole world of efficiency to be gained from developers working together remotely with the right best practices in-place.

This article was written by Ryan Wilcox, a Toptal Ruby developer.

Share this:

Read More

Wheat Belly Book Recommendation & Hidden Gems #4 | Dr. William Davis


Written by Jason Nesbitt Topics: Books, Self Improvement Wheat Belly Book

Wheat Belly Book

 

Warning: Following the Guidance of The Wheat Belly Book May Make You Feel Amazing

Thanks for joining me again for the Wheat Belly book recommendation. This is one of my favourite topics in life: diet and nutrition. If you know me, you’ll know how obsessed I get with the different fuels that feed our body and my belief of how much of an impact they have on our body.

To summarise the Wheat Belly book and entice you to keep on reading I will provide you with the following sentence:

If you want to feel more awake, lose weight and understand the fuel of your body more then you have to read this book!

So, if that floats your boat and you’re drooling at the idea of losing weight (irony), then enjoy the summary and hidden gems below of:

Wheat Belly book by Dr William Davis – Click Here to Get Your Copy

Summary & Recommendation

This book will get you excited about how amazing you could feel so definitely comes highly recommended from my humble self.

You’ll be amazed by not only the weight loss impact, but the medical issues that have been resolved by removing this white demon. I enjoy the humour of dislike towards wheat induced people. A fun style of writing that makes it very easy to read.

Reading it made me begin to wonder if most of our foods are empty calories with minimal benefit….Is that something you have ever pondered before? I’ll leave you to read the book and decide for yourself.

I’ll summarise the general findings of it: modern wheat is very genetically modified to create a lot more of it. It results in spikes insulin that make us tired, more hungry, gain weight and have an array of health issues. It’s cheap and fills us up.

This is such a hot topic that I don’t think it needs anymore of a recommendation. After reading it, you’ll be looking out for the wheat belly everywhere and feeling content at having a better understanding of what causes it. Onwards to the gems hidden in the book.

Hidden Gems

  • Wheat stayed the same for thousands of years and changed into something unrecognisable in the mid 20th century and yet still has the same name: Wheat. The book nicely explains the differences before and after to give great insight and explanation

 

  • GI level of food is the most important thing to look at (and I’d always avoided it!): glucose is unavoidably accompanied by insulin, the hormone that allows entry of glucose into the cells of the body, converting the glucose to fat. The higher the blood glucose after consumption of food, the greater the insulin level and the more fat is deposited

 

  • Click here right now to view a great GI index of common foods. In conclusion, wheat is the same, sometimes worse, than having a spoonful of sugar

 

  • Wheat has morphine like effect. You may have experienced it before. Having that big baguette at lunch knocks you out like a punch from Mike Tyson. It is also an appetite stimulant! That means that eating wheat will make you more hungry. I know I definitely crave more food after eating a lot of wheat. Me thinks this is a bad thing!

 

  • Removing wheat is pretty much guaranteed to improve moods, reduce mood swings, improve concentration and allow for deeper sleep within a few days or weeks

 

  • Gluten binds to the brain’s morphine receptor. That’s right, just like heroin. Induces a reward, kind of euphoric feeling. If this is blocked or avoided, people often experience unpleasant withdrawal symptoms

 

  • There is the usual story of large companies (pharmaceutical and food) having a sway over clinical trials to avoid the truth and promote/not create bad press for their products

 

  • My business mind was running whilst reading this book, as per usual. It made me want to create the idea of: What wheat / whatwheat.com – an app and website that explains what you can eat and the effects of it. What do you think?

 

  • Mountains of scientific evidence explaining the negative impact of wheat. This book articulates it, puts it all in one place and gives everybody a very good reason to put down that boots meal deal sandwich. Some of the studies were done decades ago which is why it is so surprising that it isn’t more common knowledge.

 

  • It got me super pumped about the low carb dream. The evidence is impossible to ignore.

 

  • Is gluten free worth it?: NO. Gluten free could be used temporarily to avoid the brain side affects of gluten wheat such as the euphoric high and addictive/withdrawel qualities. However, it still has the same, if not higher, glucose/insulin response so will still end up storing more fat.

 

  • Is rice ok? Yes, gluten wise. Long grain and brown rice are fine as they don’t increase glucose and insulin much but other types of rice can increase glucose as much as bread

 

  • Unless you’re very interested in the topic, I recommend reading just the first 25% of the book and skipping the sciency bits. It’s quite easy to flip to the next chapter when biology kicks in.

 

  • Warning: It is an anti carb book disguised as an anti wheat book. The author explains that one should remove wheat and replace it with healthy natural foods such as meat, veg and nuts – not other carbs!

 

  • Carbs are the biggest reason for appetite. Removing them will result in an individual being able to go for days without really feeling hungry. Imagine not having your life ran by the fact that you need to top up on sugar (carbs) every 2 hours. Life changing freedom!

 

So What Should You Be Eating?

As I was nearing the end of the book, I got the urge to write out a nicely refined list of what can be eaten to have the following benefits:

– a consistent level of energy and appetite by reduction of glucose/insulin spikes

– reduction of ageing due to lack of small LDL particles being created 

– avoiding all allergic reactions to gluten

It turns out that the author had the exact same idea as when I got on to the next page, I found a very similar looking list. Useful stuff! Check out the list below:

– As much meat as you want (not cured such as bacon, sausages or salami). Cook at lower temperatures for as little time as possible

– as many eggs as you want

– as much fish as you want

– as much cheese as you want. Full fat.

– as many vegetables as you want

– as many raw nuts as you want

– some fruit (preferably berries). E.g. 10 blueberries or 3 wedges of apple or orange. Not dried fruit.

– some quinoa or oats. E.g. 1/2 a cup

– some brown rice. E.g. 1/2 a cup

– some potatoes. E.g. 1/2 a sweet potato

– some legumes. E.g. 1/2 a cup

– some cottage cheese, yoghurt, milk and butter. E.g. 1 serving a day. Unflavoured and unsweetened

– some soy. E.g. 1 serving a day

– use the following oils generously: extra virgin olive, coconut avocado and cocoa butter

Recommendation In A Recommendation – My Favourite

If you are interested in this topic then I highly recommend you check out Grain Brain by David Perlmutter and Kristin Loberg. It is very similar and stresses the same points as the Wheat Belly book. You grab your copy by Clicking Here.

Grain Brain concentrates more on the effects of wheat/gluten on the brain and is an excellent read. It explains the non visual effects of gluten such Alzheimer’s etc. in a very understandable, albeit, medical way.

The Wheat Belly Book is Totally Worth It

The Wheat Belly book is worth it just for the list of easy to make recipes at the back! Great low carb ideas and a surprising amount of sweet treats. I can’t wait to try them.

Thanks for joining us again. I hope these books are having a positive impact on your life. I know they certainly are on mine! Until next time…

Share this:

Read More

Learn to Code: Toptal’s Quick And Practical JavaScript Cheat Sheet: ES6 And Beyond


Written by Irina Papuc Topics: Learn to Code learn-to-code-3

JavaScript: What is ES6?

ECMAScript 6 (ES6) is the latest standard specification of JavaScript, the programming language of the Web. Since HTML5 and the birth of Node.js, the runtime that allows us to run JavaScript on the server or desktop, JavaScript has gained a unique momentum. There is a growing adoption rate among enterprises, embracing it into production, and thus its newest features were greatly awaited.

We created this cheat sheet as a list of ES6 features we use everyday. Trying to be comprehensive but concise at the same time, new API methods are left apart. For those who need them, make a quick search by yourself or try to explore the MDN documentation to catch the latest experimental APIs. However, some the most bleeding edge characteristics like async and await from the next specification draft (ES7) are included. This is because of most of us developers are going to use a transpiler like Babel anyway to get advantage of the newest JavaScript.

You can test out some of the mentioned tips by running the node REPL with this command:

node --use-strict $(node --v8-options | grep harm | awk '{print $1}' | xargs) #ES6

Or, use directly a babel-node to get the most of Javascript in your console.

 

Download JavaScript ES6 Cheat Sheet

CLICK HERE TO DOWNLOAD JAVASCRIPT ES6 CHEAT SHEET

JavaScript (ES6 and Beyond) Cheat Sheet

Constants

> const EULER = 2.7182818284
> EULER = 13
> EULER
> 2.7182818284

let vs var

> var average = 5
> var average = (average + 1) / 2
> average
> 3
> let value = ‘hello world’
> let value = ‘what is new’
// -> throws TypeError: Identifier 'value' has already been declared

Warning! If array or object, the reference is kept constant. If the constant is a reference to an object, you can still modify the content, but never change the variable.

> const CONSTANTS = []
> CONSTANTS.push(EULER)
> CONSTANTS
> [ 2.7182818284 ]
> CONSTANTS = { ‘euler’: 2.7182818284 }
> CONSTANTS
> [ 2.7182818284 ]

Be aware of Temporal Dead Zones:

> console.log(val) // -> 'undefined'
> var val = 3
> console.log(val)
 // -> 3

Because it’s equivalent to:

> var val
> console.log(val)
> val = 3
> console.log(val)

Variables declared with “let/const” do not get hoisted:

> console.log(val)
// -> Throws ReferenceError
> let val = 3
> console.log(val)
// -> 3

 

Binary, Octal and Hex Notation

> 0b1001011101 // 605
> 0o6745 // 3557
> 0x2f50a // 193802

New Types

Symbols, Maps, WeakMaps and Sets

Arrow Function

> setTimeout(() => {
…  console.log(‘delayed’)
… }, 1000)

New Scoped Functions

> {
… let cue = 'Luke, I am your father'
 console.log(cue)
… }
> 'Luke, I am your father'

Equivalent with Anonymous Function

> setTimeout(function () {
…   console.log(‘delayed’)
… }.bind(this), 1000)

Equivalent with Immediately Invoked Function Expressions (IIFE)

> (function () {
… var cue = 'Luke, I am your father'
… console.log(cue) // 'Luke, I am –
… }())
> console.log(cue)
// Reference Error

Object Notation Novelties

// Computed properties
> let key = new Date().getTime()
> let obj = {  [key]: “value” }
> obj
> { '1459958882881': 'value' }

// Object literals
balloon = { color, size };

// Same as
balloon = {
  color: color,
  size: size
}
// Better method notations
obj = {
foo (a, b) { … },
bar (x, y) { … }
}

String Interpolation, Thanks to Template Literals

> const name = 'Tiger'
> const age = 13
>
console.log(`My cat is named ${name} and is ${age} years old.`)
> My cat is named Tiger and is 13 years old.

// We can preserve newlines…
let text = ( `cat
dog
nickelodeon`
)

Default Params

> function howAreYou (answer = ‘ok’) {      
 console.log(answer) // probably ‘ok’
}

Promises

new Promise((resolve, reject) => {
  request.get(url, (error, response,  
  body) => {
    if (body) {
        resolve(JSON.parse(body));
      } else {
        resolve({});
      }
  })
}).then(() => { ... })
.catch((err) => throw err)
// Parallelize tasks
Promise.all([
   promise1, promise2, promise3
]).then(() => {
   // all tasks are finished
})

Classes, Inheritance, Setters, Getters

class Rectangle extends Shape {
  constructor (id, x, y, w, h) {
    super(id, x, y)
    this.width = w
    this.height = h
  }
  // Getter and setter
  set width (w) { this._width = w }
  get width () { return this._width }
}
class Circle extends Shape {
  constructor (id, x, y, radius) {
    super(id, x, y)
    this.radius = radius
  }
  do_a(x) {
    let a = 12;
    super.do_a(x + a);
  }
  static do_b() { ... }
}
Circle.do_b()

Destructuring Arrays

> let [a, b, c, d] = [1, 2, 3, 4];
> console.log(a);

> 1
> b
> 2

Destructuring Objects

> let luke = {  occupation: 'jedi',
 father: 'anakin' }
> let {occupation, father} = luke
> console.log(occupation, father)

> jedi anakin

Spread Operator

// Turn arrays into comma separated
// values and more
> function logger (...args) {
 console.log(‘%s arguments’,
    args.length)
 args.forEach(console.log)
 // arg[0], arg[1], arg[2]
}

…Go Destructuring Like a Boss

> const [ cat, dog, ...fish ] = [
‘schroedinger’,  ‘Laika’, ‘Nemo’, ‘Dori’]
> fish // -> [‘Nemo’, ‘Dori’]

Or Do a Better Push

> let arr = [1, 2, 3]
> [...arr, 4, 5, 6]
> [1, 2, 3, 4, 5, 6]

…And Destructuring in the Future    ⚠ ES7

{a, b, ...rest} = {a:1, b:2, c:3, d:4}

Async   ⚠ ES7

async function schrodinger () {
return new Promise((resolve, reject)
  => {
   const result = Math.random > 0.5
   setTimeout(() => {
     return result ? resolve(‘alive’)
     : reject(‘dead’)
   })
  })
}

Await   ⚠ ES7

try {
console.log(await schrodinger())
// -> ‘alive’
} catch (err) {
console.log(err)
// -> ‘dead’
}

Export   ⚠ ES7

export function sumTwo (a, b) {
return a + b;
}
export const EULER = 2.7182818284
let stuff = { sumTwo, EULER }
export { stuff as default }

Importing   ⚠ ES7


import React from ‘react’
import { EULER } from ‘./myexports’
import * as stuff from ‘./myexports’
// equivalent to
import stuff from ‘./myexports’
// { sumTwo, EULER }

Generators

They return a objects that implement an iteration protocol. i.e. it has a next() method that returns { value: < some value>, done: <true or false> }.

function* incRand (max) { // Asterisk defines this as a generator
while (true) {
// Pause execution after the yield, resume
// when next(<something>) is called
// and assign <something> to x
let x = yield Math.floor(Math.random() * max + 1);
max += x;
}
}

var rng = incRand(2) // Returns a generator object
> rng.next() // { value: <between 1 and 2>, done: false }
> rng.next(3) // as above, but between 1 and 5
> rng.next() // NaN since 5 + undefined results in NaN
> rng.next(20) // No one expected NaN again?
> rng.throw(new Error('Unrecoverable generator state.'))
// Will be thrown from yield

This article was written by Jesus Dario Rivera, a Toptal Javascript developer.

Share this:

Read More

Bootstrapped: Building A Remote Company


Written by Irina Papuc Topics: Business DCF 1.0

 

The Dream: Building A Remote Company

If you ask me, working remotely rocks. I’m currently writing from a small beach bar located on a remote island in southern Thailand. Looking up from my laptop, I see nothing but the endless ocean and its crystal clear blue waters. I’ll be enjoying this morning undisturbed and focused on my work because the rest of the team hasn’t even gotten up yet. Time zones work out really well for distributed teams.

My colleague Thomas recently talked to 11 thought leaders in project management about the impact of remote work on a company; some scrum experts argued that distributed teams could work together effectively while others came out strongly against it.

I understand the concerns; you can’t just open up the office doors and release everyone into the wild. It’s not guaranteed that you’ll end up with a thriving business. Marissa Mayer at Yahoo famously axed remote work in 2013 after feeling that some employees abused it.

So how does a tech company get this working remote thing right? Read on. The following is based on our story at Planio and how we made it work.

The author, Jan Schulz-Hofen, working remotely on an island beach.

Enter Planio, my remote company

There are a number of things which motivated me to start my current company. Breaking away from client work while retaining all the benefits of being a location independent freelancer was one of them.

In 2009, I was sitting in the shadow of a cypress grove situated in a beautiful Mediterranean-style garden overlooking the rolling hills of Tuscany, working hard on a new side project of mine: Planio.

It’s a project management tool for people like me: developers. Planio helps make client projects more organized and transparent all while reducing the number of tools and platforms needed to do the job. Planio is based on open-source Redmine (an open source Ruby on Rails-based software project), which I’ve used remotely with my own clients since its very beginnings. So, in a way, remote work is already in Planio’s DNA.

Fast forward to today, and my small side project has grown into a real company. We’re a team of 10 now, serving more than 1,500 businesses worldwide. We have an office in Berlin, but many of us work remotely.

In this article, I’ll dig into the principles, tools and lessons that have helped us along the way. After reading it, I hope you’ll be able to architect your software company so it’s remote-friendly right from the start.

“Talk is cheap. Show me the code.” – Linus Torvalds

Every Thursday we have an all-hands conference call where we discuss what we did the previous week and what’s coming up next.

At the beginning, we spent a lot of time discussing ideas before deciding on what to do, but we found that it’s a lot harder when some team members are on a poor quality telephone line and you can’t see them.

Now, we often just “build the thing” and then discuss it – we create a working prototype with a few core ideas and then discuss that. For instance, we recently hit some performance issues with our hosted Git repositories. Instead of discussing and analyzing all the possible ways in which we could potentially save a few milliseconds here and there with every request, my colleague, Holger, just built out his suggested improvements in a proof-of-concept on a staging server to which we directed some of our traffic. It turned out well and these ideas are going into production.

This method focuses everyone’s minds on action rather than talk. The time invested in writing code is paid back by less time spent talking in circles.

Use Text Communication

Real-time communication punishes clarity. Instinctively calling a colleague when you need something is very easy, but it’s not always your best course of action. I can’t remember the number of times I’ve started writing an email or a Planio ticket for a problem only to solve it myself just while writing it down.

Zach Holman, one of the first engineering hires at GitHub, agrees: “Text is explicit. By forcing communication through a textual medium, you’re forcing people to better formulate their ideas.”

Text communication also makes you more respectful of each other’s time, especially when you’re living multiple time zones away. Immediate communication can be disruptive; the person might be in the middle of figuring out why the last deployment went wrong. With an email, s/he should be able to consider your write-up at a more convenient time.

Be as Transparent as Possible

Time spent worrying about office politics isn’t conducive to shipping working software, and transparency promotes trust. It’s no coincidence that many remote-by-design companies, such as Buffer, have radical transparency. In the case of Buffer, it shares revenue information and the salaries of all its employees.

Automattic, the company behind WordPress.com, also emphasizes transparency. In his book, The Year Without Pants, Scott Berkun shares his experience working remotely for Automattic, and that all decisions and discussions are internally available to employees in its P2 discussion platform as part of its emphasis on transparency.

The chat feature in Planio works in a similar way. Discussions are open for everyone to see and chat logs are linked automatically from the issues discussed so nobody is left out; even new hires can read up on what previous decisions were made and why. When I started building the chat feature, I considered adding a feature for chatting privately with others, but when we discussed it as a team, we ended up leaving it out because we wanted to keep team communication as transparent as possible.

I think transparency is critical for remote teams. For example, imagine you’ve just joined a team of remote developers. Perhaps you’ve never met your new colleagues. You don’t know the unspoken rules of behavior. You might be worried about whether you’re doing a good job. Are your teammates actually being sarcastic or do they really mean their compliments? Is everyone privately discussing how good of an engineer you are?

Digitalize Your Systems

We choose our services based on what they offer by way of online platforms, from telephone providers to banks (many of them will even offer a small financial incentive for going paperless, plus it’s great for the environment, too). I’m lucky to have a lawyer and an accountant for Planio who are comfortable sending emails or messages with Google Hangouts instead of summoning me to their offices. (I strongly recommend you ask about this at the first meeting.) Bonus points for getting them to sign up with your project management tool and become a part of your team!

We’ve even digitized our postal mail; at Planio, we use a service called Dropscan that receives our letters, scans them and forwards the important ones to the appropriate person. You don’t want to your friend to pick up and read them out over Skype. If you cannot find a mail-scanning provider for your city or country, some coworking spaces offer virtual memberships to maintain a physical mailing address while you’re away.

For those companies sending out mail, there are services available so that you never have to visit a post office again. We use a German printing company with an API that automatically sends a letter along with stickers to each new paying Planio customer. It’s something people love, and we don’t have to print and mail a thing. International alternatives include Lob and Try Paper.

Digitalize Your Systems

Should You Have a Digital Presence Mandated?

In a co-working space on the tropical island of Koh Lanta, Thailand, I noticed that someone in a support role for a major e-commerce platform was constantly on a live video feed with the rest of the team. Sqwiggle offers a similar “presence” functionality for remote teams.

I suppose mandating that all employees are on video while working might be based out of a fear that employees abuse remote work arrangements. In my experience, that’s not the case. At the tropical co-working space, there’s a certain urgency in the air, despite the laid-back clothes and coconut drinks. People are quietly focused on their laptops; it’s as if they want to make sure remote work delivers results, so they can stay out of a fixed office for good.

We found that we don’t need a digital presence because we have a great level of trust among everyone on the team. I also think that it’s paramount to respect everyone’s privacy. If your company is moving from an all-on-site setting to remote work, a digital presence might help the more anxious managers to overcome any trust issues.

Choose Bootstrapping over Venture Capital

Most venture capitalists are looking for outsized returns, so they’ll prefer an intense short burst of 12-months’ work from a team over a more sustainable pace. Front App, a startup funded by the Silicon Valley accelerator Y Combinator, rented a house in the Bay area for their three-month stint in the Y Combinator accelerator program. The goal is to optimize for evaluating a business idea quickly.

Given the outsized return mindset, you may have a hard time convincing a venture capitalist to fund you when you’re working from a beach in Cambodia. This is why many venture-backed startups (such as Buffer or Treehouse) that use remote work built leverage first. Buffer was profitable before taking on investment while Ryan Carson, the founder of Treehouse, had already proven himself with a previous startup.

Here’s a better way than venture capitalism: bootstrapping. It means financing your company with revenue from initial customers. In my opinion, it’s by far the superior approach because it enables you to build your company on your own terms and remain in control. However, it often requires working two jobs or freelancing on the side while you get your company started. It took me about two years working on both Planio and client projects (via my software development agency LAUNCH/CO) to get going, but it was well worth it.

Bootstrapping also forces you to build a business that generates revenue from the very beginning, which I find much healthier. Hint: Building a B2B SaaS makes this much easier than creating a consumer app because businesses are far more willing to pay monthly subscriptions if it adds value. You have to sell a lot of consumer iPhone apps at $0.99 to cover monthly payroll for even the smallest of teams.

Choose Bootstrapping over Venture Capital

Bootstrapping forces you to build a business that generates revenue from the very beginning.

Price your Products Strategically

One of our first clients was a massive technology company with billions in annual revenue. Obviously, I was delighted that they’d choose us over much bigger, more established competitors. They’re still a happy customer, but we have moved away from very large enterprise accounts; I’ve found that they require a lot of hand-holding and in-person meetings before they’ll become a customer.

As Jason Lemkin points out in his article on scaling customer success for SaaS, when you have big enterprise accounts, someone will have to get on a jet to visit them twice a year. If you’re a small company of two or three people, that person is going to be you, the CEO, the CMO and the CSO all rolled into one overworked hamster.

Keeping your pricing model within the rough bounds of a $49/$99/$249 model as suggested by developer-turned-entrepreneur Patrick McKenzie means avoiding having to hire an enterprise sales team, and having to earn the massive amount of capital required for it. You, the customer, don’t expect the CEO to pop in at Christmas with a box of chocolates when you’re paying $249 a month.

Build on Open Source

A venture-backed business based on proprietary software is great when your play is a “Winner Takes All” game and own the market. When you’re a bootstrapped company, open source software can give you reach and leverage you could never have achieved, otherwise.

There’s precedence of profitable tech companies building a business around open source software; Basecamp famously open-sourced Rails, guaranteeing themselves a supply of highly qualified engineers for the rest of eternity. GitHub has become a unicorn, leveraging the open source project Git that Linus Torvalds started to manage the Linux kernel sources. Our friends at Travis-CI started as an open source project, ran a crowdfunding campaign and then turned it into a remote-focused bootstrapped business (which also campaigns for diversity in tech through its foundation).

Planio is based on Redmine and we contribute many of our features and improvements back to the community. This works great in multiple ways; our contributions and engagement in the community help advance the open source project and Planio gets exposure to potential new customers. For us, it’s the most authentic way to build a brand; by showing our code and taking part in open technical discussions, we can demonstrate that we know our stuff!

Hire Proven Professionals

Hiring a fleet of interns every year makes sense only if you’re intent on scaling up your employee count as soon as you hit the next round of funding.

Outsourcing tasks is easy if it’s copy-and-paste, but you don’t want to outsource your DevOps to someone with the lowest hourly rate when you have thousands of customers relying on your servers. You’ll want proven professionals, such as those at Toptal.

Matt Mullenweg, the founder of the popular open-source blogging platform WordPress, stated that by focusing on quality means that his company, Automattic, predominantly hires experienced candidates who can handle the unstructured working environment of a remote company.

That means it “auditions” candidates by paying them to work on a project for several weeks, then hire them based on performance. Automattic has found this method is far more effective in finding the right candidates than traditional CVs and cover letters.

Emphasize Quality of Life

Work takes up a massive amount of our time, year in and year out. It should not be something that you just do to be done with; you’d probably end up wasting a huge chunk of your life. The best source of motivation and the main ingredient for great results is a work environment that’s inspiring, enjoyable and fun. Travelling, learning and engaging with people from different cultures makes work feel less of a sacrifice or necessary evil (at least in my life) than when working a nine-to-five office job.

Emphasize Quality of Life

Work takes up a massive amount of our time, year in and year out. It should not be something that you just do to be done with.

It’s not just about travelling the world, though, there’s the personal freedom aspect. Parents get to spend more time with their kids, thanks to avoiding a two-hour commute. You don’t have to live in Silicon Valley to earn San Francisco wages. Maybe, your significant other gets a great job opportunity abroad, too. You’re not faced with the painful choice between staying at your job and continuing your career or becoming a “trailing spouse” with limited career options.

At Planio, even though many of us work remotely, we all try to meet up at least once a year in a fun location. Last year, we spent a few weeks of summer in Barcelona, and several of us met here in Koh Lanta, this year. I’m still looking for ideas for the next destination, so let me know if you have any travel tips!

What tools, ideas or techniques have you found that make working remotely easier and more effective? Leave a comment below.

This article was written by JAN SCHULZ-HOFEN, FOUNDER & CEO @ PLANIO and friend of Toptal.

 

Share this:

Read More

Learn to Code: Wisdom and Tools for the Journey


Written by Irina Papuc Topics: Learn to Code learn-to-code-2

Learn to Code

Programming is a great skill to have. It is hugely rewarding on both a personal and professional level, giving you the ability to build and tinker and invent. It can open doors to all kinds of career paths with great benefits, be it a respectable paycheck, freedom to work when and where you want, or all of the above.

It’s no surprise that more and more people, from all kinds of backgrounds, are deciding to learn to code. But, each person who tackles the task is soon faced with an unpleasant reality: Learning to program is hard.

Complicated and confusing, at first, much of coding doesn’t make any damn sense. Contrary to expectations, the feeling of “I don’t get it,” may persist unabated long into the journey, making once bright-eyed beginners feel hopeless, lost, and ready to give up.

The moral of the story is this: Be prepared. The path to programmer paradise and learning to code is a long one, and without the right mindset at the beginning, it can quickly lose its appeal.

In this article, I’ll attempt to give you some guidance on what to expect on your journey, how best to go about it, and what tools and resources you may find helpful along the way.

The journey to programmer's paradise begins with a single step.

What to Expect

Maybe it’s obvious, but the first thing to make sure you wrap your head around is that programming, at its core, is a technical discipline. The earliest skills you learn will require a lot of “exactness” and “correctness,” and trying to cut corners will get you nowhere. You will have to learn at least a little bit of math, as well as a lot of things that might feel like math, such as procedural logic.

The point is, learning the foundations of programming takes a lot of focus and practice. However, countless people, techy and non-techy alike, have made this journey before you so do not be discouraged. As we will see, there is an abundance of resources for people just like you to help make the process as easy as possible.

Learning programming ain't easy.

 

The learning curve to learn to code is steepest in the beginning. There is a huge amount of “fundamentals” to absorb, including the various parts of a programming language (expressions, variables, data types, operators, loops, conditional statements, functions, classes), and the techniques for understanding how much of your computer’s time and memory space your code is going to use (complexity). You will write a lot of code that doesn’t work the first time, so you will have to come to terms with the bane of every programmer’s existence: debugging.

Once you’ve learned how to write code, you will be able learn how to write robust code. Making code efficient, easy to read and understand, and easy to expand on, is an art, and one that is constantly evolving. You will be able to start exploring different software philosophies, and go from simply being a “coder” to being a “software architect.” This is also a process that takes a lot of time and practice, but the better you get at it, the more you will find opportunities opening up for you.

How to Learn to Code

Each person’s journey to programming paradise is different, but there are some good principles that all travelers can benefit from. Here is the basic process I recommend if you are just starting out:

1. Choose Your Destination: Pick a Language, Any Language

If you are serious about learning to code, the language you pick really doesn’t much matter. Most popular programming languages share the same fundamental concepts, and by the time you’ve really gotten the hang of programming in your first language, picking up a new one will be easier than the first time around. If you are learning through a university degree program, or similar, your language will probably be chosen for you.

In any case, unless you know exactly what you want to do in the long run, there are only five languages I recommend considering, which strike a balance between ease of learning, versatility of the knowledge gained, and an abundance of long-term job prospects: Ruby, JavaScript, Python, C, and Java.

Here are some general notes on each, to help you decide:

Interpreted Languages

Interpreted languages are easier to get started with. This is because their source code can be run as soon as it is written. In contrast, compiled languages require an extra step between writing and running the code.

As a result, interpreted languages allow for faster coding, but they do not use computer resources as efficiently, and it is easier for bugs to go undetected. They are best suited for applications where performance is not a priority. These languages are very popular for web development. In fact, one of them, JavaScript, is the only language that can be run directly in a web browser, contributing to its rapid rise as one of the most lucrative languages to know.

Ruby

Pros

  • Extremely flexible syntax.
  • Easy to get started with.
  • High demand makes for well-paying jobs.

Cons

  • The flexibility can obscure much of the underlying processes.
  • Slow performance makes it a poor fit for high-end applications.

Commonly Used For

 

JavaScript

Pros

  • Only option for in-browser software.
  • Critical to every modern website.
  • Extremely high demand equals an abundance of well-paying jobs.

Cons

  • Complex syntax can sometimes be confusing.
  • More challenging than Ruby or Python for beginners.

Commonly Used For

 

Python

Pros

  • Elegant, minimalist typing syntax is beloved by practitioners.
  • Easy to get started with.

Cons

  • Slow performance means poor fit for high-end applications.
  • Poor scalability. Language design makes for problems in large applications.

Commonly Used For

  • Web back ends. See Django.
  • Scientific research and academics. See SciPy.

 

Compiled Languages

When code is compiled, it is converted from human-readable code into optimized machine code before it runs. The result runs much faster and more efficiently than interpreted languages. The compiler that does this must, as part of its job, make sure that everything that has been coded “makes sense,” and, as a result, it can identify and prevent many types of bugs that interpreted languages are susceptible to.

For this reason, it is harder to get away with mistakes or bad code with these languages. They will force you to gain a deeper understanding of what is really going on “under the hood,” and you will learn much more about how a computer really works. The price is that these languages are more labor-intensive, and typically more challenging to learn for beginners.

Compiled languages are used in applications that require performance and reliability, including embedded applications, which may run on hardware with tight resource limitations, and large, complex applications, where even a small bug can wreak havoc.

C
Pros

  • Can deliver better performance than any other “high level programming language.”
  • Will teach you the most about how a computer works.

Cons

  • Probably the hardest to master from this list.

Commonly Used For

  • Operating systems.
  • High-end video games.
  • Embedded systems.
  • Robotics and artificial intelligence.

 
Java
Pros

  • Most widely-used language, overall.
  • Strict typing forces a clear and efficient way of thinking.

Cons

  • Complex syntax can be cumbersome to read and work with.
  • Considered by many to be old-fashioned, monolithic, and approaching decline.

Commonly Used For

  • Large-scale enterprise applications.
  • Web development.
  • Android development.

 

HTML and CSS: Not Programming Languages

It should be noted that HTML and CSS, which are used in pretty much every webpage that has ever existed, are not programming languages. They are presentational languages, used to define how something should look and what it should contain, but not how it should behave. Nevertheless, they may be a good place to start, because they are much easier to pick up, and will teach you how to type things correctly. In addition, if you plan to do any web development, you will have to learn them at some point anyway.

2. Start Small

Learning takes time, and there is a lot to absorb. If you try to build a complete application on your first day, it won’t work out. To spare yourself the frustration, start by solving small, simple problems, and work your way up.

For example, the first program that is traditionally written when learning a new language is the “Hello World” program, which simply prints the words “Hello World” to the screen. In most languages, it is almost impossible to write a simpler program, and clearly this program does little of actual use. However, it still incorporates many of the fundamental parts of the language, and so it is perfect for introducing oneself to how the language is typed.

From here, you can write something that adds or subtracts some numbers, then something that takes input from the user. You can then learn about conditionals, which are a way to make decisions, and loops, which perform repetitive tasks. Soon enough, you will be ready to build your first object, and at that point you can start to experiment with building complete applications.

3. Be Patient

The core concepts of programming can be quite challenging. Many of them are not at all intuitive if you don’t know already know how the computer works at a deeper level.

For example, when I was starting out, I found debugging to be an infuriating process; it didn’t feel like programming. Instead of writing new code that did cool new things, I would spend an entire day scouring something I had written, trying to figure out, “How did I f*** it up this time?” scratching my head and ready to give up. Eventually, I would discover I had left a single semicolon out somewhere, or used a tab instead of a space, and by the time I got my code to work again, it would be the end of the day. I would feel like a total idiot; it would feel like such a waste of time.

Learning coding takes a lot of perseverance, especially on the days you feel like you aren't getting anywhere.

 

This sort of thing is going to happen to you, and it will drive you absolutely nuts. So, one of the keys to success is this: be patient, and go easy on yourself. Some of the best advice on the subject recommends focussing on the process, not on the goals. If you focus on your eventual goal (“I want to build a website by the end of June”) you will get discouraged, and feel like a failure. By letting yourself take as long as it takes to make progress, you will be more successful.

4. Practice Practice Practice

Like any skill, getting good at it really comes down to practice. There is nothing like doing something, to learn how to do it! Even if you can only spare a few hours a week, if you keep practicing regularly, you will, one day, find yourself knowing how to program. Eventually, you will develop an intuition for things, and something that took a whole day at first (like tracking down a bug), may now only take a few seconds.

When you feel like you have more or less gotten the hang of the basics of programming, a great way to get practice is to start your first project. Think of a simple application you’d like to build, such as a to-do list, or a calculator (again, start small), and give it a shot. This will teach you how to solve architectural and design problems, and build different pieces so that they will fit together into a working whole. These are the essential skills that will allow you to truly call yourself a programmer.

Resources

Depending on your goals, learning style, and means, you may want to use different resources along your journey. To help you determine what methods are right for you, here’s a quick summary of some of the tools you can use, ordered, roughly, from more structured learning to less structured learning.

These tools and resources will help you learn to code.

Structured Learning

This is the category of options that provide instructors, homework, tests, grades, deadlines, and real consequences if you don’t make your studies your highest priority. These are the options where you will have to go to class or flunk out of the program.

Formal University Degree

The most costly but, for many, the most valuable option, a formal university degree will give you the best foundation for a thriving career in programming and computer technology. You will receive recognition for your accomplishments in the form of your degree (a major leg up when entering the professional marketplace). But more importantly, you will emerge with a deep and thorough understanding of all things computer, and your abilities to write truly top-notch, effective software will reflect this.

Here are some of the things you can expect to learn in-depth from any decent university program, and that may be more difficult to find thorough instruction for elsewhere.

  • Electrical Circuits – The basic physics underlying virtually all computer hardware.
  • Digital Logic Circuits – How to represent truth and logical constructs with circuits.
  • Microprocessors and Computer Systems – How logical circuits are combined to make a programmable computing machine. What’s happening on all those little metal pins and printed wires.
  • Operating Systems – How to program a computer to manage, organize, and protect itself, and enable the safe operation of multiple applications.
  • Databases – How to store and copy large amounts of data without losing it, corrupting it, or making it impossible to search through.
  • Networks – How different and unrelated computer systems can talk to each other.
  • Higher Mathematics – Including Calculus and Linear Algebra. Essential for any career in advanced or cutting-edge fields.
  • Signal Processing – How to cross the boundary from the analog to digital worlds, and vice-versa.
  • Numerical Methods – For when real-world problems don’t fit neatly in a computer.

Computer science and engineering school will kick your ass, and you will have to sacrifice and dedicate yourself to completing it. But the rewards will be well worth it. I struggled to earn my own degree, but the day I received it remains one of the proudest days of my life.

Bootcamps

So-called “bootcamp” programs have emerged to fill the needs of those who do not have the time or resources to pursue a formal degree, but are willing to work hard, and at least learn the minimum necessary to start a software development career. In both cost and required commitment, they fall between a formal degree and the self-directed options discussed below.

Bootcamps typically involve 8 to 12 weeks of intense study and cost around US$10,000. They cover a lot of material in a short amount of time, during which you will have to sacrifice most other pursuits. But, they promise to prepare you for real-world software development, and put you on the fast track to a career in programming. Many bootcamps culminate in career days, or otherwise attempt to place you in a paying job soon after graduation.

Bootcamps are a relatively recent and explosive phenomenon. As such, it is still hard to measure their success rate, and many have yet to develop a proven track record of placing graduates in jobs. With that said, the available programs can only be expected to get better as this burgeoning new industry continues to grow. As long as you do your research carefully, you may find this is perfect option for you.

Most bootcamps are local programs, so you will have to see what is available in your town. If you live in a major metropolis, perhaps you can find what you’re looking for on this list, or this one.

Semi-Structured Learning

More and more resources are becoming available every day for those who work best with an element of structure and guidance, but do not have the time or resources to commit to a formal degree or bootcamp program. These options are typically offered entirely online, and many are completely free! As the high demand for such services has become apparent, these tools have grown rapidly in sophistication and value delivered. Courses in software development have naturally driven much of this evolution, as learning and teaching software through software has obvious benefits.

So you want to be a programmer, do ya? These tips and tools will help you get started.

Massive Open Online Courses (MOOCs)

MOOCs are an amazing resource and are making major strides in leveling the playing field for quality, affordable education. They offer much of the structure and guidance of the world’s best formal university classes, but are available online to anyone, anywhere, who has an internet connection. Many popular MOOCs are also entirely free, although for an additional price (and commitment to studying), formal credit can also be earned for many classes, equivalent to university credits.

There are many first-rate MOOC platforms available online with courses taught by professors from the world’s most prestigious universities, and community platforms so that you and your classmates around the world can help each other learn. Here are some of the best-known providers:

Be advised that, as advertised, these courses offer university-level coursework, so you better be prepared to work hard to get through them!

Guided Tutorial Websites

If you like structure and guidance, but don’t like deadlines, there are a lot of great online platforms that provide automated, step-by-step training through a wide range of delivery methods. Some are driven by video tutorials, some by text. Many include interactive code editors for you to practice on in your browser. These give you great flexibility to learn at your own pace, be it a half-hour of practice at the end of each day or a 10 hour marathon on the weekend.

While many of these platforms require a paid subscription in order to access all the content, most offer free trials so that you can get started right away, and decide for yourself whether it works for you.

This is just a short list, so search around and see what else is out there!

Unstructured Learning

For those who want to find their own way to learn to code, or improve their knowledge on their free time, without the pressure of structured lessons, the following tools provide a self-directed approach. Even if you are going to take one of the above approaches, you may find many of these resources helpful for supplementing your learning or providing a platform for practicing.

Drill Websites

If your goal is just to practice solving programming problems, the internet, once again, has you covered. The following sites offer ever-expanding sets of coding challenges, along with interactive coding interfaces, for solving problems, having your solutions graded on the fly, and comparing how they stack up to other users’ solutions.

 

Videos

Learning programming passively has limited practicality, but if you want to absorb some of the deeper concepts, learn to code between meetings or with a glass of wine in the evening, these lecture series are some of the best out there. If you like this sort of thing, check out what else is available on YouTube and around the web.

 

Books

Even with all the wonders of technology available, for many people there is still nothing like a good book to dive into and get a deep understanding of a topic. If you like learning this way, check out Toptal’s List of Top Free Programming Books.

 

In Closing

Learning to code is a very personal journey. Everyone starts with different resources and different goals and encounters different challenges and opportunities along the way. Don’t worry about what others are doing, or how they got there. Even for experienced programmers, the journey itself never ends, as there are constantly new things to learn.

Once you've become a programmer, a world of wonders awaits you.
 

So, my advice to you is, take it slow, and enjoy the journey! There is a lot to explore, and a world of wonders awaits you. A journey of a thousand miles begins with a single step. Here are some good shoes. Good luck!

This article was written by NICK MCCREA, a Toptal Ruby developer.

Share this:

Read More