Categories
Programming WordPress

Potential Tech Conference Talks

I am constantly thinking of new potential talks that I would want to either give or convince others to give. Some of these have been on my list for almost a decade, while others are relatively recent ideas.

Roles on a web team

There is a big difference between roles, jobs, and titles. I cosider a role to be the atomic unit and they bunch up into a job. So for example, a role is “Writer of CSS” and that might be a part of the “Front end developer” job. It also might be a part of the “Designer” job. I want to look at all the roles that need to be filled (I think there are somewhere around 100-200) in order to build, launch, and maintain a website and how successful teams are able to define jobs.

Improv for Web Developers

It’s been a long time since I did improv, but many of the things I learned from it are foundational things I use every day. This could be participatory; this could be a disaster. Just like an improv scene.

This is likely closer to a lightening talk than a full talk.

Axioms for the Web

Axioms are ideas we use to start our reasoning that are so fundamentally true, we use them to define what is true. They come from a Greek term that roughly translates to ‘that which commends itself as evident.’ They are phrases as simple as: A + B = B + A. One look at this phrase and we understand the truth within it.

I want to expand on a lightening talk I did a few years ago to look at what things are so fundamentally true for websites that they define what is true.

DUX – Developer User Experience

What is the experience of contributing to and using your code base like and how can we use lessons from user experience design to influence ways in which we improve it?

Interviewing developers

I’ve refined my interview questions over the last decade and think it could be interesting to share these questions, perhaps even doing a mock interview on stage. I might even talk about questions I used to use and why I don’t use them any more.

Foundations of HTTP

A look at the http standard, how it has evolved to http/2, how it is evolving to http/3 and the foundational concepts of http verbs and status codes that are incredibly relevant to all web developers.


Get in touch if you would like for me to give one of these at an event you are organizing. None of these are fully flushed out so they will take some time, but I think there would be interest in all of them.

Categories
Programming

My developer interview questions

I have interviewed over 100 candidates for developer positions over the last decade. In that time, there has been one consistant refrain on twitter: “Interviewing is broken”. And as someone who has been on the other side of the interview, I agree. I’ve evolved my developer interview questions with this in mind.

I’ll note that this is what I’m using now and will likely evolve. My questions aren’t tricks, they aren’t academic, and they don’t necessarily have right and wrong answers. My goal with them is to start some conversations and try to learn how a candidate thinks and reacts.

I’m a bit worried that putting these out here will “ruin” them, but I also think part of what is broken about interviewing is the idea that things need to be a surprise and we need to see how people think on their feet. The majority of the time, this isn’t how we work so why interview with that in mind?

Most interviews, I use just two questions as my base. For more experienced people, I have a third I use as well if I’m trying to understand if they are truly senior. I also am generally looking for people who will work throughout the stack, even if they have a specialty. I also don’t expect candidates to be experts at the entire stack. My developer interview questions are thus general and not generally language specific.

How do you ensure you write quality code?

What I’m looking for here is that they have a definition of quality and they put in some sort of process to make sure it happens. I’m trying to weed out people who won’t write tests, while also learning if someone is going to be overly cocky or has lone wolf tendencies.

Some of the best responses to this are questions along the lines of “How should I define quality code” as it shows they don’t just rush to solutions, they try to define the problem better.

I usually end up having follow up questions here depending on how they answer. If they mention automated tests, I might ask how they decide what should be a unit test and what should be a functional test. If they mention code review, I might ask what are the big things you look for when doing code review.

Hypothetical situation: The CEO says the homepage is slow

For this one, I put on my old Simulation Director hat from Model UN and we go through a hypothetical situation where you get an email from the CEO saying the homepage seems slow and asking you to look into it. Totally hypothetical, no one has ever gotten this email at any job ever.

I’m trying to see how people approach being given minimal information and needing to debug. I’m trying to see if they look for tools, such as asking me what metrics they have available. I want to know if they can identify backend performance issues vs. front end performance issues.

This question goes in a different direction every time as I tend to follow the path the candidate leads me on. Thankfully, I’ve written and encountered a lot of slow code in my life, so I am able to go in many different directions.

In this question, I might ask them for ideas for how they would fix some issue. I might see how familiar they are with concepts like RUM, Server Push, and using EXPLAIN in sql.

*Programming Language You know* has changed a lot, what’s your favorite new feature?

This is my experienced developer question. I’m trying to make sure they stay current and continue to learn. I’ll follow up often with “What do you like about it” and then I’ll ask them to explain why it is better than some older alternative and then I’ll ask them how they would explain it to a more junior colleague.

I always pick the language that their resume seems to most emphasize and I only use this for people who have been coding in it for at least 7 years. I’m hoping to see someone that stays current, that has opinions, and can share them.


The candidates I am usually looking for are people who like to learn, people who can debug, and people who aim for greatness, but know that often perfect is the enemy of complete. I hope my developer interview questions help me find them and I hope they want to work with me after the conversation. I hope to always work at places that pass the Jorbin Test so people will want to work with me.

Do you think my questions could be better? Do you see flaws in them? I would love to hear your feedback so I can itterate. To paraphrase Akin’s Third Law:

Interviewing is an iterative process. The necessary number of iterations is one more than the number you have currently done. This is true at any point in time.

Categories
Code Programming WordPress

__DIR__ vs dirname( __FILE__ )

Calling a constant should always be faster than a function call, right? PHP contains two different ways to get the directory that a file is currently in. __DIR__ is a magic constant added to PHP in 5.3. The official PHP documentation specifically states: “This is equivalent to dirname(__FILE__).” Equivalent in return doesn’t necessarily mean equivalent in performance though, so I decided to test the performance of both accross a couple of variables.

Testing Methodology

When running lots of tests, I’ve found that travis-ci can be a big helper. You can define the matrix of the tests you want to run as your testing matrix and then use the results. So I setup a repo for my tests. The repo contains four main pieces:

  1. A file generator which creates the code I’ll actually run the performance test on.
  2. A test running script which runs the actual tests.
  3. The travis.yml file to define my tests matrix
  4. Files used for the actual test. This is not linked, there are 400,000 files. The generator shows them off.

My test calls the function I am looking for 100,000 each. One run has all the files in 1 directory, and the other has one file per directory. I wanted to rule out the possibility that a single directory could affect this call.

I ran this test on six version of PHP: 5.6.40, 7.0.33, 7.1.27, 7.2.15, 7.3.9 and 7.4-dev. Each test did 650 runs and I looked at the user time for each of those runs. This means that I called both __dir__ and dirname( __file__ ) 130,000,000 times each. I then took the times for each of these runs and looked at that maximum (slowest) run for each and the 95% time ( the average between the 618th and 619th slowest) to rule out any extreme cases. Overall, the results between maximum and 95% are similar.

User is the amount of CPU time spent in user-mode code (outside the kernel) within the process. This is only actual CPU time used in executing the process. Other processes and time the process spends blocked do not count towards this figure.

Stack Overflow

__DIR__ vs dirname( __FILE__) Test Results

95% performance

Script5.67.07.17.27.37.4
dir ( 1 folder)1.42.762.082.512.271.3615
dir ( many folders)1.382.292.552.36152.651.57
dirname( 1 folder)1.58152.272.74153.242.411.5215
dirname( many folders)1.682.292.08153.292.68151.87

Overall, the results show that __dir__ is generally faster, but it’s rarely much faster. Consider that in the slowest run ( using PHP 7.2 and calling dirname( __FILE__ ) on multiple folders), each call took 0.0000329 seconds. The fastest run was 2 hundred-thousandths of a second faster. This is such a micro optimization that except under extreme scale, it’s unlikely you will ever notice a difference. That said, under most versions of PHP, __DIR__ is faster.

So: __dir__ or dirname?

At the end of the day, the performance of __DIR__ is ever so slightly better, but more importantly I think it’s clearer and easier to read. So I’m on team __dir__, but the performance is only a bonus.

If you have a different thought, or think that my testing methodology could be improved, please let me know in the comments below.

Categories
Art Programming WordPress

Art and Commit Messages: Volume 2

Last year I published volume 1 of Art And Commit messages and sold nearly 50 copies! For my first zine, I was ecstatic that so many people were willing to spend $3 on something so unknown. I have already started thinking about Volume 2 and think that it will be a great thing to publish at WordCamp US. I’m also thinking it might make sense to include some different things this time.

Art by more Artists

Volume 1 featured my art, for Volume 2 I would like to feature the art by more artists. I am also thinking of budgeting a small amount so that artists are compensated, but as Volume 1 didn’t make any money I think this is going to be a low amount. Maybe $50 for each piece.

Are you interested in having your artwork featured in Art and Commit Messages? Let me know:

Essays by More Writers

Along the same lines, I want to feature a couple of essays about commit messages from a variety of people. What kind of essays would you like to see in volume 2?

Finally, I want to figure out some sort of game to include. Maybe I loved reading Highlights for Children too much as a kid, but I think a game would be fun.

Art and Commit Messages: Strange Bedfellows

Art and Commit Messages might feel like an odd combination but the best of both are snapshots that convey an intent. Art transposes the emotion of the creator to an audience. It can transport you into the brain of the artist. The best commit messages similarly transport you into the brain of the creator. They share the coders intent.

That’s the message from the cover of volume 1. I absolutely recognize the odd combination, but they are two things that I care about and I hope that by combining these two strange bedfellows I can encourage people to write better commit messages.

Overall, my goal remains to encourage high quality commit messages through education, entertainment, and an understanding of history. I’m not looking to make money, if I was I wouldn’t be making a zine.

Do you have other ideas for making Art and Commit Messages better? Leave a comment or get it touch and let me know!

Categories
Art Four Short Things Programming Uncategorized

Four Short Things – 16 February 2019

Inspired by O’reilly’s Four Short Links, here are some of the things I’ve seen, read, or watched recently.

Git for Ages 4 and Above

My friend Adam recommended this talk as a good deep dive into git. One thing I often preach is the importance of understanding the tools you use on a regular basis. It doesn’t matter what editor you use (but really, it should be vim), what matters is knowing how to use your editor. The same can be said for git. Git is much more powerful than git commit, git push, and git pull. The piece I used yesterday? git checkout master -- filename.jsto revert a single file in a branch that didn’t actually need changes.

Tom Brown at Laugh Fest

Do you live in or around Grand Rapids? If so I highly suggest checking out The Tom Brown at Laugh Fest in March. You will laugh your socks off.

Public APIs

This collection of mostly JSON REST APIs has everything from APIs around art, music, and photography to weather, news, and NFL arrests. It’s a great first stop if you are looking for a data API.

Two Elephants

I finished my first new canvas of 2019.

Four Short Things is a series where I post a small collection of links to art, news, articles, videos and other things that are me. Follow my RSS feed to see Four Short Things whenver it comes out.

Categories
Art Design Four Short Things Programming

Four Short Things – 9 February 2019

Inspired by O’reilly’s Four Short Links, here are some of the things I’ve seen, read, or watched recently.

The Value of Good Design

MoMA’s spring exhibition includes a show featuring everyday objects, the types that it’s feasible to find in our homes. Brooms, Rakes, Chairs, A Slinky. With an emphasis on work that appeared in shows from the 1930’s to 1950’s, there is plenty of Eames, Saarinen, and Bruan to make any home goods nerd geek out. In addition to the main section of the show, there is a small lab where you can couch and sit on some of the items on display. It’s open until June 15.

Terraform

Describing itself as “Write, Plan, and Create Infrastructure as Code”, terraform allows for almost every part of your infrastructure to happen as code. You can thus keep your DNS in GitHub. You can keep your GitHub config in GitHub too.

What’s new in PHP7.4?

Odds are, you aren’t running PHP7.3 yet, but that doesn’t mean work hasn’t started on PHP7.3. Heck, 8.0 is already being planned. It’s still early, but coalesce assignment is my prediction for what is going to cause the most useless arguments and also be the biggest win.

Inclusive Design: Who’s Opportunity is it?

My friend David uses his journey to help explain how inclusive design is a win for everyone. He looks at Inclusive design as an opportunity for business, content, quality, performance, and people. Definitely was one of the best things I read this week.

Four Short Things is a series where I post a small collection of links to art, news, articles, videos and other things that are me. Follow my RSS feed to see Four Short Things whenver it comes out.

Categories
Art Design Four Short Things Programming

Four Short Things – 2 February 2019

Inspired by O’reilly’s Four Short Links, here are some of the things I’ve seen, read, or watched recently.

Design Patterns for Managing Up

The first time I was introduced to the phrase “Managing Up” I hated it. Why should I be responsible for my boss? They are supposed to be responsible for me. As I’ve grown I have recognized that as with all relationships, the manager-managee relation requires all parties to invest in its success. This article covers four challenges and offers patterns of behavior to help build and improve the relationship. These four situations are:

  1. Someone asks you something you don’t know
  2. There is a problem that is your fault or responsibility
  3. There is a decision that you don’t agree with
  4. Your manager gives you negative feedback

Metropolis II

LACMA is the largest art museum in the western United . On my first visit, Chris Burden’s kinetic sculpture stood out to me. I like art that reminds me of the building and imagination you do when you are young. Metropolis II is a massive sculpture that features cars and trains traveling around a city.

Picasso’s Drawings of Bulls Inspired Apple’s Famously Simple Designs

“Pasadena, Norton Simon Museum, Picasso P. The Bull, 1946” flickr photo by Vahe Martirosyan https://flickr.com/photos/vahemart/31475770070 shared under a Creative Commons (BY-SA) license

Picasso’s lithographic drawings of The Bull start as a full picture of a bull and over the course of the drawings, become more abstract and minimized to only a few lines. But it is still clearly a bull. Apple incorporated this into its design education. The continued minimization and removal of elements is evident. A phone is still a phone without a headphone jack, and a bull is still a bull when it is made with simple lines.

How We Made The Force Report Database

This “how we built this” article explores all the work that went into the Force Report Database from NJ Advanced Media. Awesome to see data reporters sharing not just the outcome (in this case a tool to help the residents of New Jersey understand police use of force) but all the steps and missteps it took to get there. The lessons learned at the bottom could also make it easy for other places to replicate this reporting.

Four Short Things is a series where I post a small collection of links to art, news, articles, videos and other things that are me. Follow my RSS feed to see Four Short Things whenver it comes out.

Categories
Art Four Short Things Programming

Four Short Things – 18 January 2019

Inspired by O’reilly’s Four Short Links, here are some of the things I’ve seen, read, or watched recently.

100+ Lessons Learned for Project Managers

I am a firm believer that software and web development can learn a lot from other disciplines. Much as Akin’s Laws of. Spacecraft Design can be easily modified for the web, I think these lessons from Jerry Madden, the former Associate Director of Flight Projects at NASA Goddard Space Flight Center, can also be valuable. One that stood out to me, since it seems so incredible accurate, is lesson #14.

The first sign of trouble comes from the schedule or the cost curve. Engineers are the last to know they are in trouble. Engineers are born optimists.

Lesson #14

Untitled by Mark Rothko

Mark Rothko is often thought of for his large “multiform” colorful paintings, but The Met’s Epic Abstraction show also includes a few of his watercolors. It’s a nice reminder to not be siloed into what we are most known for. Overall, this show lives up to its name and features many epic pieces of abstract art. It has no end date currently scheduled, but I have a feeling that it will depend on the construction of a new modern wing.

The Marvelous Mrs. Maisel

When this first came out, I watched the first two episodes but never really fell into it. Then over the last my entire family seems to have all watched this separately. It’s funny, sad, and displays the same level of intellectual dialague that Amy Sherman-Palladino displayed with Gilmore Girls.

Anatomy of a Dress Shoe

Over the last four years, I’ve gone from regularly using one pair of shoes to having a number in regular rotation. I’ve mostly bought them second hand, but I’ve also taken the time to learn about Goodyear Welts, and even got one pair resoled. Shoes are one of the most important articles of clothing that we ware and this overview will help you the parts of the shoe.

Categories
Programming WordPress

Douglas Crockford could sue the White House

Recently, the White House switched to using WordPress for whitehouse.gov. While doing so, they deployed the most recent version of WordPress. WordPress 4.9 includes a copy of CodeMirror for an improved experience when it comes to editing code. In order to provide linting of JavaScript uses JSHint.  And this is where things get interesting. 

JSHint is mostly licensed under the MIT license. I say mostly since it inherits some code from JSLint which uses a modified form of the MIT license. It requires that the software only is used for Good, not Evil.

"The Software shall be used for Good, not Evil."

So the White House is using software that can only be used for Good, not Evil. Which means that if the White House has used its website to do evil, it has violated Douglas Crockford's license. 

The next minor version of WordPress removes JSHint, but the inclusion of it will live on in internet archive history. 

Categories
Design Programming tao

Random Thoughts On…Product Engineering

For the past 5.5 years, I've been a part of the product engineering leadership at a couple of organizations. While I'm not sure if these ideas translate to client services, I know that they have all been valuable to me as I work long term building products and brands.

  • It's important to periodically reevaluate your tooling and process. Iterating on the process can be just as important as iterating on features. As a team, you are able to take all that you have learned about how you work and try to improve upon it.  It's important to not do this too often though, otherwise, you are spending your time chasing something shiny rather than building something that solves problems. 
  • Users over business requirements. Users over short-term wins. Users over everything. If you aren't building for people, your motivations are wrong and you need to rethink what you are doing. Always think about users. If you are discussing working on anything and no one has asked how it benefits users, ask that question. 
  • Implementors need to have control over either the schedule or the scope of a project. Giving up both leads to burn out and/or low quality work. Implementors mean everyone actively contributing, and not just the engineers. 
  • Design is more important than you think. Design is not done at a specific point. Designers need to be involved in everything. Yes, even the most underhood back-end project. Design thinking is undervalued. I've yet to see it be overvalued.
  • Share your work and ideas internally early and often. Even when they are half-baked or you don't think they are very good. 
  • It's important to understand that what is a high priority for you, isn't always a high priority for the team. That said, every member of the team should have at least one personal priority accomplished on a regular basis.
  • At least once a quarter, you should do a sprint focused on developer experience, refactoring, and bug features. Keeping the code easy to work with shouldn't be forgotten.
  • Do things that don't scale, but make them scale if you keep doing them.
  • There are a lot of things you can optimize for and deciding what you want to optimize for is a challenge. Sometimes you need to optimize for Time To Launch, others you want to optimize to make it easier to iterate on the UI. Figure out what's important on a project by project basis.
  • Don't forget any of Akin's Laws of Spacecraft Design, especially number 1.
  • At the end of the day the rules for success are 1) keep the site up 2) faster is better than slower 3) experiment with everything else