Nest Cams to Help General Contractors

I had an interesting conversation with a friend last night who was doing some home remodeling.  He mentioned that part of the hassle of any such project was that the general contractor (GC) with whom you are directly in contact, doesn’t really know the state of construction site (what has been done, who has stopped by to work, what it looks like, etc).

They are limited to three sources of information:

  • their subcontractors
  • the homeowner
  • a site visit

The first source may or may not be reliable, depending on the relationship and how busy they are.  Using the second leads to every homeowner’s nightmare (micromanaging the home improvement project), and also may have some reliability issues.  The third may not be feasible, depending on the size of the project and the number of projects the GC is running.

However, there is now a fourth option that my friend mentioned.  (I thought of drones, silly me.)  My friend had anecdotal evidence that using these outdoor cameras was very helpful to some general contractors.  They can review footage in much less time than driving to the site.  They can send video around.  They can text their subs and resolve any issues that may arise, or reschedule work if needed.

Using a camera system, like the nest outdoor camera, gives the GC an independent, truthful view into the construction site.


Founding engineer or Founder/CTO?

I’ve seen a number of great posts about the contrast between VPs of Engineering and CTOs for startups.  Here, here and here. The short version, if you don’t want to read those posts, is that a CTO is technology oriented and a VPE is process and team oriented. At a young startup there is significant overlap. If you are a software startup, you need to be aware of this split.

How quickly these roles need to be delineated depends on the size and growth of your startup. If you have one or two technical folks, no need to do this (but you do need to determine who is in charge of technology). If you have ten engineers and are planning to add five more in the next six months, you should have already split these roles up. But today I wanted to write about the difference between being a CTO, the typical title for the founding technical member, and founding engineer. This is based on some discussions I’ve had or read, most notably with Jason Cole, who runs a consultancy focusing on technical leadership (all erroneous thoughts are of course mine).

When you are early in a startup (seed or pre-seed), you want a developer who can ship product. Nothing is more important than choosing the right market and getting a solution out to that market so that customers can give you feedback (with their dollars). CTOs of bigger companies actually don’t spend any time coding. They work on strategy, partnerships, hiring and other higher leverage activities. But that won’t work for a startup–you actually need someone to build product.

That person is really a founding engineer. Such a person is a special breed. Like an engineer on a larger team, the founding engineer needs to be able to execute and build product, quickly. They need to be aware of technical debt and when assuming it makes sense. They need to write code that works, is testable and performant. They need to evaluate whether to build or buy or download from Github. They’ll be performing devops tasks as well, such as monitoring the application, troubleshooting performance issues, and making sure deployments and rollbacks happen cleanly.

In addition to all of that, the founding engineer must communicate with non technical folks, both within the organization (including the CEO) and outside of the company. The founding engineer may or may not be doing tier 1 customer support, but will be doing tier 2 support. They also have to be willing and able to drive decisions, especially around technical issues. They need to be able to understand and give feedback on the business strategy at some level, as that will determine technical decisions. The founding engineer also needs to able and willing to take market feedback. This may be filtered through others, and any response should be discussed with the other founders, but market feedback and quick iteration is a strength of a startup. The founding engineer may be doing some product management as well, depending on the other team members’ strengths. They’ll be the de-facto UX designer. They also will be interacting with vendors and contractors. They may review budgets and will hire technical team members. It’s possible they’ll interact with investors if funding is sought.

For all the additional responsibilities, the founding engineer should be compensated, well, like a founder. With not much money and gobs of equity. (Not much money is obviously relative, and depends on market value.)

But, at some point the company will either grow or fail. If the company fails, there’s obviously no worries about future roles! But if the company succeeds and grows, the founding engineer can take four paths.

1. CTO

They can grow into the CTO role, focusing on technical strategy. Until there are significant numbers of engineers (10ish) the CTO may continue to code. They may be doing code reviews for some time thereafter. But at some point they’ll be focused on technical direction of the company, competitors and partners, and large scale technical trends that may affect the company’s business.

2. VPE

They can grow into the CTO role, and then transition to a VPE. The reason they have to go through the CTO role first is that it’s unlikely the company will need the process and team building skills of a VPE until a bit later. But at that point they can focus on delivery, team building and process. They’ll likely work with product managers and the CTO on strategic direction of the company.

3. Technical lead

They can choose to remain a technical lead. This will mean that someone is hired over them into the CTO and/or VPE roles. This will be tough on the ego. However, it’s important to realize what brings them joy in life. If they want to stay close to the code, a technical lead role is best. In this role, the entire team needs to be very aware of who is in charge, especially if this transition happens after the CTO or VPE path is attempted.

4. Leave

An early stage startup is a magical thing. Everything is on fire all the time, but the ability to wear many hats, have a direct impact on customer lives and ship quickly may be what they value. If so, as the startup gets bigger, some of these opportunities will disappear. Specialization happens.

There’s nothing wrong with title inflation, but CTO (and CEO, for that matter) titles at a startup aren’t equivalent to the same titles at a company of 100 let alone 500 or 100,000. If you are joining a startup as a technical founder, realize that whatever your title, you’re really the founding engineer, and that, when success occurs, you need to choose.


Seek The Golden Comment: “zeus exit status 1” fix

This bit me yesterday, so I wanted to get it written down.  zeus is a preloader that makes running tests faster.  It can be a bit finicky about the gems available, even when using rvm.

Yesterday, I tried to upgrade a rails 4.2 app to rails 5.  (I failed.)  When I checked out my source branch to work on a different issue, ran a bundle install, and then a zeus start, I saw this:


zeus rake
zeus runner (alias: r)
zeus console (alias: c)
zeus server (alias: s)
zeus generate (alias: g)
zeus destroy (alias: d)
zeus dbconsole
zeus test (alias: rspec, testrb)
exit status 1

And then zeus exited.  I did some google searches and turned up these two issues: 118 and 237. Lots of folks having similar issues.

After reading carefully through these issue, and trying some of the suggested fixes as I did so, I arrived at the golden comment. I reproduce it here in its beautiful entirety:

There’s a lot of “try this” in here, but no actual debugging steps. Here’s how you can find the actual issue:

zeus –log ZEUS.LOG start then cat ZEUS.LOG

Excellent!  Using this logfile I quickly determined that the root issue was a collision in my json gem versions and was able to get zeus running again.

But that’s not really the point. The point is that this user (thank you Steven!) didn’t just provide an answer, he provided the means for me to diagnose and find my own answer.

I wish github had some way of calling out highly recommended comments, as if I’d seen his comment first, it would have saved me some time.

Just goes to show, you should always read the comments fully and look for the golden one when you are troubleshooting.


Running servers in AWS without SSH access

When you allow SSH access to your server, the user sshing can do many things.  You can restrict their access with a tool like sudo or chroot, but at the end of the day, the user has access to the system and may be able to find a way to escalate their privileges.  It’d be simpler if no one could login to the server at all, but how would you configure the server to actually be useful?

With AWS and the AWS Systems Manager, you can install an agent (open source, under the Apache License) on your ec2 servers (perhaps via userdata at boot time) and run all your commands via this AWS managed service.  That means you never have to have an ssh server running.

What about limiting what users can do?  You have the full power of IAM to limit who can do what to which servers.  Here’s how you can use tagging to limit on which servers someone can run a command.

What about installing applications?  Uou can use userdata or the ec2 run command.

What about logfiles of those applications?  You can send your logfiles up to a log aggregation service like cloudwatch logs or splunk.  It’ll be easier to manage logfiles centrally anyway.  If you use cloudwatch logs, don’t forget to move your logfiles to s3 and then expire them, otherwise you’ll pay more than you should.

What about system updates (patches, etc)?  There’s a patch manager.

What about troubleshooting?  You can use the ec2 run command to execute arbitrary commands and get the response back.

If you lock down the ec2 run command, then suddenly you have a lot less attack surface.  No one can login to your AWS instances and nose around or run arbitrary commands to see what software is present or what security measures are in place.


Functional Core, OO Shell

This video is about 30 minutes long.  Mike Gehard mentioned it to me, and I enjoyed the heck out of it.  Many takeaways from this.  One is is how using test doubles make sense at the beginning of a software project, but how it will eventually come back to bite you as the method signatures of dependencies change, and your tests don’t fail.  Another is how you can write ‘fauxO’, a nice combination that has the strengths of functional programming and OO programming.  A third is how and where integration tests make sense.

Overall, what he proposes is that the boundary of any object that makes decisions have parameters that are simple values so that that it is always easy to unit test them.  Out of this proposal fall several nice features.

Well worth the time to watch.


Sources for custom t-shirts

This list of providers of custom t-shirts came off the Techfriends slack where someone asked about vendors that handle small runs of custom t-shirts.

I have no experience with any of these.  Some folks had some comments, which I paraphrased and added.


The UNIX and Linux System Administration Handbook

I’ve been reading the UNIX and Linux System Administration Handbook.  It’s a real tome, with about 1500 pages.  It’s got five authors and some great cartoons, and covers everything from shell scripts to disk to email to system management daemons (check out the table of contents).  No one should ever read this book cover to cover.  That would be just silly.

I’ve been really enjoying picking and choosing chapters to read, however.  The sheer breadth of this book means that anyone with an interest in modern software development can find something useful in it.

Given my interest in AWS, I read all the sections about cloud computing.  These were high level and not super interesting to me, but I think they’d be great if you were a novice about cloud computing, and they did have a great survey of the major public cloud providers and when it made sense to use each of them.

Then I moved on to the networking sections.  I honestly can say that I didn’t understand fundamental routing protocols before I read that section.  This is obviously closer to the heart of system administration, and the authors did a great job with concepts and hands on knowledge of networking.

After that I moved on to containers.  Did you know that Docker is the new hotness?  I had heard of it, but didn’t understand why.  Now I do.  It’s hot for much the same reason as the ‘fat jar’ deployment is preferred in java land.  Having one single artifact that rolls up code and dependencies is a way to simplify deployments of production code, including rollbacks.  The authors focus on the fundamentals of containers, primarily Docker, but they also cover various orchestration layers like Mesos and Kubernetes.

I’m now in the middle of a chapter about continuous integration and continuous deployment, where they are discussing the concepts as well as Jenkins, one of the key technologies (see, I told you everyone could find something in this book).  After that, I look forward to reading about configuration management.

If you work in software at all and are involved in production systems, you’ll be able to find something in the UNIX and Linux System Administration Handbook (and if you aren’t, I’d be interested in knowing who owns that responsibility).


Thoughtworks Radar

Last night at the Boulder Ruby Meetup, Marty from Haught Codeworks walked through the Thoughtworks Technology Radar.  This is an informative way to keep on top of the latest technology trends without spending a lot of time researching and reading.  Sure, you could get the same information from reading Hacker News regularly, but the Radar is less haphazard.

The Radar is published every six months or so, and pulls from experts inside Thoughtworks (a leading software consultancy). You can view techniques, languages and frameworks, tools, and platforms.  Each area has a number of technologies and the proposed level of adoption (hold, assess, trial, adopt).  Within each radar you can dive in and learn more about the technology, like say, weex. You can also see the movement of a technology through the proposed levels of adoption over time.

You can also search for a given technology, if you are interested in seeing what the status us.  Sometimes technologies are archived, like Elm.

Note that this is not perfect.  The lag is real, but may help you avoid chasing shiny objects.  The Radar is also inherently biased because of the methodology, but given Thoughtworks size, scope and leadership, it’s probably one of the best technology summaries.  It’s certainly the best one I’ve run across.


Do you have a first, best, affiliated customer?

I find Ben Thompson engaging reading.  In one of his best posts, he discusses how AWS has a best, first customer, Amazon.  Every service that AWS builds has an automatic flagship customer that will stress test the application.

The cost to build AWS was justified because the first and best customer is Amazon’s e-commerce business

I really enjoyed that and have been looking around other places where you can see this same pattern.  8z Real Estate, a brokerage for which I used to work, has a social media offering, zavvie, which I believe all 8z brokers are using.  One of the kitchens that use The Food Corridor has an affiliated restaurant that uses a large amount of kitchen time. Would love to hear of other examples.

All of these companies have been able to make substantial investments in infrastructure knowing that, if nothing else, the benefits will accrue to a business with the same owners.  But at the same time the subsidiary can benefit from learning from other businesses, thought benefits flow both ways.  If other real estate brokerages use zavvie in different ways, zavvie can incorporate those lessons into the software and then 8z brokers will benefit.  If that restaurant needs a special piece of equipment, the kitchen can buy it, and all other clients of the kitchen will have access to it.

Do competitors have concerns about helping the parent business, even in a roundabout manner?  Sure.  Here’s an article about how startups should be wary of being co-opted by AWS.  The brokerages that are using zavvie have to be aware of the parent company (or, perhaps to be precise, that the owners of zavvie and the owners of 8z are the same).  However, if the subsidiary company can offer a service that is unique and/or very price competitive, that may cause competitors of the parent company to ignore their concerns, at least for the time bieng.

Once you get to a certain size of business, building an affiliated business which can serve both the original business and other competitors can be a great business model.  You can gain the benefits of marketplace intelligence along with providing the subsidiary business enough runway to survive.


Panel on Net Neutrality

I’ll be participating in a livestreamed panel at 7pm mountain tonight, hosted by Representative Jared Polis.  We’ll be discussing FCC net neutrality actions.  (They’re rolling back ‘common carrier’ status from ISPs as of today.)  (Update 12/12, apparently the reclassification is happening this week, not today.)

Please feel free to join!



© Moore Consulting, 2003-2019