Advice From A 19 Year Old Girl & Software Developer

Advice From A 19 Year Old Girl & Software Developer

Hardik Gandhi   February 05, 2018

Don’t worry, this won’t be one of the I wake up at 4AM every morning and go for a 20km run… -‘inspirational’ posts, that make people feel like they need to be some kind of super-human in order to be a good developer.

Some people might know me as ‘the girl that never does anything else but coding’ from Instagram (@theavocoder), but I’ve never really shared what I actually do on a normal day, and have done in order to become a software developer!

How I got into coding

I’m Lydia, a 19 year old girl living in Stockholm, and I am a JavaScript (React) developer! I’m very active on social media, and try to motivate more people to join the tech world by showing what my life is like in this community.

I started coding when I was 15 years old. I had a booming health & lifestyle blog on Tumblr and gained tens of thousands of followers in no-time. This is when I started creating my own responsive layouts with the regular HTML, CSS and jQuery, as I didn’t like the themes that I could buy, so I decided to just try it myself! From there on, I kept on improving my skills, gained more knowledge, and my interest in developing grew. However, I had no idea that this was already considered coding and that I could do this for a living, I simply enjoyed creating my own designs from scratch and seeing that people loved the layouts that I built and were willing to pay me for it!

I went to high school until I was 18, and absolutely hated it. I felt like I was wasting so much time on subjects that could in no way improve my future (looking at you, ancient Greek and Latin!). Nonetheless, I worked extremely hard for my diploma, worked on many personal side-projects, and have always been busy tutoring and supporting people! People have described me as the most hardworking, yet most relaxed person they’ve ever met, and I think that describes my mindset perfectly. But we’ll get back to that later!

After I finished high school, I decided to not go to university. This was a very scary step for me, as I was kind of brainwashed into thinking that that’s the only way to have a successful future: everyone around me went to the best universities! I spent so much time trying to get the best grades in high school to eventually go to a good university, did I really just waste so many years of my life for nothing? Yup, pretty much, but I don’t at all regret it! Most of the people around me didn’t understand and thought I was making a big mistake, but the small amount of people that understood and supported me really motivated me.

I’ve always been very independent: I moved to another country by myself when I was 18, travelled a lot on my own during my teens, and have always been busy doing anything to improve my future. I’ve never felt pressured into doing stuff because society wanted me to, I’ve always done my own thing. After I decided to not go to university, but give my 110% to programming instead, I went to a coding bootcamp for 3 months in Tampa Bay, Florida. I didn’t have to do this, but it definitely helped me to get some structure and be surrounded by other people who enjoyed programming as well, as I didn’t have that before. I coded intensively, was constantly out of my comfort-zone (which I love), put a lot of effort into my personal projects to improve my coding skills, and learned so many new technologies.

Guess what? Even during the 3 months, an insane amount of recruiters reached out to me asking if I could work for them. It was after I created a LinkedIn profile and could show the work I put so much effort into. As a 19-year-old girl with no work experience whatsoever, it was kind of overwhelming. I didn’t understand: did they not read my LinkedIn profile? I didn’t go to university or anything, why would so many companies want me?

Because you don’t learn how to code at school. You learn how to code by writing programs in it. Most companies don’t care if you have a nice paper saying that you studied programming at college: people care that you can show that your coding skills are good, and that you love to code.

Don’t get me wrong. If you like life at college, or simply need some more structure in your life, then it’s definitely a good decision to go there. However, don’t feel pressured. The programming community can be harsh: they hate on each other because of the language they program in, they make it seem like it’s normal to get 2 hours of sleep because you have to code all night long, and that eating junk-food and sitting all day is simply the way it is. It’s absolutely not the case.

My daily life (outside of work)

After the bootcamp ended, I flew back to Stockholm. I was extremely excited to start this new chapter in my life, and couldn’t wait to keep on growing. So what do I do nowadays on a regular day?

I wake up and try to stretch. This sounds like the typical ‘inspirational’ post I talked about earlier (they’re like everywhere in LinkedIn, it’s driving me crazy!), but it’s extremely important. You sit for hours and hours, and your body definitely suffers if you don’t take care of it. It also really wakes you up, as your heart rate increases and your brain gets more oxygen.

I try to watch online coding courses for at least 2 hours per day. I love watching online courses, because I always learn new things and get inspired by seeing the instructor writing the code with such ease. I try to give my own twist to it by working on a similar project on the side, just slightly different, so I’m not simply copying what the instructor is doing. Also, it’s perfect when you just don’t want to get out of bed and still feel like you’ve been productive ;)

I try to work on my personal projects for at least 4 hours. They make me feel super uncomfortable. I always try to use languages or techniques I’ve never used before, so I get more experience with them. And let’s be honest, it can be horrible! I’m not going to lie and say that if you work hard, you’ll get there (which you will but that’s not the point), but I also really want to emphasise on the fact that learning something new can be an emotional rollercoaster. You will feel demotivated, feel like you’ll never understand it, and really question your coding skills. If you do, congratulations! You’re a normal human being! Feeling these emotions isn’t the important part here: what you do about it is the most important part. Research it, reach out to people, write your own Stack Overflow questions (and be a hero to many people out there), and simply keep on trying until you find a solution. And if you don’t, that’s completely fine. After some time, you will probably look back at it and think “how couldn’t I get this back then?!”.

I try to read at least 2 articles. I really like seeing things from a different perspective. The articles can be about anything: how to solve a certain coding problem, why JavaScript sucks sometimes, or what the coolest new technologies are. It’s important to not get stuck in a certain mindset!

I try to solve at least 5 CodeWars Kata. CodeWars is your best friend when you just get into coding, but also when you’ve been coding for many decades! The solutions to the problems they give you are often very useful, as you will learn to improve your syntax a lot by just scrolling through the solutions that other people gave. And another big plus: when you go for your coding interview, they often give you questions that are very similar to the ones on CodeWars!

I try to not eat junk-food. Eating nutritious food keeps me very alert and, most of all, happy! I feel so much more energized and motivated when I’ve had a very healthy breakfast and lunch, which definitely improves my coding capabilities. Don’t go for fast and easy, but think long term: the better your body, the better your mind, the better your code!

Plus: you can still stretch/meditate while coding!

Did you notice something? I kept on saying “I try”. Because I’m not going to force myself to do things when I just can’t do them. I don’t want to give myself a bad feeling when I haven’t worked on my personal projects, or when I’ve eaten junk-food. Giving my 110% is my focus, but I’m human: on some days I just don’t want to code, feel tired, and just want to watch Netflix all day. And that’s completely fine! Find the right balance between relaxation and hard work. This comes back to the comments people make about me being the most hardworking yet relaxed person they’ve ever met: but it’s not easy to have this mindset!

It took me a long time to not feel bad when I hadn’t worked all day long. Especially after joining Instagram: I constantly saw posts of people coding so much that I felt like I also had to do that and simply didn’t have time to take a day off. But once I started to make relaxation an important part of my life, everything got better. I felt so much happier and I was much more motivated to work a lot.

Conclusion

By writing this article, I hope to inspire some people to also get involved in the tech world, and that it’s really not as scary as it seems. Programming isn’t only for the super intelligent super-humans like they portray in movies. Programming is for anyone who loves to create, who loves to get out of their comfort zone, and for anyone who loves to improve themselves!

To conclude, my final advice:

• You really don’t have to go to college, as long as you can really push yourself and show your passion for coding!
• Always give your 110% whenever you can, and show the world what you’re capable of by getting your name out there. However, always prioritize your health. Sleep is very important!
• It is completely normal to feel uncomfortable and to think that you’re really bad at coding, don’t let this bring you down. Everyone thinks this from time to time.
• Always remind yourself of how far you’ve come already. It’s really easy to forget how much you’ve improved, but just compare yourself now to a month ago! I can assure you it’s a lot more than you’d think.
• Don’t let other people make you feel like the language you program in is a bad language. It’s literally not, and it’s most likely very necessary and useful!

Source :Lydia Hallie

An introduction to Progressive Web Apps

An introduction to Progressive Web Apps

Hardik Gandhi   January 31, 2018

Progressive Web Apps (PWA) are the latest trend in mobile application development using web technologies. At the time of writing (early 2018), they’re only applicable to Android devices.

PWAs are coming to iOS 11.3 and macOS 10.13.4, very soon.

WebKit, the tech underlying Safari and Mobile Safari, has recently (Aug 2017) declared that they’ve started working on introducing Service Workers into the browser. This means that soon they will land in iOS devices as well. So the Progressive Web Apps concept will likely be applicable to iPhones and iPads, if Apple decides to encourage this approach.

It’s not a groundbreaking new technology, but rather a new term that identifies a bundle of techniques that have the goal of creating a better experience for web-based apps.

What is a Progressive Web App

A Progressive Web App is an app that can provide additional features based on what the device supports, providing offline capability, push notifications, an almost native app look and speed, and local caching of resources.

This technique was originally introduced by Google in 2015, and proves to bring many advantages to both the developer and the users.

Developers have access to building almost-first-class applications using a web stack. This is always considerably easier and cheaper than building native applications, especially when considering the implications of building and maintaining cross-platform apps.

Devs can benefit from a reduced installation friction, and at a time when having an app in the store does not actually bring anything in terms of discoverability for 99,99% of the apps, Google search can provide the same benefits if not more.

A Progressive Web App is a website which is developed with certain technologies that make the mobile experience much more pleasant than a normal mobile-optimized website. It almost feels like working on a native app, as it offers the following features:

• Offline support
• Loads fast
• Is secure
• Is capable of emitting push notifications
• Has an immersive, full-screen user experience without the URL bar

Mobile platforms (Android at the time of writing, but it’s not technically limited to that) offer increasing support for Progressive Web Apps. They even ask the user to add the app to the home screen when that user visits such a site.

But first, a little clarification on the name. Progressive Web App can be a confusing term, and a good definition is: web apps that take advantage of modern browsers features (like web workers and the web app manifest) to let their mobile devices “upgrade” the app to the role of a first-class citizen app.

Progressive Web Apps alternatives

How does a PWA stand compared to the alternatives when it comes to building a mobile experience?

Let’s focus on the pros and cons of each, and let’s see where PWAs are a good fit.

Native Mobile Apps

Native mobile apps are the most obvious way to build a mobile app. Objective-C or Swift on iOS, Java /Kotlin on Android and C# on Windows Phone.

Each platform has its own UI and UX conventions, and the native widgets provide the experience that the user expects. They can be deployed and distributed through the platform App Store.

The main pain point with native apps is that cross-platform development requires learning, mastering and keeping up to date with many different methodologies and best practices. If, for example, you have a small team or you’re a solo developer building an app on 3 platforms, you need to spend a lot of time learning the technology and environment. You’ll also spend a lot of time managing different libraries and using different workflows (for example, iCloud only works on iOS devices — there’s no Android version).

Hybrid Apps

Hybrid applications are built using Web Technologies, but are deployed to the App Store. In the middle sits a framework or some way to package the application so it’s possible to send it for review to the traditional App Store.

Some of the most common platforms are Phonegap and Ionic Framework, among many others, and usually what you see on the page is a WebView that essentially loads a local website.

I initially included Xamarin in the list, but Carlos Eduardo Pérez correctly pointed out that Xamaring generates native code.

The key aspect of Hybrid Apps is the write once, run anywhere concept. The different platform code is generated at build time, and you’re building apps using JavaScript, HTML and CSS, which is amazing. The device capabilities (microphone, camera, network, gps…) are exposed through JavaScript APIs.

The bad part of building hybrid apps is that, unless you do a great job, you might settle on providing a common denominator. This effectively creates an app that’s sub-optimal on all platforms because the app is ignoring the platform-specific human-computer interaction guidelines.

Also, performance for complex views might suffer.

Apps built with React Native

React Native exposes the native controls of the mobile device through a JavaScript API, but you’re effectively creating a native application, not embedding a website inside a WebView.

Their motto, to distinguish this approach from hybrid apps, is learn once, write anywhere. This means that the approach is the same across platforms, but you’re going to create completely separate apps in order to provide a great experience on each platform.

Performance is comparable to native apps, since what you build is essentially a native app which is distributed through the App Store.

Progressive Web Apps features

In the last section, you saw the main competitors of Progressive Web Apps. So how do PWAs stand compared to them, and what are their main features?

Remember — currently, Progressive Web Apps are for Android devices only.

Features

Progressive Web Apps have one thing that separates them completely from the above approaches: they are not deployed to the app store.

This is a key advantage. The app store is beneficial if you have the reach and luck to be featured, which can make your app go viral. But unless you’re in the top 0.001% you’re not going to get much benefit from having your little place on the App Store.

Progressive Web Apps are discoverable using Search Engines, and when a user gets to your site that has PWAs capabilities, the browser in combination with the device asks the user if they want to install the app to the home screen. This is huge, because regular SEO can apply to your PWA, leading to much less reliance on paid acquisition.

Not being in the App Store means you don’t need Apple’s or Google’s approval to be in the users pockets. You can release updates when you want, without having to go through the standard approval process which is typical of iOS apps.

PWAs are basically HTML5 applications/responsive websites on steroids, with some key technologies that were recently introduced to make some of the key features possible. If you remember, the original iPhone came without the option to develop native apps. Developers were told to develop HTML5 mobile apps that could be installed to the home screen, but the tech back then was not ready for this.

Progressive Web Apps run offline.

The use of service workers allow the app to always have fresh content, which can be downloaded in the background, and to provide support for push notifications, which offer greater re-engagement opportunities.

Also, sharability makes for a much nicer experience for users that want to share your app, as they just need a URL.

Benefits

So why should users and developers care about Progressive Web Apps?

1. PWA are lighter. Native Apps can weigh 200MB or more, while a PWA could be in the range of the KBs.
2. There’s no native platform code
3. The cost of acquisition is lower (it’s much more difficult to convince a user to install an app than to visit a website to get the first-time experience)
4. Significantly less effort is needed to build and release updates
5. They have much more support for deep links than regular app-store apps

Core concepts

• Responsive: the UI adapts to the device screen size
• App-like feel: it doesn’t feel like a website but rather like an app (as much as possible)
• Offline support: it will use the device storage to provide an offline experience
• Installable: the device browser prompts the user to install your app
• Re-engaging: push notifications help users re-discover your app once installed
• Discoverable: search engines and SEO optimization can provide a lot more users than the app store
• Fresh: the app updates itself and the content once it’s online
• Safe: it uses HTTPS
• Progressive: it will work on any device, even older one, even if it has fewer features (e.g. just as a website, not installable)
• Linkable: it’s easy to point to it using URLs

Service Workers

Part of the Progressive Web App definition is that it must work offline.

Since the thing that allows the web app to work offline is the Service Worker, this implies that Service Workers are a mandatory part of a Progressive Web App.

WARNING: Service Workers are currently only supported by Chrome (Desktop and Android), Firefox, and Opera. See http://caniuse.com/#feat=serviceworkers for updated data on the support.

TIP: Don’t confuse Service Workers with Web Workers. They are a completely different thing.

A Service Worker is a JavaScript file that acts as a middleman between the web app and the network. Because of this it can provide cache services, speed the app rendering, and improve the user experience.

For security reasons, only HTTPS sites can make use of Service Workers, and this is part of the reason why a Progressive Web App must be served through HTTPS.

Service Workers are not available on the device the first time the user visits the app. On the first visit the web worker is installed, and then on subsequent visits to separate pages of the site, this Service Worker will be called.

Check out the complete guide to Service Workers at https://www.writesoftware.org/topic/service-workers

The App Manifest

The App Manifest is a JSON file that you can use to provide the device information about your Progressive Web App.

You add a link to the manifest in every header on each page of your web site:

<link rel="manifest" href="/manifest.json">

This file will tell the device how to set:

• The name and short name of the app
• The icons’ locations, in various sizes
• The starting URL, relative to the domain
• The default orientation
• The splash screen

Example

{ 
  "name": "The Weather App", 
  "short_name": "Weather", 
  "description": "Progressive Web App Example", 
  "icons": [{
    "src": "images/icons/icon-128x128.png",
    "sizes": "128x128",
    "type": "image/png" 
  }, { 
    "src": "images/icons/icon-144x144.png",
    "sizes": "144x144", 
    "type": "image/png" 
  }, { 
    "src": "images/icons/icon-152x152.png",
    "sizes": "152x152", 
    "type": "image/png" 
  }, { 
    "src": "images/icons/icon-192x192.png",
    "sizes": "192x192", 
    "type": "image/png" 
  }, { 
    "src": "images/icons/icon-256x256.png", 
    "sizes": "256x256", 
    "type": "image/png" 
  }], 
  "start_url": "/index.html?utm_source=app_manifest", 
  "orientation": "portrait", 
  "display": "standalone", 
  "background_color": "#3E4EB8",
  "theme_color": "#2F3BA2" 
}

The App Manifest is a W3C Working Draft, reachable at https://www.w3.org/TR/appmanifest/

The App Shell

The App Shell is not a technology but rather a design concept. It’s aimed at loading and rendering the web app container first, and the actual content shortly after, to give the user a nice app-like impression.

Take, for example, Apple’s Human Interface Guidelines’ suggestion to use a splash screen that resembles the user interface. This provides a psychological hint that was found to lower the perception that the app was taking a long time to load.

Caching

The App Shell is cached separately from the contents, and it’s setup so that retrieving the shell building blocks from the cache takes very little time.

---

Thanks for reading through this tutorial. There’s a lot to learn about this topic and the new browser APIs. I publish a lot of related content on my blog about frontend development, don’t miss it! 😀

---

JavaScript — Null vs. Undefined

JavaScript — Null vs. Undefined

Hardik Gandhi   January 13, 2018

Learn the differences and similarities between null and undefined in JavaScript

At first glance, null and undefined may seem the same, but they are far from it. This article will explore the differences and similarities between null and undefined in JavaScript.

---

What is null?

There are two features of null you should understand:

• null is an empty or non-existent value.
• null must be assigned.

Here’s an example. We assign the value of null to a:

let a = null;

console.log(a);
// null

What is undefined?

Undefined most typically means a variable has been declared, but not defined. For example:

let b;

console.log(b);
// undefined

You can also explicitly set a variable to equal undefined:

let c = undefined;

console.log(c);
// undefined

Finally, when looking up non-existent properties in an object, you will receive undefined:

var d = {};

console.log(d.fake);
// undefined

---

Similarities between null and undefined

In JavaScript there are only six falsy values. Both null and undefined are two of the six falsy values. Here’s a full list:

• false
• 0 (zero)
• “” (empty string)
• null
• undefined
• NaN (Not A Number)

Any other value in JavaScript is considered truthy.

If you’re not familiar with truthy/falsy values in JavaScript, I recommend reading my previous article: JavaScript — Double Equals vs. Triple Equals

Also in JavaScript, there are six primitive values. Both null and undefined are primitive values. Here is a full list:

• Boolean
• Null
• Undefined
• Number
• String
• Symbol

All other values in JavaScript are objects (objects, functions, arrays, etc.).

Interestingly enough, when using typeof to test null, it returns object:

let a = null;
let b;

console.log(typeof a);
// object

console.log(typeof b);
// undefined

This has occurred since the beginning of JavaScript and is generally regarded as a mistake in the original JavaScript implementation.

If you’re not familiar with data types in JavaScript, I recommend reading my previous article: JavaScript Data Types Explained

---

null !== undefined

As you can see so far, null and undefined are different, but share some similarities. Thus, it makes sense that null does not strictly equal undefined.

null !== undefined 

But, and this may surprise you, null loosely equals undefined.

null == undefined

The explanation as to why this is true is a little complex, so bear with me. In JavaScript, a double equals tests for loose equality and preforms type coercion. This means we compare two values after converting them to a common type. Since both null and undefined are falsy values, when we compare them with loose equality, they are coerced to false prior to comparison.

Practical Differences

All of this is great, but what about a practical difference between null and undefined?

Consider the following code snippet:

let logHi = (str = 'hi') => {
  console.log(str);
}

The code above creates a function named logHi. This function requires one parameter and sets the default of that parameter to hi if it isn’t supplied. Here’s what that looks like:

logHi();
// hi

We can also supply a parameter to overwrite this default:

logHi('bye');
// bye

With default parameters, undefined will use the default while null does not.

logHi(undefined);
// hi

logHi(null);
// null

Thanks to Tim Branyen for the code inspiration.

---

Summary

• null is an assigned value. It means nothing.
• undefined typically means a variable has been declared but not defined yet.
• null and undefined are falsy values.
• null and undefined are both primitives. However an error shows that typeof null = object.
• null !== undefined but null == undefined.