Hi, I’m Nathan (or Nate, no preference). I’ve been writing software full-time since 2012, but I taught myself to program and I’ve been doing so since 2004. I think of myself less and less as a programmer and more as a problem solver, or someone that makes your business or life more efficient.
This blog exists because I keep repeating myself over time. It’s the same lessons, phrased different ways, for new and aspiring engineers. I enjoy helping others succeed, starting with tutoring through college, then mentoring others at work.
Software engineering, especially at BigCos (the Google, Amazon, Microsofts of the world), is hard, but not for any of the reasons someone new may expect. It’s the total complexity of launching something where things must always be secure, scalable, and monitored. You can’t go write something over a weekend in a new language and put it into production without a review, and that review takes both time and energy. It takes others to approve your design, then the code reviews, then maybe a security review, probably an infrastructure-as-code change, maybe an extra integration test, some manual testing in your integrated production environment, and then you can push it.
That’s just the technical work. The hardest part of each of those steps is working with others to convince them that everything is going to be okay and things look good.
Hopefully I can help you master some of those skills to deliver successfully in each stage, not through pure technical prowess, but by understanding that software is largely about risk. You need to convince others that your change is both the right thing to do and low-risk. No one thinks “yeah, there’s this huge bug on the critical path, ship it to production!”, yet bugs appear in production all the time.
A few credentials for credibility: I went to the George Washington University for Computer Science where I didn’t finish my degree (3 years). My first job was in a suburb of Philadelphia at a small start-up where I did a little of everything - built major features, re-wrote front end code, responded to customer questions, wrote external documentation, and so on. I was there about a year and a half before I went to another start up in downtown Philly (RJMetrics, bought by Magento, which was bought by Adobe) where most of my time was spent building a framework to make RESTful services faster to build. I was there only six months before Amazon called me.
Job offer in-hand, my then-girlfriend-now-wife and I moved to Seattle where I worked on the Robot Mitigation team on the retail side. The team focused on preventing bots and scraper traffic. I was awarded three patents from my time on that team. Notably I built some better instrumentation on Amazon’s CAPTCHA page, which led to fewer customers ever seeing CAPTCHAs. That team also owned the only near real-time stream of world-wide retail website data, so there was a lot of work with streaming technologies. After two and a half years I transferred teams to AWS Lambda.
On Lambda I had two large projects, one as part of an internal service re-write, the other as part of a way to onboard new business. The part of the rewrite I owned led to better availability during deployments. The other initiative dealt with crypto, including a custom key distribution mechanism. Both were successfully launched.
We moved back to the east coast (near D.C.) to be closer to family as my project on Lambda winded down. I transferred to the team that owns AWS Time Sync - NTP for all EC2 instances. As of 2020, that’s where I’m still hanging out, working to bring better time to all of our customers.
Separately, since 2016, I’ve been busy in the nights and weekends working on Docket to make it easier to exchange your health data with any physician.