JJJ's Blog

  • WordPress
  • GitHub
  • Twitter/X
  • Reviewing > Testing > Copying > Writing

    Rarely anymore do I sit down and type code out at a keyboard. Most of the typing I do happens on my iPhone or iPad via SMS or email. Typing new things at a computer is not particularly effective for me, and it’s generally not directly related to whatever task is currently at hand.

    When I do need to type, it’s usually code of the PHP, JS, or CSS varieties, which means more reviewing and testing than it does actually typing things out. Lots of thought, then copying code I know does something similar, iterating on it, testing it, reviewing it, and committing to the result.

    More often than not (let’s say 80% of the time) I copy and paste most of the code that I write. The original code comes from some other functionally proven, correctly working method that I either wrote myself or I’m already familiar with from some another project I’m involved in, and it gets iterated on over time to become something else.

    The argument for this, is we avoid human typing mistakes and reinventing proverbial wheels.

    The argument against this, is we run the risk of copying an existing, potentially hidden bug.

    It’s more important to review and test existing code, than it is to write new code. Before writing something from scratch, be sure to budget time according to a ratio of: reviewing, to testing, to time spent actually coding. My rough guess is that the code review and application hardening processes should take at least 10 times longer than the time it took to write new code, and about half that for code that’s been copied from existing trusted and known-working sources. Maybe longer, exponentially so if this new masterpiece is a large addition to an existing project.

    By copying existing code, you automatically inherit the labor that went into forging it to begin with. Each time a new file is created and code is written from scratch, potentially thousands of costly man hours are being completely disregarded. It’s an arrogant way to get things done, and a method/mindset usually better avoided in most circumstances.

    There will be times where it’s nose down, neck deep, headphones in, write-new-code-mode. When that rare opportunity arises, be sure to budget the appropriate time to reviewing and testing it.

    JJJ

    April 3, 2012
    Uncategorized
  • JJJ

    March 9, 2012
    Uncategorized
  • I miss Pier 38

    Watching this video about Automattic from 2010 reminded me how much I miss our old office at Pier 38.

    JJJ

    February 20, 2012
    Uncategorized
  • The Fantastic Flying Books of Mr. Morris Lessmore

    Gorgeous.

    JJJ

    February 19, 2012
    Uncategorized
  • Atmosphere

    JJJ

    February 19, 2012
    Uncategorized
  • Chrome Users: Try the WordPress.com Extension

    JJJ

    January 27, 2012
    Uncategorized
  • Don’t Make Me Think

    If you haven’t had the pleasure, Steve Krug’s Don’t Make Me Think is a must-read book not just for web developers and designers, but for anyone that’s ever criticized a website, ever. I recently had the pleasure of reading it again as part of a work semi-assignment, and there were a few key points that really struck a chord with me (for the second time) I thought I’d share here.

    Web users tend to act like sharks: They have to keep moving, or they’ll die.

    Fact. With as busy as we all are and as convenient as the modern web is, this is more true than ever before. With the recent SOPA Blackout day, a dedicated Twitter account retweeted the cries of scornful users whose loss of the immediate Wikipedia access they’ve come to expect had many of them in a tailspin of emotion. Had these users taken the time to read the 3 sentences presented to them (instead of the content they were expecting) they would have noticed it was a purposeful protest and not an outage or the government shutting them down.

    Innovate when you have a better idea (and everyone you show it to says “Wow!”) but take advantage of conventions when you don’t.

    This happens to all savvy internet creators eventually. You have a great idea, maybe you even mocked up some designs or wireframes, but instead of it being revolutionary it’s a remix of old ideas that break tons of existing conventions. What you end up with is Frankenstein’s monster; a babbling clod of an idea that everyone is afraid of, even if it just wants to be loved.

    Omit needless words. Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts.

    Enough said.

    If you look up navigation in the dictionary, it’s about doing two things: getting from one place to another, and figuring out where you are.

    As the web becomes increasingly connected, more and more navigational elements are infiltrating our once flat and simple world. Remembering to keep primary navigation simple and secondary navigation to a minimum is becoming increasingly difficult to do.

    Left to their own devices, development teams aren’t notoriously successful at making decisions about usability questions. Most teams end up spending a lot of precious time rehashing the same issues over and over.

    Fact. This happens all the time, even individual Automattic projects. Everyone has great ideas with years (decades?) of experience behind them to prove their opinions are the best ones. Thankfully, these “religious debates” end up being constructive for everyone, and we’re all really good at settling down and agreeing before anything bad happens (even when it comes to reblogging.)

    Resist the impulse to add things. When it’s obvious in testing that users aren’t getting something, most people’s first reaction is to add something, like an explanation or some instructions.

    Very often, the right solution is to take something (or things) away that are obscuring the meaning, rather than adding yet another distraction.

    See navigational elements above. As newer and more capable technologies are introduced and as more systems are introduced to work on top of more systems, it’s easy, as an expert to throw all-of-the-things at existing not-so-good things.

    Consistency among browsers: workarounds and hacks are still required to ensure that your CSS works across all browsers, but these will fall away as browser makers continue to improve their CSS support.

    This made me laugh, and then cry, because it hasn’t really improved in the past 10 years. We’re still prefixing our CSS styling with browser specific tags no differently than we were writing browser specific HTML for Internet Explorer and Netscape. I’m all for a progressive and competitive web, but don’t make me think about what CSS convention I should use or what browser to favor.

    But above all, be of good cheer. Building a great website is an enormous challenge, and anyone who gets it even half right has my admiration.

    Building great websites is hugely difficult. Thanks to a bunch of really awesome open-source projects and the thousands of contributors, it’s easier than ever to make awesome looking and working websites. I’m really happy to be a part of something I both enjoy and believe in, and it’s books like Don’t Make Me Think that I enjoy rereading every few years to keep my priorities and abilities in check.

    JJJ

    January 21, 2012
    Uncategorized
  • Pork Ribs

    20120110-203105.jpg

    JJJ

    January 11, 2012
    Uncategorized
  • Ocean View

    20120107-120409.jpg

    JJJ

    January 7, 2012
    Uncategorized
  • ool

    20120107-120100.jpg

    Notice there is no P in it.

    JJJ

    January 7, 2012
    Uncategorized
Previous Page
1 … 18 19 20 21 22 … 24
Next Page

Proudly Powered by WordPress