Today is my last day as an FTE. After four years as an employee, and five years as an on and off contractor, I’m moving on from 8z. Partially–it looks like I’ll be doing some contracting. 8z is a great company that I think will be fixing what is broken in real estate for the foreseeable future.
I learned a lot in my time. Here’s a top N list:
- Hiring is hard–I had the luxury of hiring a few employees and ICs, and it was a grind to find the right person. I don’t know if that was because my budget was tight (so I was really only looking at entry or junior level candidates) or the team was small (so I needed someone willing to wear at least three hats–ops, developer, QA) or my location (Boulder) or the fact that developers are in high demand, but it was a grind. However, when I did find the right person (and I think I had a pretty good batting average) it was great to see the team gel and people advance in their skills and careers.
- Budgets are fiction, but a necessary one. The planning required for a budget enforces rigor, but the actual spend almost always changed. Like Eisenhower said.
- Blogging is harder to do when you’re an employee. It’s just harder to find the time.
- Zapier is awesome.
- Managing while being an individual contributor is hard. In a small team (we were never more than four), I (and everyone else) wore many hats, including PM, tech lead, developer, QA, DBA and business analyst. From my reading–looking at you, Rands–some of the difficulty was intrinsic to management, not just management of a small team while wearing many hats.
- Having monthly one on ones with your direct reports is a bare minimum. If you aren’t having these meetings with your reports or your superior, start doing so. The open lines of communication will pay dividends long term by making sure you aren’t surprised.
- Using the database as a bus lets you have a number of smaller isolated more easily understandable software processes.
- Being a software developer in a small team at a real estate company made it hard to find peers around Boulder. I didn’t fit into the startup culture nor did I fit into the bigCo culture.
- Default to using innodb.
- Core values can actually matter. If the CEO makes a regular effort to help them live.
- You can ship a lot of software with a small team. But code rot will eventually bit you–here Jenkins and automated tests (junit, dbunit, qunit, phpunit, py.test, pentaho kettle testing, etc) are your friends. Jeff, thanks for pushing hudson!
- Gmail is an eminently usable web client.
- Having two equal co-founders is a tough row to hoe.
- Some people can tell the difference between Budweiser and Coors with their eyes closed.
- Google Apps is going to severely wound MS Office, and LibreOffice might do the rest.
- There is no substitute (none!) for asking the person who knows. Many times I’d be discussing requirements or a bug, and come up with a question. After batting it around a few times, the best course was always “well, let’s just ask XXX”, where XXX was the person who knew. The nice thing about a small company is that the right person to ask is usually obvious, and if the first person you ask isn’t the right person, they know who is. Don’t speculate–find out!
- MLSes … if you are in real estate software and you want listing data, and you do, be prepared to spend a significant amount of time understanding your local MLS compliance rules.
- Some of my biggest wins in the last four years were finding the right tech partner, not building the software from scratch.
- APIs make sense, even in the smallest company. Even if you are never going to expose them to the outside world for gain (and more so if you will). They enforce a rigor and provide interfaces for polyglot development. And you can be surprised where they’ll be useful.
- Java has a tremendous ecosystem. This includes third party jars (like this one for querying polygons), frameworks like spring, and tools like maven. I know lots of folks aren’t impressed with maven, but I found once you get your head around it, it can make your life easier. If there’s a build feature you want, maven already has it. Plus, dependency management kicks ass–I hope that npm learns more from maven than just avoiding XML.
- A small team working primarily in Java seems to be an anomaly in this day and age.
- Having a consistent tech stack vision is good–it leads to reuse and fewer operational issues.
- It is far more satisfying to ship a 90% solution than not to ship at all.
- Hackfests and brown bags aren’t just for software companies. With the support of the CEO, I introduced both of these to the wider company (see my post about monthly brown bags and semi annual hackfests) and they resulted in cross pollination, public speaking skills for employees, and some great ideas, including one that became a core 8z initiative.
- Having software in maintenance mode is tough on a team. One of the biggest tasks for my team for about half of my time at 8z was to maintain an old complex website (10+ years old) just enough to keep it running. It was and is crucial to the business, but the business was trying to migrate away from it for a number of reasons (gobs of technical debt, among others). This required painful choices, because often the right technical choice (fix the root cause) was the wrong business choice, and technical band-aids were the right business choice. That wears on me.
- Maps in Apache Cordova are hard to get right–the single threaded javascript execution environment really stinks when it comes to complex maps. (ht @intalex)
- A five character domain name gets a lot of purchase offers. You can also tell, to a first approximation, how technical someone is by how they react to your short domain name.
- Beer Friday (aka Friday afternoon club) is a great way to get people to interact cross department, but doesn’t work for everyone–not every coworker wants to hang out and have a beer. Having other ways to cross pollinate makes sure everyone can participate.
- It is addictive to hear from consumers or other users that your software made their lives better.
- I learned as much or more from my failures as I did from my successes. To name some particular personal failures, I made a hire that didn’t work out, a mobile app of which I was owner of that didn’t get to production (or even to QA) and a vendor who I evaluated, recommended and implemented that ended up not being a fit. In each case it felt really crappy when it happened. After I had some time and perspective, I was able to identify some lessons that hopefully will keep me from making the mistake again. You might hear more about these mistakes in the future.
- Finally, I enjoyed the the opportunity to be the primary technical voice at the executive table (while I never had the title, I was the effective CTO for a time). Bringing software engineering practices into a real estate company was fun and I think made 8z a better place to work. Of course, I could not have done any of that without the support of the owner/CEO, but it was fun to see what stuck and what didn’t.
The primary reason I joined 8z was that I felt after seven years of contracting and consulting that I wanted to be part of a team again. I also thought being an employee would let me grow in ways that you can’t as a contractor. Both of these turned out to be true.
Thanks for four great years!
Follow me on Twitter
Follow me on Blue Sky