So when they unveiled the logo celebrating the team’s final season at Joe Louis Arena, it should come as no surprise that I was unhappy with it.
The primary problem I have with this is that the only way it says “Joe Louis Arena” is literally. Much like my complaint about the Hockeytown logo. Even then, they didn’t use the arena’s actual name but the nickname of “The Joe.”
The main elements of the logo are a big block of text, a Stanley Cup silhouette, and four stars representing Stanley Cup Championships. Visually, this feels more like a logo celebrating those championships than the arena that hosted the team when they were won.
The Joe isn’t all of that interesting of a building but at least try to represent it visually.
I threw together a rough drawing of the direction I’d like to have seen them go (and I emphasize “rough”).
The primary element of this design is a drawing of the exterior of Joe Louis Arena. It’s not a beautiful building by any means but it is recognizable and as such it makes sense to use it in the logo.
I kept the “Farewell Season” text across the top of the logo and the Winged Wheel at the bottom. The four stars are kept, two on each side of the Wings’ logo. A ribbon is added across the bottom of the arena rendering containing the remaining text from the original logo. The bounding shape is changed because I think it works better as a patch.
The only element removed is the Stanley Cup silhouette, which I don’t think is necessary.
So change the shape, change the colors, change any of the other elements… Just include Joe Louis Arena. That’s what the logo is supposed to be for. Show it, don’t just say it.
EDIT 2/15: I got some feedback that the bounding shape is unnecessary because it reduces the impact of the arena’s distinctive shape and I agree. I mocked up a version that uses the drawing of the arena, the ribbon, and the Winged Wheel without losing any of the important elements. Even the four stars are kept.
Martin Biron was the last player in the National Hockey League to wear #00. It’s one of my favorite stories because it mixes hockey with the pitfalls of software development.
Biron, then a rookie goalie for the Buffalo Sabres, appeared in three games in the 1995-96 season wearing #00, which he had worn during his junior career as well. He wasn’t the first to wear it – John Davidson had donned #00 for the New York Rangers in the 1970s and Ed Belfour wore it in an All-Star Game in the early 1990s – but by the time Biron made it back into the Buffalo lineup during the 1998-99 season he’d lost the number forever, switching to #43.
Between Biron’s final appearance in #00 and his first in #43, the NHL rolled out a new stat-tracking software package. If I recall correctly, it was developed by IBM (though I’ve heard Compuware mentioned as well, I could be mis-remembering) to much fanfare. Unfortunately there was a bug that only applied to Martin Biron: It assumed jersey numbers were non-zero.
When I wrote the software behind the short-lived Hockey Sweater Numbers web site I specifically made sure to handle this. IBM – ridiculously, to me – did not, and rather than fix it the league just banned the numbers that the system didn’t account for.
Why is this story on my mind right now? Because of John Scott and my own web site.
There used to be a listing of all of the winners of NHL awards on DetroitHockey.Net. I just pulled it off the site because that data is all over the Internet, I don’t need to worry about it on DH.N. But I still maintain the database for my own personal uses.
John Scott is a journeyman enforcer. He started this season with the Arizona Coyotes, out of the lineup more often than he was in it. When the NHL launched their web-based All-Star voting campaign, though, Scott quickly rocketed to the top of the voting. When the dust settled, he had been elected as the captain of the Pacific Division team.
Almost immediately he was traded to the Montreal Canadiens of the Atlantic Division, then demoted to their American Hockey League affiliate. The league never wanted him in the All-Star game and it appeared that their problem was solved. In the end, with the support of many players but seemingly few front offices, Scott was allowed to play in the All-Star Game. He would captain the Pacific Division but would represent neither the Coyotes nor the Canadiens. His petition to represent the St. John IceCaps, his AHL team, was denied. He was a man without a team.
Like something out of a movie, the journeyman now-minor-leaguer with five career goals scored twice and was named MVP of the event.
Within minutes of the announcement, I found myself staring at the administration system for the NHL awards on DH.N, entering Scott as the winner of the All-Star MVP award, and stumped because my system requires a player to represent a team and Scott doesn’t have one.
The story I’ve laughed at so much has come around to bite me in the ass a bit. Software not written to handle the strange things hockey throws at it.
Unlike the NHL, I’m adapting my software. I’m hacking in the St. John IceCaps as Scott’s team.
I love agile development methodologies. Specifically the ability to fail fast and adapt as necessary.
I love cloud services for making failure cheaper and therefore easier. We can try new things because the risks are lessened.
We have the process for failure figured out. We have the technology for failure figured out. I think we’ve still got to figure out the emotional impact of failure.
We don’t like to talk about touchy-feely things in engineering, but the fact of the matter is that failing fast, failing in ways that we’ve built business cases around, failing inexpensively… is still failing. And it doesn’t feel good to fail.
The team I’m working on had what we thought would be been a rubber-stamp demo scheduled for last Thursday. We were a few weekly sprints into the project. We’d demoed it previously and made some changes based on that demo. We were working the way we were supposed to.
The demo revealed that a handful of requirements hadn’t been communicated. Somehow this was missed earlier. Much of our work was invalidated.
We failed. We failed quickly. We failed in such a way that we could iterate on our work and save the project. We did what we were supposed to do.
But in our next retrospective, we couldn’t get over how much it stung to do it. We recognized that the process was meant to catch these things, that we hadn’t done anything wrong inside that framework, but couldn’t shake the feeling that how things went down just sucked.
I don’t know how to get over that. It feels like failure because it is failure. If we expect it at a process level, maybe we need a way to account for it on an emotional level, too.
It seems weird to justify what I write in my own blog but I was recently sent a piece by Mark Llobrera that resonated with me and I wanted to spin off of it.
The fear of stating the obvious is one of my primary personal roadblocks to writing.
I have a horrible time deciding whether or not I should write something because I feel like I shouldn’t take the time if it won’t be original. I fear that more than I fear writing something people won’t read.
Once I’ve written something, I’m disappointed if it doesn’t get a response, but that doesn’t really kick in until after I’ve published it.
The funny thing is the quote from The Web Ahead that inspired Llobrera’s piece:
I wish people would write more… In the future, we would have a better understanding of what people are thinking now. I’m very glad that I’ve been doing my blog for 15 years. I can go back to 2002 and get a feel for what it was like to build websites. Back then we thought X was true or hadn’t even considered Y. You forget these things. Having these written records—not of anything important or groundbreaking—but just the day-to-day. The boring stuff. That’s actually what’s most interesting over time.
For some reason, while I apply that logic to code samples, I give myself a different standard for my free writing.
I think what I need to remember is that I’m writing, first and foremost, because I like writing. If I want to put something to paper (so to speak), it shouldn’t matter if someone else has as well.
Last week I threw out a whole piece I’d written about WordPress issue #34976. I threw it out because I had dug into why WordPress plugins weren’t updating for me and was writing up my findings when I discovered that WP already knew, so I figured I shouldn’t bother. Had I published it, though, it would show my thought process through tracking down the bug, which is something I say I want to do.
Clearly I have work to do on this and reading that piece makes me realize it.
Like any self-respecting nerd, I have capital-t Thoughts on The Force Awakens. I didn’t see it on opening night but I did make it before the weekend was out. I’m sure my thoughts aren’t anything new but I want to get them out of my head so they’re coming out here.
It should go without saying but there will be spoilers ahead. Sorry, no getting around that.
I should also state off the bat that I loved the movie. I’m going to focus on things that could come across as complaints but I feel like they’re nit-picks more than anything. The Force Awakens was beautifully put together. Well-acted, visually-stunning, with an incredible John Williams score.
I came away from the film feeling like it was a “darker and edgier” remake of A New Hope. Orphan from a desert planet meets an unexpected older mentor, finds that s/he is force-sensitive, sees said mentor struck down by a dark Jedi in a black suit and mask, then barely escapes as a planet-destroying superweapon is wiped out by a rag-tag fleet.
But wait! It’s gender-bent! And the mentor is killed by his own son! And the superweapon is even bigger! And people actually get stabbed/sliced/etc. by lightsabers! It’s like they took the Battlestar Galactica playbook and applied it to Star Wars.
It’s awesome. It’s larger in scope than Episode IV. But I think it’s impossible not to make those comparisons.
Additionally I have an issue with the balance of power between Rey and Finn. Rey is a complete badass. Pilot, mechanic, handy with a blaster and, apparently, extremely strong with the Force. Finn… Well, comparatively, he’s okay, I guess.
I’ve seen a lot of stuff calling Rey a Mary Sue (or other worse, misogynistic things) but I actually have no problem with her character. I just wish we saw more of what makes Finn tick. This is a guy who deserted the First Order because it was The Right Thing to Do. Who picked up a lightsaber because it was the only weapon available and he needed to fight. Who used that lightsaber – with no training – to fight the closest thing to the personification of evil that he’s ever seen.
That’s badass, too, but seems overshadowed by just how incredible Rey is. Not saying anything should be taken from Rey, I just would have liked more backstory for Finn.
That said, I imagine backstory for both characters will be prevalent in future films.
On the Dark Side, we have Kylo Ren. Clearly this is a heavily-conflicted character. It’s impossible not to compare him to Anakin Skywalker (which, as he basically worships Darth Vader, is pretty much the point). I think he could actually be more of a bad guy than Vader as Anakin was pretty much tricked into joining the Dark Side. Han Solo tells his son that he’s been tricked, but I think Ben chose of his own free will to become Kylo Ren. We may learn otherwise in future films – redemption arcs are big in this series – but it seems to me that Ben didn’t want the power of the Dark Side for any noble purpose like Anakin, he just wanted power.
Seeing him without his helmet adds to that, I think. He’s not a deformed half-man confined to a suit like Vader. He’s a human who chooses the suit. He can take it off. He just doesn’t want to.
Speaking of the Dark Side… As Rey embraces the force in her battle with Kylo Ren, it sure seems like she’s putting a lot of hate and vengeance into it. We know those lead to the Dark Side. I wonder if anything will come of that.
If the new trilogy is darker and edgier, it wouldn’t be too much of a stretch for Rey to turn to the Dark Side, with her conversion showing Ben just what a horrible thing the Dark Side is and pushing him back to the Light Side.
I was in a pairing session with one of my teammates earlier today and we stumbled into an interesting little bit of inspiration.
I immediately laughed because a Google Maps search result was included, which was completely outside the context of what we were searching for (though a valid search result for the simple query we entered). As I explained why I was laughing, though, something hit us:
That gut feeling was right. We didn’t want to split anything. We wanted to apply a map to it.
Over the years at TechSmith the ASP and VB6 (mostly) gave way to C# but that wasn’t the only change. Somewhere along the line I became a software engineer.
I can’t speak for the industry as a whole but at TSC there was an impression that web devs weren’t “real developers” compared to the software engineers working on the company’s desktop products. So everyone became software engineers and everyone was equal, even if the job didn’t change at all.
Fast forward to several years ago and the term “full-stack engineer” starts being thrown around. A full-stack engineer being someone who writes back-end code and front end code and maybe does some image manipulation and can do some server management… And I fail to see how this isn’t what we used to call a web developer.
As an industry, did we create a new title just to get the word “engineer” into it? “No, I’m not one of those slacker web developers. I’m a full-stack engineer.” I get that the term became famous when Facebook was (supposedly) only hiring full-stack devs but why give it that name when “web developer” already meant that.
For a long time, even after my title at TechSmith changed, I defined myself as a web developer. One of my mentors called me out on it and I couldn’t explain why I clung to that label. Maybe it’s because, the way I see it, “web developer” is just less of a mouthful than “full-stack engineer” and more accurate than “software engineer.”
If there’s supposed to be a difference between web developer and full-stack engineer, I don’t see it.
I should say that I don’t actually have a problem with the full-stack engineer title. Web development has evolved. There are fewer gaps between web development and mobile development than there were a decade ago, for example. I just see web developer and full-stack engineer as the same thing and think it’s jarring to see the titles used as if they’re not.
Since then I’ve disliked the Griffins’ 20th Season logo, their new primary logo, and their new jerseys. Over the last year it has become painfully clear that I don’t have the same design aesthetic as the Griffins’ front office.
On top of that (and as I’ve said before), I don’t love the idea of the contest. While it’s billed as a fan design contest, many of the winners have been design enthusiasts who are not fans of the Griffins. If Griffins fans aren’t winning, you’re essentially just asking for free design work.
So why submit a concept if I don’t think I have a chance of winning and don’t quite believe in the idea? That’s the question I’m struggling to answer. I did it anyway, though, so I’m detailing it here.
It’s immediately noticeable that this is an evolution of the design I submitted last year. The striping pattern, logos, and numbers are all very similar to the 2014 design and the nameplate is identical.
As the Griffins changed their color scheme for this season, the design has been updated to reflect that change, though I kept the “vintage” palette. Off-white, dark grey as a faded black, and a rust-like red. Out of curiosity, I did give a non-vintage color set a shot and it absolutely screamed 1970s Cleveland Barons so I abandoned it. I will say that going with this color scheme could be a risk as the team doesn’t have helmet/pants/gloves to match it.
With the 2014 design, I came up with a whole set of jerseys but submitted the white one. This time I went with a red jersey with black trim. The Griffins used to have a white home jersey, a blue road jersey, and a red alternate. Now they have a white home jersey, a black road jersey, and a black alternate. I thought having a red jersey rather than just another white or black one was important so I ran with that as the primary color. Additionally, playing up the color black helps keep the jersey from looking like a Red Wings clone.
The striping pattern has been very slightly modified from my original design. The shoulder yoke, wrist stripes, and hem stripe are all black with a white outline and then a black outline. The two outlines are 50% thicker than they were. The shoulder yoke is slightly smaller to account for that.
Additionally, last year I couldn’t decide how to render what was supposed to be a straight stripe, given that the jersey template featured curved lines in places that would be straight in three dimensions. That time I went with a curved line to match, this year I called a straight line a straight line.
The number font changed from a modified version of the Chicago Blackhawks’ (which I deemed to be too wide [due to the modification, not the standard font]) to that of the New York Islanders. I decided to go with black numbers as another way to differentiate the red jersey from Detroit’s and put a white outline around the numbers to make the black more visible on dark red.
Speaking of the number, I also carried over the placement of the jersey number in the collar webbing, my favorite feature from the Griffins’ now-retired red alternate jersey.
The logo – as it was in last year’s submission – is a griffin silhouette inside a shield. The griffin stands on two legs with its claws reaching out to the front. I kept the homage to the Griffins’ original logo in place, as this griffins’ tail is the same as that of the newly-replaced Grand Rapids mark. The only change to the logo is the wing, which I was never happy with.
While I liked the fact that the original wing was raised high, the proportions and shape felt wrong. As such, the new wing is closer to the griffin’s back, larger but sleeker. This also allows a second homage, as the wing’s feathers are in the same shape as the wing on the Red Wings’ logo.
The shoulder logos were significantly harder to decide on than the jersey crest. Shortly after I submitted last year’s concept, I came up with a version of its shoulder logo that added some outlines to the text to give it more depth. For this year, I started with that design and swapped the colors around.
The first debate I had with myself was whether or not to use a Red Wings shoulder patch, as the Griffins’ actual jerseys do and both of last year’s winners did. Wanting to keep the vintage feel, I put together a patch design that was the Winged Wheel in vintage colors inside a shield in a shape that is often (mis-) attributed to the Detroit Cougars of the 1920s.
I then thought about the fact that this is the Griffins’ 20th anniversary season and that it should really be commemorated on the jersey, as it is on all three of the sweaters in their standard set. I replicated the shoulder patch from the team’s home and road jerseys and recolored it to match this jersey design. I also modified the anniversary mark to use the interlocking GR logo rather than either the old or current Griffins’ primary, as I didn’t think they fit with the griffin silhouette crest of my jersey. To give the GR logo some added heft in the anniversary logo, I surrounded it with a kind of “keystone” effect.
With that done, I decided that I wanted to balance out the roundel on the left shoulder with one on the right. This also gave me the opportunity to play with something that always bothers me about minor-league team jerseys: The seemingly-random appearance of another team’s logo. I started by creating a true roundel based on the design of the Griffins’ 20th season logo. I added text to the circle reading “Detroit Red Wings” across the top and “Primary Affiliate” across the bottom, giving reason for the slapping of a Detroit logo on a Griffins jersey. Inside the circle I went not with the Winged Wheel but with the Old English D, as I felt it fit both the circle and the overall feel of the jersey better. The D is outlined in black, a modification I wouldn’t have wanted to make to the Winged Wheel anyway.
As I said, I don’t think this design will win the contest. I don’t think they’ll pick another griffin silhouette so soon after picking one last year. I don’t think they’ll go with a design that they don’t have matching pants and helmets for (for the record, I imagine a black helmet and black pants [well, vintage black] for this set). Also, I think that there are some really… off parts of the 20th season patch but I copied those elements directly from the Griffins so I kept them in.
I don’t know. We’ll see.
One last note, here’s that Barons-esque standard red/white/black design:
Personally, I prefer my notifications via email. To the point that I look at that post and think, “Come on, he only got his notifications via SMS because he works at Twilio.” I mean, why involve an API when PHP can send email pretty much out of the box?
We use the tools that we know. That shouldn’t be a surprise. What hit me is just how much I’ve stayed inside the Trello ecosystem, at least with regards to things that are worth writing about.
So I’m going to get out of my comfort zone a bit and rewrite my financial tracking tool to make use of Twilio. I’ve been saying that I wanted to play with Twilio for awhile now but I had an opportunity to do so and chose to shoehorn Trello in instead, since it was what I was more familiar with.
I’ll write about the Twilio implementation when I get around to it.
The team I’m on recently released a new product. We’ll call it ShinyNewThing. Several weeks of work and discussion and a soft roll-out to some beta users and we were feeling pretty good about ourselves. People were excited about ShinyNewThing.
Oh, sure, testing had revealed an issue early on, but that was clearly an invalid test, the product would never work like that in the wild, right?
Of course it would.
ShinyNewThing only works on root domains and a lot of people want to put it on subdomains. In retrospect, we’re left asking why we ever assumed they wouldn’t in the first place. In fact, noticing the “bug” (as people were still calling it at the time) was kind of embarrassing.
So the team looked into it and started work on fixing it and included it in our weekly status report. Item six of six, tucked in right at the bottom:
ShinyNewThing for Subdomains
And it hit me.
By labeling it that, we had accidentally created a new product. Retroactively we had eliminated our mistake.
If we’re working on ShinyNewThing for Subdomains now, clearly ShinyNewThing was never meant for subdomains. We didn’t make an assumption, we simply followed a business decision. That that business decision never happened doesn’t matter.
It’s an example of the importance of branding. Nevermind that we’ll never actually use this name publicly, that we’ll own up to it as a bug caught while the product was in beta, and that it’s not intended as a brand. It’s pretty clear that we could hide behind this name if we wanted and no one would be the wiser.