An internet radio show about the internet starring Dave Rupert and Chris Coyier.

Subscribe on iTunes or RSS


244 Rapidfire 80

01:09:10 Download

Show Description

What's the difference between a site that's straight up files vs WordPress? What's CSP and why does it matter? Does MySQL matter? Understanding the benefits of HTTP2. And how can you clean up a project you're taking over?

Show Sponsors

Interested in sponsoring?

Time Jumps


  • Alex Zaworski

    What is the benefit of a CSP that allows unsafe inline? That’s so confusing to me. Is it just to tick a box on Observatory (et al) saying “yup I did the CSP thing!” or what? Does it still protect you from anything?

  • Here is what I would say to Prakesh (apologies if I spelled that incorrectly):

    There are two very important things to remember:
    1. Your company needs to make money. You need to make money. You were hired to complete a task that makes more money for the company than it does for you. Remember that first.
    2. Your situation is web development IRL. There is ALWAYS legacy code. Prove yourself first, and earn those “brand-new” projects (w/o compromising your salary).

    Here’s how you cope:
    1. SHIP FIRST. Finish the first project as fast as you possibly can, proving to your boss that you are actually capable of completing the task they hired you to complete. A LOT of developers are a combination of ego and enthusiasm, and always believe that they could write that code better. Many, in my experience, can’t actually deliver on it, though.
    2. During this first project, do these things:
    1. make notes where spaghetti code introduces additional risk to completing the work and meeting the deadlines. keep a notebook handy, and when you encounter identifiable risk, open your notebook, write down the new line item, close the notebook, and get back to work.
    2. change a tiny bit of code every time you are in the code base. 3. give your boss a project retrospective after it ships, that outlines what you’ve identified as the issues.
    1. “the code is terrible” is not an acceptable answer.
    2. use it as an opportunity to show initiative (by writing up a project retrospective)

    Consider this approach to influencing permanent change:

    1. Take inventory of all the parts (write it down)
    2. Divide the parts up into these stages:
    1. What do I need to fix now, and what small improvement can I make today (like, add a unit test, or adding an assets folder, etc.)?
    2. What could I fix, but it would require a little more time to get it right?
    3. What needs to be scheduled deprecation (planned obsolescence) and re-written?
    3. Be faithful.
    1. Earn the reputation for honesty, transparency, and fortitude.
    2. Be kinder than you want to be, more communicative than you would be on your own.
    3. Cultivate compassion for your colleagues, and a healthy dose of self-awareness.
    4. Accommodate whenever possible, but don’t be afraid to be that brick wall when something is just plain wrong (use sparingly).

    Doing these things has helped me in my career as a programmer, and while I am not famous or rich, I’m still living quite comfortably and have not had to compromise the things that are deeply important to me, in order to do so.


  • David Hicken

    Here’s a good blog on the do’s and don’ts related to transitioning from HTTP/1.1 to HTTP/2:

Job Mentions