I don't care about setting and maintaining AWS instances, docker containers and jenkins.

The older I get, the more I realize how precious my time is and now I have very little patience for anyone or anything that wastes it.

This is also why I've basically cut off all social medias from my life (except HN occasionally), have always preferred working from home to avoid wasting time in traffic, have cut off people who I don't enjoy spending time with and spend more time with my family instead.

Sadly the extended out of state family seems to like FB, and I try to follow science/math twitter.

As you get older, something in you clicks, that you realize that time spent being angry, or combative, reduces the time you have for enjoying things (family, life, etc.).

Your time on earth is a zero sum game. Maximize its utility, maximize your enjoyment, minimize your negativity (e.g. outrage of the day on social media). Your life will be better.

Like, a 30-min vacation sometime after work and 2-3 minute vacations hourly.

The key is to drop all goals and switch to a sense of complete freedom, even for a short period of time.

Absolute freedom. I do as I feel most of the time and I’m very lucky to be able to do so.

However, from my experience, this is not a popular opinion among developers.

Turnover is a reality that can't be ignored. New people come in and now have to figure out something that reads like a stream of conscience. It isn't well documented, doesn't follow the latest best practices and doesn't support modern paradigms and uses outdated frameworks/libs, but works great.

The apps I build always take into consideration the talent pool my employer intends to pull from. The reality is that they (usually) can't hire general "technologists" that are proficient at all layers of the stack. If the project is something that only you will ever work on, then you can do whatever you want and this whole conversation is moot.

More silliness. Pay developers enough so that they'll stick around. If they stick around, then you don't need to hire for talent in a particular framework or language. You can hire for intelligence, creativity, passion, drive, whatever... and invest in training people when they get there.

Jumping from framework to framework and language to language as the talent pool does is incredibly wasteful.

It's amazing FANG companies have any turnover based on that logic. Turnover happens for a variety of reasons... like global pandemics... you can't make a blanket statement like that and expect to be taken seriously.

In JS land there’s a ton of churn though for sure if that’s what you were thinking about. Not all of it though.

The point I am making is, using the current {shiny} tools might not be the correct answer (it could be though depending on the use case). Just use whatever gets the job done faster and then iterate. Some developers will start solutionising based on technology instead of focusing what is the purpose of the system and how it will help users. AKA: CV driven development :)

That question translates to me as "your sister teams/leadership/communication infrastructure are completely incompetent/lacking and you're on the spot to pull an 18 hour shift to clean up their mess. What do you do?"

Sure occasional unforeseen emergencies/breakdowns in communication are expected even at the best of companies, but I'd replace it with a hypothetical that makes the company sound fundamentally competent. Perhaps something like "The company has promised the customer a To-Do List App, however automated testing failed to catch a mission-critical edge-case. This comes to light the day before it's supposed to be delivered. The flaw is so fundamental that the app will have to be re-written. Everyone else is handling other parts of the delivery, so you're on the spot to do it on your own. The only thing that matters is that it's done fast. What do you use?"

IMO your counterexample is wildly implausible, and is likely to sidetrack the candidate. "Is nothing salvageable? What was the flaw? What automated testing? Do I have to use that testing in my alternative fix? How does that reflect on the rest of my tech stack choice?"

Perhaps a more innocent miscommunication like the customer failed to clearly communicate requirements, and it was just discovered in an email conversation that they were expecting and as-of-yet un-implemented To-Do List App in the current release, which is shipping tomorrow/this week/etc. I've experienced situations like that before, not sure how applicable it is to your business.

My original example is born of a decade of cynicism, and you're right that it could reflect poorly on the company. Thank you for the feedback, though in fact I'm happily unemployed right now.

It would make no sense for an interviewer to provide meaningless context unless they were deliberately attempting to distract from the the question, or are otherwise simply incompetent/unfocused. I don't see how gas-lighting candidates would be a productive mode of interview, particularly given that each party only has the interview from which to judge each others' character. Even if the candidate were to successfully discern the gas-lighting, all it would do is prevent trust from being formed. At that point every interaction would be subject to question.

So with the assumption that gas-lighting is not the intent and that the hiring party is competent, the question is how is the context meant to inform the response?

Given that the interviewer is gauging the candidate's ability to perform a job, it is sensible to assume that realistic-sounding context applied to a question is meant to see how the candidate would perform in what the interviewer deems a "realistic" scenario.

If the scenario is unrealistic but meant to impart other information, then it should be obvious or stated as such, so that the candidate can attempt to parse to the correct information from the scenario to inform their response.

If the point is merely to motivate the candidate to answer the question by placing themselves in a narrative, I'd argue they should be motivated enough by the fact that they're in a job interview, without the need for unrealistic scenarios. If they aren't then they clearly aren't taking the position seriously or likely have other issues that would impact their job performance even if hired.

Take the hypothetical removed from context: "You have make a deployable to-do list app as quickly as possible, speed and basic functionality are the only priorities. What tools do you use?..." That format accomplishes the same goal of revealing the candidate's knowledge of what a quick/dirty workflow looks like. The followup questions mentioned "what problems to you anticipate when scaling the solution? How would you on-board coworkers? How would you shift from rapid development to ongoing maintenance? etc" would then flesh out the candidate's knowledge equally as well.

Good point I think

It's like you're aware of the issue (sales doesn't give two shits about the capacity of the engineering team) but you want someone that is good at wasting a lot of time efficiently instead of improving communication with the sales team.

If all your hypotheticals revolve around cleaning up the mess of flagrantly incompetent coworkers/leadership I'm going to get the impression that that's what I'm expected to do all the time. You could get the same information with different hypotheticals, so there's no point in making your company sound like a horrible place to work.

Happily, we would come to a mutual decision that I should produce profits for someone else. It sounds like you're one of those managers who wants supplicants, not applicants. Good luck with that.

It sounds like you're one of those managers who wants supplicants, not applicants.

Absolutely not. I want human beings with whom I can have a good relationship with, based in communication. I definitely don't want to hire a robot who is making important assumptions based on questionable (and totally wrong) heuristics, and Not bothering to ask simple questions.

So yeah, someone applying a weird algorithm to the questions I'm asking them isn't going to be a good fit.

Yet if I go back to my non-management dev friends and talk about this, they are all like “eeeew, what about X and Y” and I’m just like, but neither the citizens or my IT operations staff gives two shits about any of that.

I’m not going to say what is right technically, because I’m not qualified to do that, but I do know what will happen as it’s my decision, and we’ll be slowly moving all our customs forms to a PHP CMS system and we’re just going to shoot the docket container it comes in directly out into our internal Azure cloud with public access through our national identity system (NemID). My developers aren’t going to be out of work either, but instead of making the same form with small differences 9000 times, they will be building Drupal modules with actual challenges.

That's exactly what I meant. I remember arguing with a colleague who over-engineered a simple ORM table by having 3 classes. One was just an empty class, the other was an empty interface, and the third was the actual class. When I asked why did you make it this way? He said: "What if we decided to use Mongo later?

Technically he was right but practically, he was wrong! I saw this overthinking and over-engineering pattern across many in-house dev teams. But this is just my experience, and I'm not judging what is right and wrong from devs point of view. Every decision has its context, but I saw how these complications affecting the delivery and customer experience badly.

I mean, it's just fun. Developers are biased to do things that make work interesting, even if it's superfluous. We think that coming up with a better framework or tool will save time in the future. I think that often it's just a wash or a net negative since you now have to maintain this tool AND when you first start on creating it, you are sort of naive about what it needs to support, so you open yourself up to a lot of hurt later when clients of your tool come up with more requirements than you envisioned.

Standards matter if you want to show your code to someone else

I completely overbuilt a recent side project and ended up scraping the whole thing because it wastes too much time to maintain it. As much as I love building new projects, having children at home reminds me that time is my only true resource and it's better spent with the kiddos (at least at this stage of my life).

More and more, I want to build things that are in the former category if I build them at all outside of work.

TLDR; Wasn't a total loss as I did learn some, however I would have rather spend more time on developing the actual product (or in retrospect more time with my family).

The way I'd describe it is that /most/ codebases can fit into what you'd call a "web app" including most codebases that include complex systems -- there are, of course, significant exceptions.

You never realize how much configuration of AWS is like pulling teeth until you stop.

Now that CV-driven development is the standard, we are forced to learn new bloated "devops" tools and services every year.

This type of knowledge expires very quickly.

Also these tools and services do not develop communities: business users drop last-year tools like hot potatoes when a new cheaper or shit^ny one comes along.

This hype-fueled corporate-driven culture is not going to end well.

Why are we immigrating to the new thing? For the same reasons as we migrated to the old thing. Why is the new thing better? Because it’s just so much better.

I’m not saying modern tooling is useless; I don’t use ed, cc, and make for my development. But there’s a huge difference between a zero to one tooling effort and an N to N+1 tooling effort. The first one requires figuring out all the implicit/implied/manual parts of the process. The second one is often just turning one set of configuration languages into another.

We just observed it happen. As the engineers, we did our job best we could regardless. Things broke, we fixed. Somethings rolled back, and even for those they claimed credit & celebrated for re-inventing the wheel.

Spot on. There's a serious point of diminishing returns when piling up tools.

At some point the cost of learning, adapting, deploying, maintaining yet another tool becomes a net negative.

Often the solution is to replace 5 fancy tools with 100 lines of Python and Bash.

I think this meme was still fairly true then: Node was at risk of splitting into Node.js and IO.js, React was still new-ish and people were (rightfully) panicking over the drastic changes coming in Angular v2, Docker was still new-ish and there were arguments over whether Docker Swarm or Kubernetes was the future. But nowadays Node has stabilized, React and webpack have been comfortably dominant for years, Docker’s model of containers won out a long time ago and Kubernetes is there if you need it, but is mostly useful for people building a PaaS.

If people don’t want to learn these things, then fine, but I do wish the overall mood here would update to reflect the fact that we are now living in a much more stable time than when these memes were created.

Also, you shall shortly be smited for not having included Rust in that list. :)

Quite the opposite. The cambrian explosion of tools and SaaS is getting faster and the average useful lifetime of anything released today is getting shorter.

I used to program all day long.. and I guess I still do, but now it's for work, and after 8h of work I'm just done, you know? The "stuff I want to look at" list is growing longer and longer and there's no hope of me ever catching up.

(I can't imagine how it is for people with kids. How do you get anything done in your private life at all?)

Now, it turns out my career was lacklustre, so no great loss, and I'm sure having older kids is different than mine (1 and 3) but right now I get make 40-60 minutes a day to do what I want. Not much time for a side gig. I'm writing this right now with my kid watching a cartoon next to me when I originally wanted to work on some UI stuff for a side project, because I'm exhausted. Speaking of the above, she's scratching her butt so maybe we need to discuss the importance of thorough wiping.

(Good luck!)

The first few years of kids were infuriating and terrifying. I built my career by constantly exploring and learning after hours. Kids made that impossible, and that made me frustrated (because there’s SO MUCH I want to do besides diapers) and scared (because how can I maintain my career without learning).

It’s somewhat better now. I’m seeing them grow and can believe that this stage of life won’t last forever. I’ve managed to keep up with work by increasing efficiency during core hours, though I still look forward to getting back on the wagon with side projects when I can.

Here are a few beliefs that have helped me build & maintain a positive mind set:

- An engaged parent is priceless to a child. They desperately need you and you are irreplaceable. There is huge value in showing up for them, it’s just very different from your prior experience.

- COVID is terrible and we’re all struggling to get by. You must ruthlessly prioritize where you spend mental, physical, fiscal and chronological resources. Nobody expects you to maintain the same pace as before; we are all suffering through this together.

- Family and Profession both benefit from strengthening your mind, body and habits. Level up your time management game to improve exercise and diet. When the kids get easier, you’ll have more capacity for professional endeavors than before.

A lot of it is fear - I honestly don't know if I can compete with people who can work all weekend or put in late nights.

Sometimes managed to convince people to do this once a week, sometimes once a month, or somewhere in between. For example now I’m doing it once a fortnight.

Everyone recognizes that learning is an integral part of the profession, so I think companies should really accommodate that, rather than expect people to carve out personal time for it.

For the first and a half or so we've had a difficult life with the first kid. To be honest, there is just no way around it. Especially your first kid. The SEAL-level sleep deprivation and complete lack of "me time" really takes it toll. I'm also not the type of dad to let mom handle everything. She also has a career and, to be honest, a better one too. So I was regularly up at 2AM, 4AM and 6AM. Then a workday. :) (If you have young parents around you, please try to be compassionate.)

But for some reason I'm more effective now than I ever was. I can remember "not having enough energy" to complete some project for as long as I am alive - even when I was alone. It is clear to me this had very little to do with my actual life and more with my attitude. My life is more complex and demanding than it used to be but somehow I still managed to lose 60lbs, learned to read Latin, took guitar lessons and started a business. Every single one of these items never would have left my todo list without my family. They have endowed me with a keen sense of priority which made planning my life quite easy to be honest.

I know those achievements I listed are not that hard, but for me they are significant. I've found most things in life don't require your eternal soul as a sacrifice, they just take (usually a lot of) time and so you need to be strategic about your goals. Take it slow, don't burn yourself out, but also don't stray from left to right unnecessarily. Keep your eyes on the ball. Don't shift from "write a compiler", "read latin", "write toy OS", "build cpu from nand-gates" to "learn german" and back to "learn to draw realistically" in a month. Focus. A dirty word, I know, but a powerful one.

We don't. It sucks. And if we ever mention the impact of having a kid on our quality of life it makes us bad parents and terrible persons.

I should have resisted more about having a kid. I am happy we made only one.

Because as children age you're able to reclaim some of your life back. At least, if you don't fall into the trap of them living a packed schedule themselves.

I've got three, the eldest is now old enough to babysit the rest if needed. With a consistent bedtime and family nearby to care for them on occasion, my wife and I do get some spare time. We mostly choose to spend that together but we can pursue our own hobbies also.

And how I envy the idea that living close to family would save you time instead of draining some.

It sounds like you and your partner should work on splitting the load more. You don’t need both parents to look after the kid constantly, you can often take turns. Kids can also watch TV and all kinds of stuff. They also have earlier bedtimes, giving you even more free time.

Turns out that you need 3x the money when you need to feed 3x the people, so no, my job is not as meaningful as it could be and while you can't say it is my child's fault, that certainly caused my family status.

I started playing with some kind of programming when I was about 9-10, BASIC on a MSX and later HTML that opened up me for web development on ASP 3.0 and PHP at the time.

It was a very big hobby when I was young and turned into a career when I was pretty young, about 16. It stayed as a hobby for another 9-10 years but I got to the point where thinking about programming outside of my paid time was exhausting...

It helped me tremendously, I would never have a career if I wasn't extremely curious about programming for 15-20 years of my life, I just got to the same stage as you did.

There is an evergrowing and endless list of things I want to learn and experience, staying on top of the latest tech on my own free time is just too costly nowadays. I still do it, when I need it for work and during work hours, and all the accumulated experience helps me to figure out things way faster so I don't need to use my free time to catch up. Increasingly rarely I get that curiosity again, to use my free time to study something work-related. When I do it nowadays it's for much larger and abstract concepts such as organisation culture and change, team spirit and building trust and effective communication.

I noticed that the past 5 years of my career has been much more about the human and social aspect of work rather than technical ones. And I didn't try to become a manager, tech lead or product owner, it has just attracted me as I think I always got attracted to gaps of efficiency at work. It seems that seeing this human aspect of work brought me closer to more human aspects of life (arts, music, sociology) and a bit away from controlling the machine I learned when I was a kid.

You seem to have a really nice outlook on things so I'd really appreciate any hints on how to reconcile this and get to where you are! (I dont have any kids yet)

If you think otherwise, it's probably your ego lying to you.

That’s a long winded way of saying, no ones individual contributions are that important... it’s only through the concert of others that any person reaches those heights.

You can sacrifice sleep, but that's not sustainable for everyone.

My partner and I block out a couple hours each week for the other to wrangle the kids so we can work on our various hobbies/projects. I've found that when I work on my computer-based hobbies I usually end up frittering away half the time reading online news whereas outdoor construction, yard, and bike projects don't seem to suffer from that so they end up making more progress.

Hopefully in ~5 yrs I can actually do some of these things with the kids and it'll get a little easier.

I am maintaining a list of them in a notebook, and am trying to limit the number of them to not more than 8-10 at the same time. And I can only start a new one if I finish an old one.

Everything in that list is a task with a clear Definition Of Done, so I know when I can cross them out. Realistically, each of them would take from 4 hours to a week (assuming full-time). Over the years, many things got done. Slower than I'd like, surely, but I think a SaaS business will come out of those TODOs in a few years.

This way, things are moving forward (since I must complete something), but I am allowing myself freedom to switch effortlessly. That motivates to do *something* when the hour comes. :)

I have a full-time job, two-kids and a small SaaS side-business and it is all consuming.

I either get up early or stay up late to work on my own stuff.

The goal is to transition into working for myself but that is going slowly and I’ve been at it for a while so I’m feeling a bit burned out lately...

Thoughts of just selling the damn thing and just working my 9-5 are becoming more frequent...

It has replaced about a third of my income so the goal is to start another project soon.

But yeah, right now I'm both single and in lockdown, and if it was any other way I wouldn't spend a week just programming some sort of custom build/deployment agent.

With kids? One of my colleagues once told me that once you have them, you'll suddenly be out of time you didn't even know you had in the first place.

There’s a nice side-effect, too: The CI definition documents how to compile the project. I recently dug out an old LaTeX “project” and there was nothing, no Makefile or anything. Had to look up everything again to get it to run (with XeLaTeX and Biber).

A little combination of the right personal interests and perspective goes a long way towards building up resilience to deal with the ugly bits.

Even within the last few years of my job, we've had numerous disruptions to our automated builds due to everything from repo changes to version bumps in our fundamental deploy tools. I've got a self-assigned action to take just tomorrow due to how a change in how secrets management has now disrupted our performance testing process available to devs. Anecdotally, it seems more and more that as newer build tools move forward, they rarely seem to prioritize compatibility with existing methods (I'm looking at you, k8s, and your API versioning; "where feasible" turned out to be a loose definition).

Unlike, say, tasks on Azure DevOps. Not a fan of those.

Okay, sure, but that's not an argument for CI. That's an argument for a Makefile.

In fact, I find myself going back to Makefiles all the time not in spite of all these specialized build tools, but because of them. Even if the steps are straight-forward for someone who's familiar with the tools, just having a Makefile there in the repository root will be helpful documentation to help someone new (or myself in 2 years) get started with how to build the stuff. For example, for LaTeX, it could be something like:

  build: slides.pdf handout.pdf

  %.pdf: %.tex
    pdflatex $*
    pdflatex $*

Several years ago, I started using make extensively. Not to compile, but to automate. Make understands failing and dependencies. Also, bash and zsh have wonderful completions.

I used to write a bash or python script to do this. They often turned into their own projects and were painful to document.

A great make example (thanks Aaron) is on YT: Using Terraform, Packer, and Ansible Together": https://youtu.be/pkEezNSFWtA. Aaron automated it all with make.

Ya, I know... Make was created in 1976 to compile Fortran. It's old school. I love it.

I use it to test my kubernetes CSI driver on 5 versions of k3s with a single make call. That call is the tip of a dependency tree. The leaves end up being a line or three of bash running Ansible, Go, Helm, etc, but could be anything.

Documentation is simple because the make dependencies are so easy to follow. They are much of the documentation. The docs are correct because we execute them.

There are three forms of cognitive workload: Intrinsic, External and Germane.

Intrinsic is things you just *know*. How to write a class in java, how to write a query in SQL, ...

External is stuff you only need occasionally, and need to look up every time: How to deploy to X, how to set up CI/CD, ...

Germane is context knowledge. Usually referred to as business knowledge.

You want to keep external cognitive load a minimal as possible. You can really dig deployment and stuff, and then this becomes your intrinsic cognitive workload and coding becomes more or less external, but for somebody who just likes to code, it's best to once do a deep dive to deployment logics, write a scaffold and stick with an automated version forever.

But I agree about the cognitive load. I have ADHD so in order to qualify as "high functioning" I need to continuously improve my coping strategies when it comes to keeping that load low. I write everything down. My thought process is anchored in long text files with hundreds of indented lists. My programming style is super verbose and perhaps a bit enterprisey, but each class does one thing and I always spend extra effort making sure the things I can re-use work well enough that it's safe to forget how they work.

Oddly enough, my reserves are much bigger when it comes to programming. I remember having trouble with some linear algebra homework - it involved a lot of matrix calculations, and my results just didn't make sense, and I couldn't focus long enough. So I programmed it instead, and it worked immediately and solved my homework. I think it was about change of basis, which actually got me side-tracked because I realized the same code could be used for a simple 3D renderer. And that's what got me into computer graphics. What was the topic again?

Also adhd, and our coping mechanisms are similar.

What are you basing this opinion on? :)

---

As an aside, the blog in your profile link ( https://teraku.me) has an invalid HTTPS cert. Seems to be for a different domain.

"Don't become a well-rounded person. Well-rounded people are smooth and dull. Become a throughly spiky person"

-Bruce Sterling

I've been following a similar path: automation and testing give me certainty and peace of mind when I'm working on bigger teams, so they should also improve my personal projects, right?

Well, the difference is that my personal projects are used only by me in limited ways, and I also don't have to worry that someone will break the build when I'm not looking. So the extra work making things super safe would not pay off that much.

Except when I feel I'm losing grip on what I'm doing, either from having to cover many use cases, not being experienced, unstable dependencies, or risk of data loss. That's when I set up CI pipelines for my personal projects.

When someone at work says "Hey, lets just use Xyz package I found online! It does just what we want!" you need to ask: Who fixes it when it causes a problem that stops us from shipping? Who does the security audit? What data does it collect, and to where does it send that data? What will adding it do to our software's performance? Who decides when to update it to the next version and verifies compatibility? Is its license compatible with our workflow/software?

All of a sudden, people are less excited about that great doodad they found on StackOverflow! I'm always troubled by the cavalier attitude about relying on external tools and library dependencies. Yolo just pull it in! In some cases it might be the right decision, but not always. And, avoiding third party stuff is not always just blind NIH mentality: There are costs to depending on someone else for your project.

"It's just a simple JSON parser, we can write our own" is a dismissal that can sink you down a rabbit hole of bugs and future technical debt.

The most important thing about using a third party library is that its easy to replace with another one if it doesn't work out.

Don't let third party data types or dependencies leak out of the module where you use them, for example via an API, and things go a lot smoother

Old, established third-party dependencies are not necessarily better for the job than new, trendy dependencies. Their entrenched nature can be an advantage and also a limitation. And when you roll it yourself, then that is of course the newest and least established solution of all.

They WILL be great. They'll do exactly what YOU need them to do, and nothing else.

Software at present is a disaster, partly because we're just piling on complexity all the time, thinking only of the benefits and never of the huge downsides ("fighting with tools").

Everyone has slightly different needs, so that is exactly what creates the complexity disaster you are talking about. I think that being more willing to re-use the existing work of past developers actually works to reduce this problem.

In a team of course it would be different - unless I perfectly document my own code, my colleagues would be better off with something they can actually google.

The mold “operates” in roughly two modes: exploring and exploiting. It explores to find the food and then it exploits the best paths to the food to consume it.

I feel our minds work in a similar way, we explore when learning new stuff and then we exploit when using what we learned to accomplish something.

Probably most of the work that majority of people do is mostly exploiting previously learned stuff, with some limited exploration sprinkled into it every now and then.

Now here I sit, Sunday, staring at a terminal window to force myself to set up a ruby on rails app on Docker so I can shove it into a EKS setup I will set up with Terraform.

Could I do this at work? Yes. Except No. In the hours of 'free time' between meetings and other work, I feel too mentally foggy to play and learn new things.

Please.Help.Me.

I think I just need a vacation.

I fought docker and all of that but had some time last year between gigs and spent a few weeks examining the state of things and experimenting. The most influential of works were recent guides by Michael Herman. [2]

In the process I learned to set up not fully reproducible server setups but branch and commit message-specific CI/CD workflows using Github Actions.

It turns out it is like most things, hard and complicated until you know and have living samples and then it seems relatively straightforward and efficient.

GA is still fairly young and there is still opportunity to create and share flourishes of art in devops there.

[1] https://www.digitalocean.com/community/tutorials/how-to-set-...

[2] https://testdriven.io/blog/deploying-django-to-digitalocean-...

Even purely in code, you always (EDIT: usually) have the choice of implementing a solution yourself or finding the work of someone else, packaged into a library, which solves the problem for you.

Implementing the solution yourself may be the most satisfying way to scratch that instantaneous creative itch. But does it create the end result which you can be most proud of or satisfied with?

In my experience, this isn't remotely true, especially if you're constrained to use a particular language and don't want to pay the overhead of wrapping another language

Using the same motivation: "let's play with things and see what I can figure out", I created a video [1] where I figure out what I need to do to create a silly version of the cat command that prints text out upside-down.

I did it for a bunch of reasons: figuring out how to replace system commands, learning a bit more about Unicode, trying out our C extension for VS Code, learning the process for building YouTube video (which was a very deep rabbit hole) ... all to produce a single video. It was fun, scratched an itch that I've had for a while that I'll continue to work on.

[1] https://www.youtube.com/watch?v=OJ2ivP2llFs

At work, and in this domain:

> I wanted to learn some new frameworks and concepts to help with that, and I decided to make my personal projects a bit more "professional". Use continuous integration, focus more on web stuff, build and automatically deploy containers and so on.

It's all docs. It's all "This thing was supposed to happen but ____ didn't do what I expected". Fighting with tools and configuration and triggers and stuff like that is the opposite of zen.

Yeah, I've basically moved on from anything that isn't Caprover + Portainer. Fuck the rest.