Forem: Jakub Senko

React timed server-side flip just right

Jakub Senko — Thu, 21 Nov 2024 10:04:14 +0000

One theme of web dev just keeps coming at me: server-side React. Last time, it was an excellent article from Christoffer Artmann. His argument about closing frontend/backend gap is so on point.

And this single argument connects to Gergely Orosz's What is Old is New Again in my mind.

You see, everybody is talking about layoffs, hiring freezes and difficulty for (even senior) software engineers to land a new job. I instead hear a strong signal from companies that it's time for function over art.

What do I mean by that? Until relatively recently it was so easy to convince exec team that we need that microservice architecture. Or we must try that new ORM lib before it is cool.

Ties have changed. Budgets are limited. We don't have time to play with new toys anymore. One guy who is "old-fashioned", yet able to deliver end-to-end is suddenly more valuable than all those specialists combined.

In Gergely's words: Fullstack is in full swing.

Not a good time for client-side UI libs. Unless... you go fullstack!

There are two points that pop in my head:

Big pro: I am a big fan of single-language stack, so server-side TS gets my approval.
Big con: React, even with server capabilities, is still just a UI library. We need Laravel-like framework to be able to beat that "old-fashioned" guy!

And so I am sure React team had great intuition with this decision. But we are still waiting for community to respond with a game-changing framework.

I will soon publish an article about my vision of Laravel-like React framework. If it got your attention, follow me!

On responsibility and limited PTO

Jakub Senko — Fri, 25 Oct 2024 12:34:37 +0000

Every single software engineering job posting I read expects responsibility. Almost none offer unlimited PTO or at least non-8h workday. And I don't get it, because the two are closely related.

We aren't a factory workers. Our work is creative (as we create things). Creativity cannot be pushed, cannot be forced, and cannot be timed. It can be encouraged, either by moving your body, focus times, exposing yourself to new experiences, or many other means. But it definitely doesn't obey to working hours.

Sometimes I need to sleep on the problem. There is no point in waiting till 5pm, I won't move by an inch.

Sometimes I need to solve my family problems before I can fully focus on the task at hand.

Other times, after finishing stressful project, I need 2 weeks off. Even in December when PTO is used already.

And sometimes I take 💩 to work for a nice 30min break nobody complains about.

You get the point.

Let's focus on the outcomes instead of outputs.

Solve communication problems. Eradicate waterfall effects. Encourage collaboration. Promote knowledge sharing. Foster trust.

And give freedom to the employees. 🙏

Except for one instance. Unlimited PTO needs to be accompanied with a minimum!

If you must, compare their performance, talk to managers from other companies to get the benchmark. But this is rarely needed when trust is living inside the company.

You had enough courage to offer flexible working hours? Remote jobs? Great! Next stop - unlimited PTO. That's what Freedom & responsibility ultimately means:

I trust you can do this, do it your own way.

And for the sake of your own success, apply the same to freelancers - do not charge them by the hour. 📅

ONCE is apples, SaaS is oranges

Jakub Senko — Thu, 12 Sep 2024 07:14:07 +0000

A reaction to David Heinemeier Hansson's (DHH) fireside chat and ScaleUp&Up podcast.

David has talked about a lot of topics, and two most resonating ones are cloud exit and the once model. Theo has published a great video reaction on cloud exit, so let me focus on the once model only - and why I think he omits a lot of important aspects to portray the once model as a good business strategy.

First, let me acknowledge that I think the once model wraps not one paradigm change, but two actually, and this realization is important. First, it removes "aaS" from SaaS, leaving you with bare software, no service. Second, it replaces a monthly pricing with one-time payment. I will touch on both changes.

It's not really once

In the podcast, DHH talks about Adobe as a good example of the once model-driven successful company. However, in reality Adobe was a once-a-year fee company. I don't know any graphics designer who didn't upgrade to the newest version every time it got released, and Adobe knew that very well. It forced Adobe to innovate faster, probably, because each major release had to be that much better to persuade customers to purchase again, but I don't think it is honest to call that kind of pricing form the once model.

Funny enough, it's the same with Campfire - updates are provided for free only up to next major version.

It's not really cheap

Companies don't usually think in terms of total valuation, but rather in cash flow. It is difficult for company to purchase an expensive item, that's why loans, leasing and other financial tools exist. I dare to say that SaaS monthly pricing is another such tool, because it allows your company to skip the bank and purchase highly complex and expensive software as a loan really. With almost all risks moved to SaaS vendor. Monthly pricing is a financial leverage!

Back to Campfire. It is unbelievably cheap. I wonder if it is profitable even. But even if it is, the price doesn't reflect all the inputs other companies had to deliver or are constantly delivering, see next points.

It's not really all-in-one

Support. Let's look at Campfire again. It only includes bare bones support. While any SaaS keeps customer support up and running to satisfy customers every single month, the once model just skips that part altogether. You may argue that some customers want this support-excluded deal and you are probably right. I only argue that those products aren't batteries included and that is reflected in the price.

The same applies to running costs - the once model just offloads this to the customer. This may be just "running one command", but I rather think it means hiring a DevOps - not cheap, and not once. Not to mention that SaaS has ability to optimize running costs by centralizing it while self-hosted server most probably stays underutilized for the most of the time.

It's not really innovative

If you’ve used Slack or Teams, you already know how to chat with Campfire.

That's the problem! All the research towards UX was carried over by Slack, Teams, WhatsApp and who knows who else. I am not against copying good designs and user patterns. But I have a feeling that this particular product is cannibalizing on that, allowing it to lower its price. Again, it is actually good that we are able to optimize production, but in the world where everything is the once model we may have no innovation eventually!

It's not about production costs only. Take Spotify vs iTunes example. Before Spotify was a thing we purchased every song for 1 USD. Can you imagine that now? Spotify has revolutionalized the way we purchase music, solving music pirating in totally unexpected way. Not to mention that barriers to discover new authors are ridiculously low, almost non-existent today. I don't want to return to the once model in music.

It's not really protecting the business

I am old enough to remember cracking software that bypassed the once model software's license verification to use it for free. Adobe remembers it well, too. Can you fight this? I guess you can, partnering with OS producers, a big lawyer firm, or by other means - all costly, reflecting in the final price. SaaS, by running software under its own conditions, is avoiding this trap, allowing further price optimizations.

It's not really simple

Imagine you'd have to manage servers for every single software your company owns. If you don't employ a senior DevOps your hard-earned company might suddenly be offline, hacked or compromised in a thousand other ways. There is nothing simple in running servers, starting from physical aspects like material failure, up to security holes in (not updated) OS, or even the once model product itself. David himself is hard proponent of compressing abstractions, and in my point of view, cloud compresses servers, and SaaS compresses running software on those servers.

It's not really the same thing

Ultimately, you may think that using the once model is just a relic of the past. I don't know. Maybe it is a pendulum swinging back, but maybe it is a model long-overcome. Only time will tell, and I want to thank David for doing it, because it is to the benefit of us all when businesses challenge standards.

So the once model vs SaaS? Let's just remember that we cannot compare apples to oranges.

Trivia: I always enjoy listening to someone who is highly philosophical, an art I don't see often in these times.

Fingers crossed, David! 🤞

Remember "divide and rule"

Jakub Senko — Mon, 09 Sep 2024 07:14:01 +0000

Divide and rule, a strategy known for millennia, from Roman Empire, to Napoleon, to British Empire is not just another military or political technique. It is one of the best tools I have ever used to conquer my enemies - technical and business problems.

You may not realize this, but divide and rule is everywhere around you:

feature flags & A/B tests,
extracting part of code to separate function,
separating concerns (e.g. MVC pattern or per-domain folders),
ICE scoring and implementing just top of the list,
ideation / research / design / implementation sequence,
and many, many more.

These are the good examples. These are the times when you are the emperor utilizing divide and rule.

However, just like fire is good servant but a bad master, we all sometimes become the object of this grand strategy when we:

allow being distracted from deep focus,
refuse to communicate, throttling the spread of knowledge,
accept "while you are looking at that part of the code, why don't you fix this long-standing bug there as well" aka context switching,
implement feature before giving it a thought,
trying the same procedure over and over when debugging,
looking for faulty commit one by one (instead of git bisect)
don't take apart our challenges into screws (when estimating time or trying to understand the complex concept),
and the list goes on.

So think about the forces that try to divide you, and come with the ways to divide them instead.

And next time you are stuck on a problem, ask this simple question: how can I divide this problem into smaller parts? It will result in impera.

"AI" will not replace you

Jakub Senko — Tue, 20 Aug 2024 14:37:56 +0000

This article is the last part of a series of notes on Gergely Orosz's What is Old is New Again talk that attempts to put his predictions (that strongly resonate with me) into practical steps for smart software engineers.

"Finally, the elephant in the room: AI"

Few weeks ago my brother, who is software developer, told me that he is afraid that AI will replace us. While I understand his worries, I was never afraid of such scenario.

Yes, AI (let's call it by its true name: LLM - large language model) looks freaking smart when used for the first time. It "understands" you in almost any human language, can reply in that same language and can produce very appealing answer - be it text, image, structured data, code or even a video. It can seemingly consume all human knowledge into one gigantic mind and throw PhD-level answers in all industries at the same time.

Until you start using it daily.

Limits we don't want to see

A word hallucinations become almost as popular as AI, because LLM often outputs what looks like a competent answer, yet it is completely off.

On top of that, if you ever tried to use chat LLM for a longer discussion, you most definitely realized at some point that it stops considering your commands given earlier. This phenomenon is called "context overflow", and simply means that the LLM isn't able to hold that much context, although for a human mind it might seem minimal.

Context overflow, however, is just the symptom of much deeper problem, which is the cost of running LLMs. Every chat, image prompt or code suggestion is very, very expensive. We will eventually optimize this (e.g. Github Copilot is quite cheap for the value it brings), but keep in mind that most of LLMs today are burning money and given higher interest rate this will not last for long. 💰

The biggest problem of all is, however, the fact that LLMs train more and more on its own output, eventually collapsing into world of hallucinations. And while some LLM producers claim to be able to detect AI text, this is ultimately an endless race.

Not a first rodeo

Also, let us remind that this is not the first AI hype. You can read more about AI history here, here, here and here. Tldr; it is getting better every time, but I don't think this time is the ultimate one - especially because it looks like we already hit the plateau.

The decision maker

Now to my final argument. "AI" isn't gonna replace you, because it, in current form and shape, lacks two deal-breaker attributes:

It isn't creative, meaning it only outputs what has already been out there in the past.
And it cannot make decisions. I literally tried to force ChatGPT into making business decision by "acting as CEO", but it refused. It gave me some answers, but also emphasized that I should take them as suggestions, not decisions.

And this is the reason why it won't replace your creative job of architecting and building software. It does make us super-productive (thanks for that!), but it isn't nearly close to becoming a decision-maker you, as a software engineer, need to be basically constantly.

So don't worry about your job. Instead, embrace the LLMs and become more productive thanks to them.

Bonus: "AI" is already everywhere

From fraud detection, recommendations, predictions, digital assistants (Siri, Alexa), translations, healthcare, advertising, weather, etc. - usually just called neural networks, world is full of AI that is not LLM, but a serious business value tool nonetheless. Let's not forget to look at the bigger picture in times of unease.

Product engineers

Jakub Senko — Thu, 15 Aug 2024 09:10:01 +0000

This article is part of a series of notes on Gergely Orosz's What is Old is New Again talk that attempts to put his predictions (that strongly resonate with me) into practical steps for smart software engineers.

"Become more product-minded / business-minded"

I like to call product-minded engineers simply a product engineers, because it is important for me to acknowledge, that I own the product I am building.

It is not a nuance.

I have seen engineers not giving much thought about what their code is going to be used for. I have seen engineers not testing their code, because (their own words) the company pays for a dedicated QA person. I have seen engineers not releasing their code to production, leaving it for others (including emergency rollbacks). I have seen engineers ignoring analytics.

And those engineers, IMHO, do not understand the single most important aspect of building a successful, effective software.

Ownership

I did what the task said, why do you put blame on me?
-a random engineer

In some companies, I assume, there is a great chasm in between technology and product people. Product people think about what and why, and then produce a task. Technology then solves the how and deploys the output. If the output backfires, technology puts the blame on product guys, because engineers just did what PMs said.

As soon as you, as an engineer, degrade your presence in the company into how, you essentially became a workforce producing code. And you know machines do replace workforce, do you?

We will never be able to take what from product, because that is the essence of their roles (that's a good thing!), but we can - and should - contribute to why, if not to both.

And this is done by firstly acknowledging, that we, as product and technology together, own the product.

Influence

As soon as you take ownership seriously, a door to product world opens up and you can observe, understand, and influence the business decisions. This is extremely important, because your proactivity can produce or save huge money. And whatever your boss told you about vision, mission and values - just remember that (except for non-profits) your company exists to make profit. The more you contribute, the more valuable you are. 💸

Gergely wrote an amazing blog with practical steps towards this attitude.

And this mindset is simply invaluable in recessions, where every dollar earned or saved is celebrated. You essentially become recession-resistant engineer.

Bonus: Do not be afraid to speak up

It may be tempting to be silent during brainstorming / ideation sessions as an engineer (or not attend at all), because you may thing that product people have much more information about the subject. I urge you to raise your voice for two main reasons:

Your perspective is different. They hear customers (current ones and the future ones), query analytics, see business implications and are trying to make meaningful compromise. But only you can see that the analytics isn't set up correctly and the data cannot be trusted. Only you can see that one feature will take 10x less time to build. Only you can see that the external tool they want to use is missing an API - an important piece for automation. Do raise your voice, do not be afraid to look stupid.
Your opinion is equal to the others. This is especially true for brainstormings. I have experienced this an endless times. What sounds like a stupid idea in my head wins the most votes. You just never know.

Stay tuned for the third note in which I will conclude this series with my thoughts on "AI" replacing engineers.

Javascript is without a fullstack framework (and will miss fullstack era this time)

Jakub Senko — Mon, 05 Aug 2024 09:23:52 +0000

This article starts a series of notes on Gergely Orosz's What is Old is New Again talk that attempts to put his predictions (that strongly resonate with me) into practical steps for smart software engineers.

"Fullstack is in full swing"

When you start thinking about fullstack frameworks, you most probably think about the big three brothers: PHP's Laravel, Ruby on Rails and Python's Django.

Now narrow your scope down to JS/TS.

Anything?

If you ever heard of RedwoodJS, AdonisJS or NestJS, those might be the closest ones. But let's be honest, nobody is talking about them, few are using them, and they definitely didn't grow enough to be put on pair with the the big three.

And they still lack features we love and use every day (such as CLI, queues, (DB) models, and more) and/or ease of use/development/deployment, tests, community, etc.

Next.js?

Let's talk about Next.js, probably the most popular JS framework these days. Vercel (owner of Next.js) doesn't mention "fullstack" keyword anywhere on the visible side of the website, yet their meta descriptions says "the full-stack React framework for the web". I'd challenge their choice of words, but I am sure SEO comes to play here as well. In my definition, fullstack comes with a complete set of tools to cover development from end to end, yet Next.js doesn't care about DB communication/schema/migrations, authentication, authorization, and so much more. Recent merge of Remix (main competitor) with React Router just shows the harsh truth - that these frameworks are just a router on steroids.

The Javascript way

Then there is The T3 Stack, a mere collection of libraries that got more stars than two our of three JS fullstack libraries mentioned above!

And with recent trends being just about "moving to the server" (State of JS 2023 conclusion from Theo Browne, T3 Stack creator), we are clearly far from fullstack.

Action points

So my predictions are:

Fullstack era will indeed come.
NestJS won't become popular enough, and thus JS will miss this round of fullstack frameworks prevalence.
Companies will use the big three or a combination of TS libraries (T3 Stack or similar) to stay one-lang.
Knowing TypeScript is a must.
In order to remain relevant in the job market, we need to be fluent with at least one of the big three.

My personal action point is to learn Django. I have past (working) experience with Laravel, some (university) experience with Rails, but I never touched Django, and barely worked with Python. Time to change that!

Bonus: An interesting approach

What I appreciate seeing in recent years is the attempt to form fullstack JS/TS framework from different angle, and that is from frontend to backend (opposite of where all the big three came from). I can see the trend all over the place, with Partial Prerendering in Next.js, to Astro Islands, to Streaming in SvelteKit. All the big three struggle with frontend interactivity, because they need JS to serve that purpose. What if we solved interactivity first, and then added all the boring (but mandatory) tools to JS frameworks later? Only time will tell if this seemingly weird approach bears fruit.

Stay tuned for the second note in which I will discuss how product/business-minded will get (un)fair advantage in their next job hunt.

Case for explicit error handling

Jakub Senko — Fri, 24 May 2024 08:06:33 +0000

One of the best articles on front-end app architecture I have ever read suggested not-so-popular patterns, including headless approach (data and logic are strictly separated from UI - e.g. React), explicit initialization (manual dependency injection), or reactivity aversion (no useEffect, or MobX's reaction). Over the years I have seen the benefits of all the patterns except for one.

It is called Concentrated error handling.

The pattern suggests designing code so that error handling doesn't have to be written for each individual call that can fail. It even encourages to treat catch clauses as code smell.

My experience just can't seem to find peace with this pattern. Let me give you my biggest concern wight away:

User experience.

🥰

Why user experience matters the most

You see, we are talking about front-end apps here. They are specifically meant to provide UI to user. They exist for the user. And if you handle your errors in one global error boundary, you compromise user experience. How?

I have been working on a project recently that relied on a single error boundary to do all kinds of stuff we do when our app throws an error:

log to console
track to monitoring software
show error message to user

Can you guess how the error message toast looked like? Yep:

This is wrong on so many levels! User must be able to read the error message in plain language, understand the problem, and ideally be able to recover from it (Jakob Nielsen's 9th heuristic rule). But with one (or even multiple) error boundaries you (most of the time) aren't in the right context anymore to be able to provide user with the least painful experience.

Let me show you how I envision error handling in front-end apps.

I am using fetch as an example, but this can be anything from websocket connection, browser APIs, library & framework calls, etc.

✨

Separate severe errors from enhancements

Sometimes data we show aren't strictly needed for the user to perform the task. For example at slido.com's PowerPoint page, information about version and package size are nice-to-have, but user is still able to download the integration even if endpoint with those information failed. We do not need to show error message to user. Instead, we do nothing - and that's user's least painful experience.

You will be surprised how much information is optional once you start paying attention to it. Are you deleting a team in any SaaS app? A list of users of that team is usually a good visual indicator for the admin of how severe the action is. But if that request fails, admin is still able to delete the team - and therefore bombarding him/her with messages about failed request is absolutely not least painful experience.

With global error boundary, you don't get enough information easily to decide whether the error comes from enhancement or not. Take this example:

const init = () => {
  const response = await fetch('/api/version-and-size')
  ...
}

const main = () => {
  try {
    init()
  } catch (error) {
    // All info you have here is generic `TypeError ` in `error` variable.
  }
}
main()

We literally have no idea what endpoint failed. Therefore we cannot decide if response data are enhancement or mandatory information.

Whereas in this slight change:

const init = () => {
  try {
    const response = await fetch('/api/version-and-size')
    ...
  } catch (error) {
    // Code context gives you hint that this failure is just enhancement.
  }
}

const main = () => {
  init()
}
main()

The code itself gives you enough context to react to error appropriately - that is to ignore it.

🛠️

React to error in the best manner possible

Now that you purposefully ignored enhancements, let's discuss handling of severe errors.

Imagine social network such as dev.to where blog posts functionality is present. You want to edit a post. Two possible points of failure are:

loading current post content into the editor,
saving edited content.

Both cases can fail on the same network level giving you exactly the same error, yet handling should be radically different:

When post content fails to load, a big error message (maybe replacing whole editor) should ask user to attempt to reload the page or manually re-trigger content fetching.
If saving fails, you most definitely don't want to remove the edited content with big error message. Instead, a toast informing about unsuccessful saving asking for a retry later is correct way to do it.

This isn't possible with global error boundary, because, again, you don't have the context (and maybe also access to models/components that need to be updated).

This article doesn't discuss the best patters for error handling, but there is tons of materials about this topic on the Internet.

🫂

Code colocation is your friend

You are probably thinking: hey Jakub, I can write a generic wrapper around fetch that will catch TypeErrors, add necessary data to it and re-throw it. That way my global error boundary has the context you are talking about.

And you are right, except for one thing. You start rolling your spaghetti if you ever use that additional context for conditional actions:

const main = (mainController) => {
  try {
    init()
  } catch (error: EnrichedError) {
    switch (error.endpoint) {
      if (error.endpoint === '/api/version-and-size') {
        // just enhancement
        return
      }

      if (error.endpoint.match(/\/posts\/\d+\/edit/)) {
        mainController.postEditModel.error = true
        return
      }

      if (error.endpoint === '/edit' && error.method === 'POST') {
        mainController.toast('Saving failed. Please try again later.')
        return
      }

      ...
    }
  }
}
main(mainController)

This is what I call a code smell! Instead, let's leverage existing (implicit) context and also make sure that related code sits together:

try {
  const response = await fetch('/api/version-and-size')
  ...
} catch () {
  // just enhancement
}

...

try {
  const response = await fetch(`/posts/${postId}/edit`)
  ...
} catch () {
  model.error = true // notice we don't access `mainController` anymore because we are in the context of `postEditModel`
}

...

try {
  const response = await fetch(`/edit`, { method: 'POST', body: JSON.stringify(data), ... })
  ...
} catch () {
  mainController.UIController.toast('Saving failed. Please try again later.')
}

🌐

On global error boundaries

Are global error boundaries any good then? I think so! They excel at tasks that you want to perform for every error out there: logging to console, tracking to your favorite monitoring tool, or even as a fallback for all the errors that aren't explicitly handled (although I'd say log those cases just so that you can add explicit handling later).

Also, top-level error handler is important for the user, because it serves as a last resort for catching unhandled errors and displaying meaningful error page to the user.

With this in mind you can sometimes purposefully handle errors implicitly. For example if app initialization relies on a request and app cannot be initialized without it, you can ignore try/catch block there and let global error handler display unrecoverable error page to the user.

Conclusion

Global error handling compromises user experience. Handle errors explicitly to leverage its implicit context. It will help you choose the best reaction to error to optimize for least painful experience for your user. Use global error handler to catch and track yet unhandled errors. Remember: you make front-end apps, user comes first.