hazbo

I'm at a place now where I'm really happy with my manager, and my manager's boss, the CTO. I can sum this up pretty quickly. They listen. Like, actually listen. They are very easy to talk to about both work related issues and issues outside of work. It's like they can see what everyone is doing and even if your job for the day is to push a small bug fix, credit will be given for that. I'm recognised here as are my co-workers. It's a wonderful place to be.

I came across this tweet[0] the other day and in the replies there seemed to be many discussions sparked around the legalities of advertising / hiring based on immutable traits. From what I could gather (not a lawyer) based on what laws people were citing, is that it's "okay" to advertise in this manor, however it is not legal to actually make the hire taking into account these traits.

In the case of this tweet, I'm not sure how I feel about this, as it's clear what their goal is:

> empower and train black Computer Science students to land their first job

which seems fine. However this goal can't be achieved if a white person ends up being hired. So does the ad imply that they will only hire a black computer science student? It seems like a bit of a grey area to me.

And while I understand the article linked is about targeting only men for jobs and not for people of colour, they are similar on the basis that it is traits we have no control over.

One other point I'd like to make here, is that IF people see this as Facebook "allowing" to filter by immutable traits, in this case Twitter is essentially doing the same, by allowing these kinds of posts.

I'd love to hear people's thoughts on this.

[0]: https://twitter.com/ryancarson/status/1039624079060267008

These are some things that I generally keep in mind whilst preparing or giving a talk. (These are just things I do, feel free to disagree.)

Preparing: 1) Give yourself enough time to write and practice the talk. If you can get ~1 month, that (for me atleast) is more than enough time.

2) Say the words out loud when practicing. You may use different words or slightly improvise during the talk, which is totally fine. Just let yourself hear some version of it a few times (out loud) before presenting. In my experience this helps to avoid stutters, and keeps you in your place.

3) Watch talks of people online that you enjoy or by people that inspire you. We all have our own "style" when it comes to public speaking. You will never be able to straight up copy someone. But watch and take mental notes as you do.

4) (If you are preparing slides), keep them simple! It is YOU who is presenting the talk. Not a wall with a projector. Treat your slides mostly as an accessory. They can help illustrate a point perhaps, or outline the key subjects. Short and simple.

Presenting: 1) If you can, make sure you have a bottle of water handy when you go up.

2) When I approach the stand, platform or stage, I like to do so with confidence. This really does depend on the setting. But for example, as I walk up, sometimes I'll take my jacket off. Or do something that otherwise makes me feel like I'm owning the space. This makes me feel much more comfortable and puts me off to a good start. Even if you're not a confident person, walk up as if you are or do something simply to make you feel more comfortable.

3) Don't be afraid to use the space you have been given. This goes both for actually walking around, and using your arms to assist your words. Hands out of pockets. Use them.

4) Pauses are a good thing! Whether it's just to take a sip of water, or just a pause for the sake of pausing. This both gives you a few moments to collect your thoughts and also a few moments for the audience to digest what you have just been saying.

5) Slowww it down. It's almost too easy sometimes to rush talks when it comes down to actually presenting one. Take your time. They came to see you! So make it worth their while.

6) This is slightly tricky in some cases, but try to calibrate yourself towards the audience. For example, in my case, I've found people seem to pay more attention if I've just said something slightly amusing. If you can get away with it, go for it! It's a hard one to explain, but the bottom line is, try to get the crowd on the same page. I'll perhaps think of a better way of explaining this one and reply to this comment.

Given that errors and error handling itself is a very normal thing to come across in most projects, would the abbreviated `err` not seem more familiar than defect or fault, to you?

Andrew Gerrand did a great talk a while back (I'll try to hunt it out) in which he talked about naming conventions. One of the things that stuck out for me, was when he said, if you're declaring a variable that is only going to be used very locally (i.e. within the next few lines or around there), then using a short name is preferred. So instead of 'response', you would simply use 'resp'. However if you're declaring something that may be used in a different part of the file, or Go package itself, go with something more verbose as to not confuse someone seeing it for the first time with no prior context. Also `error` is meaningful in Go, so `err` is used pretty much all the time.

Something I pretty much do and have heard from other Go people that they do this also, is to just keep all my projects in the GOPATH. Whether they be written in Go or not. It essentially gives you an organised structure based on git URLs, so it's always easy to find anything. I use $HOME/go, and have projects in there written in a bunch of languages.

If package `github.com/foo/bar` imports a nested package, say, `github.com/foo/bar/baz`, this will break as it will be trying to look for said package in `$GOPATH/src/github.com/foo/bar/baz`.

To answer 2) yes, you're correct. If there is a main package that exists at `github.com/your-username/hello`, a go get will leave the resulting binary in $GOPATH/bin.

I haven't tried that before but that could be a good idea. I just hope my accent doesn't make it too obvious!

I made an effort to learn Dutch for around 6 months of last year. Although it's a well known as a language, it's only spoken natively by around 20 million(ish), so isn't massively useful outside of the Netherlands and Belgium, among a few other places in the world. My first language is English. I just wanted a second language under my belt and I enjoy spending time in the Netherlands. The problem with learning Dutch is, most people (that I came across at least) in the Netherlands are already fluent in English and from my experience it seemed like they'd much rather just speak to you in English. So to actually speak Dutch there, it's important to be clear that you don't want to converse in English and that you're trying to improve your skills. It was really important to me that I'd speak a bit of Dutch every day, ideally to native speakers. This requires a bit of effort (as I live and spend most of my time in England), but it's suprising how easy it is to either find Dutch people here to speak to and also online.

It benefited me in the sense that I ended up making some new friends out of it and had a lot of fun just learning (or trying to learn) a second language. I think learning a new language like this can open up some doors and can help you meet a lot of new interesting people you'd perhaps not have met otherwise. I'd love to pick it up again next year. So we'll see.

You make a fair point. I've seen this happen before and after a while, projects that have essentially turned into a poor framework, plus the application, can become somewhat of a pain to maintain.

PHP has come a long way in the past few years and the amount of open source packages has become huge, especially since the adoption of composer. I think with that in mind, it is now easier to build and maintain PHP applications without a framework as such, but just with the components you specifically need. Like yourself, I haven't actively been working with PHP for a while either. But it's been interesting to watch what's been happening with it and it's community.

This has inspired me to quickly knock up a Dockerfile for fans of Alpine based containers, if anyone is interested.

https://github.com/hazbo/phoenix-docker-alpine

Much better on the iPhone 6. Don't bail.