wippler.dev

Search

SearchSearch

Recent Posts

See 52 more →

About Me

Mar 06, 2025, 6 min read

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.

Experience

Experienced with mostly backend server development and a little bit of frontend UI/UX. Throughout my career, I have worked across the technology spectrum, from kernel module development to mobile game creation. I have led a small game startup, managed several open source projects, and directed multiple development teams — serving not only as a technical lead but also as a mentor and project manager.

I’m passionate about open source and building great products. 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.

Technology

Everything I can answer questions about or have used in production. If a year is indicated, I have experience running or using in production for that length.

  • Golang (~10 Years) Python (~7 years) Bash, Rust (~6 months), C, C++ (~5 years), Perl (~2 years), Java (~2 years), C# (~1 year), Javascript (~1 year)
  • MongoDB (~7 years), PostgreSQL (~5 years), MySQL (~2 years), SlateDB, BoltDB, Cassandra (~7 years), ETCD (~5 years), Consul (~2 years), Redis, GCS & S3 (~1 years), ElasticSearch (~4 years)
  • Networking (~20 years), Proxies (~5 years), Sockets, Embedded, Linux Kernels, Tcpdump, Library Development, Consistent Hashing, Sharding, Partitions, Distributed Systems (~4 years), Recursive Parsers, Service Mesh (~5 years), TLS, Encryption, Hashing, Binary Trees, Trie, Cache Systems, CLI Tools (~9 years), Container Orchestration, Hashicorp Nomad (~4 years), Containers, Docker, AWS, GCloud, Android OS, Unity Game Engine, Super Nintendo Emulation - SNES, SaaS, OTEL Tracing (~2 years), Logging, HTTP H2C, Events, Data Streaming (~5 years), Analytics, GIT.
  • HTTP1/2 & TCP (~8 years), HTML, JSON, Protobuf, RPC, REST, RAFT, MIME & SMTP (~5 years), SQL (~18 years), NoSQL (~5 years), OpenAPI, YAML, GRPC (~5 years)

The Buzz Words

Architecture, Problem Domain, Coupling, Cohesion, Product First, OOP, Functional, Imperative, Procedural, Data Oriented Design, Single Table Design, Diátaxis Technical authoring, Order Of Importance, Diagnostics, Debugging, API Design, Cloud Efficiency, Scaling. Active/Active HA, Clean Code, Functional Testing, Product Over Code, Top Down Design, Immutable Testing.

Culture

Things I care deeply about

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.

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.

Architecture

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.

Key to making change easy is defining problem domains, then assigning high cohesion within the problem domain, while reducing coupling between problem domains. This applies equally to code architecture and overall system architecture.

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.

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.

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.

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 (used with permission)

OpenSource Projects

Entrepreneur

  • SuperRetro16 http://www.superretro16.com Super NES Emulator for Android. Wrote Software emulation for SPC700, SuperFX and 65c186 and others in RISC assembly. C++ JNI interface code for the Android platform to interface with the RISC assembly, wrote Dropbox support for syncing ROMS across devices and ported SuperRetro16 product to the Ouya Console (http://ouya.com)

Things I’ve built I’m proud of

Projects I’ve abandoned but are still proud of

Contact

Site Map

Links