In my defence of Java, one of the features I looked forward to in Java8 was the introduction of Lambda expressions. However, a lot of people are dissing the new feature as being “watered down”, or a “poor man’s lambda expressions”.  To understand why, it may help to see how Lambdas are used and implemented in a language like Scala and then contrast this to Java8′s Project Lambda adoption.

How Lambdas work in Scala

Scala gives you a nice syntax for specifying type-safe lambdas.  You can specify a Lambda type like so:

(paramType1, paramType2,...,paramTypeN) => returnType

As an example let’s look at your classic “take a number and square it” lambda:

val squareIt: (Int) => Double = (x) => x * x

The Lambda type (or Function type) in the example appears immediately after the colon but before the second equal sign.  The variable squareIt is type-compatible with a function that takes an Int and returns a Double.  If this were a powerOf function, we could make it’s type:
(Int, Int) => Double.

The syntax Scala uses for specifying the “type” of a Lambda expression; the parameter types and return type; is very readable once you get to know it. However, I could have written the above example without the nice syntactic sugar like so:

 val squareIt: Function1[Int, Double] = (x) => x * x

The Function1 trait in Scala’s core library denotes a Function type that accepts exactly one parameter.  In this case, the incoming parameter type is an Int and the return value type is a Double.  For the powerOf example it would be of type Function2[Int, Int, Double].

Open up a REPL and type the following to prove this concept to yourself:

scala> val squareIt: Function1[Int, Double] = (x) => x * x
 squareIt: (Int) => Double =

scala> squareIt(2)
 res0: Double = 4.0

Java8 vs Scala Lambdas – Function Types vs. SAM

Given Scala’s support for Function types, there is a convention Scala uses such that if an instance of a Class or Trait is being used as the subject of a function call then Scala makes sure the Class or Trait has implemented an appropriate apply method.

For instance, in Scala:

class SquareInt {
   def apply(x: Int) = x * x
}
.
.
val squareInt = new SquareInt
squareInt(2)

On the last line above, Scala is really just calling the apply method on SquareInt.  SquareInt isn’t actually a proper function, but rather a Class instead.

Expanding on this convention, when Scala sees…

val squareIt: (Int) => Double = (x) => x * x

… you can imagine Scala taking the following steps before compiling to byte-code:

1. Make the type of the squareIt variable a Function1
2. Create a new anonymous Class definition that extends Function1
3. Make the apply method of this new class accept an Int as a parameter and return a Double
4. Make the body of the apply method contain everything on the RHS of the equal sign
5. Instantiate a new instance of this class and assign it to the squareIt variable

This convention really boils down to: If you use the squareIt variable like a function [i.e. sqaureIt(2)], Scala simply invokes the apply method of the instance.  If no appropriate apply method exists, you get red-squigglies in your IDE or compile errors.
Try it for yourself:

scala> val squareIt: (Int) => Double = (x) => x * x
squareIt: (Int) => Double = <function1>

scala> squareIt(2)
res2: Double = 4.0

scala> squareIt.apply(2)
res3: Double = 4.0

How Java8 handles Lambdas: SAMs

EventHandler has a single abstract function named handle. Types that follow this pattern are known as SAMs – Single Abstract Method types. In our case, our SAM’s handle function accepts a parameter of type Event:

public interface EventHandler {
   public void handle(Event evt);
}

Normally, in Java, I’d use Anonymous Inner Classes to pass functionality to a function which conveys events through an EventHandler interface, like a Button alerting anyone who cares to listen that it was clicked:

myButton.whenClicked(new EventHandler() {
   public void handle(Event evt) {
      out.println("I was clicked!");
   }
});

This chunk of code, in Java8, becomes the following Lambda expression:

myButton.whenClicked(Event evt -> out.println("I was clicked!"))

You can even let Java infer the type of the evt parameter by leaving out the reference to Event, it’s smart enough to figure that out by itself.  So you can imagine Java taking the following steps:

1. Look up the expected parameter type of the whenClicked method and finds it to be EventHandler
2. Scan EventHandler to make sure it has one, and only one, “abstract method”.  In this case, EventHandler is an interface and all methods on an interface are considered abstract.  In this case it finds the void handle(Event evt) method, and it indeed is the only method.
3. Create an anonymous class which extends/implements EventHandler and:
1. Converts everything on the LHS of the -> within the lambda expression into parameters for the handle method
2. Make everything on the RHS of the -> into the body of the handle method
4. Pass the instance of the EventHandler to the whenClicked function

The above list “sounds” almost exactly like what Scala does when converting its Lambda expressions into functions except for two key differences:

1. There is no nice syntax for expressing the type of the Lambda expression
2. Java has no general invocation convention concerning Lambda expressions

Point 1 has to do with the fact that in Scala we could declare:

val handler: (Event) => Unit = (evt) => println("I was clicked!")

Whereas in Java we have no “function type” per say, instead we end up having to specify the EventHandler type explicitly.  Even though, in the context of a Lambda expression, the EventHandler interface really just is a specific synonym for “a function which takes an Event and has a void return type”.

Point 2 refers to the fact that there is no general convention for invoking lambda expression in Java8 like there is in Scala. Remember, in Scala we could:

scala> val squareIt: (Int) => Double = (x) => x * x
squareIt: (Int) => Double = <function1>

scala> squareIt(2)
res2: Double = 4.0

Instead the only way we could invoke the lambda expression directly in Java8 is to invoke the proper method on the type this specific lambda expression resolves to, in our case:

EventHandler handler = (Event evt) -> out.println("I was clicked!");
handler.handle(someEvent);

Thoughts…

I’m not a compiler writer, however I suspect adding a convention to an existing language syntax is probably not a trivial task.  In the case of Java, allowing classes to be called like functions would probably be tough to shoehorn in.  As well, adding a “function type declaration syntax” (re: (Int) => Double) might also be non-trivial.

The Project Lambda authors chose to allow Lambda expressions to be compatible with *any* type of SAM, they did this so Lambdas could be compatible with older APIs without rewriting them, or adding an extra compatibility layer. They didn’t want you to code your APIs any differently in Java8 than you would have in previous versions. Instead they want us to keep on passing those Anonymous Inner Classes around, and they’ll just give us a nicer syntax in which to create them.

Making Lambdas more general…

What will happen, no doubt, is we’ll see people follow the Scala convention by creating a library of generic Function interfaces each containing a single apply method.  We can do this and still be completely compatible with how Java8 makes Lambda expressions type-compatible with SAMs.

For instance given a library of “generic function types”:

public class Functions {

   public static class Function1 {
      public RT apply(P1 p1);
   }

   public static class Function2 {
      public RT apply(P1 p1, P2 p2);
   }
.
.
. 
}

One might build an API like so:

import java.lang.function.Functions.Function1; 

 public class Button {

     private List<Function1<Event, Void>> clickHandlers = new ArrayList<>();

     /**
      * Add a handler to the list of handlers that are invoked 
      * when the button is clicked
      */

     public void whenClicked(Function1<Event, Void> handler) {
         clickHandlers.add(handler);
     }

     /**
      * Internal function which is invoked by the Event system when a
      * the button was clicked
      */
     private void wasClicked() {
         Event event = /* create event */
         for (Function1<Event, Void> handler : clickHandlers) {
             handler.apply(event);
         }
     }
}

And then use the API with the Lambda syntax:

myButton.whenClicked(evt -> out.println("I was clicked!"));

Not First Class but…

So no, functions aren’t exactly “first class” in Java8, however the new Lambda syntax will absolutely help us make our code more readable. Silver lining found.

Back when a lot of Java developers switched over to Ruby, Java was a bit stagnant. We hadn’t really seen much happen with the language, and anyone who has written a Swing application can tell you: Anonymous inner classes make your code 5x bigger than it should be. The point being: there’s a lot of boilerplate code present in a typical Java application and this type of code has nothing to do with the application/business logic you’re trying to implement.  It’s just language cruft.

So, I can see why one would have been inclined to say that Java is like a modern COBOL. It had the following characteristics in common with COBOL:

1. The language is verbose
2. The language is stagnant
3. Only big stodgy Enterprises use it

Well, I’m happy to report that these are no longer the case.  Let’s address the issues at hand one-by-one shall we?

Verbose & Stagnant

The cure for these problems lie within a combination of the features found in Java7 & Java8.  Java7 addresses a lot of issues with verbosity, while Java8 pushes the language forward into adopting new paradigms (namely Functional Programming)

Java8 is really a turning point for Java, and shows that Oracle is actually serious about evolving the language while championing it’s proliferation while maintaining backward compatibility. Oracle can’t just gut the language and then post a meme to github to justify itself.  It’s a bit more mature than that.

Java7 addresses verbosity

As Mark Reinhold, chief architect of the Java platform said: Java7 is evolutionary, Java8 is revolutionary. With Java7 we gain some nifty features from Project Coin, a project which  set out to determine what language features could be added to improve developer friction and language readability without being all too complicated to add. Here are some of the features I’m looking forward to:

A switch statement that I’ll actually use

Yes, finally my Java brethren we have a switch statement that actually works on Strings!

switch (lang) {
   case "Java" :
      out.println("I like frameworks!");
      break;
   case "Ruby" :
      out.println("I like Pabst Blue Ribbon!");
      break;
   case "PHP" :
      out.println("I like WordPress!");
      break;
}

My God this has been a long time coming.

Type Inference: Yes, I REALLY DO MEAN Map<String, List<String>>

One of the reasons I like Scala is it’s ability to infer types.  This is such a pain-point in Java, when you use a highly complex parameterized type, both your carpal tunnel flares up and you’re eyeballs want to bleed.

So this:

Map<String, List<String>> peopleByDept = new HashMap<String, List<String>>();

Becomes:

Map<String, List<String>> peopleByDept = new HashMap<>();

They call this enhancement the “diamond syntax” as you are leaving out the types on the RHS of the expression and replacing them with a diamond <>.

I won’t go over all the nice little character-reducing features of Java7, Dustin’s Inspired by Actual Events JavaOne 2011 keynote post does an excellent job, there’s nothing more I could add really.

Java8 Moves the Language Forward

What do we get with Java8?  The two major features are:

1. Lambdas / Closures
2. A proper module system (aka Jigsaw)

I’ll only address Lambdas here because the module system is more an “in behind the scenes” feature. In my opening paragraph I spoke about how Anonymous Inner Classes cause so much bloat in a Java application.  Lambdas pave the way out of that mess.
For example…

Component button = new Button("Click me!");
button.onClick(new EventHandler() {
   public onEvent(Event e) {
      out.println("I was clicked!");
   }
}

We’d write, using Lambdas (look ma! no types!):

button.onClick(e => out.println("I was clicked!"));

I like!

Cool Companies use Java too!

Is Java used in the Enterprise? Absolutely.  However Apple, Twitter, LinkedIn, SquareSpace are all committed to it too. These companies are the antithesis of the stodgy Enterprise.  Through JRuby, Jython, Scala and Clojure companies like these plus countless startups can both directly and indirectly use Java by means of leveraging the vast open source ecosystem written in Java.

Stereotypes…

Given the above facts I think you’ll agree, Java is not stagnant, it’s getting much better on the eyes and fingers and it has been adopted by cool, non-stodgy companies. Then perhaps you’ll also agree it’s wrong to say Java is the new COBOL, just as wrong as saying Ruby is the new Java.

Not just looping…

For Comprehensions are able to actually “yield” results if so desired.  For example:

val sqlStatements = List[String]("select * from...", "selec...")
val resultSets = for (sql <- sqlStatements) yield new ResultSet(sql)

If you read my last article, you already know about the “map” function. As it turns out, Scala will “boil down” a For Comprehension containing a yield statement into a map function.  I know this because scalac, the Scala compiler, has a -Xprint option which shows you how the syntactic sugar used in every-day-Scala code “boils away”.

Using the command:

scalac -Xprint:typer <filename>.scala2

scalac will show you that the For Comprehension in our example boils down to roughly3:

val resultSets: List[ResultSet] = 
   sqlStatements.map[ResultSet, List[ResultSet]](
      (sql: String) => new ResultSet(sql)
   )

As you can see, scalac did two things here:

1. Added in all the type information you so lazily omitted
2. Converted the body of the yield statement into a function it can pass to the higher-order map function

Ah hah!

It was at this point in my learning of Scala that I started to grok the power of Functional Programming.  Simple concepts like the map function can form the fundamental building blocks underlying the broader syntax which is Scala.

Back to our example…
What about For Comprehensions that don’t yield results?

for (sql <- sqlStatements) {
    println(sql)
}

One might wonder how the above statement “boils down” to code which uses map as map returns a value and our example renders no such value in absence of a yield statement. In this case, scalac will produce code which uses the foreach function instead:

sqlStatements.foreach[Unit](((sql: String) => scala.this.Predef.println(sql)))

Filtering

Another trick For Comprehensions can do is filtering of data.  For instance:

   val empList = List(
        Employee("Craig", 1000000),
        Employee("Amir", 50001),
        Employee("John", 40000)
    )

    /* Find all employees with a salary over 50,000        */
    val layoffs = for (emp <- empList
        if (emp.salary > 50000)) yield emp

In this case Craig and Amir wind up in the layoffs List and scalac boils down the statement to4:

val layoffs = empList.withFilter(
   (emp) => emp.salary.>(50000)
).map(...)

What you are witnessing here is Scala unwinding the if statement in the For Comprehension and feeding the condition to a method called “withFilter”.  Essentially withFilter will produce a List which contains only the elements that have passed the condition.  It is this “filtered” List that map is then executed against.

But why didn’t Scala use the “filter()” method on List instead? The short answer is: several if statements within a For Comprehension (yes you can have more than one) will generate several chained calls to the filter function.  That sounds inefficient because you’ll wind up with statements being generated like so:

empList.filter(cond1).filter(cond2)...filter(condn).map(...)

The first call to filter will iterate the entire empList, the second call will iterate the list generated by the first call to filter, the third will iterate the list generated by the second call to filter, etc…

Scala uses withFilter instead because it delays evaluation of the filter conditional until absolutely necessary.  The List that withFilter generates and passes on down the chain is often referred to as a “View” a “Projection” or a “Non-Strict” List.  Instead of withFilter iterating all the elements in the List it is to act on and applying the conditional to each element, it simply returns a type-compatible wrapper around the List it was passed. Anytime something tries to iterate the wrapped list, the filter is applied to each element to see if it “exists” based on the conditional that withFilter was originally passed. Very clever indeed.

So while a chain of m filter() methods executing over a list of n elements would execute up to nm times, in contrast a chain of withFilter methods executes n times and only at the time when you need to iterate the List; in our case when map is called.

Conclusion

To really understand why Scala is considered a Functional Programming language it’s well worth it to glimpse how Scala reasons about high level concepts in a functional manner.  Give the -Xprint:typer option a spin, just keep in mind you might have to factor out a lot of the “cruft” which is injected into your Scala code to help the compiler better reason about your code and it’s high-level syntax.

Footnotes

1. For Comprehensions not only work for Lists, but in the context of an “Intro to For Comprehensions” we won’t use its generalized form
2. For a list of phases you can use with -Xprint, type: scalac -Xshow-phases. typer is a common phase to use when you want to boil away most of the syntactic sugar
3. I say “roughly” because there is a lot of cruft which gets added to the code to help the compiler out, I’ve omitted some of it and focus more at the core concept of map.
4. Omitting the types here as they distract from the point at hand

The session was very well received, my only enemy was time! Given 1 hour, how does one give 170+ people a taste of all that’s Scala without completely starving them of details? Lots and lots and lots of dry-runs of your presentation, that’s how. I must have iterated my talk a dozen or more times. I just couldn’t bring myself to trimming any more fat. The short story is, I could have used 5-10 more minutes. A crucial set of slides had to be omitted concerning the “Tuple” in Scala.

Tuple?

The Tuple is such a simple concept and it winds up being fundamental. The trick is recognizing their various uses throughout code.  One of the first slides I show is of this rather “toy problem”:

Believe it or not this is a really simple example

I chose this example because it shows off almost everything you need to know in order to get started with Scala.  How so you may ask?  Well, it demonstrates the use of:

• Two Fundamental Syntax Rules
• Higher-Order Functions
• Anonymous Function Literals
• Type Inference
• Tuples

Fundamental Syntax Rules

First of all there are some syntax rules in Scala which, if not studied early enough in your learning of the language, could really throw you for a loop.  In the example above, two such rules are at play (three if you count the creation of a Tuple using only parenthesis, more on that later):

   m.map { t => val (s,i) = t; (s, i+1) }

   m map { 
     t => 
        val (s,i) = t
        (s, i+1)
   }

I got rid of the dot between the instance variable “m” and the function “map”.  I also uncompressed the code a bit by removing  the semicolon and replacing it by a newline. Semicolons are only needed in Scala when you want to write two separate expressions on the same line.

Higher-order Functions

One of the tennets of Functional Programming (FP) is Higher-Order functions.  Scala being a language which supports FP has them.  So what are they?  Well, they are functions that can accept another function as a parameter, or return another function as a value.

Anonymous Function Literals

   def foo(x: Int): String = "You passed me a: " + x

   (x: Int) => "You passed me a: " + x

   val bar = (x: Int) => "You passed me a: " + x

   m map { 
      t =>  
         val (s,i) = t
         (s, i+1)
   }

Type Inference

Scala is particularly clever about inferring types, the benefit being the developer can become very lazy and omit types when Scala can infer them.  Let’s see a simple example:

   val s = "I'm a String"

Here, Scala can infer that you want “s” to be of type String, because you’re assigning it a literal of type String.  In our example:

   m map { 
      t =>  
         val (s,i) = t
         (s, i+1)
   }

Scala needs to infer the type of “t” because we haven’t explicitly specified it, but how will it do that?  Well, remember I said: The map function holds the key?  Let’s take a look at the map function’s signature:

   def map [B] (f: (A) => B): List[B]1

What the map function’s definition is indicating is that it expects a function, which it will rename as “f” and that function takes a type “A” as an argument, that is,  A could be an Int, String, Foo, we don’t know until map is used.  The A type placeholder is presumably defined at the Class or Trait level for the Class or Trait “m” is an instance of.

 class List[A] ... {

      def map [B] (f: (A) => B): List[B] {...}

      .
      .
      . 
   }

Now, there’s nothing to say that the types A and B can’t actually be the same types when map is used.  For example, if “m” were declared as a List[Int] and you pass it’s map function a function which returns an Int, then map will pass you back another List[Int].  Both A & B == Int in this scenario.

Getting back to our original problem, that is, how Scala infers the type of “t”; it does so by looking at the function type of the “f” parameter.  t’s type will be inferred as A (whatever that might be).  So long as the mapping function you pass it treats it “like an A”, you’re good to go.

Tuples

In the example, which I will repeat below (I don’t want you to have to scroll) there are two instances where Tuples are being used.  A Tuple is “unpacked” and a new Tuple is created. In fact, that’s all the function does really.

   m map { 
      t => 
         val (s,i) = t // 1
         (s, i+1) // 2
   }

As a developer of the code above we had knowledge of the fact that m contains a bunch of Tuples.  In this case m was defined as List[Tuple2[String, Int]].  A List that contains a Tuple, and that Tuple is made up of two components.  The first component a String, the second component is an Int.

In step 1, we unpack the components of the Tuple into the variables “s” for the first component and “i” for the second.  Notice once again we’re letting Scala infer the types of “s” and “i” from what it can gleam of the type “A”.

In step 2, we add 1 to the “i” value and then repack the Tuple.  We do this in Scala by using a comma delimited list of values surrounded with parenthesis. (Bonus Round: (a,b,c) would resolve to the type Tuple3[...], (a,b,c,d) Tuple4[...] and so on)

Remembering back to the second “Fundamental Syntax Rule”, we see that the last executable statement of a Function is its return value.  Since the last executable statement in our Anonymous Function is a Tuple, that’s the return value (and type) of the function.  The B type, is Tuple2[String,Int], in this case.

Conclusion

Can you guess then what the code sample does?  Assuming map returns a List of the things which are the output values from the function you pass it, it looks to me like you get a new List where the second component of each Tuple in the original list (re: “m”) has its value incremented by 1.

What was the biggest mistake I made when I first started learning Scala? I jumped in without looking. I felt I could just “pickup” the language, like a C# developer might pickup Java. So the point I’m trying to make is to start off in Scala by understanding some core concepts. If you do, the veil of the Matrix is lifted and you start to free your mind of the syntax which you aren’t yet used to.

Programming in Scala 2ed

I should mention, as I’ve been working on The Scala Language Tour my “book of reference” has been Programming in Scala 2nd Edition by Odersky (the language creator), Spoon & Venners.  It’s an invaluable resource for really understanding Scala and getting to the heart of the syntax and concepts which make you scratch your head when you’re new to the language.  I can’t say enough good things about it, it’s completely worth grabbing a copy for yourself.

Footnotes

1. The map signature in Scala is actually a bit more complicated than what is depicted here. For sake of not mudding the waters with a lot of detail, the spirit of the map function is demonstrated instead

House wouldn't put up with your ineptitude

Professionalism in my line of business (Software Development) is quite literally all over the map.  Putting aside issues regarding slackers (people who spend more time on social media than their code) we find the functionally inept.

Functional Ineptitude

Dealing with a normally inept person might be easy, they can’t do their job so to justify their removal from your team is a simple process of pointing out their failure to deliver.  However, the functionally inept will typically work hard and produce artifacts that satisfy the outward facing requirements set forth on the project plan.  What the Project Manager doesn’t understand is that the quality of code being produced is not robust, doesn’t stand the test of time and is so tightly coupled to the rest of the system it’s like a symbiotic parasite feeding happily unnoticed.  The problem is, once this code is noticed, it would kill the host system to remove the parasite.

Functionally Inept Developer – a Developer who by all outward facing means gets their work done; however, does so at the expense of code quality and robustness with little to no regard for the rest of the development team.

Coping Strategies

Unless you are blessed with a quality-driven Project Manager or Technical Lead worth a damn, you will be stuck with the functionally inept developer for as long as he/she can crank out code.  Given that I am a contractor, I typically step foot into companies who don’t know my track record.  In fact, a PM at one of my previous gigs told me as much after I raised concerns about a functionally inept developer.  It’s a very frustrating situation to be put in, one where you have no power to influence or change your team, yet are expected to deliver and work as a team.

So, after realizing I wielded little to no power with the “higher-ups” I decided to take matters into my own hands.

1. Break the build, get an email

What plagues software project team development more than “the broken build”?  Pretty much nothing IMHO!  It’s the fastest way to completely stop development dead in its tracks.  If you can’t build the system,  it means you can’t continue without first tracking down the source of the failure and correcting it.

The first thing you should do is setup a version control policy that reads something like this:

1. Do an update from your VCS, fix any local conflicts which might have resulted
2. Do a full compile of the code base
3. Run unit tests, ensure no failures
4. If it took you a while to resolve conflict, check once again for changes in VCS and repeat from step 1
5. Now check-in your changes with a USEFUL commit message (unlike these ones)

9 times out of 10 nobody on the team will listen to you.  So the second thing to do is setup a Continuous Integration (CI) server like TeamCity or Hudson.  If you are at Compu-Global-Hyper-Mega-Net and they don’t have CI servers, set one up yourself, even if it’s just running on your own desktop.
What a CI server will do is:

1. Checkout code from VCS
2. Compile & Run Unit Tests
3. Email the offending developer (or the team if you configure it thusly) stating the actual piece of committed code which caused a build to break

Before I had set up a CI server on a previous contract, I cringed anytime I had to update from VCS.  It was such a massive waste of my time to have to sift through the various commits and pinpoint when and how a build was broken.  Even with all my awesome CSI-esque investigation, I’d often be ignored by the guilty developer, or be told “works on my machine” as a defence.  Fast-forward to after CI was setup:  the guilty party now gets an email from an impartial build machine. That seems to prompt people to realize it was really them who broke the build, and they should do something about it.  Especially considering they’ll most likely get the email 5 minutes after their last commit.  When they get 10-20 emails a day, it becomes embarrassing for them, and they have no one else to blame but themselves.

You broke the build? Bollocks!

2. CYA with Unit Tests

Convincing a team of developers to write unit tests from the point of view of someone who’s not in charge is next to impossible.  Don’t waste your breath.  The smart ones will see your bug count and realize why it’s so low.

When you have a functionally inept developer, their tests (if they even know what one is) will suck just as badly as their code.  Instead, you need to look at Unit Tests as a defensive measure.  You are protecting your code, from theirs.  If the inept one changes the codebase in such a way as to break your functionality they’ll find out right away because a test which ran successfully before their changes ceases to afterward.
Sure the functionally inept will tell you “it’s your test that is broken, not mine”, however you have to make them understand that it was their changes which broke existing functionality and they better have a pretty good reason for doing so.

3. Followup Code Reviews

I’m not even going to go on about code reviews and how important they are.  What people seldom understand is the importance of a followup review.  Case in point, I was at a gig where a functionally inept developer was up for code review.  Of the various problems noted, two were outrageously inept.  The first was a 650 line long method (Cyclomatic Complexity of 14+ if memory serves).  The second was that the aforementioned  method was not thread safe.  This means, if two threads called the method at the same time, you could never guarantee a proper response.  It would be like a database which didn’t support transactions, you never know if your application was prone to dirty reads. Comp/Sci 101.


The developer in question was more mad at me than embarrassed.  He saw no problem with his 650 line long method and didn’t know what thread-safe meant or why it was important.  He was a “senior developer“.  I proceeded to kindly explain to him that we were writing web services and thus multiple requests could be calling the same function at the same time.  I spelled out a pretty simple solution to fix the code, but alas it fell on deaf ears.
For a few weeks after that review I kept my eye on commits by this developer, none of which pertained to fixing either of the aforementioned problems.  I proposed a followup review and the tech-lead stated there was no time in the plan for one.  That code went to production as far as I know.

4. Demand from Others what you Expect from Yourself

You are a professional, you shouldn’t be ashamed of demanding as much from others.  You’ll notice the pictures I chose for this article are of the fictional character Dr. Gregory House and the very real character Chef Gordon Ramsay.  I did so because Dr. House will call you on your bull if you are inept or cut corners and Chef Ramsay expects nothing but the best possible job you can do.  A lot of people think Ramsay is “an a-hole”.  I just think he has a high standard that he strives for himself, and is very disappointed when others fall short of that mark.


The truth is, Software Developers are not held to the same standards as Professional Engineers.  So stop calling yourself a Software Engineer.  Anytime I hear that designation it reminds me of this Denis Leary skit.  The fact of the matter is every company allows their developers to operate in different ways, most of which are dysfunctional.  I don’t know why we’ve gotten away with this for so long, but it’s the reality of our profession.


So in closing, strive to do the best you can, educate those willing to learn and keep inept developers (functional or otherwise) at as far a distance from yourself as you can.  The code-grenades they produce are theirs to jump on, don’t become collateral damage when the pin is pulled.

You know, I’ve had this domain for about 11 years now and have never put up a blog, but dammit, I’m getting so good at setting up wordpress that it’s really a no brainer for me to do so.  I used to blog a long time ago over at JRoller and I do have The Basement Coders Podcast blog, however this domain seems to be the logical place for me to Blog as it’s just for me.

Back when I was attending university in the late ’90s we used to call Blogs “.plans”.  Why?  Because within your Unix home directory you could place a file named “.plan” which would show up if someone fingered you.  Sounds a lot dirtier than it was.  This was the internet before we had the social graph, before websites were even prevalent; it was a time when you had to know the username and host where a person lived.

One of the most famous .plans to reach the web that I can remember is none other than John Carmack. John, of course, is the demi-god responsible for bringing us such games as Doom and Quake, not to mention he pioneered (in my mind) the idea that a game company can not only make money from producing games, but they can also take the time to build the game in such a way that it’s guts (engine) can be distributed to other gaming companies that perhaps do not want to spend the time and effort (not to mention expertise) in writing a gaming framework that a creative set of people can take and produce something wonderful with (Return to Castle Wolfenstein comes to mind).

John is one of those types who literally eats, sleeps and breathes problem solving. “Our map files aren’t compressing well using libraryX, I’ll write my own algorithm”  That’s the type of guy he is.  I guess you can say he would be a person in the computer field I look up to. Not only can he talk for 45 minutes and at the end of it you have no idea what he said (because he’s at *that* level) but he’s not just a one trick pony. I remember watching the QuakeCon 2004 Keynote speech about Doom 3 (Carmack couldn’t attend because of the birth of his child, hence why he is on a video screen). In this keynote he kind of humbley mentions that he took over the sound engine code and re-wrote it.  I was blown away.  Not only does he make this revolutionary graphics engine, he also does the sound engine.  To put that into perspective, that would be like if when your cable guy setup your digital receiver he turned around and said “That faucet looks a bit leaky, I’ll re-do your plumbing”.
The thing I like most about John is his ability to think like an application developer. He doesn’t just one-off a game, he creates an eco-system (a framework+tools) that can be utilized by both hard-core programmers and his high-level designers, not to mention his fan base through the release of modding tools. That’s what I (and many)&nbsp;like doing in software projects. Framework+tools == teh win (“the” intentionally misspelled).
Sadly John’s .plan is gone, he has switched to a blog over at his side-project website (side project being: trying to launch a person into space). He hasn’t updated it since 2006.  Sad.  You can find him on Twitter though, and every once in a while he throws out some random graphics prose.