I am a software engineer, cloud architect, and part-time technology teacher/mentor. I have very strong opinions on buzzwords, and I will probably make some kind of a pun within the first 5-10 minutes of any conversation.
IT Interests and Experience
I have professional experience working with a whole lot of individual services within Amazon Web Services (AWS) in order to build applications, systems, and various environments/platforms. Most of those included setting up Docker-based deployments (with docker-compose or ECS; hoping to get to play with Kubernetes soon) when possible, designing and implementing data ingestion/delivery pipelines, and using/setting up/configuring continuous integration/deployment (CI/CD) tools and servers.
I am absolutely fanatical about AWS and figuring out how to get stuff running “right” on the cloud and will help almost anyone with AWS-related problems to the best of my ability. Teaching technology is something I abolutely love to do, and is something I will always make time for. My current job gives me the opportunity to work with everything from middle school children to college students to fellow engineers both in and out of my company.
Lately, I have been spending a lot of time (both at work and in my personal time) looking into a lot of the newer cryptography, identity, and network security solutions. The blockchain has turned into a great buzzword, but its uses for things like keyservers (keybase), immutable document stores (steem), and immutable transaction ledgers (cryptocurrencies) coupled with cool new ways of applying authentication/access controls (like upspin is doing) have really lit a fire in me to try to contribute to the identity and security solutions of all kinds. I am still trying to find out the hows, whats and the whys on that one.
Technologies and Languages
In no particular order, I wanted to present a list of things that I particularly enjoy in technology. Be warned that if you ever bring any of these things up in conversation with me, you may not see the end of the coversation.
- AWS/Cloud
- Cryptography - Mostly in novel applications of mature crypto implementations
- Let’s Encrypt
- Keybase
- Blockchain (don’t get me started)
- Anything security related
- Docker
- Microcontrollers/Embedded Systems
- Raspberry Pi
- MSP430
- Arduino
- Digital Signal Processing
- Hobby electronics - firmware and fun I/O with LEDs and sound
- Linux (Red Hat/CentOS/Fedora and Ubuntu, primarily)
- Golang
- Python
- User Experience (UX) and Human Centered Design
- Systems Engineering
Hobbies and Stuff
I tend to read a lot. Mostly novels, particularly science fiction and fantasy type stuff, but I also try to keep up with some fields of academic research - at least the headlines on places like Arstechnica.
Some video games have recently caught my attention that got me to get back into playing some video games - games like Soma, Remember Me, and Assemblance all play on some really cool topics that Ray Kurzweil would likely find disturbingly accurate. In other words, I am very much into futurism and strongly believe in a future that is tightly integrated with technology and artificial intelligence in ways I probably will never fully comprehend.
- The singularity, man!
Seriously though - anything related to the intersection of humans and technology, including:
- AI/Machine Learning (see past the buzzwords, please…)
- Brain controlled prosthetics/Brain Computer Interface (BCI)
- Bionic eyes
- Nano-bots
- Genetic engineering - holy CRISPR!
- Neuroscience - of the cognitive and behavioral varieties
- Hacktivism
- Technology education at all levels - children through continuing professional education
- Technology law/politics/policy (purely from an observer’s perspective)
- Cyber security awareness (tin foil hats)
- Travelling (who doesn’t like travelling?)
- Craft Beer
- There’s always time for a beer
- Tacos
- I will never say no to tacos
Education and my “problem solving mindset”
Penn State University ‘14
B.S Engineering Science
Thesis: Design and Implementation of a Portable EEG Acquisition System
My major was basically a major for people who couldn’t decide which one to pick and couldn’t possibly pick more than one or two. The program emphasized a multi-disciplinary approach to problem solving as well as aiming to strike a decent balance between traditional theoretical science education and practical engineering approaches/solutions. As I continue to get more and more industry experience, I am realizing just how influential my undergrad really was for developing my still-constantly-evolving problem solving mindset. For what it’s worth, I am not married to calling it that, I just don’t know how else to frame it.
My take on what the program was trying to instill is that science education tends to focus too much on the theory or the “why”, and while some students are able to connect some dots together and see a million applications for whatever theory it is they’re discussing, the engineers among us need something a bit more concrete. However, some engineering education can focus a bit too much on the solutions - the “what” of fixing practical problems - without going into enough depth on the “why” - how the science of the problem affected the chosen solution.
So I came to learn that there needs to be a balance between the two such that when the problem inevitably shifts dramatically (as we see in the current IT landscape), there can be the complete understanding behind why the problem was happening and how that influenced what got built. Too often you see people trying to morph an existing solution to a new problem domain and are left wondering why it isn’t bulletproof or things just feel clunky and wrong. The best analogy I can give (and repeatedly use in conversation - ask anyone I know) is likening it to trying to fit a square peg into a round hole. When that doesn’t work, the naive approach is to try to shave off the edges of that square peg until it looks like it will fit in the round hole. Unfortunately, this just leaves a half-baked solution, and people are left wondering why things still don’t fit quite right. With a complete understanding of why the square peg (the solution) fit in the square hole (the original problem domain), you can/should take those lessons learned and apply them to building a round peg (novel solution) for the round hole (shifted problem domain). You can’t just transplant the solution from one problem domain to another without understanding why it worked in the first domain in the first place.
And so I tend to focus on paying attention to the problems, not specific solutions. One service or product or environment never fits all, and I always try to true back to the “why” whenever possible.