Things just got started, so at first I thought it'd be too soon to write about it. But then I reminded myself that reflection should be done even as things are progressing, perhaps that's even more important than a big-ass end-of-year or end-of-journey review. So let's just chill and jot down whatever relevant points that come to mind. Plus, this is a perfect time to really let go of the lesser obsessions (like choosing words), and just keep an honest journal.
So I started looking at freelancing opportunities back in June. This whole thing is a huge culture, and it can be overwhelming to newcomers, but I decided to just try one thing to get started, and naturally that's Upwork, something I heard from Chris' blog (he's the author of SumatraPDF). Setting up the profile, including a brief resume, etc, fine, but the real work starts when you look for actual jobs, and that's overwhelming. Where do you even start? Web app dev, front-end dev, etc, that sounds like a decent place, right? There were so many, I remember the very first one I looked at and considered applying for was a simple web app (party game with no back-end). Great, I will use Elm, I thought. But as I looked at the description more closely, it raised some suspicion. You must pass validators for JS, CSS, etc, well, bummer, because I use Elm-UI instead of CSS, so it's not handwritten. But that's not the deal breaker. Then it literally said, it's a project they didn't have the time to do, and they wanted it done by a contractor so that they could post the code on their own GitHub repo, etc. Whoa, what kind of project? Tell me it's not a school project. Point is, it's my job to make something useful for a client, sure, but if what they're after is just the source code and they literally said "copy/paste", that sounds to me like an academic integrity violation. And that's the end of it.
Well, I expect a lot of failures, I set a goal, that by the end of this year, I get to start work on something. So I kept trying. Next I thought to narrow things down. Let's see whether some people specifically want Elm. Not that many, it turns out. Actually, among the search results, most just tagged "Elm" as a keyword, but never mentioned Elm specifically in the description. Only two were serious about Elm, and they're both hire instead of contract (namely, they want you to join their team, instead of giving you a specific project). One of them was a senior leadership position, and that's obviously out of my league, for I have no leadership experience. The other was more down-to-the-earth, but I also felt inadequate, because in one of their linked articles, they stated their focus on UI animations, which I never learned anything about. Bummer, again. But as I read the description again, I realized that in the text proper, they never actually mentioned animation per se, but just expressive UI in general, and they just wanted to see some interesting UI in the application/proposal.
OK, I'll give it a try, even if it didn't work, it's worth doing just for sentimental reasons, because they love Elm, and I love Elm, too, so it'd be a nice token to keep that my very first freelance proposal was about Elm. I picked the chat app that I worked on back in 2022, because
-
It's so far of the largest scope among my personal projects, featuring a responsive Elm-UI front-end with i18n support, dark/light theme switching, authentication (JWT), real-time status indication, both text and image message storage via IndexedDB; and all the back-end mechanisms: WebSocket, PubSub via Redis, TLS via Rustls, password hashing via Argon2; plus the cloud deployment (Docker, Linux VM, etc), point is, it's prototype and feature-incomplete, but it's the most complete client-server app I've done so far;
-
The project was mostly about exploring mobile apps (because real-time chat is inherently about highly portable devices), and although I concluded that because of the limitation of web pages imposed by mobile browsers and most likely the OS as a whole, real-time chat implemented as a pure web app could not completely replace a native app (which then led me to learn Kotlin and Jetpack Compose in a later project), it nevertheless showed that we both cared about the mobile experience. And they have explored in this direction far more thoroughly than I have. And indeed, if one day, mobile could go full web, that would be super exciting, Kotlin/Compose is fine, but I'd choose Elm/Elm-UI any time.
So I took some time to do a screen recording for the chat app demo (rusty but got a decent result after some getting used to; no audio, just a Snagit capture on my Mac); I also added the time tracking and photo portfolio apps to the application. These two are pure front-end apps, but they are so far my only two regularly used Elm apps (I mean dogfooding, since I haven't gone on social platforms to present them yet).
I got a response soon after, which was a surprise. But more surprisingly, the client liked those examples; however, they'd already hired enough people at that moment, so I was like, on the wait-list. But that already exceeded my expectation, at least they were interested in what I had done so far, and that's truly reaffirming.
I thanked them, and added that, if they needed an extra hand later on, feel free to communicate ahead of time with me the specific skills required for the job, so that I could prepare in advance if necessary. And they listened. After a while, they got in touch and asked me about CSS basics. I never learned CSS properly, esp. Flexbox, and with me getting more and more comfortable with Elm-UI, I no longer find myself interacting much with it for quite some time now. But I know 1) Elm-UI is implemented using Flexbox, and 2) CSS is what browser understands, and by the "systems programming mindset" (by Andrew Kelley, creator of Zig), it's always empowering to work at the API level that's the lowest on your platform. After all, Elm-UI isn't perfect, and it's evolving (v2 in the making), and they mentioned performance issues with Elm-UI due to rebuilding the stylesheet. I personally haven't encountered such slowdowns, could be due to the different extent to which we use styles dynamically (Elm-UI embeds two stylesheets, one static, the other dynamic). For example, if they use UI animations extensively, that could potentially lead to a lot of rapid rebuilding. But could this problem common to all CSS-in-JS solutions? It's an interesting topic to keep an eye on.
The point is, I gladly learned Flexbox, and took notes. They liked the notes as well, and then offered further advice (per my request) that I could practice Flexbox skills by imitating apps I use or find interesting. The process of communication, pre-contract, was nice. I find them sincere, direct, no-nonsense, and I think it's a good sign that we could work well together.
The talk continued on and off, until one day, they said they liked how I took things seriously and invited me to join the teamwork platforms, so that I could get ready further.
We soon scheduled a chat, and I had no clue that it was basically an "interview", and I didn't prepare anything. I didn't do super well, given my limited speech skills, but that's not the point, we communicated fine, understood each other, and that's all it matters. Moreover, that, in a sense, is the real kind of "interview" in the ideal world, namely, there is no preparation or training, so everything you say is right out of your instinct, there's no filtering from those "practice sessions". And there's no code interview, as all we do in the team is write code, for actual projects, not regurgitation or reflex of known algorithm implementations. (I'm not saying such practices are all bad, I actually did the Flexbox Froggy game as a study prop, but it's really easy to get lost in the culture where people flock to large corps, where there're insufficient human resources to interview applicants for real-life experiences and skills, and thus such personal processes are replaced with standardized tests; speaking of which, even US institutes are moving away from standardized tests, because they understand, finally that these things can be cracked without real internalization. So again, a healthy amount of artificial problem-solving exercises are good, but it is highly exploitable in the real world if it becomes the main ruler of merit.)
The process just got started. There's much to learn, and much to communicate. But I think it will be a process of learning and growth, both intellectually and socially. I much prefer a small team, where communication is direct and organization is flat. There were previously recorded review/feedback sessions with great detail, from which I could learn about some of the common pitfalls early on, and people even helped me setting up the project when I had network troubles downloading dependencies. I'm grateful for all these things.
So let's take the necessary steps to get up to speed, and hopefully contribute to the project soon!