Future Tech I want to see – personal ultrasound

https://www.butterflynetwork.com

I saw this personal ultrasound device last week. It is a $2k device that attaches to your smartphone and allows you to ultrasound anything you want. Its targeted at the medical field, with that price tag, but the form factor is spot on. These kinds of speciality sensors make sense, everyone has a smartphone. And if you can integrate at the smartphone level it makes your product cheaper and easier to use. I would like to get one of these just to see what is inside peoples’ bodies. I saw a video of a CT, or similar, scan while a person was speaking, and the tongue is shaped very strangely. 

In a sense the smartphone as a common platform makes cheaper medical equipment easier. I wouldn’t be surprised if Bill Gates starts outfitting African hospitals with equipment like this in a few years. After that search and rescue squads might carry smartphone based medical equipment. My hope is that in the long term everyone will be able to get medical imaging when they want it, not just after taking time off to go to the hospital and waiting for hours.  

 

 

Note: This is not affiliated, but if I ever get actual traffic I will be adding affiliate links.

Building a Single Page Static Site with Hugo: Not as easy as it seems

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.

Switching jobs sucks

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. 

Always squash before opening Pull requests

When you are working on a feature it makes sense to make incremental commits as you proceed with the work. Then when you are done you want to just open a Pull Request and wait for approvals. But it is important to squash your commits into a single commit before merging  into the master branch. The reason is if you need to revert your code change, you can revert a single commit and move on. You don’t want to be in a position where you have a serious bug in production, and you are trying to figure out if you reverted all of the commits. Save yourself the panic and trouble by squashing before you commit to your master branch. Some services like github will automatically squash for you, use that feature if you have it. 

Useful git commands for squashing

# git --amend amends your last git commit 
git commit --amend

# rebase is the command used to actually squash commits 

# git rebase -i HEAD~4 rebases the last 4 commits including the head commit
# the -i toggles interactive mode which opens an editor
git rebase -i HEAD~4

When you run the command git will open a text editor that asks you to choose what to do with each commit.

Example screen when you start an interactive rebase. All commits are picked by default.

The default is the vi or vim editor. In this window you want to change the command for the commits you want to squash. 

Interactive rebase menu

Then the next window will give you a chance to modify the commit message for your new combined commits.

Update the commit message for the squashed commits
Final commit after rebase

Design Documents for Distributed Companies

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.