Aaronontheweb

Hacking .NET and Startups

Business to Business Services Are What Will Make Dogecoin Succeed

March 16, 2014 08:45 by Aaronontheweb in Cryptocurrency // Tags: , // Comments (1)

dogecoinFollowing on from my previous post about the second / third generation cryptocurrencies advancing the start of the art, I’ve spent a lot of time participating in /r/dogecoin on Reddit and seeing dozens of new businesses start accepting Dogecoin every day.

I’ve mined a fair bit of Dogecoin so far (albeit on laptops, not dedicated mining rigs) and purchased a substantial amount, so I’ve been looking for some ways to spend or invest it.

Here’s some of the purchasing that I’ve done or am considering at the moment:

There’s a steady clip of new merchants and stores announcing support for Dogecoin on Reddit and elsewhere every day – to the tune of a couple dozen per day based on my casual observation of the forums.

One thing that 100% of these stores have in common is that the goods they’re pricing in Dogecoin are consumer goods, sold directly to individuals. And that’s probably the natural place for a new type of payment technology to begin getting traction, since the barriers to entry are fewest.

However, there are millions of consumer businesses that simply won’t take the currency risk of accepting Dogecoin (or Bitcoin) directly – they might try using a service like Coinbase or BitPay, which mitigate the currency risk by just pricing everything indexed to some fixed fiat (USD, EUR, etc) value and send the fiat back to sellers immediately once the transaction clears.

But the core problem that early crypto-accepting businesses like Overstock solve with Coinbase et al today is that they can’t cover any of their business costs with Dogecoin or any other cryptocurrency. If I’m Overstock’s CEO, I might be able to accept cryptocurrency from customers but I can’t use it to:

  • Pay the salaries of my employees;
  • Pay for critical infrastructure costs like large-scale hosting, CDNs, etc;
  • Pay for the COGS of the inventory sold to customers, including shipping and so forth;
  • Pay for marketing and advertising needed to drive new users to the site and grow the business;
  • Pay taxes and licensing fees;
  • Pay for service providers like accountants and attorneys;
  • Pay for the rainbow of various insurance premiums that every business has to have; and
  • Pay for real-estate and other capital expenditures.

All of these expenses are really business-to-business transactions, if you consider employees as sole proprietor service providers for the sake of this example.

 

Not being able to pay for any of those things without having to convert Dogecoin back into USD and being subject to rapidly changing market conditions is the real-world definition of cryptocurrency risk. And so the strategy of choice for mitigating it is to simply never pay for any of these services in Dogecoin – set the price for all of your goods in USD and let the customers take the currency risk at the point of sale.

However, that strategy ultimately limits the utility and value of the cryptocurrency to business-to-consumer transactions only – still really useful, but also makes the USD / Dogecoin exchange rate the sole determinant of the currency’s value, since prices for goods are still really set in USD.

 

An alternative and much more interesting approach is to start selling business-to-business services in Dogecoin directly. It’s a process that will take much more time to develop (decades) but it ultimately leads to a path where the value of Dogecoin goods can be wholly priced in cryptocurrency. And therefore: leads to a day when the value of Dogecoin is based off of its buying power indexed to real goods and services, not speculation.

I run a B2B startup at the moment - MarkedUp Analytics; if I could pay my (considerable) Amazon Web Services bill in Dogecoin alone and there were tools available to make it easy for my accounting firm to reconcile Dogecoin-based transactions in Quickbooks, I’d be in.

Growing a B2B Dogecoin ecosystem from the ground up can be bootstrapped. It starts with a few SaaS products that make it easy to do order fulfillment and process transactions – Moolah has already made massive strides on that front. Immediately after that comes accounting tools – something as simple as a bank statement plus historical fiat fair market values is probably all that’s needed until the ecosystem grows. Those are the basics that businesses selling to consumers need.

From there, the next best place to enter is marketing and advertising services – and I would start by building marketing / advertising services that make it easy for businesses to find consumers who are want to pay with Dogecoin.

Trying to get MailChimp or MarkedUp to accept Doge is the wrong place to begin – focus on building advertising networks or product listing services that make it easy for the early adopter businesses to find Dogecoin customers. Because from there, you can get a virtuous cycle that can start growing the ecosystem based off of its own organic growth, rather than hit-driven PR and speculation.

From there, if the segment of customers “willing and able to pay in Dogecoin” grows sustainably, anything is possible. Cracking the really tough nuts, like paying salary or buying real-estate with Dogecoin, will take many years of consistent growth in order to be achievable.

Dogecoin is entering a phase now where the first business-to-business services need to emerge in order to help support the business-to-consumer companies selling coffee, Steam keys, and the like. That’s how the long view of the ecosystem becomes realizable.

If you enjoyed this post, make sure you subscribe to my RSS feed!



Bitcoin Paved the Way, but it’s Not the Future of Cryptocurrency

March 1, 2014 10:29 by Aaronontheweb in Cryptocurrency // Tags: , , // Comments (1)

bitcoinUntil recently, I was extremely skeptical of cryptocurrency in general. In the midst of the investment speculation and mania in late 2013, when the price of Bitcoin first climbed to $500-$800, it smelled too much like digital Beanie Babies for my blood. So whatever interest I had in learning about the technology and its disruptive potential was buried underneath multiple layers of speculation sediment.

Two things piqued my interest, however: 1) I attended a Bitcoin meetup in Santa Monica and heard more about it and 2) the Jamacian bobsled team raised money to attend the Winter Olympics with a huge amount of support from Dogecoin.

So my interest in cryptocurrency grew and as an entrepreneur I wondered about what industries it could disrupt.

I imagine a world where I can run a legitimate business; open a merchant banking account; and accept orders from customers all over the world in a matter of minutes – without having to seek the permission of a lumbering, bureaucratic bank or credit card processing service that doesn’t give a shit about my business.

There’s a lot of exciting possibilities for cryptocurrency in general – it will take years, but it’s a real possibility that shouldn’t be dismissed.

That being said – there’s an empirical rule that I subscribe to when it comes to emerging technologies: “never bet on the first generation of a ground-breaking technology.”

I’m sure there are some counter-examples (I can’t think of any off-hand,) but they are few and far between for the simple reason that the inventors behind the new technology don’t have crystal balls and can’t anticipate every critical market factor. By and large - it's the second and third generation technologies that win. Windows, Office, iPod / iPhone, Google, etc...

So I suspected that Bitcoin would be slathered with “first generation” problems, and I wasn’t disappointed.

For most people Bitcoin is a speculative investment, not a currency

Investors all over the world buy and sell fiat (sovereign) currencies like commodities, and there’s investment markets and exchanges for it such as Forex.

The big difference between a fiat currency like the United States Dollar and Bitcoin though, is the the number of dollars in circulation moving from person-to-person versus sitting dormant in an investment account waiting for the value of the Euro to fall is orders of magnitude larger. The amount of dollars held for foreign currency trading is a drop in the bucket compared to how much is spent buying goods, being loaned, et cetera.

Bitcoin, on the other hand, has been on the receiving end of a speculation bubble unlike anything I’ve ever seen since the rise of the Beanie Baby. People who successfully acquire Bitcoin, whether through mining it or buying it, hold onto it rather than spend it.

Bitcoin Days Destroyed - from blockchain.info on 3-1-2014

The chart above is from the official blockchain.info charts and it shows “Bitcoin days destroyed” – if someone received 100BTC 7 days before they sold it, it would destroy 700 days worth of bitcoin trading days during that waiting period.

The maximum number of Bitcoin that can ever be minted is 21 million, if I recall correctly. The number of days destroyed on the chart for the past year indicates that since the value of Bitcoin really skyrocketed in October, 2013, bitcoins are finally starting to move as people sell them for USD or other fiat currencies.

And this has been true of Bitcoin in general – since its value started to take off, it’s been viewed as an investment speculation rather than a money transfer mechanism used for buying goods / services. I don’t even feel the need to look for a citation for that last sentence.

The other factor that really contributes to “Bitcoin as an investment” is its inherent deflationary policy – if someone loses a hard drive with $6m worth of Bitcoin on it, that currency is gone forever and the total available amount of Bitcoin anyone can ever have decreases. Scarcity with Bitcoin will always increase once the last coin gets mined, as currency will be lost or destroyed over time with no possibility of replacement.

So when you combine both of these factors – fever pitch speculative investment and guaranteed increase in scarcity, you get sensational claims about Bitcoin being worth $100,000 per coin by 2016. Which in turn creates more speculation and blah blah.

So why would I turn around and buy a laptop off of Overstock with Bitcoin if I think that Bitcoin is going to be worth 100x what it is today? Wouldn’t I just keep holding onto it, like the chart above indicates? Well, yes!

Bitcoin as an investment, today, is driven by the greater fool theory of investment – that some other idiot will buy the Bitcoin you bought at a greater price because he can sell it to another idiot. Bitcoin will have real value when people start actually buying real goods and services with it, which they largely are not right now.

Compare this to Dogecoin – a currency with an unlimited theoretical number of coins in circulation (designed to eliminate the threat of lost currency), where the value of each individual coin is so low that people are actively inventing ways to spend them. Hence why Dogecoin’s currency transaction volume is several times higher than Bitcoin, despite the fact that the Doge is only a few months old.

Overstock and Playboy and other companies might be accepting Bitcoin for purchases1, but we have yet to see if people will buy. With Dogecoin on the other hand, people already are.

I believe that Bitcoin’s deflationary policy will ultimately make it a loser in the long-run, when it comes to businesses being willing to accept BTC at face value rather than index it to the dollar. Ultimately the BTC speculation bubble will implode and correct itself down to the actual good / services buying power of the coin.

An inflationary policy, not unlike what most fiat currencies do, is what has historically been successful at increasing volume (and volume == buying power == value for cryptos) and I don’t see any reason why that would not hold true for cryptocurrencies as well.

Mining Arms Race

Every post-Bitcoin cryptocurrency implementation uses “mining” as a form of expanding the currency over time although “by how much?” and “until when?” varies.

The mining process looks like this, in summary:

  • Every cryptocurrency writes all of its transactions into a public ledger, the “blockchain” in Bitcoin’s case, and before money can officially move from one account to another this transaction has to be validated and agreed upon by a majority of miners;
  • All Bitcoin transactions use elliptic curve cryptography to validate transactions – every Bitcoin address comes with a public key that is available for everyone to see, but to successfully transfer currency from one account to another then the sender must sign the transaction in the blockchain with their private key using a cryptographic hash signature, SHA-256 in the case of Bitcoin;
  • Miners listen for new transactions on the blockchain and are able to authenticate them by verifying that the hash is valid – they can do this without knowing the sender’s private key, which is what makes cryptocurrency simultaneously secure and public.
  • Once a miner has validated a hash, it writes back to the blockchain “I think this hash is valid” – the blockchain will wait for a consensus of miners to all agree that the transaction is valid before officially adjusting the totals in each account.
  • The miners are rewarded for their efforts by discovering new “blocks” of previously undiscovered coins, which will yield a number of new coins that awarded to the miner – miners can also be given transaction fees under some circumstances.
    Mining was initially the easiest way to acquire Bitcoin or any other cryptocurrency – take a computer that has a decent graphics card and you can mint a few thousand of them in a week. However, over time the difficulty – the amount of work required to discover a new block of coins, increases dramatically.
    So the amount of new coins you can discover drops. However, miners are still supposed to be theoretically encouraged to mine as a result of the increase in value of the currency – that way the miners can break-even and maybe even make a profit on the costs of electricity, hardware, and bandwidth needed to mine.

One of the issues that Satoshi or any of the early Bitcoin inventors could not have anticipated is the rise of ASIC (Application-specific integrated circuit) miners – machines custom-built for executing the SHA-256 algorithm specifically, and they can do it several orders of magnitude faster than a general-purpose computer can at a fraction of the cost.

These machines are really only available to people who have lots of resources and relationships with custom foundries in China, where the hardware can be made, organizations like cex.io and others.

These machines nuked the difficulty of the current Bitcoin blocks beyond a point where the average person can't realistically mine and make a return to even cover the cost of electricity used while mining, but more over it introduced the possibility of a 51% attack – a mining pool, or a cartel of pools, that controls 51% of greater of the total hash rate for Bitcoin has the power to do all sorts of things to Bitcoin’s stability.

For instance, there was a proposal on /r/Bitcoin this week (I can’t find the link at the moment) to have the mining pools point to and validate a new, special “emergency block” containing 750,000 new Bitcoins in order reimburse the people who lost their Bitcoins during the Mt. Gox fiasco. This proposal is being ignored because it would set a terrible precedent, but imagine what might happen when Bitcoin’s last block is discovered and the block rewards diminish to the point of just transaction fees?

What if GHash.IO or any of the other mining pools who control access to ASIC miners decide to improve their returns by not validating CoinBase or OverStock’s Bitcoin transactions unless they pay the mining pool a percentage of revenue? What about rewarding themselves with new blocks, per the Mt. Gox proposal?

It’s a real possibility – there would be outrage from the community of course, but outrage won’t buy you ASIC mining capacity to dilute the share percentage of a mining cartel.

This problem is largely due to the simplicity of the SHA-256 algorithm – it’s easy to build ASIC computers for it.

Virtually every other major altcoin since, beginning with Litecoin, has adopted the scrypt hashing algorithm to attack this very issue and make it uneconomical for any one party to dominate the net hash rate of any given currency.

Scrypt is memory-hard – it is designed to make it extremely expensive to execute large-scale hardware attacks by requiring large amounts of memory to compute each individual hash, which makes it suitable for graphics card (GPU)-based mining – an activity that individuals can participate in economically.

vertcoinThere are other coins, such as Vertcoin, that have gone beyond even what Litecoin and its derivatives (such as Dogecoin) have done to make it uneconomical (different from impossible) to use ASICs for mining, thus defeating the threat of a mining cartel seizing control over the behavior of the public ledger.

Unless nVidia or AMD wants to get into the business of operating its own mining pools, it’s not supposed to be economically feasible for any one organization to buy 51% of all GPUs used in mining operations.

So in conclusion, the potential for a 51% attack with Bitcoin is very real – the miners who are able to secure relationships with custom ASIC foundries in China can make the rules at-will with BTC.

Not true for the second generation cryptocurrencies like Dogecoin and Litecoin, which fundamentally makes them less risky and more predictable in the long run.

Conclusion

The most common argument I hear from Bitcoiners isn’t really an argument at all; they say words, but what I hear is “well, I invested {x} into Bitcoin therefore it must succeed.”

The real argument that Bitcoin has going for it is momentum – it’s paving the way for cryptocurrencies to actually emerge as things that people really use to buy goods and services. In the long run, cryptocurrency will succeed in transforming how we buy and sell.

But I don’t think it will be Bitcoin that emerges as the leading standard, for the reasons I stated above.

Overall, I’m just happy that there’s a future in-store for me where I can do about my business without having to deal with the bureaucratic paralysis of banks when it comes to accepting orders from customers around the world.

Bitcoin is an issue that has a lot of emotionality and dollars attached to it – please keep it civil in the comments.


1although they really aren’t – Coinbase accepts all of the currency risk and pays them in USD, but that may change in the future.

If you enjoyed this post, make sure you subscribe to my RSS feed!



The Taxonomy of Terrible Programmers

The MarkedUp Analytics team had some fun over the past couple of weeks sharing horror stories about software atrocities and the real-life inspirations for the things you read on The Daily WTF. In particular, we talked about bad apples who joined our development teams over the years and proceeded to ruin the things we love with poor judgment, bad habits, bad attitudes, and a whole lot of other bizarre behavior that would take industrial pyschologists thousands of years to document, let alone analyze.

So I present you with the taxonomy of terrible software developers, the ecosystem of software critters and creatures who add a whole new meaning to the concept of “defensive programming.”

At one point or another, every programmer exists as at least one of these archetypes – the good ones see these bad habits in themselves and work to fix them over time. The bad ones… simply are.

The Pet Technologist

My personal favorite.

A pet technologist is born when they make the fatal mistake of falling in love with a piece of technology. It’s not a gentle, appreciative, “man this is a well-designed framework” sort of love – it’s inseparable, unrequited, Misery-obsessive love. And just like with spying, falling in love is a liability in our business.

No matter what the question is, you can trust that the pet technologist will have an answer: his or her pet technology.

“Hey, we need to implement a content management system in Rails, which database should we use?” Mongo.

“Multi-tenant blog engine?” Mongo.

“Business-critical compliance system?” Mongo.

“Inventory management system?” Mongo.

“Electronic medical records system?” Mongo.

“Distributed data warehouse?” Mongo.

And so forth.

They will invent reasons to include their pet technology in any project you work on, regardless of whether there’s a practical reason for it or not. They will vehemently, emotionally fight any decision against including their pets. Sometimes they might even resort to not telling anyone they’re using it, and will try to sneak it in at the last minute.

The Arcanist

Anyone who has worked on a legacy system of any import has dealt with an Arcanist. The Arcanist’s goal is noble: to preserve the uptime and integrity of the system, but at a terrible cost.

The Arcanist has a simple philosophy that guides his or her software development or administrative practices: if it ain’t broke, don’t fix it – to an extreme.

The day a piece of software under his or her auspices ships, it will forever stay on that development platform, with that database, with that operating system, with that deployment procedure. The Arcanist will see to it, to the best of his ability. He may not win every battle, but he will fight ferociously always.

All change is the enemy – it’s a vampire, seducing less vigilant engineers to gain entry to the system, only to destroy it from within.

The past is the future in the Arcanists’ worldview, and he’ll fight anyone tries to upgrade his circa 1981 PASCAL codebase to the bitter, tearful end.

The Futurist

The Futurist is the antithesis of the Arcanist – today is the future, and any code written with yesterday’s tools fills the Futurist with unparalleled disgust and shame. The Futurist’s goal is not noble – it’s to be seen as new and cutting edge. The Futurist’s measure of success is Hacker News karma and well-attended User Group meetups from his war stories, not effective programming.

The Futurist will breathlessly tell you with spittle-flying gasps about the latest JavaScript-does-something-it-shouldn’t experimental project he read about on Hacker News thirty minutes ago and has already forked to his Github. He’ll squeal like a teenage girl at a Justin Bieber concert every time Microsoft Research or the Server and Tools Team releases an obscure alpha of some technology he knows the name of but doesn’t understand.

The Futurist is responsible for more reverted commits than any other developer, and is often flabbergasted when his attempts to upgrade your database driver package to v1.0.13-alpha-unstable-prelease-DONOTUSE are rejected. His pleadings of “but it has Java Futures, so we get pure async!!11!1” do not stir the vigilant release manager.

The Futurist cares not for quaint, passing concerns about stability, maintainability, or teachability – it doesn’t matter to him if it’s impossible to hire Erlang developers. New is everything.

The DevOps Engineer, the QA Engineer, and the Release Manager are the natural enemies of the Futurist.

The Hoarder

The Hoarder is a cautious creature, perpetually unsure of itself. The Hoarder lives in a world of perpetual cognitive dissonance: extremely proud of his work, but so unsure of himself that he won’t let anyone see it if it can be helped.

So he hides his code. Carefully avoiding check-ins until the last possible minute, when he crams it all into one monolithic commit and hopes no one can trace the changes back to him. His greatest fear is the dreaded merge conflict, where the risk of exposure is greatest.

The Hoarder will openly tell you that his work is awesome but in confidence knows his code might suck. It probably does – but his fear of facing that possibility is what makes him who he is. The Hoarder is responsible for many last minute bugs sprinkled throughout the catacombs of the code base. His fellow engineers, tired of slowly going insane from invasion of subtle bugs, rose to fight him.

They invented tools like git blame and other weapons of accountability, and vengeance.

Ultimately, the Hoarder is damned and doomed – but there is hope for him in the short run. The day accountability comes for him at one job, his Dice resume is updated for another. The Hoarder will live to fight another day.

The Artist

A cousin of The Hoarder and The Futurist, the Artist pours his soul into every thoughtfully constructed line of code. The Artist is an emotionalist – his software is an expression of himself, a living embodiment of the genius he represents.

The Artist considers the important questions, like will my JavaScript be more syntactically beautiful without semicolons? How can I turn this perfectly readable for..each statement into a single line of LINQ? Will wrapping this block in a promise make it more… elegant?

The Artist and his code are one, which creates inevitable problems in the real world. Every JIRA issue containing documented, indisputable proof of a bug in his code is an act of artistic censorship on the behalf of users who “just don’t understand” or jealous colleagues who envy his genius. His lower lip quavers for minutes each time a UserVoice ticket announces its presence in HipChat, titled with the name of a feature he owns – even if the ticket in question is replete with the gentle patience and understanding of an early adopter.

The Artist is not long for this world, unable to have an objective discussion about his body of work with even the most sympathetic of colleagues, he withdraws from the company of his fellow developers and metamorphoses into The Island.

The Island

The Island is the ultimate loner in the taxonomy of terrible software developers, as he desires above all things to be left in peace with his favorite text editor and devoid himself of all human contact. The ideal condition for the Island is one where communication with the outside world is kept at a minimum and strictly at his convenience. Just code, no humans.

Unfortunately, reality and ideal often being far afield, the Island has to seek the company of others in order to live. So he is forced to communicate with co-workers or clients, and it is a tremendous burden for him indeed.

So he hides – he’ll miss meetings, fail to return phone calls, stay signed off of IM, keep the email client closed, and so forth. He’ll gladly spend hundreds of man-hours Gandalfing the documentation and project specs rather than simply ask someone on his team questions.

The Island is usually also a Hoarder – keeping his releases close to the vest until it’s absolutely necessary to share them. Anything to avoid people and their judgments.

And like the Hoarder, the Island is doomed. Software is a team sport and does not suffer those who do not play by its rules.

The “Agile” Guy

The “Agile” Guy is a utilitarian, who ultimately seeks to improve the efficiency and productivity of himself and his team. Unfortunately, both his understanding of “agile” philosophies and his implementation strategy are hilariously inflexible and rigid, an irony which is completely lost on him.

The “Agile” Guy’s intentions are noble: to improve the way software is made. He’ll introduce kanban boards with precisely four tiers for exactly every project and a meticulously calculated method for determining the exact number of business points and sprint points for every issue the team can encounter.

Any issue which takes longer than four hours must be broken up; any sprint longer than two weeks must be truncated. NO EXCEPTIONS.

All personnel must pair program with their designated pair programming partners at all times, no exceptions. All git commits must be done in this exact format and hours of work against a JIRA issue must be logged at regular intervals. No status updates are allowed at standups, which are strictly cut off at 10 minutes.

The “Agile” Guy forgets the purpose of the agile process to begin with – to be flexible and dynamic, and instead imposes round-hole order on square-peg problems. The JIRA board turns into a ghetto, a wasteland of broken promises and infeasible commitments. And from dusk to dawn the developers toil, pair programming all the way, while their “Agile” Guy overload looks proudly over his new empire, forged on discipline and process.

But the “Agile” Guy creates powerful enemies in his wake: the actual programmers responsible for getting things done, men and women who live in a world without luxuries of time or realizable schedules. Men and women who try to create order from chaos themselves, but are often at the mercy of failing networked file systems and poorly implemented drivers. Such intrepid souls do not suffer having the will of idiots imposed on them. Dissent and strife spread throughout the team; what follows is rebellion.

All “Agile” Guys meet their end by being torn down like the statue of a deposed dictator, complete with an Ewok luau in the Endor moonlight and the burning wreckage of their kanban Death Star smoldering in the distance.

The Human Robot

The Human Robot tries his best and his intentions are good. But he has a handicap: he interprets everything literally. The Human Robot is the world’s first true organic computer, which also means that every user-space detail of their work must be explained literally, byte-for-byte.

The Human Robot has his uses – he can find (and patch himself!) the subtle race condition created by minor JVM differences on your particular version of the Linux kernel, but ask him to implement a new feature and a monster is born. The Human Robot, unable to grasp concepts such as figurative language, imagination, abstraction, and creative interpretation, is stuck in a world where he can only process commands.

Your product lead asks the Human Robot to create a button that allows the end-user to share their documents via email with another end user; a week later the Human Robot delivers a fully functional high-throughput transactional email server embedded inside your application.

When a Human Robot is confronted about an issue with his or her work on the product, they will respond with the following sentence every time: “your requirement was not found in the specification for this project. We require additional pylons.”

This handicap rears its head most clearly in the team dynamics of a software organization. The Human Robot is the sort of person who needs a four-page-long decision tree and a finite state machine diagram to help him understand what does and does not qualify as sexual harassment in the workplace.

Human Robots often tend to be conference organizers (see PyCon 2013) and moderators on StackExchange.

The Stream of Consciousness

The Stream of Consciousness programmer is related to the Illiterate in that he too cannot read code. However, what’s fundamentally different about the Stream of Consciousness is that he can’t read his own code in addition to that of every other developer on the team.

In fact, the Stream of Consciousness programmer is best described as a “forward-only” cursor – the only way for them to solve their problems is to write new code, every time. Code reuse and refactoring are alien programming practices that the Stream of Consciousness will tell you they “understand,” but that’s only because they know the names of those concepts.

The Stream of Consciousness will happily add a third and fourth new interface to your application for writing to the filesystem, because their cursor has already moved past the first and second interfaces they wrote last week. Their code will be totally free of circular references, but that’s only because nothing ever gets used more than once.

The easiest way to determine if you’re working with a Stream of Consciousness programmer is to read their source code and look for comments along the lines of “hmm, I wonder if this works?” and “I really wish the kitchen had more non-dairy creamer.”

The Illiterate

As the name suggests, the Illiterate has a massive problem when it comes to reading other people’s source code.

The Illiterate, a close cousin of the Island, understands basic programming constructs and has a full grasp on the syntax of his / her preferred programming languages, but is totally blind when it comes to code written by other developers. We call this “code-blind” in extreme cases.

The illiterate can understand the basic “hello world” example, but beyond that he or she never developed the capacity to understand another programmer’s intent or the “Find Usages” button in Visual Studio. So the Illiterate is forced to work around this alien “other programmer” code in all of his or her day-to-day assignments – often duplicating the work of other developers and contributing to code bloat.

When confronted by other developers and asked “why didn’t you use our standard interface for rendering a dialog?,” the Illiterate will simply stare at his or her shoes and mumble inaudibly.

The Agitator

The Agitator, like the Human Robot, is a social retard. But unlike the Human Robot, has no good intentions. An Agitator is not born, they are forged through years of suffering through undesirable work environments and programming assignments.

Having been through shit work for years and years, the Agitator believes he or she now knows best and is determined to run things they see fit, whether they actually have the authority to or not.

The goal of the Agitator is to establish dominance and control over their work environment through the use of force and intimidation.

The Agitator sees themselves as the confluence of Grace Hopper and Che Guevara, a brilliant technical visionary casting off the chains of oppression by an ignorant and ineffective ruling class. The Agitator is seen by his or her teammates as an idiotic wannabe-alpha bully who gets into high volume arguments over when it’s appropriate to use Pascal case versus CamelCase.

The Agitator will routinely try to talk down peers and superiors both in an attempt to assert dominance. In many cases he will win, seeding dissatisfaction and discord in the workplace in the process.

In most cases the Agitator is beyond help, and management has no choice but to enforce the “No Asshole” rule and terminate him.

If you enjoyed this post, make sure you subscribe to my RSS feed!



Win32 Errors: How to Format GetLastError() Output into Readable Strings

November 13, 2013 14:55 by Aaronontheweb in C++, Win32 // Tags: , // Comments (0)

I’ve been doing a moderate amount of native Win32 C++ programming over the past few weeks, and occasionally I’ve needed to set up some debug points to print errors that occur during file and memory I/O.

When something goes wrong inside the Win32 API, some methods will return a system error code directly (such as all of the registry methods) and others will simple return a NULL pointer or a 0-length DWORD and require you to poll the GetLastError method yourself.

Unfortunately, these error codes are just long integers (DWORDs) and don’t contain any of that human-friendly information that I’m used to for .NET exceptions.

I created a Gist on Github that shows how we do it and have also included the code below:

DWORD dLastError = GetLastError();
LPCTSTR strErrorMessage = NULL;
    
FormatMessage(
FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS | 
FORMAT_MESSAGE_ARGUMENT_ARRAY | FORMAT_MESSAGE_ALLOCATE_BUFFER,
        NULL,
        dLastError,
        0,
        (LPWSTR) &strErrorMessage,
        0,
        NULL);

//Prints debug output to the console
OutputDebugString(strErrorMessage);

If you enjoyed this post, make sure you subscribe to my RSS feed!



You Succeed Once You Stop Giving a Shit

September 21, 2013 13:29 by Aaronontheweb in General // Tags: // Comments (2)

This post is about how to find success in any situation and draws entirely from my own experiences. Your mileage may vary.

July was a rough month for me this year – I endured simultaneous failure on all fronts. I had put on a shitload of weight, ended a relationship, and market conditions changed unfavorably for MarkedUp. All of this occurred within a couple of weeks at the tail end of the month.

I am well-accustomed to stress and handle it well. I’ve had things not go my way before, and I’ve always found my footing again.

This time something was different. Maybe it’s because of how deeply invested I am in MarkedUp or because of everything going wrong at once, I don’t know. But the difference this time I walked away with a major dent in my self-confidence and self-sureness. That’s a new one.

I wasn’t even aware that my confidence took a dip at the time. I figured that out more recently, when I started noticing a huge increase in my anxiety and apprehension when it came to routine things.

I started asking myself, “wait a second – this shit never used to bother you. What’s changed?”

Then I remembered the truth. Let’s flash back a few years.

An Unusual Habit

I was an immensely awkward kid my first two years of college. You know the formula: under-socialized kid who spent more time in front computers than people during his developmental years suddenly thrust into a co-ed dorm with babes and booze aplenty, 2,000 miles from the nearest person he knows, unsure of himself, finding his way in the dark.

In particular, I was utterly terrible with women. Terrible enough that my Freudian defense mechanism kicks in with full force when I try to relive the full horror of my own awkward blunders with the opposite sex. Jesus.

Second semester freshman year, I discovered alcohol and spent more time partying1 than studying, receiving poor grades for the first time in my life.

When Sophomore year rolled around my advisor put the ever-loving fear of God into me that if I did not clean up my act then there was no chance I’d ever make it to a decent Computer Science graduate program. I immediately dropped the partying and focused on my school work, and somehow my social life managed to get even worse than it was the year before.

Worst of all, my grades improved but not by a big enough margin to move the needle. I still wasn’t succeeding. Failure on all fronts. Sound familiar?

So I made a decision.

At the very end of Sophomore year, I signed up for study abroad the following summer in Berlin, during the 2006 World Cup.

None of the people on that trip from Vanderbilt knew me, and certainly none of the other students in Berlin. I had a clean slate, and since I had fucked my last one up during freshman year of college, I was going to do things right this time, damn it.

The decision I made was simple: I would not give a single iota of shit about my schoolwork and not take myself seriously. And drink beer. Can’t forget the beer drinking.

The results were astonishing: I had an easy time making friends, socializing at parties and clubs, and my grades were actually pretty good to boot. FWIW, alcohol tolerance was insane by the time we left Berlin, but we’ll save that story for another time.

So I doubled down at the start of junior year. I decided I would not care about anything other than getting the most out of my college experience. I joined a fraternity, took graduate-level courses, dated some fun and interesting women, and pretty much felt like a bad ass. My GPA junior year was a 3.8 – and the amount of effort I put into my schoolwork was a fraction of what I had put in the year before.

Senior year, same thing – I stopped giving a shit about everything by default and with the confidence that I could turn any situation in my favor when I needed to. And I did.

By the time I left Vanderbilt, I felt like a bad ass. But when I entered the real-world and got a job, everything changed. I had to start all over again and build myself back up piece by piece.

Set Your Own Odds

The point of that story is that my ability to succeed personally, physically, and professionally was inversely related to my level of emotional investment into whatever I did. It was that way all along.

I still put in a lot of hours on my school work, I worked out often at the gym, and I spent a lot of time trying to come up with fun ideas for dates.

I put a high level of effort into things that mattered, but for very different reasons than my freshman and sophomore year. I put effort into those things because I wanted to, not because I felt like I needed to.

Not giving a shit simply means doing what you want to do without any emotional investment in the outcome. Put differently, you gradually develop habits to counter your mind’s self-protective “flinch” reflexes.

Negative outcomes and consequences were still possibilities with everything I did, but I hardly thought about them. After all, I live in a part of the world where it’s considered a really bad day if you lose Internet access for 24 hours – what’s the worst that could happen, really?

Once you stop worrying about the negative possibilities, every opportunity has nothing but upside. Ask the cute girl / guy at your gym out for drinks – the worst thing that can happen is a slightly awkward story that you and your friends can laugh about over drinks later. It’s all upside from there.

Stop giving a shit. Stop caring about what other people will think about you if you fail. Worry only about what you’ll think of yourself if you don’t try. No one likes a pussy.

Bold without Knowing It

So, jumping back to the present. Once I realized what was going on, I ran through my process for putting my brain back into “don’t give a shit” mode:

Work towards concrete goals – we can’t control our calendars and circumstances at every given moment, but we are always in charge of deciding what’s important to us. Remember what those goals are. Create a path for realizing them. All of them. Follow it. Even if it takes years. Ignore everything else.

Step into every punch – an old boxing metaphor; if you’ve ever tried boxing, your first natural reflex when someone tries to punch you in the face is to jerk your head back out of the way.

If you let that happen, you drop your cover and leave your face exposed, which allows experienced boxers beat the shit out of you.

So the antidote is to train boxers to step into their opponents’ punches with their guards up and use counter attacks or controlled evasions, instead of flinch reflexes.

The same goes for every day life – when your chest tenses up right before you send a critical email, condition yourself to just press send and don’t think twice. Do the opposite of what your pain-avoiding reflexes tell you.

Practice taking risksread my full post about the subject. Start habitually taking risks on small things, so you’re prepared for the really important stuff in the future.

Decide how you want to react to things – from the Seven Habits of Highly Effective People: “you can’t control everything that happens, but you can always control how you react to them.”

My (chosen) default response to most things: “meh.” Celebrate victories and learn from defeats, but don’t dwell on either.

Find the upsides – as mentioned earlier, every day risks offer very little for us to be afraid of beyond mild embarrassment and maybe some financial / temporal setbacks here in the comfortable first world. So look at your opportunities, even the small ones, and use the upside as your primary decision making metric, rather than fear of failure. You’ll make bolder, better decisions that your 80-year-old self will appreciate.

Find the things you like about yourself, then show them off – there’s an engaging, interesting person inside all of us. Find him or her and let the rest of the world in. Me? I’m pretty sure I can make just about anyone laugh.

So even though this post makes me feel a little vulnerable and reads like dust jacket of a self-help book, I’m publishing it anyway. If it helps someone else find their stride, that’s all that matters to me.

Nothing ventured, nothing gained.


1FWIW, my social skills did not improve as a result of said partying

If you enjoyed this post, make sure you subscribe to my RSS feed!



Being Right is Always the Wrong Choice

August 27, 2013 03:48 by Aaronontheweb in General // Tags: // Comments (3)

It was about four or five years ago that I had an intrinsic need to be “right” all the time.

I couldn’t let it go when someone made a mistake, or slighted me, or disputed the quality / direction of my work. Everyone else was wrong. I wasn’t alone in this regard either: a number of the people around me did the same thing.

Being right

Being right made me feel superior; it made me feel better than the idiot who did that thing wrong; it made me feel moral; it made me feel righteous.

When someone made a mistake, I felt compelled to point it out – even if it meant interrupting a speaker’s presentation during a team meeting. People started spending a lot more time perfecting their talking points and PowerPoints – time that should have probably been spent on something that actually impacted the bottom line for the business.

When someone criticized my work, I deflected their criticisms or manufactured my own reasons for why their criticisms were invalid. My work is a fucking masterpiece, after all. The quality of my work didn’t improve, and I didn’t learn anything unless it was the hard way. People didn’t care about what I had to say about their work either, since they knew I didn’t listen.

I went throughout all of my work fervently believing that what I was doing was correct and righteous – there was no room for self-doubt in this guy’s super powerful brain. I made a lot of mistakes that could have been avoided, and looked the part of the arrogant idiot on a climb-down after each one.

But at least I was “right” and everyone else was wrong.

I have an assertive personality, so my need to be “right” manifested this way. You can easily substitute this with passive-aggressive behavior, which is what most “right” people do.

Being effective

My life changed early in my career when one of my mentors dropped the following bombshell on me after I had a friendly but needlessly assertive altercation with another employee:

You can choose to be right, or you can choose to be effective. It is a binary choice. You pick one, or the other. They are separate circles on the Venn diagram with zero overlap in between.

I choose “effective” every time.

There hasn’t been a day in my life since, nearly five years ago, that I haven’t said this line to myself over the course of any given day. “You can choose to be right, or be effective.” I don’t always make the correct choice, but I’m a thousand times more effective today than I was five years ago.

I stopped caring about people’s small mistakes. And if I did care, it stopped mattering to me who made the mistake or who fixed it; as long as we took care of it.

People became less afraid of sharing their ideas with me and more empowered in their roles the longer we went without the appearance of the “You’re wrong, I’m right” stick.

If someone took issue with the way I was doing something, I would break down the problem for them and ask for data-supported suggestions on how to do something better. In many cases, their criticisms were valid and we changed whatever I was doing. Other times, their suggestions were based on bad data and we didn’t implement them. We stopped taking it personally.

Gradually, everyone put their weapons down and became less worried about accepting, acknowledging, and offering criticism. People began to share their successes with each other, and everyone felt good.

I stopped worrying about if I was doing the “right” thing when it came time to take care of business – I did the best I could, owned up to any problems I created, and tried to fix them. I gave myself some room to question whether I was doing the most effective thing at any given time.

People in the office became less afraid of making a mistake and tried new things. People offered a simple “well, that didn’t work – my bad” when something went wrong, and people stopping caring if it did. We became simultaneously more productive and accountable.

Being comfortable with yourself

The contrast is drastic between the “right” period and the “effective” period. The team became a “we” once people stopped caring about being right. Everybody felt a lot better and accomplished a lot more.

Those changes pale in comparison to how my feelings about myself changed. I no longer felt superior to anyone – because I stopped needing to. All of the feelings of superiority and righteousness that come from being “right” are a façade that hide internal weakness and insecurity.

When I changed my goal from preserving my own sense of superiority to just trying to do the best I can, everything became much more impersonal and objective.

Ultimately, this shift in priorities helped me become radically more comfortable with myself. There are still things that bother me and things I feel aggrieved about, but I rarely do I think about who’s right and who’s wrong anymore. There’s simply nothing to gain by it.

I owe every thing good that’s happened to me since I graduated from college to this change in thinking. It’s empowered me to become a leader and made me much more comfortable in my own skin than I was just a few years ago.

Being “right” is a war of attrition waged by the weak against the strong; it’s designed to systemically give weaker people leverage over others by gradually instilling doubt and undermining moral authority.

Comfortable, strong people will recognize this behavior for exactly what it is: whimpering and squeaking from small people who feel like shit about themselves.

When you stop needing to play the “who’s right and who’s wrong” game, every encounter you have with a “right”-minded person makes you think “there’s a piece of work; probably not going anywhere fast.”

You can choose to be right or be effective. Being right is always the wrong choice.

If you enjoyed this post, make sure you subscribe to my RSS feed!



Instant File Server: turn any directory into a webserver with a simple command

August 14, 2013 03:46 by Aaronontheweb in Node, Open Source // Tags: // Comments (4)

Our engineering team has been neck-deep in configuration hell lately. Editing 2000-line Solr configuration files, trying to get Apache Oozie integrated into DataStax Enterprise, Cassandra 1.2 upgrades, and more – and the one thing in common with all of these tasks is the prevalence of enormous XML configuration files.

Having wasted countless hours trying to use tools like SCP and various Sublime Text plugins to try to edit (or hell, even view) the configuration files on our dozens of Linux machines, I finally had a “fuck this shit” moment this week and wrote instant-fileserver, a stand-alone file server that you can start using a single command on any directory on any operating system.

instant-fileserver (ifs) allows you to:

  • expose the contents of any file system via HTTP;
  • view individual files as well as directory listings;
  • create, read, update, or delete any file using ifs’ dead-simple RESTful API;
  • create multiple ifs instances using a simple command; and
  • safely edit any file from the comfort of your Windows / OS X machine and push the results back onto your Linux servers once you’re finished.
    Here’s an example usage:
$ npm install -g ifs
$ (ifs is added to your PATH; go anywhere on your system)
$ ifs -help
$ ifs [arguments...]
... starting ifs on 0.0.0.0:1337
    Here’s a quick demo video to show you how easy ifs is compared to the alternative
Using Instant File Server (IFS) – Video Demo
      If you hate having to move heaven and earth to do something as mundane as edit a damn file, IFS is the werewolf-destroying silver bullet you desperately need.
      ifs is built using Node.JS and it has a tremendously slim codebase, so anyone can edit it or extend it if they wish. ifs is licensed under the MIT permissive license.

    Fork the ifs source code on Github – we accept pull requests!

    If you enjoyed this post, make sure you subscribe to my RSS feed!



    Cassandra Summit Talk: Real Time Analytics with Cassandra, Hive, and Solr

    July 18, 2013 04:41 by Aaronontheweb in Cassandra, Hadoop // Tags: , , , // Comments (0)

    I spoke at the Cassandra Summit this year about how we use Cassandra, Hive, and Solr in production at MarkedUp Analytics.

    Planet Cassandra recently made all of the videos and slides available and I thought I would share. Enjoy!

    Slides:

    If you enjoyed this post, make sure you subscribe to my RSS feed!



    Brush the Dust Away

    July 15, 2013 04:27 by Aaronontheweb in General // Tags: , // Comments (0)

    This post is about stress.

    It's been nearly a year since I started MarkedUp Analytics, and we've come a long way - I've raised money, won the business of some amazing customers, built the nucleus of a really talented team, and developed a product that people rave about. At the previous //BUILD conference, no one had ever heard of us - this time our logo was shown onstage during a keynote. Feels like progress; none of it was easy.

    I took my first vacation in two years last week and had a chance to put some distance between myself and MarkedUp for the first time since inception, and I thought a lot about some of the assumptions I had about starting a company when I was just getting started, in particular this section from "The Seven Unproductive Habits of Startup Founders:"

    7. Sacrificing nearly all social, physical, and personal needs in the name of “getting it done”

    You can push yourself to a large volume of work over a short period of time – you can cram 80 hours into a work week if you can try. But you can’t do it forever.

    You know what a successful entrepreneur needs?

    They need to work out and get sleep so they can maintain their stamina and energy level. They need to go out with friends and blow off steam. They need to go out on dates. They need “me” time to collect themselves.

    Creating a balanced life takes discipline – I dropped the ball on this epically at Microsoft. I starting changing my behavior before I left Microsoft and it’s made me more effective and productive.

    Counter point: I've put three inches on my waistline since we went live with customers on September 29th, 2012. I stopped working out within a week of our product launch and burned the candle from both ends often since. It's been nearly 300 days since I last synced my Fitbit. My diet consists largely of whatever-I-can-get-in-5-minutes choices, which doesn't correspond well with healthy ones.

    Why did I not heed my own advice?

    Adding customers as stakeholders to your product produces an immediate and intense set of external pressures on your company. The timelines for delivering everything increase by an order of magnitude and the pressure can be so tremendous that it can crush some employees and founders like empty beer cans. Add investors and a fixed amount of operating capital to the mix and it intensifies the pressure and the timelines by another order of magnitude. Even if you don't panic, you have to move and act like you are.

    The immediacy of it all never goes away; it's there waiting for you when you get home; when you sleep; when you're in the shower; when you're out with your friends; when you're in the car; when you're with your family; when you're alone. You are damned by the contents of your inbox; the social media mentions; the Github issues list; the sales inquiries; the status updates from your teammates; the error rate alerts from your monitoring systems; the bid alerts from AdWords; the investor email updates; accounts payable; quarterly taxes; insurance; rent; lawyers; accountants; interviewees; PR; fuck. Your life quickly becomes a list of things you failed to do when you intended to do them.

    You can never distance yourself from the pressure; there's no one to cover for you. You are haunted. You are cursed. And if you don't stop running as hard as you can to keep up, your company dies, your hopes and confidence with it.

    At least, that's how it's felt for the past 8 months.

    Your salvation is in accepting that you can never do all of the things and everything always takes longer than you anticipate. In your role as a highly accountable person you have to give yourself permission to leave things in an incomplete state each and every day. The stress you experience throughout your life is an unconscious choice to self-flagellate and self-punish. It may feel real, but isn't.

    You will always harbor doubts; you will always have deadlines; you will always have some negative outcomes; you will have disappointments; and you will always have the ability to choose your priorities and act accordingly.

    The inflection point for me was when I spoke onstage at a conference recently and saw just how large I looked in the recording, like one of those retired NFL linebackers who forgot to change his dietary habits after leaving the football behind.

    So I wage a campaign against demons of my own making in order to reclaim my time and life. I will not judge myself or my company so harshly. I will not deny myself a glass of red wine with my girlfriend because we have a deadline. And I will get my ass back in the gym, even if it means coming into the office later each morning. I will not beat myself up over unread emails in my inbox, because there's no value in it.

    Your accountabilities will always be there for you; what's left of your life and youth will not.

    You'll have a list of things to do that is temporally impossible to satisfy; accept it and don't let it slowly strangle the other parts of your life like weeds.

    Give yourself permission to go home with a full to-do list each day. Give yourself the permission to enjoy the things that matter to you but don't cross anything off the list. Get used to having people bitch at you for not responding to their emails ("my free time belongs to my kids," as one of my investors put it.) Who cares? Those feelings of guilt and shame are an illusion. Keep your priorities organized, your head clear, and your chin up.

    If you enjoyed this post, make sure you subscribe to my RSS feed!



    What Do You Need to Become an Elite Developer?

    MarkedUp Analytics’s customers are developers and so are most of the people who work at the company, so I spend a lot of time thinking about and refining my answers to the following two questions:

    • What are the lowest common denominator skills and programming knowledge that my customers have?
    • What are the lowest common denominator skills and traits that the developers on my team need to have in order to best serve our customers?
      As I’ve been exposed to more customers and as I’ve turned over members of our team1 I’ve started refining my answers to these questions.
      Turns out that most of our customers are fairly sophisticated and thus I expect the developers on our team to be one step ahead of them.

    I’m sure every company says this, but in our case it’s true: we need elite developers in order to solve our customer’s problems.

    MarkedUp builds distributed systems that integrate into native third-party applications, written by our customers, on multiple platforms and use machine learning to create insights in as short a timeframe as possible, a task that’s many orders of magnitude more challenging than your average iPhone or web application.

    There are companies like DataStax or Liquid Robotics that have to deal with radically harder problems than ours, and I’m amazed by their ability to attract really great engineering talent. So this problem is solvable, but how do I identify elite developers who are going to be able to contribute to the business and tackle these challenges?

    I’m still figuring it out, and I’ve made some big mistakes along the way thus far. But I’ve had some successes in attracting great engineering talent to our company too. Here’s my opinion on what makes a software developer elite (your mileage may vary!)

    Traits

    An elite developer is determined more by their character, attitude, intellect, and diligence more than anything else. Knowing any specific framework, programming language, design pattern, development platform, and so forth isn’t nearly as relevant.

    So what character traits does an elite developer have?

    Humility – the best developers I’ve worked with know that they are talented but don’t know just how good they are relative to their peers. Even if they did know, it wouldn’t change their attitude. They do the best job that they can and do it knowing that their work isn’t perfect; contains bugs; might not completely meet the spec; and might be changed in the future.

    Able to accept criticism – part and parcel with humility is the ability to accept criticism, whether it comes from a peer, a customer, a manager, or anyone else. Whenever you do anything of consequence you should expect criticism from some corner of the universe. Elite developers not only accept it, but they listen to it and try to distill actionable insights if possible.

    Doesn’t let good be the enemy of perfect – a lot of talented developers struggle with perfectionism, myself included; over time the great ones learn to live with impurities and get software deployed to production while the perfectionists piss time away on remote edge cases and other activities with no economic value.

    Inquisitive – some of our interview questions at MarkedUp are live-coding exercises, and here’s a little secret: we really don’t care very much about the quality of the code produced by a candidate during an interview.

    But we care a lot about the questions a candidate asks about the programming challenge.

    If a candidate starts coding right away without asking us any questions about the scope of the challenge or the technical details, it’s usually an instant fail. Inquisitive developers do a much better job of learning how their code fits inside a larger system and learning about the real-world use cases for it.

    Independent learners – the developers who’ve delivered the most value for me are ones who constantly want to learn and improve their skill set; they ask if they can pair-program with me while I work on our API or on the SDK; independently review some of our code and create JIRA issues for me when they find bugs with my own code (!); they buy O’Reilly books on some of the technologies we use, like Hive and Hadoop, and read them over lunch; and they ask if they can leave work early to attend a tech talk or even give one themselves (!).

    Everyone needs help along the way, but the truly great developers are the ones who learn for the sake of learning and the satisfaction of self-improvement. It’s humbling to work with this type of developer, because typically they get other members of the team excited about learning too and turn this into a group activity.

    Able to break down large projects into small tasks – people don’t launch rockets or build massive systems by setting out to do everything all at once; they break down massive projects into smaller milestones and small, fine-grained tasks. Really strong developers have the ability to visualize the end in mind and the steps for getting there. It’s an essential skill for an architect of any sort.

    Able to visualize relationships between abstractions – part and parcel with the previous point, really great developers have the ability to visualize relationships between abstractions in the systems they work with and build. This can be as simple as being able to see how services interact with each-other in the course of fulfilling an end-user’s request or how classes should be composed inside any given system. This allows a developer to work on a small part of a really large system and understand how their work will integrate with components that aren’t finished or haven’t been started yet.

    Embraces challenges – great developers can operate outside their comfort zone, even if it means failing initially. Challenges are viewed as an opportunity to learn and improve, not as a threat to appearance and performance.

    Focuses on immediate results – sticking with the previous analogy about launching rockets, great developers break up their work into small deliverables and ship small pieces immediately and frequently into a development branch. They don’t hoard commits or wait until “it’s done.” They ship small deliverables often.

    Behaviors

    The traits above are the most important ingredients of a great developer, but there are learned and acquired behaviors that every developer must develop before they can become elite.

    Unconsciously, religiously commits everything source control – the greatest sin you can commit as a developer is failing to put something into source control for you deploy it. Most companies try to automate deployment in such a way that it’s impossible for deployment to occur without source control involvement, but this isn’t always feasible. Little things like shell scripts, SQL queries, configuration files, and others often fall between the cracks since they aren’t considered part of “the app.”

    However, a great developer is religious in their use of source control – anything that gets used in the course of regular business, even a one-off business intelligence script, finds its way into source control when an elite developer is behind the wheel. They rack up pull requests and HipChat spam with religious fervor, because they live in perpetual fear of being the stupid asshole who forced someone else to reverse-engineer a critical backup / restore script during an emergency.

    They master their source control system, make liberal use of feature branches and version tags, and clean up after themselves once a feature goes into production. Source control is as natural to them as breathing.

    Writes README files, comments, and docs even for internal tools – I tell every developer this when they start at MarkedUp “your code will be a part of this organization longer than you will.” The point of that is that people change careers, companies, and jobs frequently – so when we write a piece of code that does something important, we need to make it possible for someone else to use and modify it without us present to answer questions.

    Great developers recognize this and make it easy for other developers to leverage their work, during and after their time on the job.

    Embraces bug tracking and agile processes – organizing your work is just as important as performing it, and bug tracking / agile tools like Pivotal Tracker and JIRA enable teams to prioritize and distribute workloads across large projects.

    But more importantly, they allow PMs and peers to see what work has been completed / performed without having to hold numerous meetings or calls. Bug tracking, pull requests, and agile boards are communication tools – and great developers embrace them for efficacy in measuring, quantifying, and communicating progress.

    Masters debugging, tracing, and monitoring methods – just because the code is in production doesn’t mean it’s finished. Great developers master the tools they use for debugging, logging, tracing, and monitoring apps that are in production or are about to be.

    In the .NET universe, this means mastering the Visual Studio debugger, Fiddler, IntelliTrace, the Windows Event Viewer, performance counters, and others. In the OSS world this might mean performance monitoring tools like Graphite and Nagios, or others.

    Great developers understand the necessity of these tools and master them, which enables them to respond more quickly to infrastructure failures and bugs.

    Communicates concisely and asks relevant questions – most developers are not social butterflies; like any STEM field, it’s often populated with introverted people who like to spend most of their working hours concentrating on issues at-hand.

    However, the elite developers are ones who recognize what needs and doesn’t need to be communicated – if there’s something contradictory in a customer spec, it needs to be raised with the stakeholder. If someone broke convention and used camel case instead of PASCAL, just go fix it and send the offender a note, not the entire team alias.

    Engages other developers on the team – programming is a team sport, and elite developers love working with other people whom they can help and who can help them. They ask for and solicit help when necessary.

    Programming Skills

    Now for the programming part – what skills does a programmer need to have before he or she can be considered elite? This is subjective and sometimes domain-specific, but there’s my take.

    Experience with multiple languages and platforms – diverse taste in tools is the greatest skill that a developer can have, because it keeps the developer on a position where they know how to learn new things if necessary (and it often is!)

    Being a one-trick pony and limiting yourself to a single platform will naturally limit your ability to grow and learn, so great developers try their hands at new things even if it’s just for fun.

    Understands language / framework implementations – the most powerful .NET developers I met prior to joining Microsoft all highly recommended that I read this book: CLR via C#. I did, and the content from this book was directly responsible for passing my technical interview at Microsoft. Above that, it’s changed the way I look at all of my .NET code.

    Understanding your how code is executed at the OS or hardware level can provide some huge benefits, especially if you’re doing a lot of work with concurrency or native programming. For instance, understanding how SQL Server’s row / table locking algorithms and its journaling system work allow you to design around potential performance bottlenecks in high-performance systems. Great developers learn these implementation details and leverage that knowledge to write more robust code.

    Writes code for patterns, not specific instances – it’s an intuitive skill that can’t really be learned, in my opinion. You either have it or you don’t. Really talented developers infer the patterns in a system, even before a module or a piece of code is written and they code for those patterns, rather than specific instances. This skill limits technical debt and results in a tighter, more usable codebase.

    Knows how to learn – this might seem obvious, but I’ll reiterate: there are a lot of developers who simply do not know how to learn something new. They can ape examples they’ve seen before and often need to be hand-held along the way, and they can’t truly internalize a new concept and form the muscle memory to code independently with new technologies.

    Great developers know their mind and know how to teach it something new – what works for one developer may not work for another, but nonetheless they all know how ot learn.

    Has experience with multiple types of software (native, distributed, web, etc…) – a great developer is a well-rounded developer; if your only experience doing software development is with simple CRUD applications, then you’re missing out on a lot of the corpus of modern software development. A great developer isn’t necessarily an adept professional in each domain area of programming – they might focus primarily on web development and dabble in native, but they take away new lessons from each experience and understand more about computing overall.

    Until I wrote the MarkedUp SDK, I never had any practical experience with advanced data structures in production like concurrent binary heaps and circular buffers; I likely would never have encountered those had I stuck to doing just ASP.NET MVC or Node.JS development all the time. Now that I have that experience, who knows – I might find some applications for those in a distributed program or a Web API application in the future.

    Experience with multiple types of development tools (IDEs, Text Editors, command line compilers, and more) – I have some bad news: if you’re an EMACS ONLY or VS2012 ONLY developer, you’re limiting yourself. Experience with multiple types of development tools is a good thing, because great developers recognize that improving your workflow habits over time is just as important as improving your programming knowledge and experience.

    The right tool for the job will often be different – Visual Studio, for instance, is a fantastic tool for when I’m debugging C# or C++ but I much prefer Google Chrome developer tools and Fiddler for debugging JavaScript.

    Some sysadmin / operational knowledge – writing the code is only the first step; deploying it or releasing it comes next. Great developers are not often expert system administrators also, but they know enough about their operating environment to avoid pitfalls and execute a basic deployment if necessary.

    Knowing how to run a build / release process, deploy a piece of server software to production, or how to configure a piece of COTS software like Apache or IIS to host a web application is critical to ensuring that the software actually meets its functional requirements. If you aren’t able to produce a development build of a native app using compiler flags, then you can’t very well participate in that part of the QA process, can you?

    The point is – great developers don’t wait for someone else to solve their problems; they can do enough sysadmin work to build and test on their local environment, and are self-aware enough to not proceed any further if they don’t know enough to run a live deployment.


    1developer turnover is a natural and expected byproduct of growth in a technology company, I’ve come to learn. Don’t let anyone tell you otherwise.

    If you enjoyed this post, make sure you subscribe to my RSS feed!



    Search

    About

    My name is Aaron, I'm an entrepreneur and a .NET developer who develops web, cloud, and mobile applications.

    I left Microsoft recently to start my own company, MarkedUp - we provide analytics for desktop developers, focusing initially on Windows 8 developers.

    You can find me on Twitter or on Github!

    Recent Comments

    Comment RSS

    Sign in