Tools

Freelance Developer Coach

TL;DR: I’ve launched a new company called Freelance Developer Coach (http://www.freelancedevelopercoach.com/) and we’re releasing our first product November 1st of this year.

The longer version is that I’ve done a lot of startup work over the years, but never something that was completely mine.  Last month I started designing a new company with what I considered to be an ideal business model.  I wanted something I could build and scale on my own where every piece would be automated so I could build once and sell thousands of times.  I knew that I wanted to create something which helps people and doesn’t steal time from their lives with no return in the real world (I’m looking at you Fortnite!).

I was fortunate enough to listen to a Tim Ferris podcast on a long drive where he mentioned some of his principles from The 4-Hour Workweek. One of his recommendations was to ask yourself, “What’s easy for you, but hard for others?”.  I immediately thought about hiring and managing freelance developers.  I’ve spent the last 6 years very focused on hiring and managing freelance developers for various companies and projects.  At first, I thought about creating something for hiring managers like me to manage this process.  Then it occurred to me that my greatest satisfaction came from coaching developers on the non-technical skills and habits which made them easier to work with – and more valuable.  After all, that’s what I’ve spent years writing about here.

After that drive, I returned home and sketched out the application and the business.  I had recently read Disciplined Entrepreneurship after a hearing it mentioned by a guy I really respect so I worked through the 24 steps and made sure I had answers for the 21 which applied to my idea (the other 3 are more for enterprise software).  That weekend I outlined a couple of ebooks related to the idea, set up some landing pages, and ran Google Ads.  My theory was that if people are interested in the ebook, then they’ll probably be interested in the software.  More importantly, if they aren’t interested in the ebook then I need to rethink the messaging, the market, or both.  So I launched my ads late Saturday evening to see what I could find.

I woke up Sunday to leads –  hundreds of people had clicked through my ad and dozens had provided their email address to get the ebook.

At that point, I knew that I could reach my market with a message they were interested in.  Since that was the critical first step, I started planning out the rest and after I completed the financial model I was pretty sure that I was on to something.  So now I’m back on familiar ground: building mode.  The first release is planned for November 1st, with follow-on releases every 30 – 60 days after that as long as the market continues to indicate interest.

I’ll post updates here at Big Swinging Developer, but there probably won’t be anything until after launch – focus and execution are top priorities until then.

Reflector Recap (with Lessons Learned)

If you're unfamiliar with Reflector and its history, you can catch up in under a minute with the bulleted list in my previous post.  Since the announcement, I've read every tweet that had "redgate" in it.  I read the Red-Gate forum posts.  I read the links that are in the tweets and the forum posts.  And, I read all of the 132 comments that I received after offering to buy 10 licenses at $35 per (which Red-Gate then matched with 100 more and bumped them up to the $95 Pro version).

As I mentioned in the previous post, there is a lot of information surrounding this event that is valuable to any entrepreneur, executive, marketing person, or product manager.  Here are some of the lessons that I've learned from the experience:

Free Is Unlike Any Other Price

I had read that "free" is a unique price in Predictably Irrational by Dan Ariely, but there's a big difference between reading about it in a book and watching people freak out over it.  Almost all of the negative posts that I read centered around "Red-Gate said it would stay free and now it's not".  I'm guessing that there wouldn't be as much noise if the situation had been "Red-Gate said that it would stay affordable and now it's a little less so" . . . it just doesn't have the same punch, does it?  To be clear, I understand that "free" does have some unique properties: zero risk, zero acquisition friction, etc. and I'm not suggesting that people shouldn't feel they way they feel.  The lesson learned here is that "free" needs to be treated differently and that it's risky to price anything as free that can't stay that way.

All Information Gaps Will Be Filled

If you've read most of what's been written about this event, you'll notice 2 things about the information:

  1. It's incomplete.
  2. People will fill in the gaps with their own beliefs.

I read everything from "since Lutz got paid" and "Lutz may not have done the deal if it wasn't going to remain free" to "Reflector should go back to being open source" and  "Red-Gate installed a timebomb in it".  To the best of my knowledge, the details of the deal were never made public.  That means that unless you're Red-Gate or Lutz, you don't know the details.  As for the open sourceness and timebomb: Plenty of people have pointed out that it was never open source and the timebomb had been there for years before Red-Gate acquired it.  The lesson learned here is that any information gap will be filled by someone, at some point and that you might want to consider a defensive move of laying out relevant facts when it's time to announce an unpopular decision.

Non-Physical Products Are Different

People have a different view of non-physical products compared to physical products.  If you buy milk from the store, you don't expect it to last forever.  You know that it's an exhaustible resource that disappears as you use it.  As a physical object, it can't be 2 places at the same time.  Non-physical products have non of these limitations.  Because of this, limitations built into a non-physical product are often seen as taking something away from the end user.  DRM for music, games, and movies is a good example since it so clearly takes away capabilities from the non-physical product.  People hate DRM for a variety of reasons, but one of the most common is that it makes the non-physical product behave in unexpected ways.  All of a sudden you can't listen, play, or watch – not because your network connection went down but because someone made the media require a continuous connection.  That was a limitation that was consciously built into the product.  The timebomb in Reflector is similar.  Except for trial software, most people don't expect software to expire.  When the expiration comes, it's not only unexpected but it's clear that it was put there consciously which can lead to feelings of "you did this to me".  The lesson learned here is that if you're going to do something unexpected, make sure people are aware of it and consent to it in order to avoid an emotional response down the road.  As a point of clarity, "aware" means that they actually know what's going on which means it can't be buried in a EULA.

Developers Are Even Differenter

I lumped music, games, and movies together above when talking about non-physical products because they all have a similarity that separates them from software: most consumers can't create their equivalent.  Once you get into the realm of software, then things get a little stickier . . . all of a sudden you're talking about things that could be created by the end user, although it's often impractical for them to do so.  If you narrow things down to "developer utilities" then you're on really thin ice.  You are actually targeting a market segment that is often qualified to create the thing you're selling them.  Most of the time they'll be very rational about purchasing tools: "This will make me better.  It would take longer to create this myself then the price divided by my salary/rate.  I should buy this."  If something happens to suppress the rationality (like messing with "free"), then they can quickly go into "I don't care what it takes, I'll build it myself!" mode.  The lesson I learned is that when targeting developers as a market, it's important to avoid doing anything that might flip the rationality switch.

Conclusion

To cause the reaction we saw over the last two weeks, it's safe to say that Red-Gate made a mistake.  What's not clear is exactly where the mistake was made and what should have been done differently.  It's not clear because we don't have all of the information.  Don't let this opportunity go to waste, though.  There are some folks who paid steep tuition for the lessons that you can learn from this experience.

Think .NET Reflector Is No Longer Free? You Might Be Wrong…

There's been A LOT of discussion about Red-Gate's decision to start charging for .NET Reflector.  For those of you tuning in, here's a really compressed history:

  • Lutz Roeder created .NET Reflector many years ago (full history: http://en.wikipedia.org/wiki/.NET_Reflector)
  • I venture to guess that the majority of professional .NET developers use the tool.
  • Red-Gate bought Reflector in 2008 (I remember because I saw Neil Davidson at the Business of Software Conference in Boston and asked him about it).
  • Reflector has been free, or had a free version available for its life thusfar.
  • Red-Gate announced yesterday that they'd start charging for Reflector in March with no free version available (as far as I can tell).  The price that replaces "free": $35.
  • Lots of people are going apeshit about a tool that used to be free no longer being free.

That brings us up to speed.  For some fascinating reading, check out the Red-Gate Reflector Forum.  I'm being serious here.  It isn't often that you get to see so many diverse thoughts, opinions, and expressions of outrage in one place.  ANY marketing person, product manager, executive, or entrepreneur would be wise to read the forum posts and comments for a mixture of warnings, lessons, and insight into the community/customer mind.

For my part, I don't have a strong opinion about whether Red-Gate is right or wrong on this matter and that's actually not what this post is about.  This post (like many other posts) is about behavior and action.  While I can't make Reflector free for everyone, I figure I can make it free for 10 people.  I've made enough money doing development work and consulting while using Reflector that $350 seems like a reasonable price for me to pay.  At the same time, I know that there are lots of folks out there doing good work that can't pay $35.

Post a comment about why you want a copy of Reflector by Sunday, Februrary 6th.  I'll pick 10 and buy each a $35 license of Reflector 7 upon its release.

If Red-Gate (or anyone else) should decide to match the offer, then the freebies go up from there.

UPDATE: Just got off the phone with Red-Gate and they've offered to match with 50 licenses (I'm still paying for the first 10 so I now have a total of 60 to give away).  As such, I'm extending the deadline through Friday, February 11th.

FINAL UPDATE: I was pleasantly surprised when Red Gate initially offered the additional 50 licenses, but I was blown away when I talked to them again and they offered another 50 for a total of 100.  Not only that, but they said that rather than wait for V7 to be released that they are going to be giving Reflector Pro licenses (the $95 one), which will convert to the Reflector VS license when version 7 is released!   I'll be emailing the folks who get a license on Saturday 2/12 and Sunday 2/13.  Licenses should arrive on Monday 2/14 or Tuesday 2/15. Thanks to everyone who commented!  BTW, if you missed the cutoff I see that Dan Maharry is giving away Reflector 7 licenses on his blog.

Brownfield Development: How To Peel The Onion Without The Tears

In the Spring of 2008, I decided to become a brownfield development specialist.  Greenfield development is when you're starting a project from scratch and get to design everything with only minimal constraints.  Brownfield development is the opposite of that: it's when a project is n months into development and most of the constraints have been cast in stone.  My guess is that if you were to ask every developer you know whether they'd prefer to work on a greenfield project or a brownfield project that they'd all say greenfield.  Heck, I'd bet that a quarter of them would laugh so hard that Red Bull shot out of their nose just at being asked the question.  Therein lies one of the secrets of becoming a Big Swinging Developer:

You can make money being good at things that other people hate to do.  A lot of money.

When people hate to do something, they don't do it very much.  Since they don't do much of it, they never get particularly good at it.  This makes it harder for them to do it and the cycle starts all over again.  Some common values of "it" for development include: writing tests, documentation, and creating installers.  You can safely add brownfield development to the list since a job description of "Support the big ball of mess that runs our business while adding features and fixing bugs" doesn't usually have folks banging down your door. Throw in the fact that you'll have no relevant documentation and few, if any, tests to guide your way and you can picture weeks of pestering your co-workers with questions just to get to the point where you can fix a simple defect.

But what if brownfield was easy for you? What if, rather than pestering your co-workers with basic questions, you could understand what the code was doing and then ask why it was doing things that way rather than asking what it actually does?  That's what my secret weapon, Visustin, gives you.  You paste in your source code and it'll generate a flowchart for you:

Visustin-fullshot

It supports 31 languages including the popular .NET, open source, and SQL variants.  I spent last week throwing hundreds of lines of Python into the tool and tracing through an incredibly complex financial trading system to learn how portfolio valuation is calculated.  I was able to correctly describe the process to my team lead, including a couple gotchas buried in the code even though I don't know Python.  Since I know how the system works, though, I can find the path the code will take and identify where problems are likely to occur while coming up to speed on the language at night.

If you're a developer, I'd highly recommend Visustin.  It's great for code reviews, documentation, and for diving into existing systems.  Developer or not, look around your industry and find the important things that no one wants to do because there's a real opportunity there.  You can become better (or more tolerant) than anyone else simply by identifying the key aspects to the unpleasantness and solving that problem first.