Category: Uncategorized

I recently launched www.seattledatingpics.com for my photography work. It is a simple static landing page that pitches my online dating focused photography in Seattle. It seemed like overkill to launch a new wordpress site just for a single page so I decided to use Hugo (https://gohugo.io) as a static site generator. Hugo is written in Go and offers a way to create static sites with markdown and themes. Unfortunately, Hugo’s documentation for single page static sites is difficult to find.

The solution is that  you need to find a theme which supports a single page static site, and then you create a _index.md file which acts as your home page. 

Here is my config.toml for a single page static hugo site.

baseURL = "http://www.seattledatingpics.com"
languageCode = "en-us"
title = "Seattle Dating Pics"
theme = "ananke"


DefaultContentLanguage = "en"
SectionPagesMenu = "main"
enableRobotsTXT = true

background_color_class = "bg-dark-blue"

_index.md for a single page static site

---
title: "Seattle Dating Pics"
date: 2018-12-30T18:22:27-08:00
draft: false
---


Online Dating is difficult and the right pictures make all the difference. I can help you capture your better side and help you meet people online.

I started seattledatingpics because I had trouble getting good pictures for online dating apps. Online dating should be fun and having good pictures helps. 



### Options ###

__Take a Turn__: You and I will take turns taking pictures of each other with my equipment. We will get shots of the same positions and poses. This is free as long as you take a turn with the camera!

__Hire me__: You hire me to do a photo shoot of you. We will move around Seattle filling in your profile. I have rooftop deck and gym access. We can hit great spots that you like or go to my favorite places in the city.


Send me an email at __nick@sledgeworx.io__ with seattledatingpics in the subject line and we will setup a photo shoot!

Remember to turn the draft parameter to false before you build for production. I was banging my head against the wall trying to figure out why my website worked locally, but not on S3.

You don’t realize how much switching jobs sucks until you do it. I moved on from my first post-college jobs after almost 4 year, and its been more of a shock than I expected. Once you have been working at a company for a few years you start to know everything that is going on. You know how to be productive. You know who is important, what projects are important and have a good idea of where things are going. You know if your job is secure and how to do well. But once you switch jobs, all that goes out the window and you have to start building up your organizational knowledge again. 

The best way to increase your compensation is to switch jobs every 2-3 years. But while that saying is correct it underplays the cost to you of switching jobs. Yes, you are getting paid more. But you gave up your political position in your last company. You lost years of domain expertise and a large number of valuable relationships. If you left on good terms, which everyone should, you will still have those people in your network. But they will not be in your corner for the next political battle. 

Early in your career switching regularly is probably the best option. But as you move up in the hierarchy you may need to stay at companies for longer terms. At the beginning you can get promoted every years, Developer 1, Developer 2, etc. But you reach a point eventually where it takes longer to move up. Going from engineering manager to vice president is much harder to do than moving from senior engineer to engineering manager. You will need to know more people and have a better political position to reach vice president than engineering manger. 

How do you hash out architecture and design at a remote only company? Slack chats and phone calls are a slow way to communicate with an entire team. And miscommunication with people 1000s of miles away can cost you the time and money you were hoping to save by working remotely. 

The Design Document workflow

Some companies have a design document centric workflow. At the beginning of a project instead of writing Jira tickets or tasking out stories, an engineer will spend some time writing a 3-10 page document which describe the plan of attack for the project. This doc will include assumptions, design decisions and constraints, as well as a summary of the changes to be made. The document is not an exhaustive specification, but can include proposed interface or library changes. Then the team will have a review session to read and ask questions about the design. Next after some revisions, and possibly a follow up session, development will begin. 

Google Docs or any other shared document tool is sufficient to support the document review process. If you want to make the process truly asynchronous you could rely only on document comments and skip the meeting all together. 

Typically, a design document should be required both embarking on any significant project or feature addition. Adding a new button to a web form would not need a document, but building a new web service or adding a major feature would. 

When I worked in a distributed consulting company we used this workflow for proposals and Level of Effort estimates. But software design was usually handled by discussion and whiteboarding followed by implementation with half-hearted documentation occurring at the end of the project. A design document process would have helped share design between the east and west coasts keeping more of our projects on the same page. 

I spent the first three years of my career at a small agency/consulting firm. We did a combination of standard application development and technical management consulting work. We had problems with code quality decline in older projects, issues with pushing out solutions quickly, and we had very poor feedback loops into our software. 

We tried to write quality software and did plenty of testing. The biggest gap was that we sold cloud native architectures to our clients, but we never actually ran cloud native software ourselves. 

One the companies strengths was that our Project Managers would interface with your Product Owners and business analysts to make sure we were building the right software for clients. And because our clients were bureaucratic  cable companies we needed a lot of Project Managers to work with the clients’ bureaucracies. So we ran all the latest Scaled Agile frameworks and helped train our clients to use them. 

I moved to one of the biggest tech companies recently and here we also have problems with code quality in older projects, but this company has much better feedback loops and takes a little more time on developing and vetting solutions. 

Its funny that we spent a lot of time at my last job building continuous delivery pipelines for our clients, but I still never got to work with one. Here at BigTech we have full CD to production despite running one of the biggest websites in the world. 

On the process side, Project Managers don’t exist at all. And there is a lot less ‘Agile’ process on my team. Engineering design is handled with more formal design documents and design review meetings. Designs are written in documents instead of being hashed out on whiteboards during a meeting and only partially documented after that.