Feature Image

I had a conversation recently with a few other area web developers about the current state of affairs in Nashville. Most of it centered around geeky stuff related to programming and the latest "new hotness" that was sure to generate a lot of excitement right up to the point when folks realized it was a solution in search of a problem. Out of the talk came a few things that I have been coming back to mentally revisit a lot lately.

Ship fast and often / fail fast and cheap

Both of those are cliche at this point, but it is also a great mindset to have. The best approach to a massive four-month project is to not do it. Instead, ask questions like "what can we ship in four weeks?" The priorities can change by the hour, so committing to less time to build and being faster to market always will win out over the cumbersome behemoth project. "The best way to build big web apps is to not build big web apps."

Perfect really is the enemy of good

This goes hand in hand with shipping faster, but this is the core of it. Everything in programming can be distilled into a series of compromises. Trade in a bit of performance to make it extensible. Gain back that performance at the expense of an extra layer. While I think there should be general guidelines for such things, accepting that there will always be room for improvement is also important.

Manage technical debt as if your job depends on it

Because it does. I heard this presented at a conference this summer and it really stuck with me. Every new line of code is another potential liability. Particularly for projects with many components and user types, adding extra features creates an inordinate amount of overhead for maintaining (and understanding) how everything works together. Not managing this "debt" effectively can paralyze the progress on a project.

Hire outside the box

Everyone has an idea of what their ideal coworker should be like, and developers are not an exception. The trouble is that it is easy to get into a rut of "just like us" in terms of skill-sets and preferences. The ribbing that everyone gives about your programming language(s) of choice should not be a deciding factor in making a hire. There is an idea that a "team of rivals", to borrow from Lincoln, is the most effective way to keep each member honest. Obviously the team still has to be a "team" in every sense of the word. Diversifying skills and basic demographics (particularly gender) on a team is a must.

Build it to prove it

An idea is great, but selling somebody on it is nearly impossible without being able to demonstrate it. That goes for everything from an entirely new product to changing the styling of a button. It is not lost time to spend creating something in order to prove its viability. You may even convince yourself not to do it in the first place, which is much better to do now rather than two weeks into a project that somebody else signed off on.

Don't quit your day job

The saying goes that you will not get rich working for somebody else. I take a different view. It is not that I lack an entrepreneurial spirit, it is that I dismiss most of those that claim to have it as simply unable to hold down "normal" jobs because their personality does not permit it. It seems as if the entire collective of entrepreneurs is a self-help group for the perennially unhireable. While new businesses are founded every day that grow into those same companies that "normal" people now work at 9 to 5, most do so with little fanfare and are far too busy focusing on the business to care. It is entirely possible, and even more likely, for somebody to make enough money and to be happy in their life without ever starting a business.

Recruiters aren't in it for you

I have already written about this topic before, but it bears repeating. My experience with tech recruiters is still less than stellar, and I do not expect that to change. With the current high demand for folks in the field, it is still best to go it alone rather than hoping for the best from a recruiter.

New team members succeed or fail largely based on cultural fit

While I hate "not a good cultural fit" as a reason to pass on an otherwise talented developer, it is true that you succeed or fail at a new job has less to do with what you commit to the code repositories and more to do with the willingness of others to help you learn. For the first few months, any new developer is effectively a "sunk cost"; mistakes will be made and time learning the system will not contribute towards actually completing anything. But what happens after that largely depends on whether he or she makes a personal connection with their new coworkers. A friend of mine strongly recommends hiring on a contract basis first.

---

The great thing about this field is that I learn something new just about every hour of every day. The best lessons are the ones that change my opinions, no matter how long I have held on to them.