Hi!
My name is Derrick Wippler, I’m an techie with 21 years of experience building, improving, and running software and software development teams.
I live in San Antonio with my wife and two kids. I’m passionate about open source and building great products. I’ve been fortunate to be a part of two different startups, of which, one was successful. I’ve learned a ton about how to run a great product, built teams and scale services to heights I never imagined was possible at the time. I’ve made many friends along the way, and I’m proud of all that we built together.
A few things I’m quite proud of are. (In no particular order)
- Kernel Device Driver author in C
- SuperNES Emulator author in C++ and Assembly
- Point Of Sale devices (UI and Backend)
- Game development in Unity C#
- Designed, Wrote and Operated solutions at Rackspace Cloud Block Storage at scale
- Full Stack product development in Angular and React
- A passion for functional (product) testing
- Product first focus (Product over code)
- CTO of a small gaming studio
- Scaling distributed backend services in golang
- Scaling both SQL and NoSQL databases
- Taking a failed team, and re-align along value streams
- Mentorship, and team leadership
- Writing and teaching
- I love communication protocols (TCP/IP, HTTP 1&2, TLS, SMTP, etc…)
- Experience building and scaling services to accept and process millions of emails a second at Mailgun
- Community engagement via Opensource projects
- Also, I know all the buzz words!
Leadership
You lead by example, and encouragement. I believe my role is to give advice, and to be a sounding board for other to bounce ideas off of. Rarely do I ever tell people what to do, and how to do it. Every person and project is an opportunity to learn and grow. If you don’t allow room for experimentation and failure, then there are no opportunities to learn and grow. (TODO: Reference blog post)
Also, A few of my former employees said I was the best boss they ever worked for. Which is cool because I didn’t pay them a lot, so I must have been awesome 🤣
Product First
The product is always more important than the code. You can have beautiful code, but a horrible product. This does not mean that your code cannot also be beautiful, it can, but code NEVER comes at the expense of the product. Hence, product testing should be at center of every project. (TODO: Reference blog post)
High Velocity & Architecture
There are strategies which developers and architects can employ to ensure velocity over the life of a product. As an avid student of such strategies I have a focus on managing technical debit before it begins, and managing it over the product life cycle. Good Code, and therefore Good Architecture share the same characteristics, they both make change easy. If code is easy to change, it’s good code, if your architecture makes change easy, then it’s good architecture.
Functional Testing
My number one strategy for managing tech debit is always functional testing. If you are ONLY testing the public interface of the product (API or Code Interface) then you are free to change the underlying implementation as you wish without impacting the “function” of the product or public interface. Once you fully understand and grok the power this provides you, you will never go back to only unit testing again. (TODO: Blog post Reference)
Documentation
Code explains “how” a thing is done, but it lacks the “why” which is often more important than the “how”. Code comments shouldn’t explain the “how”, but instead give context about “why” the code does what it does. This is most important when on-boarding new members to the company and team.
Giving new devs and managers as much context as possible by explaining “why” our code and architecture exists in it’s current form is of paramount importance. Even if the answer to “why” happens to be “Because of historical reasons”.
Code and architectural complexity can live on for years because the individual who wrote it made assumptions that are no longer true, so the current owners make assumptions that the existing code needs to be there, “because it’s always been this way”. Documenting the “why” helps brush aside the assumptions of the past so that future individuals can sweep away technical debit. This is yet another reason why functional testing is so important.
Okay I am looking at this now, I have to say Derrick your documentation in
the Handbook is truly incredible. written with verbosity, care, and
enthusiasm, and is very thorough. It has made my onboarding process super
streamlined relative to other companies.
-- New Senior Dev, third day on the job
Things I’ve built I’m proud of
- https://mailgun.com
- https://github.com/mailgun/gubernator
- https://github.com/mailgun/groupcache
- MIME Parsing Library in Golang (Private)
- https://github.com/thrawn01/hubble
- Rackspace Cloud Block Storage (Private)
- https://github.com/thrawn01/clip
- SuperGNES / SuperRetro16 Google Play
- https://github.com/kapetan-io/querator/
Opensource Projects I’ve contributed too
- https://github.com/rackerlabs/atom-hopper
- https://github.com/rackerlabs/rackspace_cinder_extensions
- https://github.com/falconry/falcon
- https://github.com/openstack/python-cinderclient
- https://github.com/etcd-io/etcd
- https://github.com/pb33f/libopenapi
- https://github.com/mailgun/mailgun-go
- https://github.com/vulcand/vulcand
- https://github.com/slatedb/slatedb-go
Projects I’ve abandoned but are still proud of
- https://github.com/thrawn01/steve
- https://github.com/thrawn01/ollie
- https://github.com/harbor-pkgs/cli
- https://github.com/thrawn01/humble