Tag Archive | analysis

On Secretly Terrible Engineers – A Rebuttal

Today an article was brought to my attention. One that, at the time of writing this post, had hit the front page of various sites (including Hacker News) and had been shared over 2,600 times. The article is On Secretly Terrible Engineers, which is a criticism of the tech industry and the mentality which it holds towards hiring both new and experienced developers/engineers.

Spoiler: I strongly disagree with most of this article. If you aren’t open to debates and discussion, quit reading here and return to your normal activities.

Note: any and all bolding or emphasis will be entirely my own and not present in the original article. If you see bold, know that I bolded it.

If you’re still with me, I’d like to tackle this article inline because educated context, which is what I feel the article lacks in the first place, makes the world go ’round. Let’s begin with the credentials and qualifications from which the author speaks.

I am not unbiased here, having gone through this process myself. I started programming in second grade. I wrote tens of thousands of lines of code in high school, programming games and my own web server. I got a Mathematical and Computational Science degree from Stanford and continued coding. I should have been a software developer, but after a series of interviews, I realized the field was never for me. So much hostility, so little love.

I want to make my first criticism the most important: the author has never been a professional programmer drawing a paycheck. Yet, the entire article is about how the world of professional programming works, and how it’s broken. I liken this to me getting a law degree and then, after a few interviews at firms that happened to have mediocre or bad hiring practices, writing an op-ed about how the legal industry is broken and law firms and their lawyers are all cold, heartless entities that are not welcoming to job applicants.

The fact that the author earned a Computer Science degree from Stanford is impressive. Unfortunately, as many people who program full-time have realized, most theoretical knowledge gained in school translates very poorly to real world programming. I would venture out and say that the author probably was not a very good programmer when they were fresh out of school, looking for that first job. I say that because for the most part, none of us were. I certainly thought I knew how to program when I graduated, but in reality I was a terrible programmer – arguably even “net negative” (creating more problems than I solved) due to my ego and blind confidence.

They lurk, unnoticed in the great halls of engineering that are the office strips along Highway 101. “Programmers” not programmers, people who have cheated, stolen, and lied their way through engineering careers without anyone realizing they can’t code. They are among us, incompetent Cylons secretly plotting to undermine us at a crucial time.

What is this “us” that the author speaks of? There’s a reason I put the author’s credentials (which are at the bottom of the original article) at the top of this one. The author does not work in this field. There is no “us” – the author should have said “you” but knew it would be accusatory instead of an empathic opener that developers and engineers could relate to.

Secretly terrible engineers (STEs) are everywhere, and they may be on your very team as we speak.

There is only one way to stop this scourge, one interview to defeat them all. Well, more like a dozen interviews with white boards, but that doesn’t sound nearly as cool. But I digress. One interview to rat these jackals out, to prove just once that no matter how much you did in the past, you will be discovered as the Person Who Doesn’t Know The Big-O Of Trie Insertion.

The interviewer, preparing for this moment for years while waiting for git pushes, stands up and stabs his finger at the interviewee. “I’ve got you!”

I would not hire a candidate based on a pop-quiz style test. A company that I used to work at did this, and it sucked. We ended up hiring a bunch of the “secretly terrible engineers” or STEs as the author puts it. This is because a pop-quiz test can be studied for; it tests your ability to memorize and repeat, not your ability to comprehend. People would fool us into believing that they were skilled developers by reciting the correct answers to us. Within a few weeks of working at the company, they had usually outed themselves as terrible. Needing basic instructions on for-loops, source control, or even that pesky Trie Insertion that you seem to mock as if it were not a part of the daily job for many of us (ever built a type-ahead or autocomplete system?). It’s O(n) where n is the length of the key being inserted, by the way. I didn’t have to look that up because it isn’t trivia knowledge. It was derived easily from my practical understanding of data structures and algorithms.

The interviewer is not preparing for years to out the candidate, and certainly does not make a theatrical show of it. This is because for every 200 candidates that we (proverbial) interview, 199 can’t code. It gets really depressing and morale-depriving to constantly be rejecting candidates. We find no joy in it. It may feel like you were “outed” or a scene was made because you were unable to pass the interview, and this is very emotional for and personal to you, but on our end it’s just disappointing. We really liked your personality and attitude, and we’re frustrated that we cannot hire you and work with you. The only thing that stands between you and the job is core competency, which you lack.

Or, at least, I guess that is how this moment is supposed to go, since it never seems to actually happen.

How would the author know? They don’t work in the field and they likely don’t hire developers. If they did, I think they’d have written an entirely different article. The author’s evidence so far is entirely anecdotal and surely suffers from sample bias.

But there is also a darker vein running through these articles, of how to see through the posers and fakes, of how to test engineering skills so that you don’t hire that STE. In this view, the world is swimming in pure engineering mediocrity, and only extraordinarily careful interviewing will allow you to distinguish between fraud and genius.

It’s a paranoid fantasy, a As don’t hire Bs bullshit lie.

I agree with the first paragraph. It sucks, but it’s important to carefully screen candidates and hire the right developer. A bad hire costs more than you’d probably ever guess. It is true in my subjective experience that careful interviewing is the key to distinguishing between a fraud and a genius. Pop-quiz style interviews don’t weed frauds out. Only an interview that tests basic coding proficiency can weed them out.

As for the paranoid fantasy bit, I’d ask again how the author knows this, based on their lack of experience in the field. Also, what a sensational, angry comment!

The reality is, few professions seem so openly hostile to their current members as software engineering. There is always this lingering caution when interviewing a new candidate that somehow this individual has gotten through every interview process and team review without anyone realizing the incompetence before them. Founders swap stories of “that one guy” who somehow managed to work on infrastructure at Facebook, but was a complete idiot.

I agree. The industry is cold and unforgiving to most candidates. I consider myself a very talented developer, but that didn’t stop me from going through 6 interviews, 4 of which involved coding in order to land a job at Stack Exchange. I did it willingly because I knew that anyone that I would work with also passed those tests and is a competent developer. In reality, my coworkers are all brilliant (or geniuses, as the author says). I’m lucky to be on such a talented team. This is why these practical code tests are important: they ensure that your hires are skilled and that you get the best bang for your buck (the “10x developer” as the author puts it).

As for “that one guy,” he exists. As a start-up grows, they experience growing pains. Sometimes this is a rapid in-flux of hires to accommodate some scale issues or immediate need. Part of the growing pains is learning to weed out the fraud “developers” also, and so this person tends to get in before the interview process is solidified. Once hired, it is very hard to get rid of an employee (and it costs a lot too), so that one guy at Facebook slipped by. He got in as Facebook experienced growing pains, and slipped by the not-yet-solidified interviewing process. Most of us have worked with at least one of these people recently if not multiple times throughout our careers.

I’ve always been curious what all these people have been up to in the Valley. Where do they go all day? What do they do? If we are so surrounded by lackluster talent, how do we build all of these companies that seem to be taking over the world? Are STEs secretly burrowing owls who transform into humans during engineering interviews?

In all my years immersed in the tech industry, I have never once heard a firm talk about the idiots lurking in their own offices. They always seem to be elsewhere. For everyone.

If you made 7 bad hires and 3 good (or “10x” as the author stated) hires, you’ll likely get the work done. The 3 good developers probably won’t love their jobs (because they’re picking up the slack of the other 7, and in doing so hiding the 7 from the peering eyes of management). Your company culture will also suck, but the work will get done.

No firm is going to willingly talk negatively about their employees, especially when they’re seeking or have received funding and extra especially to someone who writes for TechCrunch. That would be asking for trouble. But hey, the author’s experience can dictate their entire view of the industry if they’d like it to.

Despite the worst talent crunch that Silicon Valley has ever experienced, we still regularly throw away huge groups of talent for not perfectly answering the latest hip algorithm question. “What do you think of the latest RB-tree research,” your interlocutor asks. “What?” “Buzz! Fail. Or should I say Fizz? Dammit I lost track,” you barely hear as security walks you in shame out of the office.

Here we agree: this is a terrible hiring practice. Pop-quiz interviews are pointless as they don’t accomplish anything and don’t filter out bad candidates. If this is an experience that the author has had, it becomes clearer to me why they wrote this article.

Yet in engineering, we expect people to do live engineering on a white board under stressful interview conditions because, well, because that is what we have always done. Most programmers need StackOverflow, Google search, or Dash in order to be effective, yet you get to an interview and are expected to spontaneously remember the positional arguments for some esoteric function. And we keep doing this even with people who have years of experience in the field!

As prior discussed, these types of interviews are terrible. They accomplish nothing other than a round of FizzBuzzword Bingo, and make the candidate feel stupid or bad. I deplore these companies. Read my prior blog posts for better ways to hire good candidates.

Yet, we don’t make the same assumptions in Silicon Valley. You can work at Facebook or Google for years, and still start over from scratch with FizzBuzz when you start searching for another job. That is complete paranoia. Nerds are frankly very nervous about status, which Paul Graham argues comes straight from high school. I am not as convinced by such pop sociology, but there is something in the culture that is making us seek out and destroy those losers on our group projects that can’t carry their own weight.

There are definitely elitist engineers; most of them are misguided. The industry is certainly full of egos. I’ve met enterprise architects that couldn’t architect their way out of a cardbox board, and junior developers who think that they are experts who know everything. It’s definitely a problem, and makes the industry seem harsh to newcomers.

No, but we only realize this when we consider the real context of how engineering happens today. We still act in interviews as if every engineer works independently, when in fact teams greatly affect the performance of every contributor. We act as if engineers should have the entirety of Python’s standard library memorized, when in reality we all use the API reference docs. Take an engineer and remove their team, their search engine, and StackOverflow, and yes, they might look completely incompetent. That’s a fault of the interview, not them.

Actually, that’s the fault of the candidate. If you ever interview with Stack Overflow, we will test your coding skills in a way that prevents you from looking up the answer or depending on libraries. This is not to make the challenge extra hard; it’s quite the opposite. We believe that libraries and helper functions abstract away the true complexity and importance of code. Many developers can sling code from libraries all day (think LINQ or jQuery), but the ones that understand the computational complexity of what they’re doing under the hood are the ones that I want to work with.

If a candidate cannot solve a relatively simple (or even moderate) programming problem without the help of documentation and libraries, then they do not know how to code.

We need to move beyond the algorithm bravado to engage more fundamentally with the craft. If people are wired for engineering logic and have programmed in some capacity in the past, they almost certainly can get up to speed in any other part of the field. Let them learn, or even better, help them learn.

Agreed, fully.

No one ever offered me a book. No one even offered advice, or suggestions on what was interesting in the field or what was not. No one ever said, “Here is how we are going to bring your skills to the next level and ensure you will be quickly productive on our team.” The only answer I ever got was, “We expect every employee to be ready on day one.” What a scary proposition! Even McDonalds doesn’t expect its burger flippers to be ready from day one.

This is the saddest part of the article to me, as it reveals the true experiences of the author.

I believe that empowering developers is how you bring out the best in them and get things done. This involves mentoring in positive ways: offering and suggesting books (countless devs have loaned me books over the years), offering advice (also countless), and suggestions and talk of what’s hot in the field. It makes me angry at the industry that the author had this experience, and I agree fully that it’s bullshit and needs fixing.

As ambassadors to future developers and engineers, we should be more welcoming and willing to teach. If the candidate has the right attitude and aptitude, they can learn – quickly. I leave you with this: while I disagree with the author on many of their points, this one is at the crux of the problems in the IT industry.

iPhone 6: Style Over Substance

Like many of you, today I watched the Apple media event in which they announced both the iPhone 6 and Apple Watch. I’m not going to talk about the watch, but instead about the phone.

For years Apple has been a true cachet brand. They are a luxury item that is sought after for status and image. I don’t blame anyone for owning an iPhone: they’re reasonably sexy and you get to show off the Apple branding. Good on you.

My smartphone adventure started with an iPhone 3 in 2008. It was an amazing, groundbreaking piece of hardware back then. Android was nowhere near it and nothing else came close. I was able to put my iPod Nano in my dresser drawer and use the phone for both music and talk/text. It was amazingly innovative and nothing at the time compared.

This morning I was very excited to see Apple finally innovate again under the direction of Tim Cook, after years of what seems like stagnation on the mobile front. Instead, I was disappointed. I’m going to explain why in terms of comparable hardware and cost, not in terms of opinion (because they’re cheap and everybody has one).

Let’s compare the bleeding-edge Apple iPhone 6 and 6+ offering with my Nexus 5 (a phone that is nearly 1 year old and was released on Oct 31 2013). I highlight the winner in bold for each spec:

Nexus 5 iPhone 6/6+
Processor 2.26 GHz quad-core Krait 400 “Snapdragon” A8 chip specs not released, benchmarked at 1.4 GHz dual-core
RAM 2 GB Benchmarked at 1 GB
Battery 2300 mAH 6: 1810 mAH. 6+: 2900 mAH
Screen Quality 1920 x 1080, 445 pixels per inch 6: 1334 x 750, 326 pixels per inch. 6+: 1920 x 1080, 401 pixels per inch
Screen Size 5″ 6: 4.7″. 6+: 5.5″
Storage 16 GB 128 GB
Fingerprint Sensor Nope Yup
LTE Bands 6 20
Front Facing Camera 1.3 MP 3.2 MP
Rear Facing Camera 8 MP 8 MP
NFC, Bluetooth Yup Yup
Wireless 802.11ac 802.11ac
Screen Polarization/View Range Sucky Sucky
PRICE $349 for 16 GB no contract, unlocked 6: $649 for 16 GB no contract, unlocked. 6+: $749 for 16 GB no contract, unlocked

Thoughts: Apple has some better specs, but they tend to be with respect to the cheaper hardware aspects (LTE bands which are redundant anyway, storage space, front facing camera). The iPhone 6 standard model has a really poor display resolution, surprisingly, since Apple has made strides in display technology with their retina MacBook Pros and iPads. The battery on the standard iPhone 6 is also poor compared to the Nexus 5, though the 6+ gets a much larger battery with its larger size. In terms of performance (CPU/RAM), Nexus 5 dominates.

Conclusion: Apple cheaped out on this phone, big time. It BARELY competes technically with the Nexus 5, an Android phone released almost 1 year ago. I cannot believe that for the cost of 1 iPhone 6+ I can buy 2 Nexus 5’s. It truly must be a cachet phone if people are willing to pay the price for such mediocre hardware.

To Node.js Or Not To Node.js

Node.js – it has rapidly become the “new hotness” in the tech start-up realm. With each passing day, the fan base of Node lovers grows larger, spreading their rhetoric like a religion. How do you spot a Node.js user? Don’t worry, they’ll let you know. 😉

One day you’re at a regular user group meeting, sipping soda and talking with some colleagues, when the subject turns to Node. “Have you guys tried Node.js?” asks one of the people in your group. “It’s all the rage. All of the cool kids in Silicon Valley are using it!” “What does it do?” you ask, only to be bombarded with a sales pitch worthy of the best of used car lots. “Oh, it’s amazing!” they reply, sipping their diet coke and shuffling their hipster fedora and backpack with MacBook Pro in it (or something like that), “It’s server side JavaScript. It runs on a single thread and it can do 100,000 web requests a second!” They glance at the group for the oohs and ahhs, but most people just stare back with amazement in their eyes. Then, your hipster Node-loving friend drops the words that start wars: “It’s way better than .NET” – and just like that, your group is hooked. They go home, download the Node.js tools, write “Hello World”, and suddenly they’re on their way to the next user group meeting to talk about how great Node is.

Okay, so I might be exaggerating the appearance and demeanour of your average Node lover a little (read: a lot, almost entirely in fact). However, I have had this exact scenario happen repeatedly over the last six months, with ever-increasing intensity and frequency. Node users love Node. They want you to love Node. They’re excited about it.

Having given it some thought, why wouldn’t Node.js developers be excited? Want to fire up a “Hello World” web server in Node? It’s trivial:

// Load the http module to create an http server.
var http = require('http');

// Configure our HTTP server to respond with Hello World to all requests.
var server = http.createServer(function (request, response) {
  response.writeHead(200, {"Content-Type": "text/plain"});
  response.end("Hello World\n");

// Listen on port 8000, IP defaults to

Want to do the same thing in .NET? Be prepared to learn about IIS, the Machine.config, the Web.config, the Process Model, how Global.asax works, either ASP.NET MVC or WebForms (huge paradigms in themselves), and how Visual Studio works. Don’t forget to learn how to create a solution, at least one web project, and how to deploy the application to IIS. Oh, and one little detail: go ahead and learn C# while you’re at it. All of that’s pretty much just as easy and intuitive as Node.js, right?

.NET is incredibly complicated. Node.js is incredibly simple. On the merits of that fact alone it’s no wonder that these .NET developers and fresh-out-of-college kids who have already dabbled in JavaScript are transferring these skills to the server side and standing up web servers in literally 5 minutes and 5 lines of code. How can you deny the sexiness of that? The bragging rights it gives you? The ease and comfort of a language you’re already familiar with?

This, in my opinion, is why Node.js is becoming huge. It has simplified and streamlined the development process and made programming very accessible to almost everyone (or at least anyone who has ever played with JavaScript).

However, to those who sell Node.js as single-threaded, and to those who sell Node.js as having significantly better performance than .NET, I say this: you are wrong.

With simplicity comes misunderstanding and the concept of “Leaky Abstractions.” As my good friend and colleague Thomas B. said to me during dinner last week: Node.js is opinionated. It has an opinion on how you should do things, and it forces you to do them a certain way.

Node.js is not single-threaded, though many Node developers in my experience believe it to be. Node’s creator believes that a single-threaded listener delegating I/O-bound work to a thread pool is the key to a highly available application. As a result, Node.js forces you into this paradigm of event-based asynchronous execution of I/O operations via a thread pool.

Node.js has a single thread listening for connections. All of the code which you as the Node developer write is executed on this single thread. This single thread is all that is exposed to you. As soon as a connection is received, Node’s listening thread executes your coded event on the same listener thread. This event either does quick, non-CPU intensive work (like returning static content to a client), or long-running I/O bound operations (like reading data from a database). In the case of the former, the listener thread does in fact block for the duration of the request, but the request happens so quickly that the delay is trivial. In the case of the latter, Node uses V8 and libuv (which it is built upon) to delegate the I/O work to a thread from an underlying pool of native C++ threads. The single listening thread kicks off the work to an I/O worker thread with a callback that says “tell me when you’re done” and immediately returns to listening for the next connection. It is thus plain to see that Node.js is indeed multi-threaded, though this functionality is not directly exposed to the Node developer.

An important note regarding Node.js is that any CPU-intensive code which you write will block the entire system and make your application scale poorly or become entirely unresponsive. As a result, you would not want to use Node.js when you need to write an application that will do CPU-intensive work such as performing calculations or creating reports.

This is how a single thread can handle multiple requests at once; receiving a request and either serving static/simple content or delegating it to an I/O thread from a thread pool are both very cheap and quick operations. When the thread pool thread that is doing the long-running I/O work signals to the single listener thread that the work is done, the listener thread picks up the response and sends it back to the user; this is another very cheap operation. The core idea is that the single listener thread never blocks: it only does fast, cheap processing or delegation of requests to other threads and the serving of responses to clients. The diagram below (taken from Stack Overflow) explains this visually:

Node.js Processing Model

This is a very good, scalable, highly-available way to write code; Node.js nailed their approach and developers benefit from it. However, as of .NET 4.5, you can easily create this exact paradigm/pattern in your .NET applications. The difference is that .NET does not force you to do so.

With the introduction of a very tidy wrapper around asynchronous programming in .NET 4.5 (async/await keywords), Microsoft made asynchronous, event-based programming quite a bit easier and more intuitive. And with recent conformance by Microsoft to the jointly-created OWIN specification, the web pipeline of .NET has become much simpler.

In fact, you can now write the “Hello World” asynchronous web server in .NET in about as few lines as Node.js! In this example, I host a web server in a console application which is terminated when a key is pressed:

/// <summary>
/// A simple program to show off an OWIN self-hosted web app.
/// </summary>
public class Program
    /// <summary>
    /// The entry point for the console application.
    /// </summary>
    /// <param name="args">The arguments to the execution of the console application. Ignored.</param>
    static void Main(string[] args)
        // Start OWIN host
        using (WebApp.Start<Startup>(url: "http://localhost:8000"))
            // Runs until a key is pressed

    /// <summary>
    /// This code configures the OWIN web app. The Startup class is specified as a type parameter in the WebApp.Start method.
    /// </summary>
    private class Startup
        /// <summary>
        /// Configures the web app.
        /// </summary>
        /// <param name="app">The app builder.</param>
        public void Configuration( IAppBuilder app )
            // We ignore any rules here and just return the same response for any request
            app.Run( context =>
                context.Response.ContentType = "text/plain";
                return context.Response.WriteAsync( "Hello World\n" );
            } );

One of the big positives of Node.js is that you opt-in to complexity. You start very simply and add on functionality as you need it. I’m a big fan of this approach and I feel that this is where Node really shines. Nothing bothers me more than starting an “Empty MVC 4 Web Application” from template in Visual Studio only to have it install about 15 Nuget packages, one of which is Entity Framework. Great, I fired up a blank application and already my ORM has been decided for me. Who said I even needed one in the first place?!

The above OWIN-based approach to hosting a web app in .NET allows you to benefit from Node’s simplistic approach. I have started out simply, and can now add Dapper if I need an ORM, Newtonsoft.Json if I need to serialize to and from JSON, Unity if I care about dependency injection, etc. It’s a nice, clean slate upon which I can build any framework that I desire.

This approach in .NET is very comparable to Node.js, with a few differences:

  • Node.js uses 1 listener thread, while .NET uses N listener threads. If your Node.js application does CPU-intensive work at all, it will block the entire system and potentially cause your application to become unresponsive. .NET, on the other hand, is designed to do CPU intensive work. Tying up a thread to do some CPU work is not of concern because there are other threads available in the listener thread pool to take other requests while this is happening. However, both Node.js and .NET are limited by the server resources; in either case, if you max out the CPU or RAM, your app will perform horribly, regardless of thread delegation. This is known as resource contention.
  • Node.js delegates I/O bound work to an I/O thread worker pool, and .NET implemented asynchronously (async methods and the async/await keywords) does the same.
  • Node.js uses an event-based paradigm, and .NET does also when implemented asynchronously.
  • Node.js offers high performance for I/O bound, low CPU operations, and .NET offers comparable performance when you skip the IIS pipeline. IIS tacks on a significant amount of performance overhead due to things like session state management, forms authentication, the process model, request lifecycle events, etc. These are not bad things to have and use, but if you don’t need IIS, session state, forms auth, request lifecycle events, or the process model, then don’t use them!
  • Node.js must parse/serialize to and from JSON, and .NET must serialize to and from JSON to interact with .NET objects. Parsing is going to be much cheaper in Node.js than serializing is in .NET, but .NET also enables you to serialize to XML, Atom RSS, and anything else that you desire. With Node, this is a bit trickier, and the serialization overhead comes back into play to even the field.

When someone compares Node.js to .NET, I find that they often actually compare Node.js to IIS hosted frameworks such as ASP.NET MVC, ASP.NET WebForms, and ASP.NET Web API (in IIS hosted mode). These are all tools built on top of ASP.NET to simplify enterprise web development and to do CPU-intensive calculations. In these scenarios, Node.js will have an advantage, because it is designed specifically to NOT do CPU-intensive calculations. You are effectively comparing CPU-intensive Apples to low-CPU-usage Oranges. It is not a fair comparison.

When someone compares Node.js to a self-hosted .NET web app which does I/O-bound long-running operations via asynchronous thread pool delegation, they find that there is not much of a difference in performance between the two runtimes. In fact, comparing Node.js to self-hosted Web API (NOT using IIS) doing low-CPU work, the numbers are very close:

Web API vs Node.js

This image was taken from a benchmark done in 2012 with the Web API Release Candidate (not Web API 2, and NOT OWIN hosted). Given that Web API 2 exists, and can be self-hosted via OWIN, I’d love to see a more recent benchmark comparing the two. In fact, I will try and do this for my next blog post.

So, to Node.js or not to Node.js? I submit these final thoughts:

I guess the point of all of this has been that neither Node.js or .NET is necessarily better/the best/the new hotness. They both serve a purpose, and while Node.js is much easier to use and more accessible to developers, .NET is very versatile and powerful as well. They are built to do different things: Node.js specializes in performing and scaling well for low-CPU, highly I/O-bound operations. .NET can perform well in this scenario as well, but can also perform well with high-CPU operations. In fact, I would argue that .NET excels at CPU-intensive operations, especially when compared to Node.

There are many .NET developers in the current tech scene that are capable and competent. This means that it’s not too hard to find, hire, and retain good .NET talent. They can pick up self-hosted OWIN web apps in a matter of days, and begin to write very scalable, high-performance web apps and services based on it. They can even easily host Web API in an OWIN web app via console, a Windows service, or Azure. There’s a community that has existed for over a decade that evolves the .NET framework with amazing tools and add-ons like Dapper, Unity, and Newtonsoft.Json. This community is mature and there are many prominent voices within it that offer advice and help.

Relative to .NET, there aren’t as many Node.js developers in the current tech scene that are capable and competent. This is because fortune favours the bold, and only a few have been early adopters of Node.js. In my experience, few Node developers will truly understand what is going on in the Node.js processing model and how to exploit it for maximum performance, though the opinionated paradigm of Node.js will force developers to write good asynchronous code. It can be hard to find, hire, and retain good Node.js talent. This will become less of a concern as Node’s following grows. The Node.js community is budding and has created some amazing tools and add-ons for Node.js as well such as ORMs and DI frameworks. This community is not yet mature and I am not aware of many prominent voices within it that offer advice and help. As a result, it could be difficult to find support and tools for Node.js if you encounter a problem.

In conclusion, both Node.js and .NET are great. Which one to pick for a particular solution/application, however, depends on many factors; it is not black and white but a full colour spectrum. It would be very foolish and naive for a .NET developer to use .NET to solve every single problem just because “that’s what we use.” It would be similarly foolish for a Node.js developer to propose Node.js as a solution for every project or problem that he or she encounters. One must choose the right tool for a given job, and be open to different paradigms in order to truly excel.

In general, use Node.js when you have highly I/O-bound operations that don’t use much CPU. Use .NET when you need to calculate things and use a lot of CPU.

Don’t use Node.js solely on the reasoning that it’s much faster and performs way better than .NET: it depends on how you use .NET. And don’t use .NET if all you’re doing is heavily I/O-bound operations with low CPU usage: that’s where Node.js excels.

Static vs Instance string.Equals Benchmark

A friend of mine commented on my last post asking about how much faster the static string.Equals method is than the instance string.Equals method. To satiate both of our curiosities, I have created this benchmarking application:

static void Main(string[] args)
    var stopwatch = new Stopwatch();

    string a = "hello";
    string b = "hi";

    for (int i = 0; i < 10000000; i++)

    Console.WriteLine("Instance string.Equals over 10,000,000 iterations: " + stopwatch.ElapsedMilliseconds + " ms");


    for (int i = 0; i < 10000000; i++)
        string.Equals(a, b);

    Console.WriteLine("Static string.Equals over 10,000,000 iterations: " + stopwatch.ElapsedMilliseconds + " ms");


The results of 5 runs, where “I” is the instance method and “S” is the static method, and the times are in milliseconds:

I: 113
S: 100

I: 144
S: 96

I: 126
S: 89

I: 126
S: 94

I: 128
S: 97

And there you have it. Static string.Equals is reliably slightly faster… But unless you’re doing millions of comparisons, it probably doesn’t really matter much. It does, however, prevent the NullReferenceException mentioned in the last post when the string instance is null.

Static vs Instance string.Equals

As you may or may not know, static methods are usually faster than instance methods. This alone should be a good enough reason to use the static string.Equals method in .NET, but if that doesn’t do it for you, allow me to present a simple example.

string a = "hello";
string b = "hi";
bool result = a.Equals(b);

What is the expected result of these lines? A boolean value of false, of course. And it’d be true if the strings were identical. It’s also false if b is null. But what if a is null?

string a = null;
string b = "hi";
bool result = a.Equals(b);

The above code throws a NullReferenceException, since we are attempting to use the instance method of string.Equals and our instance is null. Effectively we’re calling null.Equals which of course is a NullReferenceException.

The static method is best to use in situations where either string (or both) can be null. Re-writing our code as:

string a = null;
string b = "hi";
bool result = string.Equals(a, b);

Allows the code to run identically in function to the original code but without ever throwing a NullReferenceException for any given string input.

The Joel Test Really is Meaningful

Well, it’s been nearly 2 months since my last post… I’m learning that if you want a blog to be successful, you have to carve time out of your busy life and make it happen. So, with renewed focus, I re-enter the fray.

The Joel Test is a curious and honest thing. It has been around since the year 2000 and was invented by a guy named Joel Spolsky, as the name might imply. In short, it’s a very brief questionnaire that evaluates the quality of your software development team, and implicitly their happiness as well.

There are 12 questions. A score of 12 is perfect, 11 is good, 10 or lower and your team has serious problems. The questions are simple and in the format of yes/no. The Joel Test is as follows:

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

For those who have never heard of hallway usability testing, I offer Joel’s definition: “A hallway usability test is where you grab the next person that passes by in the hallway and force them to try to use the code you just wrote. If you do this to five people, you will learn 95% of what there is to learn about usability problems in your code.”

The Joel Test has been in and out of my life for quite some time. Every now and then I remember that it exists, and then I evaluate my current employer on it. My current company is suffering in the programming department; we are losing people like crazy and are having a hard time hiring good folks, despite offering reasonably competitive salaries and benefits… So, realizing that we have some issues, I conducted The Joel Test on a whim. Here’s how we did:

1. Do you use source control? Yes.
2. Can you make a build in one step? Yes.
3. Do you make daily builds? No.
4. Do you have a bug database? Yes.
5. Do you fix bugs before writing new code? No.
6. Do you have an up-to-date schedule? No.
7. Do you have a spec? No.
8. Do programmers have quiet working conditions? No.
9. Do you use the best tools money can buy? No.
10. Do you have testers? Yes.
11. Do new candidates write code during their interview? No.
12. Do you do hallway usability testing? No.

We scored 4. 4 out of 12. Recall that 10 or worse means that you have a serious problem. Yeah.

So, what did I learn? I learned that part of the reason that we are losing people is that our programming practices and team environment lack something to be desired, and thus people are not happy. This isn’t really news to me, however, since the people that have quit recently have all cited these things as some of the main reasons.

What’s the next play? We need to improve the aspects of our environment and team that failed the test. The question then becomes: will management improve these things, or will they choose to ignore our suggestions because most of them (using the best tools that money can buy, quiet working conditions) cost money, and the rest of them are process changes? In fact, I’d go so far as to say that for my current company, they’d be significant process changes… And if there’s one thing that I’ve learned in my career as a programmer so far, it’s that businesses love to stay in familiar territory, clinging to what they already know and feel experienced in, and are generally afraid of significant change.

As a result of the change not being delivered, the motivated individual realizes that change must then come from within… People quit to change the negative environment for themselves (by joining a more positive one).

I encourage you all to conduct The Joel Test in your environments, and to try and improve your team with the results. What have you got to lose? Oh yeah, more developers. 😉