Win Tickets To Detroit.Code

I am very excited to be helping with the inaugural Detroit.Code conference here in July 2017.  In fact all of us that work on the DetroitDevDay conference are very excited about this new conference.  We all support growing the metro Detroit software development community and this is another great step in growing that community. (Full disclosure: I am speaking at Detroit.Code.)

As such we want to help make sure as many folks get to the conference as possible. So we’re going to give away a couple of tickets to the event. However, we want to have a little fun at the same time.  So we’re also going to run a little coding contest; everyone who gets the right answer on the coding contest will be entered into a drawing for the two tickets we’re giving away.

I have no interest in spamming folks with the details of the coding contest so if you’re reading this and you’d be interested in getting into the contest, please send me an e-mail at catenacci@ieee.org (gad I’m sure to have more spam soon) and I will add you to the list of folks who get the coding challenge.

Code And Coffee

I’ve always admired something that my friend @CarinMeier mentioned that they do down in Cincinnati (or at least they used to do it anyway).  That’s  a once-monthly “Code And Coffee” where people would get together at a local coffee shop to drink coffee and learn about some interesting topic.

I’m going to be at the Biggby Coffee in Clawson (on 14 Mile) on Wednesday May 3, 2017 at 7 am.  If you’re reading this blog post consider yourself invited to join me for some coffee, some shop talk, and likely some coding.  If you want to join, feel free. People who know me will probably guess that I’m likely to talk about functional programming but honestly I’m willing to talk about almost anything technology related.  If you do decide to join, bring a laptop.

Detroit Day Of Functional

After a bit of discussion and debate a few of us have decided to go ahead with the Detroit Day of Functional on March 25, 2017. Detroit Labs is kind enough to let us borrow their space for the day so that’s where we’ll have it. We’re charging $30 a ticket but that’s mainly to cover lunch and maybe a t-shirt for the attendees if there’s enough left over for that.

We’ve also decided to do something a bit novel (well novel for me anyway). We’re organizing the event as an unconference. That means no pre-selected speakers or sessions. We’re running the whole thing on the principle of open spaces.

I know some people will wonder why we’ve decided on this approach. I can’t speak for my colleagues but for me there were a few good reasons:

  1. I wanted to keep the event relatively simple and I wanted to focus on content more than anything else. A call for speakers is a lot of work and frankly as much as I’m usually happy with the folks we end up with I also feel bad for those who submit great ideas that we can’t accommodate. This way if anyone’s got something really neat they want to discuss, they have the opportunity.
  2. I’ve observed that no matter what I pick for a conference there are people who feel that I’ve got some sort of blinders in regards to content. I’ve been told that my conferences are too “Microsoft-centric”. I’ve also had people express concerns that underserved populations aren’t represented enough by speakers at my conferences. Well here’s your big chance to show me what I’ve been missing. Literally anyone who cares to lead a session can do so. If, for instance, you don’t feel like there’s enough content on stack-based languages at conferences, here’s your chance to remedy that. Want to have a conversation on why functional programming stinks? Feel free. That’s the point of holding this as an unconference–you decide what we discuss, not the organizers (well, not only the organizers anyway).

I wanted to insure that people know exactly what to expect from the start. I wish I were a bit more glib because I think that sometimes people feel that I swing some pretty blunt language but I can’t think of a clever way to say “Hey, we’re not going to have speakers for this event. We will have lunch and we may have t-shirts but no set agenda in terms of speakers.” I’m tempted to set up a pool to see how long it takes someone to ask me “Hey why aren’t you guys going to have speakers at your event?” This is my attempt to forestall the question before it’s even asked.

How I Blew That Interview

  • They said they wanted a “Rock Star” developer but I think they got upset when I trashed the hotel room they had me put up in.
  • They said they wanted a “Rock Star” developer but you should have seen the expression on the face of the interviewer when I smashed my guitar on his desk.
  • They said they wanted a “Ninja” developer but then they insisted that I remove my black cowl during the interview.
  • They said they wanted a “Ninja” developer but I’m pretty sure they got a bit upset having to dig my throwing stars out of the paneling.
  • They said they wanted a “Rock Star” developer but I’m pretty sure I lost them about halfway through my twenty minute drum solo.

Left Side vs. Right Side Agile

We were discussing agile today and I came up with something that I thought might be worth sharing with others.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

And I was saying to some of the folks on my team that it seems as if we’re getting right side agile and not left side.  While lots of firms these days are calling themselves agile they’re still very much on the right side of that list. As someone put it to me, lots of places are doing waterfall with daily stand ups and two week sprints.

So maybe we need to start calling out our managers and our VP’s on right side agile and tell them that we favor the left side and we want them to favor it too.

Premature Generalization

I’m sure most developers reading this post will be familiar with the term “premature optimization”. For those who may not be familiar, this refers to the tendency that some developers have to worrying about the performance of their code, usually but not always in terms of execution time, before their code is proven to work correctly in terms of customer requirements. It’s like saying, “Hmm, this function call may take 3 clock cycles to execute but if I inline the code it won’t take any extra clock cycles” before the developer has correctly defined the function to be called. It’s generally considered a poor way to write software. I believe it was probably Joe Armstrong, one of the co-creators of Erlang, who said “Make it right, make it fast, then make it pretty.” Getting the code right always comes before any sort of optimization should be attempted.

Risking the perils that may befall anyone who coins a neologism, I propose another premature condition which developers should try to avoid: premature generalization. I would define premature generalization as being the tendency to assume that what you see or what you want is what every other developer sees and/or wants. It’s the tendency of the novice developer to post messages like “Hey function x isn’t working. What’s wrong?” assuming that the rest of us also have the problem they have and we therefore don’t need any more detail to know what he or she is talking about. It’s also the tendency to assume that because they need to address some particular use case that most developers working in the language will need to address the same use case: “Hey I need library function x to return an error status when I pass it a bad argument but throw an exception when I pass it a good but out of range argument. Can we modify the standard library to do this?” In both cases, I believe they’re prematurely assuming their question is generic and therefore they don’t need to provide details to others.

Although I feel I’m flogging a dead equine I hasten to point out that as software developers we should usually proceed from the assumption that the error we’re seeing is due to something specific to us. We should also proceed from the assumption that any use case we have is likely to be a use case specific to us until we see evidence otherwise. Yes, I am aware of the irony of making generic statements here—but given what I’ve seen over 25+ years of software development I don’t believe that I’m indulging myself in premature generalization.