Issue #1

Articles from the first issue, which was published on October 8th, 2018.

Choose Boring Technology http://mcfunley.com/choose-boring-technology

I love this one for many reasons. Of them is how I managed to fail an old start-up of mine right into the ground because the amount of new, hip tech was unsustainable in the face of everyday issues you run into once you start getting clients. Looking at it now, the warning signs were so clear, even at the early stage. A library almost works with our cool stack? Lets just fork it and maintain a patched version, right? It's a hacker's dream. Sounds so cool. We don't have a single client yet, but we already maintain a collection of 4 forked libraries, custom patched.

Well. Hindsight 20/20, right? And it makes for an interesting adventure. Am I playing it too safe now, sticking to the boring stuff? We'll know in a few years.

Let's say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while. (...) If you choose to write your website in NodeJS, you just spent one of your innovation tokens. If you choose to use MongoDB, you just spent one of your innovation tokens. If you choose to use service discovery tech that's existed for a year or less, you just spent one of your innovation tokens. If you choose to write your own database, oh god, you're in trouble.

Picking a single part as a highlight was ridiculously hard, so here's another bit I love:

The problem with "best tool for the job" thinking is that it takes a myopic view of the words "best" and "job." Your job is keeping the company in business, god damn it. And the "best" tool is the one that occupies the "least worst" position for as many of your problems as possible.

Measure Anything, Measure Everything https://codeascraft.com/2011/02/15/measure-anything-measure-everything/

This was a big one for me. The concept of tracking swaths of metrics across your app was so invigorating I kid you not I suffered a form of fear-of-not-tracking-enough metrics for a very depressing while. It got better eventually. In the end, I guess you have to reach that point to back track and catch a balance.

Software Testing Antipatterns http://blog.codepipes.com/testing/software-testing-antipatterns.html

I've long, long been a pretty radical fan of moving fast and breaking things. My general belief was that a clear, efficient process of catching and fixing regressions is much more worthy of a time investment than striving for a made up metric like test code coverage. I still subscribe to that belief, but I've learned to appreciate the value of a well-designed, no-bullshit test suite. This post really helped me zero in on those, as well as validate my skepticism around some subjects like TDD. Read it!

Writing no tests at all (...) is also a valid strategy. As we have seen in anti-pattern 4 there is code that never needs testing. Writing software tests for trivial code because this is the correct way to “do TDD” will get you nowhere.

A Taxonomy of Tech Debt https://engineering.riotgames.com/news/taxonomy-tech-debt

I liked this one so much I did a talk at a local meetup based on the ideas outlined here. Gives some nice structure to thinking about tech debt.

Anyways, tech debt is one of those terms that gets thrown around a lot, we all THINK we know what we mean, but it is a sort of an umbrella term. Riot has a lot of great content on their blog, and this one shows a neat deconstruction of tech debt, with cool examples.

Floating Point Visually Explained http://fabiensanglard.net/floating_point_visually_explained/

I don't really care that much about floating point numbers (okay, the implementation is kind of cool... like really cool) but I wish the world had more posts like this about all the other topics that are constantly being explained in a crap way. Looking at you, monads.

So, anyway, check it out. I guarantee you'll get the "Wait, that's it? It's that simple?" feeling when you're done. And that feeling is crazy good. It could also help you out with a challenge on this site.

Julia Evans' blog https://jvns.ca

I am amazed and obscenely envious of Julia's ability to keep dropping so much high quality content over time. It's ridiculous, it really is. I'm linking the whole blog here, with a few favorites of my own: dropping packets, the tcpdump zine, the perf zine, whats-a-network-interface, learning at work, sqlite... seriously, this is top-staff-editor's-pick-all-time-highlight.

Writing Reviewable Code https://secure.phabricator.com/book/phabflavor/article/writing_reviewable_code/

This one's a piece you should basically steal/adapt for use inside your own team. I can't really sum it up, just go read it. It's 0% bullshit and will be well worth your time.

HumanOps https://github.com/HumanOps/HumanOps/blob/master/HumanOps.rst

I strongly believe that the mark of a mature developer is the acknowledgement of the humans behind the system. This is true on all levels of delivering stuff. From caring about readability, maintainability, hackability, scalability and robustness... end of day, it's humans all the way down.

I stumbled upon this one just as my craze of gathering any metrics I could think of was dying out... and it was a real moment of clarity to see how I missed a few very important ones. I like it when an idea humbles you.

You have two jobs https://jacobian.org/writing/you-have-two-jobs/

I'm going to save you a click, potentially: the two jobs are 1. Write good code and 2. Be easy to work with. – and it's an overall good reminder that we should really watch out in case we feel like turning into a mean code machine would solve problems.

I wrote FAT on an airplane https://blogs.msdn.microsoft.com/oldnewthing/20131008-00/?p=3003/

Okay, I don't think there's a lesson here. But the short story is worth reading, and you'll be able to start using the "I wrote in on a plane" trope... humorously, I hope.

From before the newsletter era

Choose Boring Technology http://mcfunley.com/choose-boring-technology

I love this one for many reasons. Of them is how I managed to fail an old start-up of mine right into the ground because the amount of new, hip tech was unsustainable in the face of everyday issues you run into once you start getting clients. Looking at it now, the warning signs were so clear, even at the early stage. A library almost works with our cool stack? Lets just fork it and maintain a patched version, right? It's a hacker's dream. Sounds so cool. We don't have a single client yet, but we already maintain a collection of 4 forked libraries, custom patched.

Well. Hindsight 20/20, right? And it makes for an interesting adventure. Am I playing it too safe now, sticking to the boring stuff? We'll know in a few years.

Let's say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while. (...) If you choose to write your website in NodeJS, you just spent one of your innovation tokens. If you choose to use MongoDB, you just spent one of your innovation tokens. If you choose to use service discovery tech that's existed for a year or less, you just spent one of your innovation tokens. If you choose to write your own database, oh god, you're in trouble.

Picking a single part as a highlight was ridiculously hard, so here's another bit I love:

The problem with "best tool for the job" thinking is that it takes a myopic view of the words "best" and "job." Your job is keeping the company in business, god damn it. And the "best" tool is the one that occupies the "least worst" position for as many of your problems as possible.

Measure Anything, Measure Everything https://codeascraft.com/2011/02/15/measure-anything-measure-everything/

This was a big one for me. The concept of tracking swaths of metrics across your app was so invigorating I kid you not I suffered a form of fear-of-not-tracking-enough metrics for a very depressing while. It got better eventually. In the end, I guess you have to reach that point to back track and catch a balance.

Software Testing Antipatterns http://blog.codepipes.com/testing/software-testing-antipatterns.html

I've long, long been a pretty radical fan of moving fast and breaking things. My general belief was that a clear, efficient process of catching and fixing regressions is much more worthy of a time investment than striving for a made up metric like test code coverage. I still subscribe to that belief, but I've learned to appreciate the value of a well-designed, no-bullshit test suite. This post really helped me zero in on those, as well as validate my skepticism around some subjects like TDD. Read it!

Writing no tests at all (...) is also a valid strategy. As we have seen in anti-pattern 4 there is code that never needs testing. Writing software tests for trivial code because this is the correct way to “do TDD” will get you nowhere.

A Taxonomy of Tech Debt https://engineering.riotgames.com/news/taxonomy-tech-debt

I liked this one so much I did a talk at a local meetup based on the ideas outlined here. Gives some nice structure to thinking about tech debt.

Anyways, tech debt is one of those terms that gets thrown around a lot, we all THINK we know what we mean, but it is a sort of an umbrella term. Riot has a lot of great content on their blog, and this one shows a neat deconstruction of tech debt, with cool examples.

Floating Point Visually Explained http://fabiensanglard.net/floating_point_visually_explained/

I don't really care that much about floating point numbers (okay, the implementation is kind of cool... like really cool) but I wish the world had more posts like this about all the other topics that are constantly being explained in a crap way. Looking at you, monads.

So, anyway, check it out. I guarantee you'll get the "Wait, that's it? It's that simple?" feeling when you're done. And that feeling is crazy good. It could also help you out with a challenge on this site.

Julia Evans' blog https://jvns.ca

I am amazed and obscenely envious of Julia's ability to keep dropping so much high quality content over time. It's ridiculous, it really is. I'm linking the whole blog here, with a few favorites of my own: dropping packets, the tcpdump zine, the perf zine, whats-a-network-interface, learning at work, sqlite... seriously, this is top-staff-editor's-pick-all-time-highlight.

Writing Reviewable Code https://secure.phabricator.com/book/phabflavor/article/writing_reviewable_code/

This one's a piece you should basically steal/adapt for use inside your own team. I can't really sum it up, just go read it. It's 0% bullshit and will be well worth your time.

HumanOps https://github.com/HumanOps/HumanOps/blob/master/HumanOps.rst

I strongly believe that the mark of a mature developer is the acknowledgement of the humans behind the system. This is true on all levels of delivering stuff. From caring about readability, maintainability, hackability, scalability and robustness... end of day, it's humans all the way down.

I stumbled upon this one just as my craze of gathering any metrics I could think of was dying out... and it was a real moment of clarity to see how I missed a few very important ones. I like it when an idea humbles you.

You have two jobs https://jacobian.org/writing/you-have-two-jobs/

I'm going to save you a click, potentially: the two jobs are 1. Write good code and 2. Be easy to work with. – and it's an overall good reminder that we should really watch out in case we feel like turning into a mean code machine would solve problems.

I wrote FAT on an airplane https://blogs.msdn.microsoft.com/oldnewthing/20131008-00/?p=3003/

Okay, I don't think there's a lesson here. But the short story is worth reading, and you'll be able to start using the "I wrote in on a plane" trope... humorously, I hope.