DEV Community: George

What intermediate/advanced CSS resources do you find essential?

George — Tue, 23 Jul 2019 09:49:51 +0000

I have found myself guiding traditionally non-web-based developers doing mostly intermediate front-end tasks. The discrepancy in skills and knowledge of CSS and how to properly use it between developers means I am spending a lot of time going over things such as pseudo elements, flex-box and css grid amongst others, and I am running short on time for my own work.

Im looking for any intermediate/advanced resources or courses to point others (and myself) towards when they are trying to get their head round some of the newer, less used or less well known parts of CSS, as well as a solid foundation.

Free courses preferred, although good paid resources are an option. Thanks!

What would you change about your job/work environment? 👨‍💻👩‍💻

George — Mon, 24 Jun 2019 14:48:20 +0000

How do you handle improper function arguments?

George — Wed, 19 Jun 2019 09:06:08 +0000

I've recently been thinking about how to improve my code patterns to give my work a more consistent and easy to understand feel.

Working functionally means that every function must return a response. If a function was to receive incorrect arguments, then how should it respond?

Returning false for any anomalous behaviour (invalid input/error catch) and handling that in the parent is the best solution I have come up with.

How do you handle this scenario?

What would you like to see implemented on DEV?

George — Tue, 04 Jun 2019 09:39:37 +0000

Disclaimer: I am not part of the DEV team

Im constantly seeing Ben and other people on the DEV team opening new issues on GitHub to try and implement features from posts that the community has left. Let's centralise this discussion if possible.

What new features/changes/tweaks and anything else, would you like to see implemented on DEV?

Using arrow functions might be costing you performance

George — Fri, 31 May 2019 09:50:06 +0000

Oh, and so might implicit returns…

Background

We all know and love arrow functions, the clean looks, the convenience. But using them does come at a cost.

Firstly, if you are not familiar with arrow functions, this is a simple comparison of how they compare to normal functions.

// Traditional function declaration
function functionName (...parameters) {
    // Do some stuff…
    return result
}

// The same function as an arrow function
const functionName = (...parameters) => {
    // Do some stuff…
    return result
}

Okay, I know what arrow functions are. How are they bad?

JavaScript is compiled at runtime, unlike other languages which require compilation before use. This means that we are relying on the runtime compilation engine to properly interpret and process our code efficiently. This means that different implementations can be processed differently under the hood, despite giving the same outcome.

Comparisons

To test I wrapped the function calls for the functions below in a console.time/console.timeEnd sandwich and passed each one the same variables.

// Traditional function
function foo(bar) {
    return bar
}

// Arrow function
const foo = bar => {
    return bar
}

// Arrow function with implicit return (remember this from the beginning?)
const foo = bar => bar

Results

Traditional function: 0.0746ms
Arrow function: 0.0954ms
Arrow function with implicit return: 0.105ms

Conclusion

Arrow functions and especially arrow functions using implicit returns do take more time to run compared to traditional functions. Implicit returns suffer from the same issues that arrow functions do, in that they take more compilation time. In larger scripts this could feasibly lead to noticeable performance costs, especially if contained within loops.

Does this mean that we should all stop using them then?
Well i'm not going to, and i'm not going to recommend that you stop either. I would hope that everyone is minimizing their code for production. All major minimizers will pre-compile your code in to traditional functions, just for compatibility reasons, negating the performance loss in real world use. If you are experiencing slowdowns in an unminified development environment, then you could consider this as a possible issue. In reality though, a poorly optimized loop will incur many more performance costs than a few arrow functions.

All tests were run 5 times and averaged using Google’s V8 engine running on NodeJs.
Firefox’s SpiderMonkey and Microsoft’s ChakraCore display similar results although were not tested.

TIL #0: Destructuring in JS

George — Tue, 28 May 2019 15:00:30 +0000

Today I learned (TIL) is a way of sharing with the community things that I have recently learned which I feel others may benefit from. These may be obvious to those who already know, all the way to the strange and obscure. At the end of the day we are all learning, so we may as well help each other!

What is destructuring?

Destructuring was added as part of ES6, as a way of extracting properties from JavaScript objects and arrays into variables. It makes working with large objects much simpler and I wish I had discovered it earlier!

Arrays

The type of destructuring I have seen most frequently in the wild is with arrays.

const colors = ['Red', 'Green', 'Blue', 'Yellow', 'Purple', 'Pink', 'Cyan']

const [r,g,b, ...otherColors] = colors

console.log(r) // 'Red'
console.log(g) // 'Green'
console.log(b) // 'Blue'
console.log(otherColors) // ['Yellow', 'Purple', 'Pink', 'Cyan]

By assigning an array to an array of variables, we can easily assign individual variables to each value. Use of the spread operator allows us to create a new array of all the remaining elements.

Objects

The standard way to access object properties is with dot notation.

const user = {
    name: 'Bob',
    age: 32,
    city: {
    name: 'London'  
  }
}

const name = user.name
const age = user.age
const locationName = user.city.name

console.log(name) // Bob
console.log(age) // 32
console.log(locationName) // London

This is fine for simple objects, but can become a pain to type if we are trying to access many properties. Enter destructuring.

JS Result
EDIT ON
 const user = { // Structure taken from Dev.to users API endpoint
  "type_of":"user",
  "id":12345678,
  "username":"Bob_the_nameless",
  "name":"Bob",
  "summary":"An example user",
  "twitter_username":null,
  "github_username":"UndefinedUser",
  "website_url":"www.example.com",
  "location":"London",
  "joined_at":"Jan 11, 2018",
  "profile_image":"urlToSomeImage.jpg"
}

// Too many parameters to want to write by hand to conveniently use
// Use destructuring

const {username, name, joined_at} = user

console.log(username) // 'Bob_the_nameles'
console.log(name) // 'Bob'
console.log(joined_at) // 'Jan 11, 2018'

By naming our variables the same as the object we can easily extract them. But what about nested objects will we still need dot notation? Yes but it’s way better.

const user = {
  "type_of":"user",
  "id":12345678,
  "name":"Bob",
  "summary":"An example user",
    "social_media": {
    "usernames": {
      "twitter_username":null,
      "github_username":"UndefinedUser",
      "devto_username":"Bob_the_nameless"
    }
    },  
  "website_url":"www.example.com",
  "location":"London",
  "joined_at":"Jan 11, 2018",
  "profile_image":"urlToSomeImage.jpg"
}

const {twitter_username, github_username, devto_username} = user.social_media.usernames

console.log(twitter_username) // null
console.log(github_username) // 'UndefinedUser'
console.log(devto_username) // 'Bob_the_nameless'

As you can see, we can save ourselves retyping the whole path for every variable.

I haven't covered all the use cases of this, only the few I find to be the most useful. A complete list of examples can be found on MDN. I hope this helps some of you save some time down the line!

Networking as a developer - Why and How?

George — Sat, 23 Mar 2019 14:12:34 +0000

Let's start with the elephant in the room, what actually is networking?

Networking is about creating a shared bond with someone, having similar goals, values and interests. This can be professional goals and learning, shared sports and social interests or anyone you find yourself spending any significant amount of time with.

Who should be in my network?

Your aim with a network should be to surround yourself with people you feel you could reasonably turn to for advice or maybe ask a favour from. Don't have a network of people that you cannot keep up to date with. Your network can and should extend past your professional sphere into every aspect of your life, friends and family are absolutely included. Don't forget to consider the barista you see every day before work, your neighbour or the cleaner at work. You never know if you will get a free coffee time to time, a parcel collected or your lunch exploded in the microwave at work and you just need a non judgemental cleanup.

Your network is not just limited to Linkedin, it is also the people in your phone book and those who you interact with on a regular basis day to day. You cannot stand on the shoulders of giants without a helping hand up.

Why should I network, I am doing fine on my own?

There are the obvious benefits, that are the larger goals from networking such as: job opportunities and industry connections with specialist knowledge or access to new clients. But it is the hidden benefits that make your life easier and opportunities easier to take. New learning opportunities and directions to put you ahead of the market, invites to closed events and career advice. But also support while having a bad day whether professionally or socially, you can have someone there to just make life that little easier.

Having a network is also good for your overall health and well-being; something that we, as developers, ignore far too often. It can be used for getting help when dealing with stressful work or life situations. Helping other people with their issues and problems is also a great way to reinforce your learning, and build a stronger relationship with that person. Strong relationships are key to having good mental health.

Networking sounds good, but i'm not a social person, can I still network?

We all know the traditional idea of networking as portrayed by films. Lots of business minded, self assured extroverts, mingling around a room, all talking themselves and others up, handing out business cards left, right and centre. Perhaps sipping on their complimentary glass of prosecco that their overpriced ticket promised. Each person trying to find others to help them climb the greasy pole. Is this really all that networking is? Well, no.
Fortunately as developers and professionals within the tech industry, there are countless ways to network and build connections with others that don't involve having to give the hard sell to someone you have just met.

Local meetups: A great way to meet local developers and events are often sponsored by local companies. Many are often free to attend and happen regularly (often monthly). If you ask around then people always seem to know one or two you haven't heard of. Meetups typically have someone giving a talk about a technology or process they are passionate about and are great for generating new ideas. Meetups also usually have an “after party” where people will go and have a few drinks and a chat. This is where you will meet new connections, a good tactic is to find the speaker to ask some directed questions about their talk. Let the conversation flow from there.

Conferences: Similar to meetups but whole day/multi day events where you have a chance to meet a lot more people from a wider area. Meeting new people at these events is often harder due to the less intimate nature, but is still possible. Worst case scenario, you have seen a few good talks and learned something new, what's to lose?

Mentors: If you get a good mentor to help guide you, they will often have their own network to pull resources from. Use them to augment your own network as you learn and grow with your mentors help. You can find mentors in many places, asking someone more senior at work or someone you look up to online. Finding a mentor is another topic in itself though and there are resources out there that can help you with that.

Forums: Developer platforms such as Medium, Dev.to, Github and others are great for communicating and learning from other developers. Follow and interact with content from those you look up to and learn from. Engage with their content and ask questions, maybe even reach out with a private message or request. It’s a less traditional form of networking, but highly effective for small requests and help.

Colleagues: An obvious one, I know. But still important, especially for day to day survival.

Friends and Family: Friends of friends and friends of family can lead to some interesting connections outside your field, and you can be recommended or talked up in circles you don't even know about. Opportunities can seemingly present themselves from nowhere for very little effort on your part.

Okay, I have a network, now how do I use it?

Stay in regular contact: There is nothing worse than someone asking a significant effort from you when you have not spoken in years. Monthly contact goes a huge way to keeping relationships alive, and keeps your connection with them relevant and meaningful. A “Hey, how is going?” is enough.

Don’t ask for too much: You wouldn't ask someone you just met to lend you a large sum of money. They don't know you, or your situation, why would they lend you anything? Ask for favours relative to the time you have invested in that connection.
Just met someone, ask if they know of any positions open at their company.
Regularly kept up to date with someone, ask if they can refer you for a position or recommend you for an internal role.
Worked for years alongside someone, and have a mutual trust and respect, ask them to risk their career and join your startup.

Don't ask too often: A larger network will help here, asking the same person for advice and guidance day after day will wear a relationship thin. If you have a lot to ask, spread it out across your network as appropriate. Don't risk burning bridges over minor requests.

Return favours: You can't take without giving. By building a network, you will be exposing yourself to the same kind of expectations as you expect from others. Be polite and helpful and set an example as to what you would want from others. Don't be afraid to decline requests, but be polite and apologetic while doing it. If you can't help, then can you point them in the right direction?

This article is inherently selfish and talks about the benefits to you, it is important to remember that every relationship works two ways. If you give back an grow your network alongside your own progression then you will always keep your network relevant, but crucially you will help your local community grow, benefiting everyone.

Critiquing my growth as a developer over the last few years

George — Sat, 16 Mar 2019 12:53:54 +0000

Mid 2016 I left my Computer Science degree to have a year in industry, working as a Junior Software Engineer, as many students do. I got lucky and found myself surrounded by an amazing team of motivated developers and a line manager who pushed the entire team to take every opportunity for professional development available. During this time I completed the Free Code Camp course, attended monthly developer meetups, attended my first developer conference and grew a network amongst all the learning that comes with your first developer job. When the opportunity to remain with that team arose, I took it and didn't look back.

August 2018, I had now been a Junior Software Engineer for two years; I got an email from my University. This is the final year that they will be running my degree. I had to go back, and oh boy, what a learning experience that was.

Lessons learned from returning to university.

I think and plan as a team, not an individual.

Holy moley was this a near disaster. In over two years of working as part of a close knit team, I had lost the ability to know my own limits. My decisions with planning and project scale were way off, I was estimating deliverables as if i still had a team behind me to bounce ideas off and to benefit from our combined experience. Christmas deadlines were a mad rush to deliver the assignments and all because I had committed to deliver twice the amount of everyone around me. Assignments since have been notably better planned and sized.

I will take on more solo projects and contribute to open source to better gauge my abilities and better manage my own expectations.

I have learned how to learn.

I attend lectures and seminars, get a barrage of new information, and it is no longer daunting. Working in languages I had never used days before I am able to make good headway with assignments where in the past this would have been a large hurdle to overcome. I know how to read and understand language documentations, how to structure searches to get the most relevant and useable results. A skill I only now realise is something I had gained. Looking back at assignments from previous years, they are laughably simplistic and poorly coded. All work that I thought was amazing at the time.

This is something I feel is critically important to never stop, the idea of becoming comfortable in a position and having my development stagnate terrifies me. Feeling like I am making progress towards a goal gives me purpose and drive and is the one thing that I encourage everyone to do.

I have learned how to teach.

Unfortunately there was no escaping the dreaded team project. Trying to coerce team members to attend meetings and stop waiting for other people to do work for them was an interesting challenge. I think it was more that people were burying their heads in the sand because they didn't know how to start working on something they hadn't ever been taught. Walking the team through code and patterns that would help them with their sections had a massive improvement to the engagement of some of the more unwilling members. I am now the goto person in the group now for any technical questions. Taking 15 minutes out of my day to help people and talk them through their code issues is much less stressful than wondering why there is no work delivered.

I want to write blog posts, I read lots and feel like I should share my knowledge and findings. I am sorry that many will likely be covering the same topics as others have already discussed in detail, but I hope that my own spin will help some people in some way. If just one person finds my posts useful or enjoyable, i'm going to call that a win.

I can now manage my time.

In previous years, I would be one of many, rushing assignments the day before the deadline and pulling an all nighter just to have something to hand in on time. Now I am the polar opposite, I have completed assignments, weeks or months in advance of their due dates and can refine them as needed nearer the time. I am less stressed and am working the same or less hours than I was near the end of other years and produce much better results.

Organised is not a word I ever thought I would label myself with till now. A pleasant surprise. I may even start using a calendar in the future 🤷.

In conclusion.

Returning to full time, formal education was a shock to the system, but also grounding. It gave me a solid benchmark to base my progress from and has left me pleasantly surprised with the person I have become. It is all too easy to doubt yourself when you are mentoring new team members on a project when they are more qualified than you are, or are considering applying for a promotion without any academic background to speak of. I no longer feel like an imposter in the industry and can have confidence in my decisions.

I will be looking for other benchmarks to compare myself to in the future, and I encourage everyone to. You may be pleasantly surprised!

Thank you to @rachelsoderberg for giving me the confidence to write this, my first blog post. Your Junior Developers Should Start A Technical Blog Early In Their Career post, made me realise that I have to start somewhere, sometime, and that may as well be here and now.

Not an active person on social media, I don't think I would escape. Will update if anything changes in the future.