Getting a website up in 2017

I launched two websites in 2017, yourfoods.info and sledgianowski.com. This post goes over how I did it, what went well and where the weak points were.

### Hosting:
Google Cloud Platform’s GCE is the hosting provider I chose. I think GCP has the best user interface of the public clouds and its no effort persistent use discounts make things simple for me. The cloud shell google offers is excellent and lets you ignore the SSH keys you would have to keep track of for AWS.

I will probably keep using GCP for my projects next year. Although, I am interested in testing packet.net’s bare metal hosting.

### Setup
My websites are a ghost blog https://ghost.org and a Django+Postgres web application. My blog uses nginx for the frontend and SSL encryption with ghost’s nodejs implementation as the backend.

Yourfoods.info uses a nginx frontend for ssl and gunicorn for serving the django webservice.

Let’s Encrypt is a big win for my websites. The integration between nginx and certbot, https://certbot.eff.org, is excellent making it easy to setup SSL in minutes. The main issue I have had with it is when my DNS was not pointing at my public IP in google cloud.

### Domain names
I use Namecheap for my domains and DNS provider. The pricing is decent and their DNS configuration support handles my use case well. Namecheap has two factor authentication, but its SMS based and somewhat wonky to use.

### Analytics
I am still using Google Analytics for user tracking. Its free, provides a first class UI and is very easy to setup. I gave a few free and private options a cursory glance, but they did not look like things I could setup in an hour.

### Conclusion
Its pretty easy to setup a website these days. Let’s Encrypt and Nginx integration make SSL quick and easy to get going. And the public cloud is great for small websites that do not use a lot of resources.

Team Skill Shaping

When running a team you need to balance bus factor and performance.

On an average software team of perhaps 10 people, you will naturally have people develop expertise in a particular part of the codebase. One developer will be an expert in the frontend, another in the SQL queries, the next in the controllers, etc. What you want to avoid is a bus factor of 1. Some teams try to keep every developer knowledgeable in every area of the system, this is a waste. If you have to work on every part of the system you will not be able to master any single part. To get a bus factor of n by rotating developers through different parts of the system you give up the efficiency from letting a developer master a subsystem. My solution is that you should focus on getting a bus factor of 2 for each major subsystem. Have people focus on the two subsystems that they are interested in or are available and leave things there. Just try to avoid having two developers working on the same two subsystems. You are unlikely to have two developers get hit by the ‘bus’ at the same time.

Aim for a bus factor of 2 while trying to avoid a lot of overlap on subsystems, then leave things there.

Changing KPIs — A tale of moving from individual contributor to team lead.

Changing KPIs — Moving from individual contributor to team lead.

The biggest change after my move to team lead is that my KPIs (key performance indicators) have changed significantly. I still troubleshoot bugs, create architecture, discuss and persuade teammates of architectures. I get to write some code here and there. But the work that I am evaluated on has changed significantly. Instead of being evaluated on my ability to get coding done, to resolve bugs and be a good team member, I am evaluated based on the team’s performance. Was I able to keep everyone on the team from being blocked this sprint? Was I able to keep people on the team coordinated such that they didn’t duplicate code or write incompatible interfaces? Do we have the architecture and stories hashed out far ahead enough to keep working towards the release?

Its been kind of a shock to me because I will be giving my update in standup, trying to remember what I did yesterday and its something along the lines of “I sat in on a couple meetings, reviewed PRs and helped classify several bugs.” I worked all day and am exhausted now, but I didn’t commit any code or make any progress on the story I assigned to myself. It feels like I’m not getting anything done, what happened, I used to be good at my job.

But despite feeling like nothing is getting done, I am still hitting my KPIs as a team lead. My bosses are happy, the team seems happy enough with my work, the scrum master has what he needs, etc. Its not that I am not getting any work done, its that my ‘work’ has changed to something different. I am focused more on coordinating the team’s effort and planning what we need to do next, keeping abreast of the features coming down the roadmap, keeping track of technical debt and the maintenance work we need to do.

Starting a new Go project is delightful.

I started a couple projects recently, a mock crypto exchange and my latest project a unicode manipulation library. But what struck me is that its really simple to get started. You need the go runtime and a GOPATH setup.

Then you specify the package and the main method and that is a valid program.

package main

func main(){}

Above is my program so far. It is a short program with a bit of exploratory code that converts strings into their unicode rune ids. Back when I mainly used Java, I would have had to setup an IDE, integrated maven and think about package structure. In Go I just have a main.go file, if I need dependencies I create a /vendor directory and usego get github.com/gin-gonic/gin to pull the dependency.

Overall the lightweightness of the Go tooling makes it very easy to build small programs.