• TXJS 2015

    I had the privilege of attending the Texas Javascript 2015 conference this past week. It had a stellar line up and I’d recommend watching the recorded live stream if you weren’t able to attend.

    The following were the highlights for me:

    Cold War Simulation by Simon Swain

    Simon had both an incredible slide deck and demo. He highlighted some impressive things that can be done with using Canvas. I rarely have an opportunity to use Canvas but his presentation makes me want to take a new, lengthy look at it.

    Client Side Security by Yan Zhu

    This presentation sent chills down my spine. Yan demonstrated some terrifyingly simple security holes that I wasn’t not aware of. But, she also showed some great new additions to browsers that will give developers tools to plug these holes and make the web a safer place.

    Select Box Usability by Alice Bartlett

    I really enjoyed this presentation. Alice explained the significant usability problems with select boxes. She played some videos of people struggling to figure out how to do the most basic tasks simply because of the select box control. It was a real eye opener and highlights that as developers we can’t take for granted our tech savviness and need to analyze every element we add to a site.

    Service Workers by Jake Archibald

    The hilarious Jake Archibald walked us through using Service Workers to build more performant and offline sites. He had a very interesting demo for using Service Workers to help users with spotty connection. I can see a lot of potential Service Workers in the future to load assets in the background and speed up page load time. I’m very excited to try them out!

    There were many more interesting lectures so I’d definitely recommend watching the live stream. But, if you don’t have time to watch the live stream, then at least take a look at G. Scott Olson sketchnotes for the conference.

  • Developers Are in the UX Business

    UX is often thought of as the visual design of software. Though it’s an important part of crafting a great user experience, there is much more that must be considered.

    A great experience for users requires focus on many parts of the software: visual design, reliability, ease of use, and performance, to name a few.

    I’ve often heard programmers say “not my problem” with anything concerning UX. But it’s my opinion that programmers are just as critical in shaping the user experience as any designer, perhaps even more so. Programmers are the ones in the trenches, constructing the user experience and must be on guard at all times for problems.

    If routes fail, performance is horrible, or features are buggy, then the user experience suffers, often horribly. Just ask yourself what your most common complaints about software are. For me it is slow loading pages and mobile pages that don’t behave. These are problems that programmers need to be aware of and work to fix.

    Steve Jobs once said of design:

    Most people make the mistake of thinking design is what it looks like. People think it’s this veneer – that the designers are handed this box and told, ‘Make it look good!’ That’s not what we think design is. It’s not just what it looks like and feels like. Design is how it works.

    We’re in the UX business. We can’t forget that “how it works” part is a big part of that.

  • Code Review Hygiene

    I’ve grown to really appreciate code reviews. Like testing, code reviews allow you to catch bugs and improve code quality. But they also help teams find better, alternative options, and transfer knowledge between team members.

    What follows is a list of non-technical practices to keep in mind for conducting effective code reviews. Some of these I want to start doing, some I already do, some I do but do poorly.

    1. Agree to a standard for reviews with the rest of the team. This is critical. If everyone on the team has different standards then reviews will be tough. A style guide and best practices document that the team creates is a huge help here.
    2. Remember, you are not your code. It is so easy to take criticism personally but do you best to avoid this. Everyone, no matter the skill level, has areas to improve on. Accept that and thankful that you have a team that can teach you things.
    3. Be kind. Don’t let the lack of face-to-face communication cause you to be harsh. It’s easy to fire out “you’re wrong” in a review and be harsher that you would face-to-face. But that is a great way to make someone defensive and not be receptive to criticism.
    4. Look for things people are doing right. Pointing out new an interesting things in a review is good way to encourage learning and build relationships.
    5. Be pragmatic and keep code moving. Sometimes people have differing opinions and no amount of discussion is going to change that. In that case, defer to a third party or take a vote as a team. Don’t let reviews get stuck in the mud.
    6. Give reasoning. Saying “change this” without a reason is not helpful and won’t prevent similar mistakes in the future. This also helps to keep reviews objective. It is too easy to let your personal preference come out in a review as the “right way”. 
    7. Ask questions. I learn a lot through code reviews. Especially when we start using a new library or tool. If you aren’t understanding, ask the team to explain!
    8. Have a good attitude and assume good intent. Remember, you are all on the same team and are trying to create high quality software. Developers aren’t trying to come up with bad solutions. They may just not be aware of a better way.

    If you aren’t conducting reviews yet I highly recommend it. Both Bitbucket and and Github make it incredibly easy. Any any slight slow down you might experience by always doing reviews will be more than made up for in much higher quality code and team members that are far more aware of the what is going on in different areas of the stack.