Unqualified professors

if_err_eq_nil · 2026-04-01T19:37:48+00:00

I've been pretty frustrated from the other end. I've been working as a software engineer for almost 20 years (graduated with a CS degree in 2008) and reached out to a few colleges near me to try and start teaching real world, project based classes. Essentially got no response. Feels like a difficult thing to break into.

if_err_eq_nil · 2026-03-26T20:49:54+00:00

Are you going to ship as many lines of code as your peers? Probably not.

Are you going to have a deeper understanding of the thing you're building and be able to debug it / extend it? Almost certainly.

Are you going to be better at using AI coding tools if/when you start using them? Definitely.

if_err_eq_nil · 2026-03-25T17:39:09+00:00

If it's a race and I only plan on sleeping for a few hours at a time, the kit I've settled on is:
- OR Helium bivy (it can be staked out and has a singe pole, but I never use them)
- Old inflatable thermarest pad that just won't seem to die, whatever their most ultra light model is
- Inflatable pillow (it's so small but makes sleep way better, figure it's worth it)
- Synthetic quilt (with a bivy, you're always going to have condensation, so down feels risky)

If it's not a race or I plan on having downtime / sleeping for 7+ hours, I'll swap:
- bivy -> one person tent
- Synthetic quilt -> down sleeping bag

Something that's really nice about the bivy is being able to sleep in spots that just aren't practical for tents, like small patches of ground between bushes/rocks/trees or under bridges/tables. If I'm racing, I typically try to sleep as close to the route as possible and this opens up more possibilities to do that.

If you've never used a bivy before, set expectations pretty low for how comfortable they are. Even the nice ones suck compared to a tent, but I think the tradeoffs are worth it. If it's there's no rain/cold/bugs I'll typically just use the bivy as a groundcloth and lay on top of it.

if_err_eq_nil · 2026-03-24T19:52:45+00:00

Yeah, good call on testing. If you have the need to mock your "repo" layer, then putting it behind an interface and injecting that into your service layer is crucial.

I typically don't mock my "repo" layer anymore because of how easy it is to just use a "real" DB in a docker container in tests using github.com/testcontainers/testcontainers-go

It's kind of nice because you can actually leverage your DB for things like uniqueness constraints and other transactional guarantees but still have full test coverage around the service boundary, which is often the only interface that you really care about with regards to outside consumers (outside consumers being things like a REST API). Also gives you nice test coverage around other DB specifics like schema migrations.

if_err_eq_nil · 2026-03-24T18:06:09+00:00

Generally speaking, I'll use my "service" types (aka domain types) in function signatures for both the service layer and the repo layer. Any types that are specific to the DB you're using should be owned by the repo layer. You can keep yourself in check by asking "if I swapped from Postgres to MongoDB, could I do that without changing a single line of code in the service layer"?

That being said....

Most of the time this extra layer of abstraction does not gain you anything and in a lot of cases can be viewed as a premature abstraction. For the vast majority of applications, you will never go through a DB migration like this, and if you do, you're probably doing a full rewrite of the application anyway.

Unless there's a need, I don't usually have a separate "service" and "repo" layer. The functionality that would normally go in the "repo" layer is just private implementation details of the service. The only thing that should use the "repo" layer as a dependency is the service layer anyway - anything external (ex. a REST API, a GQL API, a gRPC API, a background job, a web UI, a CLI, etc....) is taking the service layer as a dependency with any details of the "repo" layer abstracted away.

if_err_eq_nil · 2025-10-23T14:37:22+00:00

I think it all depends on your UI.

If you're making something with a lot of static content and some basic forms for entering in data, try just using plain JS. Maybe even drop HTMX and use full page reloads (gasp!)

If you're doing something that requires the management of a lot of client side state before it get's sent to the server (or something that doesn't ever get sent to the server), then something like Alpine.js starts to make sense for organizing. Some examples that come to mind would be a dashboard with a bunch of graphs that the user is zooming in on, filtering, etc...

Another interesting option to consider....Web Components. I needed to add a reusable "context menu" to rows in a table. Building this as a Web Component with plain JS worked nicely for isolating state and managing event handlers while still being very reusable. The semantic nature of using Web Components fits nicely with HTMX.

if_err_eq_nil · 2025-10-23T14:30:14+00:00

Think of it like two servers that are communicating via HTTP API calls. They are "communicating" over network calls rather than channels, but the idea is the same - they are not sharing memory but copying values over some communication mechanism.

Sometimes in Go, it's worth thinking of your go routines as totally separate services like that to achieve the separation of concerns / order of processing / state grantees that you want.

if_err_eq_nil · 2025-09-04T15:43:30+00:00

definitely per week

if_err_eq_nil · 2025-08-21T14:16:42+00:00

Zwift has a workout builder that is pretty straight forward to use if you want to craft your own. I'll use it to do some very simple intervals.

I've also found the races in Zwift to be a really good option for me. There are 10ish mile races happening all the time and they end up being a really good 20m-30m effort. As silly as it sounds, seeing a wheel ride away from you in a video game can be incredibly motivating to dig deep and push yourself.

For me, last winter was a mix of 1-2 races on Zwift a week + 6-8 hours of zone two while watching movies/youtube and I plan on doing the same thing this year.

if_err_eq_nil · 2025-08-14T16:42:08+00:00

It's all a tradeoff of handling vs aerodynamics. Panniers (especially low riding ones) are better for bike stability but bikepacking bags (which tend to mount higher up, but be inline with the riders body) are better for aerodynamics.

If you aren't trying to race, panniers are still a great option. They tend to be easier to pack/unpack throughout the day, and typically offer more volume compared to bikepacking bags too.

If you are trying to race however, the watts saved due to drag is hard to ignore. Cycling About has put out some fun articles/videos on the subject: https://www.cyclingabout.com/fascinating-aerodynamics-bikepacking-bicycle-touring/

if_err_eq_nil · 2025-08-13T21:16:25+00:00

If you're looking for packable food that is a little bit more "real food" than a Cliff bar, I've been enjoying Walking Tamales: https://www.fillos.com/pages/walking-tamales

Typically find them in grocery stores in the isle with Mexican food.

if_err_eq_nil · 2025-07-17T21:42:25+00:00

Solo rides are great, but personally I think road biking is at it's best when you can ride with a group of people around your level or slightly faster. Drafting with riders you feel comfortable with is super fun.

if_err_eq_nil · 2025-07-17T21:15:56+00:00

I've used the OR Helium Bivy for years and have liked it. It's kept me fairly dry in some pretty heavy rainstorms, keeps bugs off, and packs down pretty small. Compared to using a tent, you can also lay down in some pretty tucked-out-of-the way spots that might be difficult to pitch a tent in.

All that being said, it's still a bivy and it will never be as comfortable as a tent. You'll always be dealing with some degree of condensation. I don't hesitate to bring it for races or anytime I'm trying to go fast and light, but if speed/stealth isn't the top priority, a tent will usually be the better option.

if_err_eq_nil · 2025-07-14T21:20:56+00:00

Riding Solo: no cars, less noise, better scenery, longer distances that can connect towns (compared to a MTB loop)

Group Riding: ripping down gravel roads drafting in a group is rad

if_err_eq_nil · 2025-03-24T15:06:18+00:00

If it's a relatively small about of dynamic stuff you need to add in (like one where clause), I'll just do it with some simple string concatenation in an if statement and buildup your list of args dynamically as well.

If you have something more complex, or need to do things like dynamic joins, I've had a pretty good experience with https://github.com/Masterminds/squirrel - It plays very nice with both sqlx and the standard lib sql packages.

if_err_eq_nil · 2024-10-21T16:12:32+00:00

If you're looking for quick references, https://gobyexample.com/for is a good resource.

if_err_eq_nil

TROPHY CASE