Showing that fear of mediocrity can make the world a better place.


LINQ in a blink:Group by with count


Ever come across a situation where you wanted to find how many of a similar object you had in a list?

Sample code: All of the code used for this example is located on GitHub here

In SQL it would look something like this:



And you would get the result


Well it’s pretty easy to query a collection of objects using LINQ in a similar way:



Which could print out to the console as


We can extend it to only include those that have more than one occurrence of the grouping.








Existential bugfix

  1. Where did this code come from?
  2. What is the purpose of this code?
  3. Why does this code exist?
  4. Can this code be better?
git commit -a -m “could not fix. code is a character trait and not a character flaw.”
The difference between philosophy and development is the target of the questions and thought.

Illustrated:Successful product recipe

Rough sketch after a day of discussion on product design and development.


  • Ability to capture feedback (good, bad, and confused)
  • Product and business vision to filter and refine the feedback
  • A solid team to understand, refine, and ship the product.
  • Customers who can provide feedback


Capture feedback and use to shape vision. Ensure all parts are blended until smooth. Support and empower solid team so they can convert vision into product.

Ship product.

Repeat rapidly until amazing product.

TypeScript: It’s not about dynamic vs. static

I have to say I actually like TypeScript as an idea. The idea of type safety and static type checking as an optional compile feature in a language is pretty amazing. That means I can use the types when I need to enforce a hard boundary and still use dynamic programming to get all the benefits that it offers. But that doesn’t matter as much. For me it’s about discover-ability and growth.

Slow developer growth

Static languages (Java, C#, etc) tend to focus on the interfaces and what the IDE can tell you via Intellisense. Your class, method, or property has to have enough type information to tell the client developer how it should be used and how things work. By it’s nature it’s an authoritarian method of information dispersal. Your static code tells the client they need to pass in this type of object (string or int maybe) and you will process it. The client developer doesn’t know how it is implemented or what you going to do with it. Since the IDE is the major source of information for the developer it shouldn’t be a surprise that the C# or Java developer tends to be IDE-dependent and in many cases is stereotyped as being less “clever” than their dynamic programming counterparts. The inability and even the reduction in need in most cases to dig into the source and see what is going on slows the client developers growth. They don’t get to learn from your amazing library. Opensource can help to mitigate this but many companies that use static languages also tend to have a poor policy when it comes to opensource.

Rapid developer growth

Dynamic languages (JavaScript, Python, etc) tend to focus on exploratory interfaces. Your class, method, or property does not have type information so the names have to be much clearer. When working in dynamic languages I find myself exploring the code I am consuming more. Since I don’t have types or a compiler to check on things for me I end up looking into the code I am calling to see what will happen with the variables I pass in. This is a very democratic method of information dispersal as the library developer generally lets me browse the source to learn what I need to consume it. This has a tendency to reward well written code with loyal users since it is readable and it doesn’t make them feel stupid. It actually makes them feel smarter. They can read the code and understand it and even learn new tricks. It’s a sneaky way of turning normal development into a learning and reading exercise and reading code makes you a better programmer. Since you are constantly understanding the code you consume a little deeper than the top level abstraction (I like Scott Hanselman’s sink faucet and drain metaphor for this) you reduce the risk of becoming the dreaded cargo cult programmer.

Pick your poison

This isn’t meant to incite an us versus them or a decry static programming as evil. There are not so flattering stereotypes of programmers in both static and dynamic languages and there is a grain of truth to them. They both have their place and if you think you are a great /(static|dynamic)/ programmer but you haven’t tried the other then you are missing out. You could be a static programmer with a dynamic programmer’s inquisitive barrier-less mindset. Or you could be a dynamic programmer with an ability to scale large codebases in a clean, modular, and error-free way.

There is no one true way. There are many paths to but you need to be open to them. Become the programming equivalent of the martial arts quote by Bruce Lee “Don’t get set into one form, adapt it and build your own, and let it grow, be like water. Empty your mind, be formless, shapeless — like water. Now you put water in a cup, it becomes the cup; You put water into a bottle it becomes the bottle; You put it in a teapot it becomes the teapot. Now water can flow or it can crash. Be water, my friend.”

Thought leading keywords

Try starting to write by staring at a blank page. It’s pretty difficult to start but once you do the words seem to follow each other. Its almost like the first words lead your thoughts and guide them the rest of the way. It would then make sense that some words are better at generating followup thoughts than other. For example “it was a hot summer day when…” is better than “tuesday is fun because…”. The first one leads your mind down an ambiguous staement. It lets you figure out the rest of the story without forcing anything extra. The second one starts out with a declarative statement that leaves little room for your thoughts to follow. The same thing can be said of certain words in programming.

Good words

Given, When, Then

Given, When, Then syntax for BDD specs is a pretty powerful phrase. It can sum up some pretty complex topics and helps to get business talking the an Arrange Act Assert style language. The nice thing is that each word leads into the actual text.

Given some data
When I perform an action
Then the result should be testable. 

The syntax lends itself to a nicely structured wording style. There is power in the flexibility but care still needs to be taken to make sure the words that follow are meaningful though since it is quite open ended. The rest of the Gherkin language ( uses similarly leading words to fill out the rest of a scenario.

Get{x}By{y} / Find{x}By{y}

A method that says GetSomethingBySomeProperty helps you follow a simple data access strategy. Don’t believe me? Check out how Simple.Data uses this structure to effectively drive the framework. The framework makes sure you are consistent since the method name drives the data lookup. It’s interesting in that it removes the need for discipline in consistent naming since it will only work if your name everything correctly.


Should is a powerful word. Care has to be taken that it doesn’t get watered down like those “the system shall” requirements of yesteryear and that the word expresses it’s intent. It is useful in testing and assertions. If you want to should your way through assertions you should check out shoudly. It usually shows up in my tests methods and it helps me to think through what the system should do as opposed to the more technical implementation details.


What even based systems would be complete without such a simple preposition. Onclick, onsubmit, and on(‘user registered’, sendConfirm) are all examples of using On to specify intent to do something for an event. This one shouldn’t need much explanation if you have done any web programming. It is a utility player that is probably the most concise way to say what you want to do when a given event occurs.

On ‘end’ ShouldWrapup

It’s no surprise DSLs (domain specific languages) are gaining popularity. Coding is becoming a game of expressiveness and clarity of concept. Is your code readable? By a developer? By a business user? Should it be? Thought leading words all have a few things in common. In these cases they are prefixes. It’s tough to lead , after all, if you are at the back. They get you to think about what should be the next piece in the thought. Interfaces like IHandle and IAuthorize prompt you to type IHandle…what do i handle? I handle user registration so I guess it’s IHandle.

No, library and framework coding isn’t just about setting up a MadLibs exercise for the consuming developer but it’s about starting the sentence and having the library consumer finish it. Not only does it promote a consistent expression of ideas but it also helps by giving someone a starting point for their thoughts. Don’t give someone a blank page, inspire them to create a masterpiece.

Software accretion: The hoarder and the clam

The hoarder and the clam

A challenge was issued to all storage workers. Whoever could store the most and provide the most value after everything was stored would win. A hoarder entered the competition and boasted that he could gather the most things and be able to store them. Upon hearing the boastful statement a clam entered the competition. The clam knew that the hoarder would get bogged down and would be unable to handle the mess he created.

And so the competition started with both contestants having empty storage. The hoarder started stacking and storing at a frantic pace. Many were amazed how quickly the hoarder was able to assimilate the items he was supposed to store. The hoarder exclaimed how easy it was and that he will easily win this competition. The clam continued to diligently work at his own pace. He assimilated the items to store slowly but he distilled them to their purest form as he went. He structured and organized the items so that they fit together. He knew what he wanted to accomplish and storing the items was only part of the goal. As the competition progressed both contestants were strained and stretched to their limits. The hoarder was frantically trying to find room for items and was constantly stuffing items wherever they fit even if it didn’t make sense to put them together. The hoarder was stressed and overworked but he was still making a mess. The clam was stressed as well but it was because he wanted to make the best out of what he was given. He wanted to give his all and make sure he used all his skill to store the items. He wasn’t driven by the competition or vanity like the hoarder but by the desire to make something beautiful out of what he was given.

As the competition wound down the hoarder was tired and was moving much slower. There was nowhere else to store items and his existing storage gave way in occasional landslides. He spilled items and kicked them out of his way in order to store more things. As they both stored the last items the competition ended. The contestants were judged on their storage and the final product. The hoarder stored all the items requested of him and sure enough the place was a mess. He was commended on being able to quickly perform all that was asked of him.

The judge then asked the clam where the items he was to store were. The clam replied that he had not just stored the items but had distilled them and remove any impurities. He had organized and structured the items in a matter that would benefit the judge in the end of the contest. He then handed the judge a pearl necklace and walked away.

The judge was confused by the clam’s actions. He had not known it was possible to make a pearl necklace from the mass of items he had given him. The hoarder claimed it was unfair since the judge had not said that they were supposed to create anything from the items but were meant merely to store them. The judge told the hoarder to throw away all the items he stored since there were no longer valuable as rot had destroyed most of their value. He awarded the clam win the prize and congratulated him his perseverance in taking a mess and making something beautiful.

A not so hidden message

Everything changes. Nothing is static. Entropy will always find away to tear down the greatest works. The only reason that everything is not in a complete state of disregard is because there are people performing maintenance and fighting entropy. Without a vigilante steward and someone who has a good sense of ownership and quality software maintenance becomes a race to the bottom as entropy takes over more and more of the system leading to that unmaintainable mess known as the big ball of mud. Whether you are pulling the weeds sown by careless programming, distilling the domain, or tuning your algorithm by continuing to push and refine you can make the messiest codebase shine.

Groups considered harmful

Working in groups is an important part of modern software development. The free flow of ideas can lead to better solutions and the quality of the result can be better than working alone. But group work is not always the answer. It has it’s dark side that when abused can steal productivity and quality.

Groups are dangerous

As a developer my tendency is to be intensely individual. I have my own opinions and tend to turn off if a meeting looks like a group-think session. That said I still value working with others in groups because it is the easiest way I know to learn from others and to shine a bright light on the big gaps in my knowledge or thought process. However, there are some common anti-patterns that you should be aware of the next time you jump into a group to get something done or you make your developers take a group approach to the next problem.

Design by committee

If you work in a bureaucratic business you have no doubt experienced the design by committee anti-pattern.

Common symptoms:

  • the room is full of people who don’t know how to solve the problem but they continue to offer “solutions”
  • the meeting was billed as a brainstorming session
  • no one can clearly articulate the problem to be solved
  • unclear purpose and group members are disorganized
  • no clear owner and actions


  • don’t meet just to meet
  • have a clear agenda and problem statement. if you can’t define it you can’t solve it
  • get the right people in the meeting. if it’s a technical problem bring in the technical developers. if it’s a business problem bring in the technical developers 😉
  • make sure someone owns the outcome and make them responsible for seeing it through

Some achieve, others leave

People are unique individuals. Their skill levels vary widely and so does their level of engagement. Some people are intrinsically driven to accomplish the task and are looking forward to the work. Others are disengaged and just want to get through the day so they can go home.

Measuring skills and engagement can be difficult. Some people have really diverse skills and if you try to paint everyone with the same brush then you shouldn’t be surprised with the bland results and disengaged attitude.

Common symptoms:

  • it’s not my problem attitude
  • treating people as interchangeable widgets. (the phrase human resources being a disgusting example)
  • not asking someone what they would like to work on
  • not knowing how to engage each team member


  • find out what excites the each team member and try to incorporate it
  • allow for autonomy and ownership so people engage themselves
  • there is not such thing as “it’s not my problem”. the whole thing is a collaboration where everyone has skin in the game. if someone in the meeting has no skin in the game politely recommend that they don’t need to attend

Bumpy playing field

Since skills vary the group might fail in one of two main ways. The group could split and the top tier could start to outpace the lower tier. This causes disengagement in the lower tier since the feel less valuable and the top tier feels they are unjustly carrying the team. The other failure is that the top team is held back from utilizing their full potential since they are constantly helping the lower tier to keep up with the pace. This causes a feeling of inferiority in the lower tier as they continue to need to ask for help. The top tied feels that they are being underutilized and might lose interest and drive.

Common symptoms:

  • talk of elitism and favoritism among group members
  • mention of unfair responsibilities
  • constant tension and bickering


  • in all honesty i haven’t quite figured this one out yet. suggestions welcome

Simple problems complicated answers

Unfortunately life doesn’t get easier. The same group dynamics that you battled in school rear their ugly heads in the workplace. There is probably a maturity level where some of these problems are mitigated but there is most likely a whole new class of problems. Group-work can be frustrating but it can also be intensely rewarding. There is a fine balance between isolation and group discussion that every developer should strive to find. I find that isolation can lead to amazing discoveries and thoughts but only when I meet to discuss do ideas take on a physical shape. Always keep an open mind but don’t let an unproductive meeting go too far without trying to turn it into a productive session.