The Big Questions

Steve Blank describes a startup as:

a temporary organization in search of a scalable, repeatable, profitable business model

This is the Big Question of any gathering of geeks in some semblance of a business.  They're assembling a product to see if it'll even work - and it seems like it takes forever to start getting that question answered.  It's vastly important to start getting external answers to that question early.

There's a lot more questions than the Big One.  Some are subsets (Will customers want feature X or Y?), others are external to the specifics of running a business.  We've stumbled onto quite a few questions, some even bigger than Steve's.  Some that have crossed our minds:

Can two guys in a technically-conservative city in a technically-conservative college create a startup, one of the most liberal tech things out there?
Is it even possible for first-timers to learn all the intricate parts of a startup and still succeed at some level?
Will we be able to take on an entrenched bureaucratic system that's resistant to change?

Yikes.  I could spend all day worrying about one facet of one of those questions.  Sometimes I catch myself falling into this trap (what happens if this was all a really stupid idea?)  Downward-spiraling negativity can be deadly to my productivity.  There's a counter to this - reading inspiring books/articles that push me onward to build.

It's also important to acknowledge these questions and try an answer them.  The whole startup process is designed to tackle Steve's question above, but there's other questions, most notably, "where are the facts?"  The key to remember is that there are no facts in the building.  As such, I went to interview two people in key positions in our target market.  I'm glad I did.  Turns out there were fundamental assumptions that we got wrong and it's time for discussion and pivot.

How can I do better?

I had a pretty rough/busy weekend and wasn't able to hammer out anything acceptable last night, so I'm turning the tables.  Recently, I got my 10,000th hit on Recoding.  Awesome.  Still, I'd like to improve.  Steve Blank is fond of saying that there aren't any facts inside the building.  So, in the startup spirit, I'd like to ask you guys some questions (you can answer here or in the HN comments, I'll be watching both):

-What are your favorite types of articles?  Is there anything interesting you'd like to see me write about?

-What sort of thing are you likely to comment on?  One of my big goals is to inspire life in the comments section.

-Overall, how can I do better?

What's taking you so long?

As I've alluded to earlier, a friend and I are working on building an MVP for a startup.  Awesome.  We've got the idea, have key connections in the industry, little competition, and are ready to tear into some code.  I had hoped to have the MVP finished by Jan 14th. so I could write about it here and we could start generating hype.  No dice.  We reset our due date to Jan 31st and hacked all weekend.  We got a LOT done, but looked at our to-do list and realized that it had grown.

Obviously, startups are not a walk in the park, even when life's handed you some great opportunities.  We seem to have fallen for the idea that code is trivial.  Technically speaking, the core of the product was implemented in November.  Since then, all we've done is build up awesome things around it (and school, both of us being full-time students).  We've learned a lot in the past few months.  Here's just some of the things we've encountered:

Stuff creep

This isn't scope creep, as the scope has stayed pretty much the same.  Rather, we find ourselves adding page after page to our todo list of things we never thought of that are must-haves (For instance, a user should be able to reset their password).  It's very important to know what done is.  Sadly, one can't determine everything at the beginning of a project, especially if this is the first time.  We've had some issues with figuring out what we should do next.  We're using Trello (an awesome site) to organize everything (have I mentioned it's drastically important to have a todo list?).  Despite the amount of planning we have put into this, there are still things that we completely missed out on.

Technical difficulties

We're building this with Node.js for two reasons:

• We only have to work with one language from start to finish (very helpful for first timers)
• Node.js is just plain awesome.

Still, various frameworks and asynchronous idiosyncrasies pop up and bog us down as we learn new things or fight back bugs.  It's very easy to assume that everything will work just fine the first time you write it, and schedule for that.  Make sure to allocate time for learning and fixing (most likely, you'll be doing more of those two than anything).

People difficulties

I'm an idiot.  We all are.  I'm sure even the best developers have confessions about how they've managed to shove some code through a trash compactor.  It's ok.  We all suck.  It'll slow you down but that's part of life.  Remember to take a break and eat healthy.

Regardless of above, we're not only still working on our MVP, we're accelerating!  Stay tuned for more updates.  Our latest due date is either March 1 or February 22, depending on who you ask.

What you shouldn't do as a boss: Complaints from the trenches

Today's post is adapted from a talk I gave to managers in training.  Even if you're not a manager, I hope that you too can pick up basic principles and help implement them in your organization.  If you're interested in hosting me for a talk, you can find me via email or @RecodingBlog.

My first job was with a small IT-turned-web-development company that accidentally developed a software division.  Most of the people there were playing at their jobs, using congratulatory back-patting to reinforce the idea of how "great" they were, instead of acknowledging weak points and moving to reinforce them.

They had an excellent market position but were slowly losing it thanks to the above reasons.  There's a life lesson here: If you are not pushing you and your team to excel, someone else will and you'll find that your customers don't have nearly as much loyalty as you thought they did.

Management has the biggest impact on the velocity of a team, software or not.  Here are five simple "don'ts" that can have a huge impact on team productivity:

Don't ignore workers

There was a very flat management structure at my old job.  Virtually all of the ~20 people reported directly to the CEO.  This made it very difficult to find direction.  While flat management styles seem to be all the rage nowadays, the studies show that managers should have no more than 8 people reporting to them or else chaos will ensue.  Even if you've got less than eight people reporting to you, make sure that you stay in contact.  I strongly recommend a weekly one-on-one meeting just to check up.  An employee that feels that they are heard is happy.

Don't demand perfection

Scope creep is a very real danger to any software project.  Yes, there are many cool features that your product can have, but there's a limited time.  In most industries, you're racing against your competitors.  The (unwritten) spec of my project was subject to the whim of the CEO and all changes must be implemented before we release 1.0.  The project has been going on for over 1.5 years and still is in development

"If you are not embarrassed by the first version of your product, you’ve launched too late." -Reid Hoffman, Founder, LinkedIn

Don't keep information away

We woke up one infamous morning to discover that the CEO had announced that we'd be developing a mobile version of our product.  Now, he announced it to our customers, and us employees were CC'd in.  Ouch.  How "the boss" communicates with employees says a lot about their attitude toward them.  Instead of CCing, become an information conduit.  Remember those one-on-one meetings?  Use them to bring relevant information.  Make sure you don't assume that an employee doesn't want to know something.  Asking only takes ten seconds.

Don't make status reports anything significant

I once got three requests for project status on the same day.  I don't know what management expected to change over my lunch break.  Status reports only slow progress, as the employee has to put time aside to write the reports.  Instead, use that one-on-one meeting (aren't these handy?) to find out what's going on.  Need more information?  Chances are, your team is generating a lot of data through commits, bug trackers and other useful tech.

Finally, don't let bored people quit.

The tech world brings about an incredible amount of mobility.  It has become incredibly important to nurture professionals.  I don't mean pampering them, but rather ensuring that they have the ability to gain new skills.  I've moved on from my first job and settled into a place using cutting-edge technology developing a product that's never been made before.  Needless to say, it's much more exciting.  An important, but oft-overlooked point here is to respect free/learning time.  It's very easy to override this as it doesn't produce anything short-term.

Being Programmers

Today's post comes from Ryan Kinal and touches on something very important to us here at Recoding: people who can't program.  Unfortunately, we have met the enemy and he is us.

A common source of frustration in the web development community is programming done by non-programmers. There is plenty of code out there written by people who have little understanding of data structures, efficiency, and architecture, and that can be frustrating to those of us who have some training in those areas. When we're hired to work with this kind of system, we wonder how the hell it could have gotten to be like that.

Why on earth would someone store all that data in plain text? Why is the login system a flat file? Why is this web service one gigantic file? Why is everything so tightly coupled? This is miserable!

The cause is, often, that the people designing and building the system just didn't have the knowledge necessary to do it well. Maybe databases were foreign to them. Perhaps they had never heard of an event-based architecture, SOLID and DRY, or even taken a class in Object Oriented Programming (or whichever programming paradigm you prefer). And even if there is knowledge of these concepts, perhaps the implementation of them is confusing or not intuitive in the current environment.

It is easy to look at this from a perspective of knowledge and experience, and say "Those people are not programmers." After all, these are fundamental concepts - essential to writing good code - and they have never even heard of them. I'll be the first to admit to thinking these kinds of things.
But here's the truth: If this kind of knowledge is essential to being a programmer, then none of us are programmers.

If we, as developers, are doing our jobs correctly and passionately, then we will always be learning. Just as Ryan from today looks back two years (or one year, or six months), and sees serious flaws in fundamental areas of architecture, design, elegance, and efficiency, Ryan two years from now will likely look at what I write today and think largely the same things. It's inevitable.

So, when you next encounter a bad piece of code, keep that in mind. Yes, it's frustrating, and I don't blame you for being frustrated. But keep in mind that it could have been a younger you writing that code, on a step to wherever you happen to be now. I would be unlikely to berate my former self, for fear of scaring myself away from the profession I sincerely enjoy.

Do the same for others.

About me

My name is Ryan, and I enjoy learning. I also enjoy teaching, though I don't think I could teach professionally. Like many others, I find that teaching promotes learning. Writing a blog post, such as my previous Object Oriented JavaScript posts, I have to think critically about the subject matter. I have to clarify it for myself before I clarify it for others, and that forces me to learn. I end up with a better understanding of the subject matter.

I've been interested in the web for a long time. I've written JavaScript for a long time, and can honestly say it is my favorite language (and I will likely write more on that subject over at Blogascript). I consider myself lucky that I have found a profession that allows me to be creative and expressive, allows me to truly own what I create, has such a great culture of teaching and learning behind it, and is considered monetarily valuable.

I'm one of three full-time web developers at McKissock Education, where I work with great people to provide professional education to those who need it. It's also where I met my partner in SlickText Text Message Marketing, my fairly-young startup.

When you have nothing to do

We're in the thick of our second weekend trying to bang out an MVP to launch our first startup.  It's harder than it seems (already).  There are tons of stuff they never taught us in class (proper password resets, for starters) that we've got to learn.  Node's modularity has helped immensely, having the ability to drop in a single module in to do a single thing is so useful.  I don't know how I developed without it.

Still, we can't slam a bunch of packages and Bootstrap together and call it a day.  We're building a quality product and there's still a lot of work to do.  Our problem is figuring out what work to do.  I'm sure those of you who could rattle off all sorts of nitty-gritty that needs to be done are laughing at us right now [0] but we're new and this is difficult.  Give us time.

I have found myself sitting down to get some more coding done and having no idea what I should do next.  Yes, we've built a to-do list.  We've had several mini-discussions where we determine what the next iteration will look like.  And yet, I find myself at a loss of things to do.

This is partially due to my resistance to lean into the pain and work on things I really don't want to do (writing a Terms of Service, repeating code just to add Yet Another Form).  I've had some success challenging myself to come up with inventive ways to refactor.  Some refactoring leads to security holes, but at least fixing those is interesting and we still end up with better code.

I alluded to our bigger problem earlier: We're first-timers.  There's a lot out there that can only be learned by doing.  One of those things is what to do.  I've found myself going to other sites that have features like ours just so I can see what features they've got.  It fills in a lot of holes in my knowledge.

Simply having something to do doesn't completely solve our problem.  Once we've got something, we're flooded with different ways to accomplish that task.  Most of the time there isn't a general "best practice" for everyone.  Instead, we're stuck with the ubiquitous "do what's best for you" mantra that almost never is followed by a discussion of the options and who they're best for.

We are stumbling in the darkness but at least we're stumbling toward something and that gives me hope.

[0] If you are one of those people, could you rattle off that list into a comment for me?

In defense of strong types

Anyone who knows my coding style probably thinks I'm going to completely contradict my title.  Nope.  I've found a new appreciation for strong checking [0], if only a little bit.  As it turns out, the additional security found in strong typing can be a cure for my least-favorite part of programming - those that absolutely shouldn't be programming at all but still managed to get higher-paying jobs than me.

Those in the strong typing camp claim that their method helps produce better programs, thanks to the additional compile-time testing.  This is absolutely true, and helped me find a handful of errors back when I wrote Java on a regular basis.  The trouble is, this extra security comes at the expense of language verbosity (ArrayList<String> stuff = new ArrayList<String>(); anyone?).  Being a liberal when it comes to programming, I prefer to have a concise language that allows for rapid prototyping and development.  This does create errors but not nearly as many as my CS Professor would predict.

Of course, this entire entry depends on strong typing being used exclusively as a sort of baseline test (My freshman mantra: "It compiles!  Ship submit it!").  It's not, I know.  Compiled, strong languages do have significant speed improvements over "lesser" languages like PHP (Others say that speed of language usually isn't nearly as important as speed of development).  However, strong typing does act as a rudimentary test.  Whenever a variable is declared, there's a "test" to ensure that it's correct, otherwise ERROR.

Liberals argue that this provides false security.  "How can we tell if the variable's value is correct, not just the type?  We need more tests!"  In either case, more tests are needed.  If you're building something significant, you need tests.  Liberal programmers are free to throw caution to the wind and depend on their own tests, claiming that the time lost to writing tests is made up by writing in a simpler language.  (I haven't found any studies to back this up, I'd love to hear it if you've got one).

So far, I agree with the hippie liberals.  It's much better to write your own tests to determine what's going wrong.  Who knows your code better: You, or a compiler?  Using strong typing for testing purposes also breaks separation of concerns, but that's a nitpick.

If you can't tell, I don't really like strong typing.  Oddly enough, I also don't like it when a program doesn't fail on what should be an error, but continues soldiering on with weird results.  (thank heaven for 'use strict';).  Back to where I was: People who get paid more than me to write terrible code.

It's a sad reality that there's a huge amount of terrible code out there.  A large portion of this code is glue between several plugins mashed together into a "website."  Scary.  However, strong typing (thanks to that very breaking of separation of concerns) forces basic testing onto whoever is using the plugin/API. The "programmer" (and I use that term loosely) must provide semi-correct data.

Of course, those who write glue code are looking for the easiest plugins to steal use.  Ones that force them to provide better code will be dumped by the wayside by both glue coders and higher quality coders with liberal leanings, so this is mostly a pipe dream.  (Conservative coders will already be working in a language with strong typing.)

So strong typing is bad because it forces you to write extra code that amounts to more tests that you'll have to rewrite anyway.

[0] In this case "strong typing" means that the language gives an error if a variable is of a type that wasn't expected.  This means that the programmer