On naming

There are only two hard things in Computer Science: cache invalidation and naming things.

– Phil Karlton

At work a teammate and I have a long running joke about how we disagree with identifier naming. He favors long “descriptive” names, and I like short terse names. We never get angry over this disparity in our views, and mostly find good compromises during code review. As long as I’m not working alone, I’m more than willing to lay aside my preferences for the greater good of the team. Yet these past few days, my bias towards shorter names has been triggered into some passionate responses.

The most notable was a recent podcast from Functional Geekery featuring an interview with Adi Bolboaca. In this episode, Adi is discussing his experiences leading code retreats with host Steven Proctor. I really got worked up when Adi was speaking of how he battles functional programmers and their short naming. His claim is that descriptive naming was a principle of clean code which transcends paradigms. I just really felt that he got that one wrong.

But why? Why I do I feel strongly about using shorter names? I’ve put some thought into it and I’ve identified a few factors. Firstly I was a math geek before a software geek. I’m not talking about that math minor they forced you to get with your CS degree where you’re playing the role of the computer and not the mathematician. I’m talking about the “advanced” mathematics courses where the focus is on clearly communicating abstractions. I can’t quite recall names longer than a single character in my math courses. We’d rather reach into the bag of Greek letters to retain the brevity. If a second letter is introduced, it is as a suffix to indicate something else significant. Not a character is wasted. The reader is expected to apply the short names to abstract concepts and roll with it.

Fast-forward to the present where I am now engrossed with functional programming. This paradigm is far more closely related to the discipline of mathematics than traditional imperative programming techniques and theory (if any such thing exists). Given that functional programming is much more like math lends credence to my feeling that “clean code” applied to functional programming doesn’t carry long identifier names with it. Terseness is part of the paradigm. One can even argue that long variable names are an anti-pattern. I think it’s just the unfamiliarity of our Reverse Hungarian notation that led Adi to believe the principle still applies.

However, I feel I can lay aside the relationship to mathematics and it’s use of terse naming in route to understanding the underlying reason for my preference of short names. It all goes back to my attitude towards commenting code. The computer doesn’t care what you name things. The names we use are of importance to human reader of the code. They’re glorified comments. Names which are public and hence get included as part of an API and its respective documentation are certainly important and should carry meaning. Names which are internal to the code are mere comments attached to code artifacts. As I stated previously, I agree that the only useful comment is one that answers the question Why?. The name of an identifier never answers Why?. Rather, it always answers What? and often the context of the code has already answered this question, rendering the name redundant.

Perhaps the most classic example is the good ol’ loop iterator i:

for(int i=0; i<=10; i++) {

Developers worth their salt never use a verbose name like index for an iterating index such as this. The context and structure of the code already tell us that this is an index. By having the shorter name, the operative properties are more pronounced in the construct. That is, the start value 0, the stop condition <=10, and the increment expression i++ are quickly and easily identifiable. Longer names such as index, currentIndex, or indexOfTheLoop clutter this up and distract from these three vital pieces of information. Given that these three dictate what the code actually means versus what the author of the code thinks it should mean, I’m strongly inclined to prefer the more concise version.

In fact, functional languages like Scala take this even further. This construct is so common, we don’t even need as much clutter as the simple example above gives us. We compress it down further to the following.

for { i <- 1 to 10 } {

We see that the most important information in this construct is even more prominent: the start value 1 and the stop value 10. Incrementing by 1 is so common, it’s assumed unless you tell it otherwise. Don’t confuse this for more of my Scala evangelism for the Java oppressed. I’m pointing out that the functional paradigm’s embrace of terseness behooves us to reconsider what is regarded as clean code. I believe this results in those who have not adopted this paradigm erroneously believing the best practices transcend. The principles certainly transcend, with code readability being the principle in this discussion, but not necessarily the principles. I’ll go even further and argue that shorter names works well for imperative programming too, just as the for loop above suggests.

So what are my underlying principles with naming?

  • I believe that name length should be roughly proportional to scope size. The i in the above examples is a good specimen of a name with a tiny scope, and hence a tiny length is appropriate.
  • The name length should be inversely proportional to its frequency of use. A name that is repeated constantly through code needs to be short lest we introduce an epidemic of carpal tunnel. A frequently used name even if terse will be well understood. A great example of this is Lift’s S.
  • Don’t repeat the construct in the name. This is why we needn’t include “index” in the above name, neither should “accumulator” be used in a fold or reduce expression.
  • Don’t clutter the name with the context of the name. If you have a class named BankAccount, don’t use accountBalance. “Account” is already there, just let it be balance. Or if you have an actor, don’t name it’s internal state as currentState unless you are distinguishing it from other states such as previousState. Just let it be state.

Chances are good that I’m wrong that longer names are detrimental to readability. At least that was the consensus on twitter. If you take nothing else away from this post, let’s at least agree that longer isn’t always better.

Leave a reply below, or send me a tweet.

Tagged with: , , , ,
Posted in Software Development

ÜberConf Days 3 & 4: Hits and Misses

The last two days I hit some great sessions and some blah sessions. As I mentioned in my last post, my favorite part about this conference has been the people I’ve met and not the sessions as much. The third day I really saw that it can be tricky because although you can respectfully bail within the first five minutes of the presentation, I haven’t been able to decide if it is a miss until I’m in too far to make a switch.

Fortunately the day started off awesome with Matt Stine applying Uncle Bob Martin and Michael Feather‘s SOLID OOP principles to functional programming. As Matt pointed out, principles are universally true, and hence there should be no reason we cannot apply SOLID to functional programming. He did a fantastic job of demonstrating these principles with some Clojure code that I was able to mostly understand. The coolest part of this presentation was towards the end when he brought up the notorious Simple Made Easy keynote by the venerable Rich Hickey, and defined each of the SOLID principles in terms of complecting stuff that should be separate.

After such an outstanding talk, I thought I’d hang around and enjoy Matt’s next talk, Programming with Immutability. I should have read the overview/slides before this one started because it was all Java. Granted I still enjoyed the topic, I probably could have found something more relevant for me. Once he got into some details of different libraries to aid Java developers in adopting more immutability, I caught a severe case of disinterest and worked on yesterday’s blog post.

The next talk I attended was another dose of Nate Schutta titled You’re an architect… Now what?. I thought this would be a good one given my previous experience with Nate and my still-recent entry into the world of architecting. I came out of this talk quite reassured about how I’ve been approaching my opportunity.

After lunch I caught Rob Spieldenner showing off some of Netflix’s cloud goods. As much as I really enjoyed hanging out with Rob and Dan Woods from Netflix, this was not the talk for me. In a nutshell, it was a workshop on AWS using stuff that Netflix built because they don’t use Elastic Beanstalk. Although Rob did a fine job with the workshop, it just brought me back to how much I don’t enjoy the AWS aspects of my job.

I had no qualms skipping the second half of the AWS action for some scaling agile action with Esther Derby. This talk was probably better than I realized, but the exhaustion of the conference was building quite strongly by this point. I wasn’t able to focus very well, although I did live tweet a handful of good nuggets. Other than my general interest in agility, my primary motivation for attending this talk is to be prepared for when my team grows or our project gets other teams working on the code base. The problems we have at our tiny size will be very different from the ones we’ll have when (not if) those things happen. The biggest point that resonates with me is her suggestion to not divide teams up by component/function. Each team should be full-stack and able to deliver working pieces of functionality without depending on another team for the rest of the vertical slice. Beyond that I mostly came away with more reinforcements for what I’m already learning at work and through other resources such as This Agile Life.

I started the next day watching Rob talk more about Netflix, but this time it was about continuous delivery. Although I like where my team is on this front, I know we could get better. One of the most interesting things I discovered is that they don’t just deploy application code like we do. Their teams build out (or “bake” as they like to call it) the application code along with a machine image which eventually gets dropped and deployed on the cloud. I also learned that there are a lot of monkeys running around their cloud. The have scripts they’ve given monkey names that randomly kill off machine instances in production, in addition to scheduled drops of availability zones and regions.

Next up was some JavaScript patterns with Raju who I’ve found is yet another fantastic No Fluff presenter. Even though we use CoffeeScript at work for all of our JavaScript, I expected much of the patterns to translate. I came home with some new tricks of my sleeve. Unfortunately as you can guess, most of what he showed was things to keep you from dying in the wild world of JavaScript, many of which are handled for us in Coffee.

And then, there was Venkat. I must say that the schedule set up to save the best for last. I hung out with most of the speakers at the conference, and every single one of them would back me up when I say that Venkat is a rock star developer, teacher, presenter, anything software. This first presentation of his that I attended was on Nashorn, the JVM JavaScript engine which ships with Java 8. Although I left the talk still not sure how I should use JS on the server, I learned that it is a well-designed/smooth tool in the JVM tool belt. The FFI interop with Java is very impressive. I also found it quite interesting that it actually has a “script mode” which gives you a handful more tricks to use in your JavaScript. I also didn’t know that it is packaged as an executable with the JVM so that you can get a REPL or pass it a JS file to execute. As a result, you can shebang the top of your JS scripts and now you have executable scripts like any other. The sickest feature I saw was how you can define a Java interface to match the functions you have in your JS, and on the fly it will provide an instantiation of that interface which is wired up to the underlying JS. As I’ve said before, I’m particularly excited to see the JVM really embracing its emerging role as a polyglot runtime environment. Overall very cool stuff, very well presented.

And then, there was Venkat on Haskell. Finally, I sat down and learned me a Haskell for great good. Over my career, I’ve learned that there is only one way that I really uptake another language. That is, I have to watch someone walk me through the first steps. Until that happens, I’m all talk. I learned C, C++, and Java at my university (yeah, notice the embarrassing lack of functional languages there? I’m still nudging them over that problem). I picked up Scala from Martin Odersky’s free online course. Dave Lee exposed me to CoffeeScript while presenting a JS library at HuntFunc. I picked up Clojure earlier in the conference, and now Haskell. The two exceptions to this is JavaScript (necessity and deceptive ease) and Groovy (as a super-set language, I didn’t need to learn much to get started). I believe the biggest thing that slows me down from starting a new language is the fear of how much time I will invest before realizing any productive gains. For some reason in my mind, I feel I’ll get over that hump more quickly if there is someone showing it to me. Anyway, I digress. On to Haskell.

Haskell is every bit of bad ass I expected. I was pretty comfortable with many of the concepts because of my work in Scala. As much as I love type inference in Scala, I didn’t realize how much I was missing. Haskell will look at the body of the function and infer output AND input types. I’ve been doing Java and Scala so long, that it hadn’t even occurred to me that such a thing could happen. I really love the ideas behind having an IO monad and all that good stuff, and it was cool seeing it in action. One thing I didn’t expect to see is how the inputs to a function can be pattern matched right there at declaration time, reminding me of what I’ve seen in Erlang. I also had forgotten how every function in Haskell takes at most one argument. More arguments just means that you’re really returning another function with the next argument. Unfortunately, I’m in the same place with Haskell as Clojure… I don’t know what I should aim for next. I need to dream up something I can build with each one.

So that was the rest of the sessions I attended. As I’ve said many times, the best part is the stuff I’m not bothering to write up: Hanging out with other developers. Although I enjoyed a lot of talks at this conference, I would gladly return only to hang out. I’ve made some great connections that I’m excited about and I look forward to what some of us might be cooking up in the near future. Stay tuned.

Leave a reply below, or send me a tweet.

Tagged with: , , , , , , ,
Posted in Software Development

ÜberConf Day 2: Second expojure to Clojure

Day 2 for me at ÜberConf was the first day for many, as it marks the beginning of the meat of the conference. I didn’t love the first two sessions, but they lived up to my 3 of 5 stoke rating. While Kirk Knoernschild did a fine job presenting the modular architectures material, it wasn’t anything new to me. The refactorings he demonstrated to obtain a modular architecture to the code base just seemed obvious to me. I’m a fan of OSGi, although I don’t use it on any current projects. Hence I left that one quite underwhelmed.

For the second talk, I really took a liking to Nate Schutta. The topic of leading technical change described many behaviors I already exercise to stay abreast with the developments in our craft, such as reading blogs in down time, turning off the TV, etc. I thought the talk would be more about how to influence change in our organizations (although that piece was there a little bit). Despite all of that, I just thoroughly enjoyed Nate’s presentation style and the great points he made throughout. A great example of the sorts of things he said came out in an earlier talk I didn’t attend when he almost quoted Jason Tice from This Agile Life by stating “We’re not FTEs. We’re not ‘resources’. We are people. Treat people like people.” Needless to say, I shared that podcast episode with him.

(EDIT: In the original post, I completely forgot this talk)
The third talk I joined covered the Java type system. I don’t feel like getting much into it, but I came away realizing how much of a train wreck it is. Not trying to be arrogant here, but it really is a pain, especially with mutability ruining everything. Great talk, but the material was a little depressing if I think about having to go back to Java.

On to the second half of the day, the more compelling half of the day… As I’ve mentioned before on this blog, Clojure was the first functional language on the JVM I looked at. In that post I also expressed a renewed interest in Clojure, and now a little over a year later I finally took initiative and dove in. And when I say “dove in”, I mean I got violently barraged with Clojure. Neal Ford does not mess around when leading a Clojure workshop. He and Stuart Holloway made a conscious decision to make their intro to Clojure try to cover EVERYTHING and see what sticks with the audience. Firstly, I LOVED this approach. I always hated the snail pace of school… Like yeah, I got it the first time. Granted I didn’t understand half of what he showed, but the half I did understand is far greater than the quarter of the material I would have comprehended if given at a slower pace. So kudos for that.

I would have sunk in this workshop two years ago. I don’t know how any Java developers swam in those two sessions. If it wasn’t from the comfort level I’ve already built up for immutability, persistent data structures, code compactness, etc; there is no way I would have comprehended anything beyond "Hello, World!". I know, because I tried it before. I got to the REPL, entered (+ 1 2 3) enjoyed the echo of 6 and didn’t know what to do next. I think I’m actually ready to play in Clojure more now. I feel really torn tho because I am enjoying Scala so much at the current time, both at work and in free time.

So I thoroughly enjoyed this workshop, and I think I made a good decision forgoing my original plan to attend two JavaScript sessions. It also prepped me to be more comfortable with Matt Stine‘s use of Clojure in his Functional SOLID session. (EDIT: I’m a little ahead of myself here, as this talk occurred day 3) I’m starting to feel a LOT of pressure to spend more time in Clojure. I’ve noticed the Clojurians often point out the complexity of Scala’s syntax. Given how elegantly simple Clojure’s syntax is, I see where they’re coming from. Everything is just a list. '(1 2 3) is a list, (+ 1 2 3) is a list. A record is just a map, and it receives the benefits of all of the map functions. Scala on the other hand is frankly more like Java; there are these special things and those special things, etc. More so than ever before, I understand why Scala is often regarded as “just a better Java”. As I listen to some of these guys talk about the differences, there is a part of me that can’t stop thinking about some of the good points made.

And on that point, even if I were swept off my feet by Clojure, I still believe I made the best choice to set my team on our current course with Scala, Lift, Akka, etc. The tooling available for web application development is much more mature; Lift being the most outstanding web framework I’ve yet to experience. More importantly, I believe my team needs a gradual adoption of functional programming. There is no way I could have shut our shop down for a month while we learned a new language in hopes that we would catch up later. We needed to maintain productivity using our Neanderthal OOP skill set while we foster our still-budding functional programming skill set.

Yet a danger lies there. After the workshop, Neal and I had a great conversation about the merits of each Scala and Clojure. He described the situation as if we are standing in the OO/Java world looking at the distant functional programming world. Scala paves a wide parking lot across that chasm, allowing us to leisurely take our time reaching the functional programming world. Unfortunately, you can easily become complacent in the journey and set up camp somewhere short of functional programming. Clojure on the other hand is a narrow bridge straight to the FP world with no middle ground.

That last statement is arguably my greatest attraction to Clojure, with its elegant simplicity standing right behind it in second. Having been increasingly immersed in Scala over the past two years, I am now sold on functional programming. Now that it is clicking, I am done with the imperative paradigm. I crave referential transparency, which is arguably the greatest advantage of functional programming. I want immutability, and I want to tightly constrain side effects. I would love to spend more time in a more purely-functional language to see if I can finally defeat the last remaining footholds of imperative and object-oriented thinking.

I’m still a wee bit hung up on the dynamic typing. It won’t stop me from playing with Clojure, as I’d argue it is the most compelling functional programming language on the JVM (here, I don’t say Scala as it is a multi-paradigm language). I just think it is too valuable, throwing out the baby with the bathwater sort of thing. While I was talking to Neal, he said he felt that while static typing is valuable, it isn’t worth the cost. Matt shared a similar sentiment, lamenting that he quickly tired of fighting the compiler to run code that he knew would work. I’d like to see an example of this. In my experience, it didn’t compile because it was wrong. He even joked later on that in Haskell, if you can get it to compile then it works. Given how much Scala attempts to borrow from Haskell, this can hold true for it in many cases too. All of that aside, I see where static typing may not be appropriate for Clojure. It seems a bit dynamic in the way it likes to treat records as a map, and nearly everything else as a list.

So what’s next? I need to spend more time with the exercises Neal sent us home with. From there I need to find something to work on in order for me to stay motivated. As much as I love code, I only do well when there is a goal involved, particularly something to be built. I did receive a tweet inviting me to help with an OSS MongoDB driver wrapper. While that is moderately interesting, I’d love some other suggestions.

As if this wasn’t a long enough day, I wrapped it up by attending a make-up AngularJS workshop from Raju Gandhi. Even though we already use Angular at work, I was optimistic that I would learn some things that I’ve missed along the way. The main thing I came away with is a better understanding of how directives and such work. The best part of this one was meeting Raju and picking his brain on some of our developments with lift-ng.

I closed the day out by hanging out at the bar where I was fortunate to find many of the speakers and No Fluff Just Stuff organizers hanging out. I spent a lot of time talking to their lead developer (drawing a blank on his name at the moment). I’m certainly experiencing what others have told me about conferences: The sessions and keynotes are great, but the people you meet are the greatest part of the experience.

Leave a reply below, or send me a tweet.

Tagged with: , , , ,
Posted in Software Development

ÜberConf Day 1: Web Application Security Workshop with Ken Sipe

Day one of ÜberConf was the workshop day, and I attended the Web Application Security Workshop with Ken Sipe. I’d say the workshop met my expectations. There were parts that I knew, parts I didn’t know, that sort of thing. Here are a few hits that stood out.

This is something I had never really thought of. Single sign on? Convenient! Great user experience! But it is a security vulnerability no matter how well implemented. Another example he gave that really stood out is Mint.com. Here you give them your banking credentials, and it grabs all of your transactions and helps you budget, etc. Great user experience, but now you’re credentials are stored out there.

In other words, think of security up front. This is often one of the last considerations given to an application, but it’s arguably too little too late. It left me with the impression that I should really bake security into an application. This makes sense because when you have the hood up on a feature, that’s when you are thinking about all of the paths and use cases. While you’re there, go ahead and think about how it can be abused.

Another observation I’ve made during this workshop is the power of two. What I mean is having two different security measures. The one we are most familiar with is 2-step verification, where after logging in with valid credentials, the web application sends you a text message with a token/id. The principle in play is the unlikelihood that someone has stolen both your credentials and your phone, or hacked both systems perhaps. Another example of this I’ve not thought of before is the unlikelihood a malicious individual has gained access to both your application data and your application source. For instance, if you hope to not repeat the LinkedIn mistake, you should salt your passwords. We could use some immutable data about each user (such as the account creation date) and apply some application-level logic to it (convert it to millis, then compute the modulo with a big ass prime number) to create the salt. Hence to unlock the hash, you need both the data and the source to know how to compute the salt with the data.

As with anything in software, there is always a cost/benefit to consider. Ken highlighted how this also applies to your threat analysis. Perhaps you have identified a vulnerability in your system. Before you address it, you should first consider the likelihood of exploitation and the cost of that exploitation. An example he gave was related to his work on GoGo internet which serves in-flight wireless internet services. The pool of potential attackers have all paid a large sum of money for a plane ticket, and they are in the network for a relatively short amount of time. Hence, the need to make sure the service isn’t stolen or somehow discounted is probably not something of great value that the development team should invest time into.

So far so good at ÜberConf. I have no idea if I’ll write any more blog posts while here. Frankly I got bored during the exercises and blogged up what I learned today. I doubt that will happen for the remainder of the event.

Tagged with: , , ,
Posted in Software Development

Picking ÜberConf sessions sucks

I’m gearing up for ÜberConf next week in Denver. It will be my first tech conference. I’ve never gone because I’m cheap and would like my employer to pay for it. I’m very grateful to Mentor Graphics for their willingness to invest back into me by sending me to a conference this year. Now that it’s days away, I have to go through the sessions and decide which ones I will attend. There are so many good sessions that are run concurrently, causing me to find this process pretty frustrating.

When I first looked at the conference and the sessions planned a few months ago, I had in mind that I would learn some Clojure, R, Java 8 lambdas, and more agility skills. Due to changes in the sessions and changes in what I’m working on, I will be attending zero sessions on those. I’m not using Java at all now days. I’m curious about R, but it’s not particularly relevant to me. I would LOVE to learn some Clojure, but there are some killer JavaScript sessions at the same time which I know I need for my daily work. I suck at JavaScript and any help will be greatly appreciated. I really want to brush shoulders with more folks doing agile, but dang it if every one of those sessions doesn’t coincide with a more technically interesting one. As much as the guys at ThisAgileLife have me excited about being an agile developer, I still feel the strongest draw to the code itself.

So here are the sessions I plan to attend, why I picked them, and why the others didn’t make the cut. Click here for the complete list of available sessions. Not only are these subject to change, there’s a chance I’ll skip a session altogether if I’ve run into someone more interesting than the topics to choose from.

Session #7: Web Application Security Workshop by Ken Sipe

The first day of sessions are full-day workshops that are an extra charge. I figured since I’d already be travelling to Denver for the event, I might as well attend all that I can while there. Picking this session wasn’t too difficult. Of the things I really don’t have a great grasp on, security is probably the one that I need the most. I generally rely on frameworks and libraries to be awesome in the security department by default like Lift is, but that won’t always be good enough.

Stoked? 3 of 5
Let’s face it… I’m not excited about security, I just know it’s something I need.

The runner-ups:
Session #1: Angular Workshop by Raju Gandhi

I would love to learn more about my favorite JavaScript library/framework, but I suspect this one will be too introductory-level for me to gain a lot of skills.

Session #5: Building Modular Architectures by Kirk Knoernschild

This was my second choice, but I have other opportunities to hear from Kirk regarding modularization during the conference. No such second chances exist for security.

Session #15: Modular Java Architecture by Kirk Knoernschild

I’m always interested in busting up big things. Big stories into smaller stories, big chunks of code into smaller ones, and certainly big applications into small configurable modules. Although this one has that antiquated language in the title, I’m sure it’ll still be applicable to this Scala slinger.

Stoked? 3 of 5
I’m cocky enough to think I can already do this well enough, but wise enough to know I don’t know half of it.

The runner-up:
Session #12: JavaScript Workshop, part I by Pratik Patel

This being my only other options made my choice easier. I suspect this one will be too introductory for my JavaScript skills, despite being admittedly sketchy.

Session #30: Leading Technical Change by Nate Schutta

As someone who has twice attempted Scala adoption, this one really jives with me. I figure most people in this session are entering a little frustrated that they’ve not succeeded in adopting a technology they like. I’m hopeful I’ll leave better equipped to continue leading these types of rebellions, and encourage the other attenders along the way.

Stoked? 3 of 5
Been there done that, but I’m pretty passionate on the topic.

The runner-up:
Session #25: Toward Agile Architecture by Kirk Knoernschild

There is a good chance I’ll still go to this one, depending on how much I enjoy his prior session.

Session #37: What’s in a Type? A Mathematical View of the Java Type System by Douglas Hawkins

In case you haven’t noticed, I’m interested in type programming. If this was the Scala type system, I’d be stoked off the chart. The Java type system will do. After all, Martin Odersky was pivotal in developing the Java 1.5 generics, and I figure I can pick this guy’s brain on more advanced type systems.

Stoked? 4 of 5
Loss of a point for being about Java.

The runner-ups:
Session #31: Continuous Delivery for Architects by Neal Ford

I would certainly enjoy learning more here, but I feel my team is in a pretty good place here.

Session #38: Guava for Java by James Harmon

If I could foresee any future Java development for myself, I’d be all over this.

Session #40 : Becoming More Agile by Ken Sipe

I would love to talk some agile, but math wins.

Session #44: Functional JavaScript by Pratik Patel

There should be no surprise in my interest here. I’d love to be better at using functional programming in a language I spend a lot of time in. Granted we use CoffeeScript, it is so semantically similar that I’m certain all of the skills will translate.

Stoked? 5 of 5
Nearly lost a point due to conflicting with the first runner-up…

The runner-ups:
Session #47: Introduction to Clojure Workshop Part 1 by Neal Ford

I’m so frustrated that this session coincides with Functional JavaScript! I’m equally excited about both topics, but I had to use the “I will actually use this at work” tie breaker to settle this one. My apologies go out to local Clojuremen Bret, Chad, and Eric.

Session #50: The Top Agile Pitfalls that Lead to Trouble by Andy Painter

I’d probably rate this one a 4 of 5, but dammit if it doesn’t coincide with two 5’s. I have to believe my team does half of the caveats given in this session.

Session #54: JavaScript Design Patterns by Pratik Patel

Back in my late undergrad days, OOP really started to click when I took a design patterns course featuring the infamous Gang-of-Four. I’m optimistic that some things will really start clicking for me in the wild world of JavaScript.

Stoked? 4 of 5
MOAR JAVASCRIPT!!! Well, not that I love JS but it’s a necessary evil that I’m currently living with.

The runner-ups:
Session #57: Introduction to Clojure Workshop Part 2 by Neal Ford

Why couldn’t this be the time slot for part 1??

Session #60: The Disciplined Agile Team by Andy Painter

I’m a huge fan of discipline, and teaching it. I would hope this session would leave me well-equipped to teach others more effectively. I doubt I need much more convincing.

Session #61: Understanding Garbage Collection by Douglas Hawkins

I’m basically picking this one because it’s the only one I’m really interested in during this block. It should be really interesting and relevant, especially given how Scala doesn’t like to mutate data. I’m sure I tax the GC a little more as a result.

Stoked? 3 of 5
If I were Michael Bernstein, this would be 5 of 5.

The runner-up:
Session #69: A Java Dev Learns to Go by Matt Stine

I’m only mildly interested in Go.

Session #77: Functional SOLID by Matt Stine

I spent the requisite 10,000 hours to claim mastery of object-oriented programming thanks to my years of experience in Java. Now it’s time to bolster my journey in functional programming with principles that I probably should have known when I started.

Stoked? 4 of 5
A topic featuring “functional” in the name gets a minimum of 4.

The runner-ups:
Session #71: Hacking Workshop by Ken Sipe

Who wouldn’t want to learn more about hacking?

Session #72: JVM Mechanics by Douglas Hawkins

This one enjoys a slight chance of increase in interest based on how the prior GC talk goes.

Session #73: The JavaScript Developer’s Toolchain Workshop by Nathaniel Schutta

I can’t help but believe that half the reason I suck at JavaScript is that I’m ill-equipped.

Session #87: Programming with Immutability by Matt Stine

I’m already quite used to this in Scala. I don’t remember the last time I needed a variable. However, I’m putting in a bet that I don’t know it all yet.

Stoked? 4 of 5
A topic featuring “immutability” in the name gets a minimum of 4.

The runner-ups:

Two continuations of sessions I’m already skipping for SOLID.

Session #100: Scala: Demystifying The Funky Stuff by Daniel Hinojosa

This session is supposed to cover several things I’m already competent in, but there are some that I’m not so comfortable with. I hope this will solidify my understanding of familiar areas and make sense out of the fuzzy ones.

Stoked? 5 of 5
It’s Scala. Did you even have to ask??

The runner-ups:
Session #91: You’re an Architect…Now What? by Nathaniel Schutta

I hate to miss this one as I a sit here completing my first year of legitimately being an architect. I just can’t skip a Scala session given how much time I spend slingin’ it.

Session #97: Kanban for the simple team or complex enterprise by Andy Painter

It pains me greatly to miss this one as well. I’ve threatened several times to urge our team to try it out for a few weeks. I feel that scrum is limiting us in some ways that Kanban would free us. However, I don’t have an idea of what we would lose.

Session #110: Testing In Scala by Daniel Hinojosa

For someone who loves TDD as much as I do, I don’t feel I’m anywhere close to mastering testing when I’m doing Scala. My biggest weakness is effective mocking. I’d also like to get a better handle on property-based testing. Hopefully both of these will be strengthened by this talk.

Stoked? 5 of 5
Scala and TDD for the win!

The runner-up:
Session #107: What Does Self-Organizing Team Really Mean? by Esther Derby

Anything agile-related is of interest, but it doesn’t trump Scala.

Session #111: Reactive Programming by Venkat Subramaniam

Finally, I get to see Venkat in action in person. I fell in love with this guy’s presentation style when I saw his Scala Tricks presentation on youtube. I’m already quite familiar with the topic at hand, but it’s quite the driving force behind a lot of what I develop.

Stoked? 4 of 5
Venkat on one of the hottest topics in development? Full of win.

The runner-ups:
Session #118: Introduction to Go by Ken Sipe

There is a slight chance I’ll switch to this one. I’ll get to see Venkat later, and it’s the only chance I’ll have to check out Go despite my lack of enthusiasm for it.

Session #120: Playing with the Play Framework by Daniel Hinojosa

I’ve already built a simple app with Play and Angular. Not only was that an underwhelming experience, I suspect this introduction will do little to show me more than I learned on my own.

Session #121: Rich Web Apps with Angular by Raju Gandhi

I’m on the fence about this one. I expect it to be too introductory for me, but I also bet there are some basic features I’m not utilizing. I just sorta jumped in with it and started building stuff.

Stoked? 3 of 5
I love Angular, but the likelihood being too introductory is killing my interest.

The runner-up:
Session #129: Continuous Delivery at Net#ix: Speed at Scale by Rob Spieldenner

Hmm… Now that I look over this one again, I feel I’ll probably switch. I like where my team is at on this topic, but I’d like to see how they’re doing it so well, especially with AWS. That’s the bit that has been the biggest hang-up for me.

Session #131: JavaScript Patterns by Raju Gandhi

Another dose of patterns in JavaScript? Sign me up!

Stoked? 4 of 5
Same as before. Different instructor, so hopefully that much more to learn.

The runner-ups:

None for this block.

Session #146: Exploring Nashorn by Venkat Subramaniam

I’m interested in Nashorn for a few reasons. I’m currently the owner of sbt-jasmine-plugin and it uses Rhino for JVM evaluation of JavaScript. Rhino has had a good run, but it hasn’t been touched in years. I’m also curious what are the other uses of JavaScript from the JVM.

Stoked? 4 of 5
Venkat rocks and I dig the idea of the JVM giving first-class citizenship to alternate languages.

The runner-ups:
Session #145: I have seen the top Akka mountain, and it is good. by Daniel Hinojosa

This one is much like my feelings on the reactive talk and the Angular talk. They’re all some of my favorite topics, but I fear I already am familiar enough to not glean much from an introductory talk.

Session #149: R : Workshop I by Brian Sletten

Out of one side of my mouth I preach getting exposed to the most number of languages possible. Out of the other side I don’t ever feel like I’ve got the time to invest in something I don’t feel I’ll use. So count me among the hypocrites.

Session #156: Haskell for Java Programmers by Venkat Subramaniam

Stoked? 5 of 5
This is by far the one I’m most looking forward to. I’m most excited about Venkat of all the speakers, and I really want to learn me a Haskell for great good.

The runner-ups:
Session #155: Making Java Bearable with Guava (2014 Edition) by Daniel Hinojosa

Given that Daniel is covering several Scala sessions, I’m more inclined to this edition of Guava talk. No way in heck I’m missing Haskell for it.

Session #159: R : Workshop II by Brian Sletten

If I don’t take the first R session, I certainly won’t waste my time here.

Thanks for processing these tough decisions with me. I can’t wait to get there! On one hand I’d love to drop a blog post every day highlighting what I’ve learned. On the other hand, I don’t need to miss any opportunities to hang out with the people I meet there. We’ll see…

Leave a reply below, or send me a tweet.

Tagged with: , , , , , , , , , , ,
Posted in Software Development

Fear of plagiarism is killing collaboration

Since the inception of my team, we have really struggled with pair programming. We all agree that it is very beneficial, yet at every retrospective we ask why we aren’t pairing more. To be fair, the logistics of having three full-time developers works against us pairing well. I’m also sure we’re all pretty far on the introversion end of the personality spectrum, so pairing is exhausting for us. After a recent conversation with some of our interns at Mentor, I believe I have realized the greatest factor that is killing our collaboration through pairing. It’s the indirect result of an old fear of plagiarism.

Of course we aren’t concerned with plagiarizing one another. That’s not my point. The entire time we were in school (and all three of us have Master’s degrees, so that’s a lot of schoolin’), we got pounded with fear of plagiarism. Every discipline is plagued with an acute fear of the potential for plagiarism, and it manifests in instructors threatening extreme measures given to anyone who collaborates. My interns have told me that there are several courses where if there is any evidence of collaboration in their source code, that they will receive no credit for the assignment and be reported for academic misconduct. It strikes me as even more severe today than when I was in college, and it was bad enough then.

Fast-forward to our current positions at Mentor Graphics, and you see the indoctrination of individualism is alive and well. I’m convinced this deep-seated culture is what is killing our team pairing and collaboration. It’s not that we lack a belief that our work will be better when pairing. It’s quite the opposite. it’s that our natural tendency is to take an assignment-I mean story-from the board and work on it on our own. It was our primary mode of operation for years, so why would it change now?

I know that the role of the university isn’t to train people to do a job, but I don’t see how this benefits academia either. Graduate work always requires collaboration. Students work with their professors to get advice on their thesis and dissertations. Universities routinely churn out papers written by several collaborators. Yet in our course work, we operate in a vacuum where we must work alone. Occasionally there was a course where we had a project which we had to pick a partner or form a team. I always dreaded those because I simply didn’t know what to do or how to work with other people. Out of distrust, I feared being the one who was pinned with most of the work. While these team assignments were rare, at least most undergraduate programs feature a collaborative senior project for a semester or two. Unfortunately, these opportunities are not the norm. The culture instead fosters individualism and students like me need more chances and instruction to become comfortable, effective, and trustworthy in team environments.

As an undergrad, I always enjoyed working in study groups even if I was excelling in the course because the opportunity to guide others helped me master the material (take note that this differs greatly from team projects. In a study group, the outcome of my score was not dependent upon the performance of others). The few semesters I instructed discrete mathematics, I found ways I could encourage students to work together on assignments in hopes they likewise learn better. My key policy for this was the way I graded homework. I never graded for correctness. I merely took note if the student completed the assignment. Then I let the students know they were encouraged to collaborate on the homework because I wouldn’t be grading it such that original work was required. While this did leave open an opportunity for free-loading students to do no work and get credit for completing the assignment, I believe my exams were sufficiently challenging to eliminate any students who haven’t grappled with the homework material. I’m very pleased to report that I often found my students working together on the homework, discovering the solutions together, and teaching one another. Not only do I believe they had a better understanding of the material, I believe I did a better job preparing them for their future careers in software development.

I would love to see a re-examination of how universities are handling plagiarism. I haven’t the faintest clue what the solution to this problem is. I understand the need to protect intellectual rights and ownership. Somehow we need to balance the integrity of the degrees awarded to the individual, while encouraging these individuals to hone their teamwork skills. Again I don’t know what to do about it. I just know that today’s approach to policing plagiarism is creating a very costly negative side effect. It is harmful for both the industry and it can’t be good for academia either.

Leave a reply below, or send me a tweet.

Tagged with:
Posted in Software Development

Type-Level Programming: The Subspace of Scala

Earlier today I was able to finally give the presentation-version of my recent exploration into type-level programming in Scala at HuntFunc. Writing my presentation with impress.js is the other distraction from blogging I mentioned last time. Although the presentation turned out really good (viewable here), I’m not certain if I’ll go that route again. It was a good bit of work to finagle each slide into an absolute position in three-dimensional space. It’ll depend on how much time I have and if I find something that’s equally impressive.

The presentation basically covers everything I wrote about in those four type-level programming posts. I was able to make it flow a little better by having the foresight into where I was headed with the material, whereas I just meandered around with the blog series until I stumbled upon something useful. Another thing to bear in mind is my audience of eight or so developers only contained one member with extensive experience in Scala, so I had to take my time and be gentle with the material.

So if you haven’t gotten enough of my thick Southern American English drawl discussing software, press play below and enjoy the presentation!

Tagged with: , , , ,
Posted in Software Development

Get every new post delivered to your Inbox.

Join 548 other followers