Nobody can put a popup over your stuff and say “Don’t look at the content right now. It’s so much better if you login!”.
Nobody can build their brand off of your work. Nobody can make money off of your work, if you don’t want to.
Nobody can tell you “You can’t have your own domain on here.”
Your hoster will most likely not suddenly go: “Oops we just went out of business / were acquired, we’re deleting all your stuff but you can export it until tomorrow and fuck off, basically.”
And if they do, you can go and host that somewhere else.
You can still decide to re-distribute your content to places like Medium, dev.to, Micro.blog, Twitter, Instagram, Linkedin, Facebook and / or via a newsletter. It’s a good way to extend your readership.
You can have an RSS feed! That feed should always be under your domain!
Writing on the internet under other peoples / companies domain names is like giving away money.
Sure, sometimes it makes sense to guest-post on somebody else’s blog because it broadens your audience. That’s a good trade-off.
You should just always have a place that people can come back to that is yours.
Since I realized that constraints can produce more creative outcomes I‘ve been fascinated by it.
I think I first learned about it when the iPhone became popular and the form factor and usage patterns produced beautifully designed apps and then website and web app designs that were optimized for mobile.
I read up on it a little and there seems to be a pretty logical explanation for this.
In an environment of abundance the brain is not being challenged. The brain likes to be efficient as possible. If there is an abundance of resources it’s going to be harder to be creative because your brain has no incentive to really get into gear.
In a situation where you are confronted with resource scarcity of some kind, your brain has no choice to start turning up in order to find out how to work around the scarcity.
This results in more creative, out-of-the-box thinking.
I think there is a second element that plays a part in this as well: reduced cognitive load.
Resource scarcity could also be interpreted as: some decisions were already made for you. The fewer decisions you have to make, the more brain capacity is available to you to solve the problem at hand.
It’s a great post with lots of good advice to grow high quality followers.
I was able to watch the whole ride and it was quite something. There is one
thing I noticed about how she used Twitter that I think had significant
influence in why she blew up.
She editorializes her Twitter account. She deliberately tweets content that
might be valuable to the developer community. And she responds to tweets a lot.
She also keeps a very friendly, welcoming and helpful tone.
Be kind and provide value frequently and consistently over long stretches of
time is basically the ultimate recipe for attracting and growing an audience
on the internet. We’ve all seen this work many times.
It has happened many times over on YouTube, Twitter and of course many blogs.
The thing is, the hardest part is not to come up with the topics or to do the
writing itself. The hardest part is to keep it going in a specific rhythm over
long stretches of time.
It takes a lot of discipline to keep that up, it’s hard work. But if you can do
it, it will pay off.
My hat goes off to Emma for doing it.
If you want an audience too, follow the ultimate recipe and you most likely
will not blow up like Emma did, but you will for sure attract an audience that
cares about what you have to say.
A few weeks ago I set out to write a blog post about technical debt and the
complexities of getting rid of it, or some of it, when you work for a company.
I wanted to see what others had written about it and of course I landed on
Martin Fowler’s article about technical debt.
When I started reading it I realized that up to that point I didn’t really know
what tech debt was.
It seams that while being confronted with the eternal vastness of software
engineering, this is what my brain does: when I hear a term for the first time
and I can deduce its approximate meaning from context, I store it as a known
term. Even though I don’t know exactly what it is.
What I deduced it to be was: “Legacy code, that makes it hard to maintain your
code or to add features.”
And every time I heard or used the term “technical debt” there was a tiny little
voice in the back of my head going: “Why is it “debt”!? I don’t get it.”
Anyways good ol’ Martin cleaned up that part of my brain and made it crystal
clear for me:
Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us
think about this problem. In this metaphor, doing things the quick and dirty
way sets us up with a technical debt, which is similar to a financial debt.
Like a financial debt, the technical debt incurs interest payments, which come
in the form of the extra effort that we have to do in future development
because of the quick and dirty design choice.
We can choose to continue paying the interest, or we can pay down the
principal by refactoring the quick and dirty design into the better design.
Although it costs to pay down the principal, we gain by reduced interest
payments in the future.
It’s a metaphor! It is actually a term that was invented in order to explain
consequences of sloppy coding to people in suits!
Fowler goes on to write:
The metaphor also explains why it may be sensible to do the quick and dirty
approach. Just as a business incurs some debt to take advantage of a market
opportunity developers may incur technical debt to hit an important deadline.
The all too common problem is that development organizations let their debt
get out of control and spend most of their future development effort paying
crippling interest payments.
Thank. You. Technical debt can lead to crippling interest payments. These
can slow down your development teams so badly that you can’t compete anymore.
The term “technical debt” carries all the information you need in order to make
the argument to company leadership why getting rid of it or keeping it at bay
may be a wise business decision.
As you may know, I am a member of the JavaScript band
Nested Loops. We performed on the last three
opening performces of JSConf.eu.
We will not be performing at JSConf.eu this year.
It was a great honor and privilege for us to be able to do that and we are
thankful for the opportunity.
We produced original music for the conference and performed it in a browser. If
you want, you can re-live of our performances
on YouTube.
And you can listen to our story on the Changelog podcast
here.
I have no idea if we will ever perform again at JSConf.eu or any other event.
If you want to talk to us about performing at your JavaScript conference or any
other event, or if you needs some original music just
drop me an email or DM me on
Twitter.
This article by Dr. Axel
Rauschmayer was exactly what I needed to wrap my head around how to use async
functions without confusion.
Because I was just using them intuitively so far and because of their
synchronous style I got confused about when to try-catch. I also attempted to
call an async function without await in front of it while using await in its
body, fully expecting it will be executed synchronously.
It’s important to remember that the foundation of async functions is Promises.
The most interesting parts of Axel’s article to me, were these:
My blog is built with Hugo. Every blog I ever had was built with a static site
generator or a file based CMS. I love static site generators, they make content
management simple, they are secure and it’s fun to build websites with them.
For me, they have one problem: creating a blog post is annoying. Typically the
file for the post needs to have the date in it and the slug and then you need to
put in the Front Matter for the post. It is all just very tedious and annoying.
That’s why I made blog-cli. It creates the Markdown file for me at the right
location with the correct file name, inserts the basic Front Matter and opens
the file in my favorite Markdown editor. This means I go from post idea to
writing in 1 second.
This should work for most static site generators. At least for simple setups.
Here is how it works.
First you have to install blog-cli. You need Node.js and npm for that.
npm install --global @kahlil/blog-cli
Then you need to tell blog-cli where you want it to put your posts.
blog --path ~/my-blog/posts
Then you need to tell blog-cli about your favorite Markdown Editor.
blog --editor 'ia writer'
Now you are all set and you can create a new post and open it in your editor by
simple specifying a slug.
blog my-new-cool-post
This will create a new file with the filename: 2019-01-17-my-new-cool-post.md in
the directory you specified, ~/my-blog/posts in this case.
The Front Matter that is inserted looks something like this:
Now, if you are part of the cool kids club then you probably keep your files in
a Git repository, commit new blog posts and push them to Github at which point
it gets deployed to Netlify.
It turns out that blog-cli can help you with that as well!
blog --publish
Will automatically commit all changes with the message ‘new post’ and execute a
git push.
Nifty, right?! If you are static-site-generator-blogging as well I hope blog-cli
can help you.
If you have any ideas to improve it please send an issue or a PR
on GitHub.
I’m excited about blogs this year. It really feels like blogs and RSS feeds are
back. I am especially happy to see some developers getting serious about it.
Dan Abramov started the year off with a barrage of
really good posts of which some already went viral. People even started to
translate them into different languages. Wow.
Yoshua Wuyts started the year with a new blog as
well. With a sick dark theme, too.
Just a few days ago I stumbled over remove.bg. You can
upload any picture with a face on it and it will give you back the same picture
with the background removed and made transparent. It’s quite astonishing. How do
they do this?!
Salary negotiations at the start of a job always feel somewhat like a war to me.
Each party is trying to get on higher ground to get the tactical advantage over the other.
Typically one of those parties comes to that fight ill-prepared. Generally that’s the prospective employee.
It’s weird that your first interaction with your future employer is them basically trying to get the best of you. Companies should just pay fair market by default but they don’t. They try to get you as cheap as they can.
Here are the three most important things I learned.
1. Never give a number
If they want to know what you want to make, they want to gain leverage over you in order to lower your ask, don’t tell them.
Rather tell them:
First and foremost I am interested if we are a mutual fit. I am happy to talk about the financials later on in the process.
If they keep asking say this.
Money is not that important to me right now, I would like to find out if we are a mutual fit first. I do expect to be paid a salary that is fair market.
If they want to know what you currently make, they want to gain leverage over you to see if they can low-ball you, don’t tell them.
Rather tell them:
I don’t feel comfortable talking about the internals of my current working arrangement out of respect to my current employer.
Or just be blunt and say:
I don’t see how my current salary factors into these discussions. Let’s find out if we are a mutual fit first.”
The goal is to get them to make an offer first. That offer will be in the middle range of what they can offer you and you can negotiate up from there.
2. Always be negotiating
Always negotiate. Not necessarily because you need the money but because it represents your value at the company. It is a matter of respect and it influences how you are perceived at the company.
3. Start negotiating when you receive an offer
Since you are not giving them a number, they will make an offer. Here is where you start negotiating. At this point it is highly unlikely that they would reject you for negotiating. They simply invested too much into you already. Take your time, maybe say you have to talk it over with your spouse, or that you need to read through it in peace.
Then you could say that the offer is “interesting” but not quite there to get this done. Ask if there is flexibility on that number. They might make you another offer that is higher and that they can’t go any higher. This is where you can tell them that this offer will work if they can throw in a few more vacation days or something like stock options etc. As @patio11 puts it in his article:
You Have A Multi-Dimensional Preference Set. Use It.
This kind of tactic should get you to the high end of what is possible to get for your position. This will make you feel good and strengthen your position in the company from the get go.
To be honest, I think it is a flaw in the system and really uncomfortable that one of your first interactions with your new employer is of this nature.
There are rare cases in which it’s done differently. Basecamp for instance pays everybody the same competitive salary based on job title and current market situation. You should read their article about it, it’s such a refreshing take on this matter.
The most valuable part of the book for me personally was how she describes outlining a blog post.
I always thought outlining a post was to come up with some high-level headlines. That never really helped though, because they were too high-level and I was still busy working on the structure of the blog post on the fly while filling in the gaps between the headlines.
No, what I learned from Amy is that you have to write down each and every thought that you want to put into that post. Write them down, fuck structure, fuck grammar, fuck spelling.
Put it all on (virtual) paper. Now that you did that you can look at it and move your points around, give the whole thing some structure, delete some, add some.
Once you are happy with that, you go ahead and write the blog post. At this point its super easy because all you need to do is write it out, you are not structuring it while you write it anymore.
This makes so much sense because it completely separates writing a blog post into two smaller isolated steps:
Determine content & structure
Write it
Take this here blog post for example. When I first started writing it I started with a big introduction about the book and Amy and bla and immediately I got bored of my own words.
That made me stop and think again: what is it really I want to convey with this post?
Just Fucking Ship is great
Here is why it was great for me
So I deleted everything and just wrote Just Fucking Ship is a great book and went on writing about my greatest take-away from it.
I feel like it makes this post much more meaty and interesting for somebody to read. It definitely is much more fun to write.
For closing I would like to add that there are also many more surprising tips in that book to help you finally start and also actually ship your side project.
But instead of telling you what they are I would rather you go and support Amy Hoy and get yourself the book! It’s a really quick read and it is worth it.
Whenever I use git rebase -i to squash commits, Git opens the squasher (that’s how I just named the text view for the
interactive rebase) in VIM.
My knowledge of vimming is not very great so I used to just type i and then inch around with the arrow keys and delete
character by character in order to delete the word “pick” a bunch of times and then type “squash” a bunch of time.
Of course that was incredibly annoying, so
I finally looked up how to vim in
the squasher and it is glorious. So here is how you do it:
First, move to the line with the first commit you want to squash, which is typically the second one.
Then, enter into something called visual block mode (WTF?! What does that even mean?) by hitting ctrl + V.
Something magical happens: when you move the curser it blocks out every character you move over with white and if you
move down it will cover as many characters you covered in the line above. It looks like blocks. So I guess that’s where
the “visual block” comes in 😅.
Select all the rows you wish to squash while visually blocking out the word “pick”.
Now, more magic: hit C and type the word “squash”, after that hit esc and see the word “squash” applied in all
places that were “visually blocked out”.
If you only could exit VIM at this point, you would actually successfully squash all these commits. A boy can dream,
right?
Jan and I had the distinct honor to guest on the JS Party podcast last week to talk about Nested Loops. First of all it was a really great experience to be a guest on there. The Changelog family of podcasts are very professionally run and it was a great pleasure to be on. @noopkat, @jerodsanto and @adamstac made us feel very welcome and comfortable.
We talked about how Nested Loops was founded and immediately had band problems. Why I am rapping with a Jamaican accent. What @bonotes role is. How the tech works and evolved on the music, video and effects sides. I think it came out great and you should definitely give it a listen.
Get it by looking for JS Party in your favorite podcast app or listen right now, right here:
Reactive Programming is a paradigm that solves a lot of problems that many JavaScript frameworks partly implement by introducing some sort of “reactivity”.
That typically ties the reactivity down to one use case in the framework itself. Reactive Programming can be helpful in many more scenarios though.
One huge hurdle for adoption seems to be to grasp the actual concepts. Specifically doing push-based programming instead of pull-based.
I can relate because it did take me quite some time to get there but once the switch was flipped, so to speak, I started to think in terms of Reactive Programming instantly.
That seems to be exactly the problem, it’s not a hard concept to understand. It just takes a lot of effort to start thinking about your programming problems differently.
I am currently putting together a talk that is trying to flip that switch. I have a few ideas based on things I wished I knew in the beginning.
Basically it will focus on making you understand three things about RxJS Observables:
Observables are just functions receiving an observer
