So my first, 7 or 8 years out of college, I was…in every sense of the phrase, a “hard-core developer.” I had the geekie websites that I would visit. Websites that made could get away with Star Wars references that I never could here at Ever Evolving (even though i try…). And not just one geekie website mind you, I had a different one for each and every day of the week.
I was constantly on the prowl. Looking for new tips and tricks to optimize my development powers. I kept a notebook handy all the time, just in case that sudden stroke of genius hit me in the shower. I took on side projects to build up my resume. I had R&D programs going on that I’d dedicate at least 5-10 hours every week towards playing with new features or architectures.
And it paid off. By the time I was 27, I was running my own team. Working the largest, and highest profile projects that were coming into my office. Nobody questioned what I was doing. I mean, why would they? I was too busy doing great things. Life was great…
…well, except for when it wasn’t that was. The requirements of my professional life where bleeding into my personal life as our timelines to turn around new features were shrinking. Nevermind bug fixing or regression testing the old features. My social life began to tank because I was working too many hours while trying to go to school, and had replaced my fun weekend escapes of my early twenties with nights and weekends in the office or library (or both – heck I didn’t discriminate). All the while, I was not getting a dollar in overtime pay or bonus – so I was essentially doing this for someone else to make a buck…
And then it happened. I burned out. I finished my MBA, and said to hell with the developer lifestyle, I’m moving onto greener pastures. Fast forward five years, and I’m pushing hard into this Entrepreneur lifestyle. My work life is still probably taking too much of my time, but I’m back to being excited about what I’m building.
Still, those early days as a developer were invaluable in building the skills that are allowing me to thrive as an entrepreneur. I wanted to take a second to highlight three key lessons that I continue to take with me on this business building venture, that I once painstakingly learned in my days as an engineer…and one world altering one that I’ve learned since stepping away from the keyboard (metaphorically speaking of course)
Lesson #1: Build Small – Test Small. Especially Initially
One great lesson that all junior developers learn the hard way is to continuously compile and debug your program as you build. I remember, sitting in the sub-basement of my office building (because that’s where the developers lived) , and man was I MOTIVATED on this day. I was pumping out lines of code quicker than Donald Trump could offend a room full of women and minorities.
And then it happened. I had to test it. And the code blew up in such epic proportions, that it made the Hindenburg look like that sparkler that your crazy Uncle Nick brings to your parents 4th of July BBQ. I had no idea where to start debugging it. And line by line I had to tear down all that great code.
I may have cried a little that day. However, the lesson stuck. Build and test in small increments, verifying along the way, so you KNOW what does work, and what doesn’t.
To apply that to your business. Are you interested in moving your product into a new market? Of course you are. Bigger (read: more) overall market share will (read: should) increase overall profits (read: revenues). However, this strategy could also be disastrous if your product line isn’t ready in the eyes of the new market.
In his best-selling book Crossing the Chasm, Geoffrey Moore argues that one of the key factors in establishing a market is realizing that the people within that market all communicate with each other. Therefore, if you bring a product to a new market, and the early adopters chew it up and spit it out, you have done damage to both your company and brand that is irreparable. By looking for feedback from early adopters, and choosing a small niche market to establish your “beachhead” within the mainstream – Mr. Moore argues that your chances of adoption increase exponentially. Just like in developing code, small, steady, and incremental steps will pay larger dividends in the long run than making leaps and bounds before your product is proven.
Lesson #2: Instead of reinventing the wheel, leverage what others have done before you
Developers, as a group, are inherently lazy. And no, not in the “I don’t like my job” lazy or “I don’t want to implement that for you” lazy. In the lazy of, I don’t want to do the same thing twice. Sure, we will give rationale that makes sense. Like, reusing code will make it easier and cheaper to maintain in the future. And while that is technically accurate…having lived that lifestyle I can tell you that what it really comes down to, is laziness.
But, you know what, in some instances, laziness is good. I mean really, who wants to redo work that you’ve already spent brain cycles on before? And those brain cycles, who ever said that they even had to be spent by you? Why not leverage what smart people before you have done? After all, it worked out well for Sir Isaac Newton who famously stated that “if [he had] seen farther, it [was by] standing on the shoulders of giants.”
Listen, and I mean this in all sincerity. Don’t plagiarize. Don’t steal. But also, don’t go into something blind. When I have to market new products, I’m absolutely going to look at what competitors have done. Or I’m going to find a comparable business model to the one I want to implement and reuse what I can.
While there is always more than one way to skin a cat…there aren’t that many different ways. And when you are looking at broad brush strokes, most successful companies are using similar philosophies.
Take for instance, a book written by Verne Harnish called Scaling Up. In this book, Mr. Harnish recommends meeting with your team every day to discuss the issues that everyone is facing, and so impediments can flow up, and corporate direction can trickle down.
Now, if you work in a bi-coastal company, it may not be feasible to meet every day. But there are emails, software solutions, or other methods that would allow this information flow to take place. Instead of fumbling around internally, looking for a solution that will work, why not look to other successful bi-coastal corporations, and see how they have been able to successfully navigate these treacherous waters? Unless they are a direct competitor of yours, most companies, and by extension their employees, love talking about what has made them successful.
Lesson #3: Sometimes its best to walk away from the problem
Why is it that I’m never smarter, then when I’m in the shower? Or when I’m taking my pup for a walk through the park. Or after I’ve had my first beer on a Friday night? Whatever the reason, I learned quickly as a developer to keep a notebook handy to jot down ideas as they come to me about problems that had stifled me throughout the day.
Now, a lot of these epiphanies are a direct result of all of the trial and error that I had performed during the day; however, the “ahh haa” moments never come when I’m at my desk. And even as I have transitioned away from low-level development to higher-level thinking, nothing has changed. Moments of inspiration still strike at the most in-opportune times.
Granted, my epiphanies now deal with marketing or pricing, not how to code a method or class. And I write them down in Evernote, and/or create a task in Todoist, and not on pen and paper. But, I still capture the ideas quickly. And take down enough information so I can remember, not only the idea, but the context that helped produce the idea.
And I use Lesson 3 as a pivot point to my one world-altering idea. When you work as a programmer, you get caught up in bits and bytes. You get concerned about optimizing the code for run-time or maintainability or flexibility. You look at new stuff that comes out for easier ways of completing tasks more securely. But, perhaps ironically, it wasn’t until I walked away from the lab when my biggest, world altering idea, hit me like the coyote hitting the rocks chasing the roadrunner.
World Altering Idea #1: Nobody cares about your code.
In the world of customer sales and marketing pitches, no product has ever been sold based on how well documented the code was. Or how reusable it is. Or how maintainable it is. Potential customers care about two things: what functionality does it provide and how well crafted is my experience as a user.
Now, I’m not suggesting that you shouldn’t care about your code. Or that you shouldn’t attempt to optimize it during development time. Or that you shouldn’t pay attention to the reusablity of it. bThere is a concept that is starting to gain traction these days called “technical debt”…and it is very real. And it can very much wreck your product (or business) if you accrue too much of it to quickly.
However, what I am saying is that code doesn’t sell. And when you are a small business, looking for two dimes to scrape together to get by, you need to balance your horizon-gazing moments with the immediate need. When you are bringing a product to market, the concept The Lean Startup uses is Minimal Viable Product (MVP), until that MVP is out there, you aren’t even sure there is a market for the product. And why should you spend time optimizing code for a product that there potentially is no demand for?
As a producer of that code, that was a brutal lesson for me to learn. I was so involved with my own work that I was unable to see the forest from the trees. However, stepping away from the code, and realizing my place in the larger ecosystem has allowed me to see the benefit of pushing something before it is technically done.
Nobody cares about your code, because all they care about is what your code can do for them. And if there is one lesson that this recovering application developer has realized, it is that no business can survive without funding. And you can’t secure funding, by keeping functional capabilities tucked away in the lab.
You need to release soon. You need to release often. You need to measure your results. You need to pivot and you need to repeat. The sooner you release your current product, the sooner you can build something better. But, that better product, won’t have anything to do with how well your code is documented…