Anssi Piirainen

Are you a craftsman or an engineer, or both?

2025-06-20T00:00:00Z

Recently I've been thinking a lot about the software development process—things like automation, testing, and scaling. I've also been thinking about code quality. The following questions have been on my mind: What does good-quality code look like? How long should files and individual functions be? Should you break it into smaller chunks, and how should those chunks look? I've also been thinking about the timing— when these things matter the most. What are the most important things when the development organization is young (like a startup), and how do they change as the company grows (like a scale-up company)?

When thinking about different approaches to software development, the concepts of Software Craftsmanship and Software Engineering came to mind. I think the first time I became familiar with the craftsmanship idea in software was when I read the classic book The Pragmatic Programmer by Andrew Hunt and David Thomas, back when it was published in 1999. The book introduced the idea of software craftsmanship, emphasizing the importance of care and pride in software development. I highly recommend it. Good stuff in it.

I started thinking—Is it enough to master craftsmanship skills? Or should you also master engineering skills? What does it even mean to be an engineer, and is that different from being a craftsman? Let's first define what these terms mean.

Craftsmanship

Software Craftsmanship is a mindset and movement that emphasizes the art, skill, and pride in software development.

Quality over Quantity: Focuses on writing clean, maintainable, and well-crafted code.
Continuous Improvement: Encourages lifelong learning and mastering the craft through practice.
Professionalism: Values responsibility, ethics, and delivering value to customers.
Mentorship & Apprenticeship: Emphasizes teaching and learning through experience, much like in traditional guilds.
Developer Autonomy: Encourages individual developers to take ownership and pride in their work.
Craft over Process: Prefers strong technical skills and judgment rather than strict reliance on formalized processes.

I think all of the things, except for Developer Autonomy perhaps, in this list are good things and should be practiced by every developer. Let's talk about Developer Autonomy later and why that might not be so important might even be a bad thing in a team setting.

Engineering

Software Engineering is a discipline that applies engineering principles to software development.

Formal Processes & Methodologies: Emphasizes standardized methods like Agile, Waterfall, DevOps, etc.
Planning and Documentation: Strong focus on requirements, design, testing, documentation, and lifecycle management.
Scalability and Reliability: Ensures systems are engineered to scale and handle complexity reliably.
Team Coordination: Encourages defined roles, responsibilities, and structured communication.
Measurement & Control: Uses metrics, models, and reviews to ensure quality and predictability.
Compliance and Risk Management: Addresses regulatory, safety, and compliance concerns.

All of this also sounds good to me. But are they really necessary and worth the effort? When should you use them? Let's dive into that next.

A good read on this topic is Modern Software Engineering: Doing What Works to Build Better Software Faster, by David Farley.

When to do what

Startup

A young startup is first looking for product-market fit. They need to be agile and flexible to adapt to changing market conditions. In this kind of organization, you don't want anything to slow you down—this rules out most of the engineering practices. I would rule out the following, just because these are unnecessary burdens that make you slower when you need to be agile:

Automated testing
Extensive documentation
Investing for scalability (premature optimization)
Compliance and risk management

Automated testing is most likely a waste in this phase. When you pivot once a month, you’ll throw away your codebase. The code that you build for the MVPs should be minimal and probably shouldnot include many tests. But what if you can use AI to generate the tests? That might change your mind.

I would use most of the craftmanship practises in a startup.

After finding PMF (product-market fit)

Then when (and if) you finally find product-market fit, you need to start adapting your approach. You need to prepare yourself to take over the world. Perhaps you'll reach millions in MRR within the next few months. Your traffic and number of users grow, and your development team grows in size. All of these require you to change your way of doing things.

When you grow, the engineering practices become more important. You need to invest in scalability and reliability, and you need to document your code and processes. You also need to plan your development and coordinate your team. You need to make sure that you can onboard new developers effectively—and that means the spaghetti code you developed in a rush when the company was young and small might need to be rewritten or heavily refactored.

About timing: It can be tricky to know when to change from startup-style cowboy coding to a more disciplined approach. This is because the shift the company experiences is rarely an event that you can recognize. This means that you need to start shifting your style gradually, starting with small changes and gradually increasing the level of discipline.

Another reading tip: Tidy First? by Kent Beck. This book introduces "tidyings" that are small refactorings that can be done quickly and easily. These are small improvements that you can do every time you need to add a new feature to the codebase. Applying tidyings continuesly slowly moves your code to a better structure. I find the to be a great approach and avoids the risks associated with big refactorings.

Craftsmanship remains important. Developer Autonomy, a craftmanship practice, will lose relevance as the company grows. Teams become more important than individuals. Shared code ownership, as emphasized in XP and other agile methodologies, becomes more important. It's the team that should have autonomy and ownership of the codebase that is the team's responsibility.

Conclusion

So, are you a craftsman, an engineer, or both? I think the answer is: you should probably aim to be both, but at different times and in different ways. Early on, when you're in the fast-paced world of startups, craftsmanship helps you move fast and keep things just good enough without overthinking. But as your product matures and your team grows, engineering becomes more and more essential. You need structure. You need repeatability. You need to build things that won’t fall apart the moment you scale.

It’s not a binary choice. It’s a spectrum—and knowing when to lean more into craftsmanship and when to bring in the engineering discipline is part of being a great developer. So maybe the real goal is to become someone who can adapt. Someone who knows how to build quick and dirty when speed matters, but who also knows how to slow down, clean up, and build things that last when the time is right.

Working with Web Components

2025-06-20T00:00:00Z

I've been working on an alternative to TradingView since late last year, and it has been a great experience. I've been using TradingView to follow crypto prices for several years now. At some point, I got the idea that it might be worth implementing my own alternative, so I started experimenting with it.

It's now been almost six months of working on this on and off during evenings and weekends, and it's come pretty far already. I even have a website for it: Spot Canvas.

Why Web Components?

I've been working with React for close to eight years and wanted to try something different. Probably two years ago, I would have chosen React for this project as well, but since then, I've grown a bit bored with it. I've also seen how React apps can become big and hard to maintain over time — I'm no longer convinced that it's the best option for web applications.

So these are the main reasons I chose to go with web components: I wanted to try something different and also learn something new. In hobby projects, it's good to experiment with different technologies — that's how you learn and grow.

How Has It Been?

I've enjoyed working with web components! 🙂 It's been like a breath of fresh air. It has reminded me of my time working with Flowplayer when I was building the first version using Flash — I can use similar patterns and design choices that I had with the object-oriented structure I built for Flowplayer. I'm less of an OOP fanatic nowadays, so I'm avoiding deep class hierarchies and things like that, but I am indeed using classes. I think classes can be a good fit for user interfaces.

State management has been nice to work with. None of that useState or context-based weirdness I was used to in React. I'm using the ES Proxy-based solution from xinjs, and it works great. It makes things streamlined and convenient.

You can find a standalone demo of the chart here.

Tech Stack

The tech stack I'm using for the frontend (the chart app) looks like this:

TypeScript
Web components using the Lit framework
Plain old CSS (embedded in TypeScript files, as is typical with Lit)
Bun
Firestore for live subscriptions for real-time price and indicator updates

The backend runs on Google Cloud with:

TypeScript
Bun
Firestore

Roadmap

So far, I've implemented the basic price chart with trading pair selection, time granularity selection, and candlestick rendering. You can pan and zoom in both the timeline and the price axis. At first, it felt easy to develop, and I was making good progress, but as more features started piling up, things naturally became more complex — no surprises there.

I just released an Indicators feature, which is essential for this kind of product. You can read the release announcement here.

Getting to this point has taken six months.

The road ahead includes:

Technical analysis tools (drawing tools)
User accounts with settings, etc.
The ability to save chart layouts
An asset library for saving favorite trading pairs
Scripting for custom indicators and for interacting with the chart

Want to Help?

Let me know if you're interested in collaborating on this project. I'm convinced that there's a need for a solid trading chart alternative, and with the help of vibe coding, we can build something great! 🙂 I could use help on both the development and marketing sides. You can reach me at anssip@gmail.com.

The most effective way to learn a programming language

2025-06-20T00:00:00Z

Intro

I decided to learn the Rust programming language, and here's how I did it.

I started by reading a book about Rust. It's a good way to begin, but it's not enough. You don't really learn programming just by reading a book; you have to write code. So, I began writing a simple password manager in Rust. I'm not exactly sure how I came up with this project idea, but I think it was because I had been using several paid apps like BitWarden and Dashlane, and I wanted to see if I could create something to replace them.

My setup for the project was pretty basic: I had read a bit of the book, but my knowledge was very minimal. Still, I managed to get started with the project and implement some basic features through a lot of trial and error. I had to look up a lot of things on the internet and read the Rust documentation. I wrestled a lot with the syntax, particularly with the Rust borrow checker. The borrow checker and Rust's memory safety features make Rust challenging to learn. However, what really surprised me was that when I finally got the program to compile, it actually worked and did what I wanted it to do. There was usually no need for debugging and troubleshooting—it just worked. This got me very excited about Rust. It's a strict and tough language to learn, but once you get your code to compile, it's very likely to work as expected.

With my very basic understanding of Rust, I was able to implement a simple password manager that worked. I called it Passlane, and I made it available in Github. It had all the features I needed: I could add, edit, and delete passwords. I could search for passwords in the vault and use them. I could also generate new passwords. I was actually using the program as a replacement for Dashlane.

At this point, I stopped learning Rust for a few months and moved on to other hobby projects that interested me more at the time.

Coming back to Rust again

After a year, I decided to return to Rust and continue learning it. This time, I bought some physical books about Rust from Amazon. Armed with these books, I resumed reading and learning, and I also started working on the password manager project again. I began heavily refactoring the messy code I had written earlier. As I learned more about Rust, I replaced huge parts of the codebase. I delved into traits, lifetimes, error handling, and many other concepts. With each new piece of knowledge, I revisited the password manager codebase.

When I learned about async programming, I realized that for my CLI-based project, I didn't really need async. So, I removed all async code and the Tokio runtime, which significantly simplified the code.

When I studied error handling and the ? operator, I replaced all the unwrap() calls with ?. I embraced the Result type, implemented my own Error type, and used it throughout the codebase. This made the codebase simpler—and simpler is usually better.

I also studied the Rust module system and refactored the codebase to use modules and much smaller files. This was another improvement.

This process of studying and then immediately applying my new knowledge to the fairly large codebase of my project was the core of my learning process. This approach really solidified my understanding. In my opinion, it's the most effective way to learn a programming language.

You can see my extensive rewriting and refactoring in the commit history of the project. I also significantly changed the functionality by switching to Keepass as the storage backend in version 2.3.0 of the app. This change was made to ensure users could trust that I was taking the right steps to keep their data safe. Additionally, I added support for TOTP codes (Timed One-Time Passwords) for 2-factor authentication.

Conclusions

My conclusion is this: When learning programming, you should write code as much as possible. At the same time, read books and documentation. Use AI and chatbots to ask questions. Asking for help from tools like Copilot and ChatGPT can be very effective ways to learn, but that's a topic for another blog post.

The project

I have my password manager available in Github. It's called Passlane, and at this point, I'm quite proud of it. Check it out and let me know what you think!

Open Source Sports Betting

2025-06-20T00:00:00Z

Photo by Abigail Keenan on Unsplash

Over the past few months, I have been deeply engrossed in a new personal project: the development of a sports betting website. The genesis of this endeavor was a conversation with former colleagues who are currently engaged in the iGaming industry. This discussion was particularly nostalgic for me, as I previously worked with a company that designed a sports betting product for the Finnish gaming operator PAF.

My objective was to explore the implementation of this concept utilizing contemporary web technologies, specifically GraphQL, the latest Next.js framework with server components, and server actions. My particular interest lay in harnessing the capabilities of GraphQL subscriptions to seamlessly provide real-time odds updates to end-users during live (in-play) sporting events.

To provide an overview, the backend infrastructure is powered by the Kotlin programming language. This backend hosts a robust GraphQL API, supported by a relational database. The Kotlin application is hosted on AWS within Elastic Container Service (ECS), while the database resides within AWS RDS. The Continuous Integration (CI) workflow is effectively managed through GitHub actions.

On the frontend, we have a modern Next.js application that capitalizes on server components and server actions. Vercel serves as the hosting platform for the frontend. I used Auth0 for authentication and authorization.

The event fixtures and odds are fetched from the Odds API.

The feature set currently includes the following functionalities:

Real-time updates on live events, complete with scores.
Listings of upcoming events.
Betting on live events and upcoming events
Tracking and management of bets on the dedicated bets page.
Payouts from winning bets are added to the user's gaming account balance.

You can explore the live website at https://www.parabolicbet.com/.

Additionally, for anyone interested, my code repositories are readily available:

I'm enthusiastic about this project and aspire to see it thrive in the real world. If you happen to represent a gaming operator with aspirations for a collaborative venture, please do not hesitate to reach out. I am available for freelance opportunities to bring this project to fruition. Together, we can make it a resounding success! 🚀

In any case I see this as a great learning experience and a way to perhaps disrupt the iGaming industry a bit. I don't think this industry has seen too much open source projects so far 😊

To sprint or not to sprint?

2025-06-20T00:00:00Z

Here is a lesson I learned recently: Scrum sprints are excellent if you want to squeeze the maximum performance from your team. Scrum also helps to gain sharp focus on the most important things that you should finish first.

Kanban vs Scrum

Our team started with a Kanban process. We had a backlog of tasks, and we started working with daily standup meetings and biweekly retrospectives. In the beginning, things were looking good, and we started finishing work slowly but surely. Then things began to go downhill.

There had been a recent major release of the system we were assigned to work on. The release was made before our new team inherited the project and the codebase. The release was a bit disastrous, and bugs started pouring in, making our backlog bigger and bigger. As the issues kept piling up, our focus started shifting from one critical problem to another, hurting our ability to concentrate and fix these issues. In a sudden move, our team decided to opt-in to a micromanagement approach for solving these problems. Our boss started assigning every task to individual developers! A lot of focus was put into prioritizing the backlog items, which helped a lot. The best idea I can think of for a situation like this is to use Good Old Scrum Sprints.

Needless to say, I was not too happy with the micromanagement approach and started thinking about what would be the best process to use in our situation. The best idea I have come up with is to use Good Old Scrum Sprints.

Do some sprint planning: Prioritize the issues, and take the most important ones to your first sprint backlog.
Make sure that the team commits to completing the tasks in the backlog.
Release at the end of each sprint.
The team should self-organize and decide how to accomplish the sprint goal. No need for micromanagement during the sprint.

The duration of the sprints could be one or perhaps two weeks.

This has the following benefits:

You will have a focused sprint backlog containing all the items that the team needs to finish.
Your team can concentrate on the work included in the backlog and ignore everything else.

Once the sprint is complete, the team continues with the next one repeating the cycle again.

Final thoughts

I'm now thinking that Scrum works better than Kanban for a new team. It is also a better choice when you have time pressure to finish things urgently.

However, I think pushing your team to its absolute maximum performance cannot be sustained in the long run: people burn out, and you risk losing them. Kanban is an excellent choice if you have a stable product and things are going smoothly.

Here is a great comparison of Scrum vs Kanban from the Scrum Alliance.

I'm Joining Emmy Clothing Company

2025-06-20T00:00:00Z

After four years of working as a freelance developer and a consultant, I joined a circular economy startup called Emmy.

I have concentrated entirely on hands-on programming and tech work during the past four years. I wanted to have this tech focus to help me level up my development game which had gotten a bit rusty during my 10-year stint as an entrepreneur in Flowplayer. In my opinion, this worked out pretty well to the extent that pure tech focus is starting to feel a bit boring, and it's time for me to take the next step in my path.

About Emmy

To give some context to this blog post, let me first briefly introduce Emmy. The following quote is from Emmy's LinkedIn page

Emmy is a pioneering service for consumers to recirculate brand apparel that they no longer need. Reinventing the way people sell and buy second-hand items, we offer an effortless turnkey service for people to wake up the money sleeping in their wardrobes.

The circular fashion economy is growing faster than the traditional linear fashion market. According to this article, the resale segment grows 24x faster than retail. With 20 %+ monthly sales growth, Emmy is one of the fastest-growing apparel recirculation operators in the Nordics and Europe.

Motives and Purpose of Work

There are a couple of motives that pushed me to this move. First, I want to expand my role beyond purely technical hands-on work. In Emmy, we plan to grow the development efforts and expand our development team with both in-house and external developers. Being one of the company's first in-house tech people means that I get to drive the successful growth of these efforts.

Building software is more than just programming: As an engineer, I think of it as Software Engineering, which takes a holistic look at building software. It takes more than just typing on the keyboard to build quality software effectively: People and the team, communication, processes, company culture, learning and knowledge building and similar "soft issues" all play important roles here.

Suppose I would continue my career concentrating mainly on programming as a consultant. In that case, I think I would be wasting 70% of the skills and experience that I have gained during my 30 years career in software engineering. I'm looking to Emmy now as an opportunity to widen my professional scope so that I can use my current skills fully and also learn more.

Now more than ever, the purpose of work has become vital to me. I hope to experience the excitement of working in a startup environment again. I look forward to being an integral part of making Emmy a success. Being part of something great provides purpose for me. As a consultant, I have missed that.

Emmy's role in the circular economy is the second part of the meaningful purpose. Following surely sounds like a cliché, but Emmy is making the world a better place by providing means for people to recycle.

We need to recycle to save the planet. I want to advance the transition to a circular economy where recycling is the norm. This mission feels more purposeful than the ones I have been working on lately: ad-tech and consulting to bill an hourly rate.

The tech stack

Saving the world is nice, but it's even better with cool tech. I will be working on state-of-the-art technology in Emmy, including tools like Shopify and GraphQL APIs, serverless & Lambda, Next.js, Contentful.

I'm excited to dive into these technologies during the upcoming weeks and months. Especially the serverless stuff I look forward to learning and mastering.

Stay tuned for another blog post, perhaps more about the tech aspects of building an e-commerce store. Watch this space for the next update :-)

Review Environments are Awesome

2025-06-20T00:00:00Z

What is a review environment?

Let's start with some background information and describe the "traditional" practice that I don't recommend anymore. The traditional development model looks like this:

Have two branches in version control: a development branch and the main branch.
Have two different environments: one for development and one for production.
All development work goes first to the development branch.
Development branch gets deployed to the development environment.
Testing happens in the development environment.
Deployment to production occasionally happens (at random intervals) when some set of features is ready and tested in the development environment.
The production deployment is triggered by a marge of the development branch to the main branch.

Now, there is a new kid in town, in which everything happens around pull requests. It changes the game (for the better). The new model relies on temporary review environments that exist for the lifetime of each PR.

The team splits the work into small tasks, each of which will be deployed to production once implemented.
When a developer starts working on a task, he creates a new branch forking it out from main.
When a developer completes coding a task, she creates a new pull request (PR) towards main.
The new PR triggers the CI engine to build a new review environment and deploy the PR codebase into this new environment.
Another developer reviews and tests the change in the review environment.
Once the reviewer accepts the PR, the author of the PR merges it, which then triggers the CI to build & deploy the task's changes to production.

This screenshot shows a pull request in Github. There is a View deployment button that opens the app in the PR specific temporary review environment. Reviewers need to test the app in this environment before the PR author is allowed to merge it. Github allows for blocking the merge until a predefined number of reviewers have accepted the change.

Workflow

Review builds enable continuous and seamless delivery to production. The workflow allows the team to release in small steps incrementally. There is no need for any orchestration of testing in dedicated development and testing environments, nor is there any coordination of production releases.

All development work needs to be split into small tasks that can be individually released. Each task/PR should result in a change that can be pushed to production without making the product inconsistent or broken. The tasks should be small so that they can be reviewed and tested with reasonable effort. Ideally, each task should be coded in one or two days and then reviewed, fixed & refined in another one or two days. Having larger chunks as tasks is not recommended because massive changes are harder to manage and review and are more prone to break the production system. The goal is to have a continuous stream of tiny releases that happen multiple times per day.

Implementing a large change-set, a so-called epic, requires completing several small tasks and PRs. Each of these PRs modifies the product in some small way, and because it usually does not make sense to reveal half-baked features, we need to delay the moment when we make these modifications visible to the end-users. One way to achieve this delayed visibility control is to build a feature gate into the product.

The feature gate works like this: When features are behind the feature gate, they are only visible to testers, developers and other trusted users. When we open the gate, everything that was hidden behind it become visible to all. The moment to lift the feature gate usually comes when all the PRs related to the epic become ready, and the whole epic becomes complete.

There you have it: A continuous stream of production releases: It all just kind of automatically happens when developers work on the tasks pushing them forward using pull requests.

Reviews

Pull request reviews are at the centre of the workflow. They act as a quality guard to ensure that only inspected code changes flow into the product.

The review consists of two main parts: the code review and testing of the functionality.

All testing happens as part of the PR review. Some organisations might have QA persons (testers) as part of the development teams, but many teams and organisations can do very well without them. Developers can be as equipped to do the reviews as any professional tester would be.

Note that also automated testing can happen as part of the PR builds. The best practice is to run a comprehensive unit test suite at this point to ensure that the deployment only occurs when the automated tests have passed.

How to implement automatic review deployments?

Many cloud hosting platforms like Heroku and Vercel offer PR based review builds and deployments out-of-the-box. Heroku calls them review apps and Vercel calls them preview environments. It is also reasonably straightforward to implement them using Github Actions. I recently enabled them for one React app using AWS CDK to deploy the app to S3 and Cloudfront. Julien Goux does a good job documenting this approach in this dev.to article.

How to use country-specific keyboards with Linux

2025-06-20T00:00:00Z

I recently switched to using Linux in my desktop computer that I use in my daily work. Getting the keyboard to work correctly was probably the thing that took me the longest time to get right.

I am using an Apple keyboard with a Finnish key layout. I am using a Macbook as my mobile computer, and therefore I wanted to have a similar keyboard layout in this desktop computer. Switching between the two computers is more comfortable if things are not too different between these two computers that I use. Typing comes mostly from muscle memory, and typing speed suffers dramatically if inconsistency of keyboard layouts starts to cause muscle memory to fail when typing.

Let's get to the dirty details on how I got things going.

KDE Settings

I am using KDE as my desktop package, and I have set it to use "Apple | Apple Aluminium (ANSI)" as the keyboard model in System Settings. I make the keyboard layout to be "Finnish (classic)".

One would expect this to be enough, and everything should "just work"s with the plain old Apple computers. But nope, with these settings I was not able to type square brackets, curly brackets, pipes, tildes etc. that one uses a lot when programming or working on the command line.

I got these "special characters" working using a tool called Autokey.

Autokey

I am using Autokey for getting the special characters in their familiar places. Following shows all the Autokey scripts that I have in place:

# at.py to send the '@' character
# Hotkey: <alt>+2
keyboard.send_keys("<backspace>@")

# backslach '\'
# Hotkey: <alt>+<shift>+7
keyboard.send_keys("<backspace>\\")

# left curly bracket '{'
# Hotkey: <alt>+<shift>+8
keyboard.send_keys("<backspace>{")

# right curly bracket '}'
# Hotkey: <alt>+<shift>+9
keyboard.send_keys("<backspace>}")

# dollar sign '$'
# Hotkey: <alt>+4
keyboard.send_keys("<backspace><shift>+4")

# pipe '|'
# Hotkey: <alt>+7
keyboard.send_keys("<backspace>|")

# left square bracket '['
# Hotkey: <alt>+8
keyboard.send_keys("<backspace>[")

# right square bracket ']'
# Hotkey: <alt>+9
keyboard.send_keys("<backspace>]")

# tilde '~'
# Hotkey: <alt>+]
keyboard.send_keys("~")

The scripts shown above will make my Apple keyboard with a Finnish key layout work like expected. There could be still some missing mappings that should be there, but I have not discovered them yet. I can easily add more mappings if I find out additional needs.

The mappings you will need for some other country-specific or regional layout will be different. The approach that I describe here will work for other layouts as well.

I am using autokey-qt which is a GUI tool that I use to enter the scripts I listed above. There is also a GTK version called autokey-gtk available for Gnome and other GTK based environments. One script is capable of handling only one character, and therefore you will need to have a separate script for each of them. You can record a hotkey shortcut for each of the scripts. In the screenshot below, you can see my at.py script, which I have mapped to hotkey <alt>+2.

As you can see, the script sends two different keys in sequence:

a backspace to wipe out the character that my keyboard normally sends when I press ALT + 2.
the character I want to Autokey to emit when in press ALT + 2: the @ symbol.

Make Autokey start when KDE starts

To finish the setup, we need to have Autokey starting automatically. To do so, I went to System Preferences / Autostart, and added /usr/local/bin/autokey-qt as a program that gets started automatically when the KDE desktop starts.

When and why to use TypeScript

2025-06-20T00:00:00Z

I have programmed exclusively with JavaScript for the past five years. I enjoy programming in JavaScript, and until recently, I saw no reason why I would switch away from it. I did not understand why I would compromise the speed and agility that JavaScript brings.

I love the dynamic nature of JS. It allows me to quickly implement new solutions. My thinking was that TypeScript's added type declarations and type checking would make me slower and less productive.

Recently my opinion has changed, and in my latest projects, I have begun to understand the benefits of TypeScript.

In this article, I explain the reasons why I changed my mind about TypeScript and why I think that many projects will benefit from using it instead of vanilla JavaScript.

Working solo

I think that JavaScript is adequate when working alone, but it's sub-optimal for teams.

JavaScript is suitable for quick development. When working solo, It does not matter that much if the code is hard to understand for others. The chances are that you, as the sole author of the code base, can understand it well enough to maintain and enhance it.

JavaScript allows for rapid development partly because it does not require any types or interfaces to be written. You are not "wasting" any time in writing this typing.

In the past, I have implemented sizeable codebases using vanilla JavaScript and I have maintained them for years. This has worked well because I have been the only person working on these projects.

Teamwork

I recently started working on a huge JavaScript codebase that had been authored by one developer over several years. My task was to implement a small enhancement to it but was unable to do it because it was simply too hard for me to understand what was going on in the code.

The original developer obviously was able to still make changes to it, but for me, the code did not make much sense. The coding style, or the lack of it, was making my brain hurt.

We decided to start migrating the project to use TypeScript. We identified two areas that would benefit the most from type annotations:

Interfaces for all message types. The project is using a messaging system, and several different kinds of messages are sent and received between modules and functions.
Interfaces for all DB types. Just like the message objects, these DB records are also passed between modules and functions.

We added these interfaces and proceeded to add typing to all functions that have these objects in their signatures as parameters or return values. It's these type declarations that make the code easier to understand. You can immediately see from the type declarations what data the function takes in. Interfaces describe the structure and typing of all complex parameters. There is no need to inspect the calling code, or the function implementation, or the unit tests, to figure out what fields these complex objects are composed of.

A shared understanding of the code becomes vital when you are working as a team. Added type information brings added understanding.

Fewer bugs

The type information is also consumed and checked by the TypeScript compiler. The compiler will tell you when your code is not type safe.

It's the classic benefit that type checking brings: Catching bugs earlier in the development process. You will catch and fix bugs during development instead of your customers finding them when your app is in production.

Airbnb reported a 38% reduction in bugs by adding TypeScript to their development process.

The TypeScript compiler has a strict option which enables more stringent type checking. With the strict option enabled, it will flag out more potential problems.

If using TypeScript is better than using plain JavaScript because of the compiler warnings, why wouldn’t you want to turn the compiler warnings dial up to ten?” ‐ Embracing the TypeScript Strict Mode – Steve Fenton

It's probably best to not use the strict mode when migrating an existing JS projects to use TypeScript. In our TypeScript migration project, we have started with the strict checks disabled, which makes it possible for us to have the build passing and the program running with less effort. If we decide to enable the strict checks, we have more work to be done before the compiler is happy enough to produce a runnable program.

The cost of using TypeScript

TypeScript does not come for free. There is some cost associated with using it:

It takes effort to write type annotations and to maintain them
Type annotations add clutter to the code base

It should be noted that our industry is using several techniques to catch bugs. Typescript and its static type checking is only one of these techniques. Here are some of the recommended practises: Test Driven Development, pair programming, code reviews, design reviews, and linting.

If you are using TDD and code reviews, you are likely already efficient in recovering bugs early. In this case, adding TypeScript will not have such a significant impact on improving quality. You should consider your situation and try to determine whether the benefits of TypeScript will out-weight the costs.

Object-Oriented vs Functional Programming

During the past two years, I have been learning to use functional programming in my JS projects. I was a bit worried that TypeScript would not be a good fit for functional programming. My uninformed thinking was that TypeScript would make my code similar to Java, where everything is based on classes, and everything has to be an Object.

It turns out that my worries were unjustified. TypeScript builds on top of JavaScript and everything that I can do with JavaScript I can also do in TypeScript. I am not forced to use classes, or to declare types for all variables. Typing is optional and can be added where most appropriate.

Conclusions

When to use TypeScript?

You will benefit from TypeScript when some of the following are true:

You have a rich data model where data objects are passed between modules and functions.
You have more than one developer working in the project.
You are developing an open-source library. It needs TypeScript typings so that people can use with their TS code bases.

Why use TypeScript?

Type checking catches bugs early.
It enables teamwork by increasing the understandability and maintainability of the code. Because of this same reason, it makes it also faster to bring new team members up to speed.

When is it better to stick with JavaScript?

There are some situations where I would not use TypeScript but would go with vanilla JavaScript instead:

You have experienced JavaScript developers who are using TDD and code reviews
Quick prototypes are quick to develop with JavaScript
Single-use scripts (migration scripts etc.) are an excellent fit to be done with JavaScript

How to add object fields conditionally

2025-06-20T00:00:00Z

I often run into situations where I need to construct an object in JavaScript, and I want to set fields to this object conditionally. That could be an options object that I am passing as a parameter to some other function or API. I have only some of the field values available, and only those should be part of the parameter object.

To describe the situation, let's take a look at an example with a straightforward syntax using if statements.

Here I'm mutating the object conditionally, setting fields for values that are available. I don't like this kind of mutations, because they make the code hard to follow.

Here is another attempt:

const options = {
    key1: value1 || undefined;
    key2: value2 || undefined;
};

This "solution" pollutes the object with fields that have undefined values. These fields will be present in the object, even though their values are undefined. With this kind of an object, you cannot be sure what happens when you pass it to the external library you are building this object for: It might behave just fine, or you might get errors, or worst, it might work in some unpredictable ways.

The Way

Following is the cleanest syntax that I know of that solves these problems:

const options = {
    …(value1 && { key1: value1 }),
    …(value2 && { key2: value2 })
    };

I like this a lot: Looks clean, does not add unnecessary fields to the object, and it does not use ugly if statements.

With the ES6 shorthand property syntax it looks even more clean:

I found this trick when I was looking at some code that my ex co-developer had produced, and have used it twice since I discovered it. I hope you find it useful too.

The new anssipiirainen.com

2025-06-20T00:00:00Z

A week ago, I decided to set up a new website for this blog. Somehow I always have the urge to learn something new. Just programming with the same old tools and languages becomes boring, and something new is needed to spice up my life.

This year I have been blogging a lot. Writing is an area that I want to keep on doing also in the future. Up until this point, my blog was in Squarespace. I felt that I wanted to improve my blogging workflow: It should be easier for me to work on, and the result should be better looking and friendlier for the reader. I also wanted to learn something new while building my new blogging "platform".

I ended up building this website using Hugo. Hugo is a static site generator and provides a developer-friendly "hands-on" experience for the user. It's a totally different experience than the GUI centered approach that Squarespace offers. With Hugo, everything happens in a text editor and in the command-line interface.

Hugo is implemented using the Go programming language. I am interested in learning Go, and one big reason for choosing Hugo was to get some exposure to Go.

Deployment

This blog is deployed in Amazon S3 using Hugo Deploy. It's using Cloudfront as the CDN.

I used a nifty trick to enable a piece of URL rewriting using Lambda@Edge to enable directory index documents. For example, the path of this page is /post/new-blog-site/ and this needs to be mapped to /post/new-blog-site/index.html because the actual page index.html file recides in that path in the S3 bucket. With a quick web search, I found out that this can be achieved using a Lambda script that is deployed and runs in all Cloudfront edge locations.

The result

As you can see from the looks of this site, this is quite bare-bones. It looks nerdy. Just like I wanted it to look like :smile:

I have direct access to the CSS files, which is great, because I also want to improve my styling skills.

The page templates are there available for hacking whenever I feel the need to work on the site layout or on additional features. I could integrate a mailing list to this site eventually, for example. The Go page templating system seems powerful.

I can now write the blog posts without leaving my favorite text editor, Visual Studio Code. I write my blog posts in Markdown which is a format that Hugo directly understands. Previously I had to copy/paste all text to the post UI in Squarespace website, and now, with Hugo, my workflow is more straightforward: The markdown file sits in Hugo's content directory all the time when I work on it.

I just found out that there is a Grammarly plugin for Visual Studio Code. I use Grammarly for checking the spelling grammar of my posts. The VSCode plugin seems a bit flaky at the moment, but it could be a great addition to my workflow.

How to Organise Remote Work for High Productivity

2025-06-20T00:00:00Z

The popularity of remote work is on the rise, and in the past weeks, the demand has seen exponential growth. Following are some of the non-obvious reasons for using remote workers and remote teams:

Companies can look for the best talent all over the world. They can look outside their neighbourhood for new talent.
Companies want to place people in markets that are in different parts of the world. It makes sense to have people close to the customers, and in the same time zones with them.

Right mow, the Coronavirus is forcing many companies to have their employees working from home. Suddenly there are a lot of employers and employees trying to figure out how to operate in this unusual situation.

Companies are always looking to increase their productivity and profits. Based on my ten years of experience as a remote worker, I can say that not every remote team is working effectively and achieving high productivity. The world is full of companies and organisations that have no clue about remote work and are now suffering when the virus forces them to practise it.

Companies need to have the right practises in place to make remote working effective.

The best practises for remote teams

There are a lot of practises that can improve remote working. In this article, I'm presenting the top three.

Backlog of work
Asynchronous communication
Timely feedback

Backlog of work

The Backlog ensures that people have a place to go when they need new work.

Many software development organisations know how to use backlogs and visual boards for organising work. The backlog is a prioritised list of work that the organisation wants to complete. The backlog needs to be available for access from anywhere and online tools, like Github boards and Trello, are excellent for this.

These tools are not only for distributed teams: Many on-site teams are using them as well. Visual boards are useful tools for everyone. For remote teams, having tools like this is more important because in a distributed setting, people cannot rely on face-to-face communication nearly as much as in a co-located setting. For remote teams, the practice of asking around does not work well.

All items in the backlog should be planned.

People need to be able to trust that the task they take from the backlog represents work that the organisation wants to complete. People don't want to invest their time on stuff that is not needed. Nobody likes wasting their time on busywork.

Everyone in the team should be familiar with the tasks that are in the backlog.

Joint planning is one way to make sure that everyone is familiar with the tasks. The team could assemble the backlog as a team exercise. In Scrum, the whole team gets together periodically to plan the tasks for the next iteration of the project. After the sprint planning session, the team members know the tasks well enough to be able to start working on them later in the iteration.

I have seen the Scrum backlog planning approach work well for building a working backlog.

Don't be too attached on the idea of the backlog here. The most important thing to take away from this is that there needs to be some mechanism in place which ensures that people always know what to do next. You and your team can together decide what the best tool for you is.

Asynchronous communication

Programming requires deep concentration. You should not interrupt a programmer at work if you don't want to destroy his focus. Achieving the flow state of tight focus takes time, and interruptions will harm focusing. In fact, frequent interruptions may prevent a person to never reach the flow state. His concentration never gets deep enough to achieve the state of deep work and high productivity.

In recent years, open offices have become less popular. Companies have realised that the constant communication and interaction which happens in open workspaces can kill productivity. Knowledge workers, like programmers, need private spaces to be able to concentrate.

That being said, not all work is deep work that happens in the flow state. Knowledge workers need to communicate to share information and to synchronise their work to achieve shared goals. This is where async communication comes in.

Asynchronous communication happens when you send a message without expecting an immediate response. Take email, for example. I open and respond to the email several hours later.
Synchronous communication happens when you send a message, and the recipient reads it and responds immediately. Meetings or water-cooler discussions are examples of synchronous communication.

Async communication can improve productivity because people can concentrate on it when they have a break from their deep work sessions. People should be able to alternate between deep work and between communication at their own rhythm — this would be the recipe for high productivity.

Companies should encourage async communication. It should be part of the standard working culture of the company. Tools like Slack can be excellent for async communication. To make async communication effective in a tool like Slack, have the following rules in place:

people don't expect an immediate answer to their questions
people don't feel the need to answer right away when someone asks a question from them

It should also be noted that async communication can make it possible for people to work in different time zones. Not all messaging needs to happen when the time zones overlap. You can send a question when the recipient on the other time zone is sleeping, and then receive the answer the following morning when you wake up.

Timely feedback

Sometimes developers run into situations when they cannot make progress on a task before they get some from someone else. A decision needs to be made, a question needs to be answered, or some new tool needs to be purchased, before work can continue.

You don't want your developer to be stuck for long times. You should quickly help him (or her) so that he is free to continue his work.

Async communication means that you don't need to answer peoples messages and questions immediately. On the flip side of this, you should not take too long with your answers and feedback. Long delays can be frustrating and, for obvious reasons, delays are disastrous for the overall productivity.

Summing up

To succeed with distributed teams, the top things to prioritise are:

Make sure you have a solid backlog of work available at all times
Promote asynchronous communication
Provide timely feedback

Thanks for reading and keep up the good (remote) work!

Functional Programming tricks for simplifying and improving code

2025-06-20T00:00:00Z

Functional Programming can make your code simpler. Simplicity means that the code is easier to read and understand, testable, and more maintainable.

In this blog post, I describe some of the Functional Programming (FP) tricks you can use to turn your code better by making it simpler.

Get rid of temp variables

Functional Programming favours immutability. This principle of immutability means that you don't change the values of your variables after you have initialised them. Similarly, you don't mutate your objects, or strings, after you have created them.

If you are programming in JavaScript, all your variable definitions should use const. For anyone who is reading your code, the constant definition gives peace of mind: It guarantees that the variable is never reassigned. Because reassignment is impossible, the reader's brain is free from the burden of tracking and recognising reassignments from the code.

What about when you need to change your values? At first, you could have an array:

const fruits = ['apple', 'orange', 'banana']

What do you do when you want to add a new fruit into this list? The solution is to initialise a new constant variable with new or updated values. We can copy the existing fruits values using the spread operator:

const allFruits = [...fruits, 'pineapple']

You should follow the principle of immutability everywhere in your code. Because if you do, your code becomes cleaner.

You know that the value of your fruits variable never changes, and you know this fact the first time you see the declaration of the variable. After the initialisation, anywhere you see the fruits variable, you know that it still has the same three fruits in it.

Get rid of loops

Functional code tells what happens instead of instructing how it should happen.

Loops are not functional, and we should get rid of them.

Consider the following loop:

var list = [];
var i = 0;
while (i < rows.length) {
    var row = rows[i];
    var message = {
        childAddress: row[1],
        action: 'switchToBackupNode2',
        role: 'edge'
    };
    list.push(message);
    i += 1;
}

The functional alternative gets rid of the while loop and uses map to process the rows into a list.

const list = rows.map(r => ({
    childAddress: r[1],
    action: 'switchToBackupNode2',
    role: 'edge'
 }))

In addition to getting rid of the loop, this code has also removed temporary variables row and message and the loop variable i.

The result is much more readable.

It's crystal clear.

You can trust that this code works just by looking at it. To be fair here, to gain this level of trust, you need to understand the map function first. The map function is used everywhere in functional programming and thus learning it is an essential step in transitioning to FP.

map is one of the functions that programmers use for list processing. Processing data in lists is a big part of FP, and you should also learn the other list processing functions: most importantly, the reduce and filter functions.

Removing ifs

Removing ifs is a useful strategy in my guest of simplifying code. There are several strategies that one can take to remove if statements from code, and applying any of them usually results in cleaner, easier to understand, structures.

Let's look at some strategies for removing if statements.

Ternary Operator

The ternary operator is my main tool for getting rid of if statements from variable assignments.

Consider the following:

let message;
if (person !== null) {
  message = `hello, ${person}!`
} else {
  message = 'hey there!'
}

There are two problems in the code above:

I must use a non-const variable message **because, with the if-structure, I am unable to give the message a value right away in the variable declaration.

The code is quite a verbose and complex considering that it only accomplishes the simple task of declaring a variable and conditionally assigning a value to it.

The same job can be done in one line by using the ternary operator ?:

const message = person !== null ? `hello, ${person}!` : 'hey there!'

Boolean operators && and ||

The boolean operators, && and || provide effective alternatives to if statements.

Instead of doing this,

if (value) {
  doStuff(value)
} else {
  doStuff(1)
}

you can do this:

doStuff(value || 1)

The logical OR operator || here provides a quick way to pass a default value to a function. You can use the same trick every time you don't know, or when it's not guaranteed, that a variable has a value: Provide a default value by prefixing with || .

Here is an example of how to use the AND operator && . First, the version using if:

if (data) {
  sendData(data.value);
}

Then we remove the if using &&:

data && sendData(data.value)

Here, we are using && to fist check that the data variable holds a value. Without this check, the code would crash when there is no value (in other words, the value is null or undefined).

We are relying on short-circuit evaluation of boolean expressions when using these operators her. With the && and || operators, JavaScript will not evaluate the latter part of the expression when the first part is falsy. You can learn more about short circuiting here.

Maps and lookups

Using maps as lookup tables is an effective way to replace a sequence of if-statements. Consider the following:

let language;
if (country ==) 'FI') {
  language = 'Finnish'
} else if (country === 'SE') {
  language = 'Swedish'
} else if (country === 'USA') {
  language = 'English (American)'
} else if (country === 'UK') {
  language = 'English (UK)'
} // etc...

A cleaner way is to use a map of country/language pairs.

const languages = Map([
  ['FI', 'Finnish'],
  ['SE', 'Swedish'],
  ['USA', 'English (American)'],
  ['UK', 'English (UK)'],
])
const language = languages.get(country)

The second implementation is much simpler. The code reveals it's intention right away. As a bonus, it converts the language variable to use const

Small Functions

Functional Programming is all about functions. It's better to write many small functions instead of a small number of long functions. The main reason for decomposing code into smaller modules is that smaller (shorter) pieces are easier to understand in isolation. Smaller pieces are also easier to test and maintain.

With the tricks I have shown here, your code can be more compact. That is an important goal and an excellent reason to learn these tricks, and more importantly, to learn functional programming.

There are more tricks and strategies like this. Let me know if you would like me to write a post about the other strategies!

Career Options for Ageing Developers

2025-06-20T00:00:00Z

The half-life of a programmer is short. According to this [New York Times article from 1998](https://www.nytimes.com/1998/01/26/opinion/now-hiring-if-you-re-young.html), only 19% of programmers are still working as programmers 20 years after they started their career as a programmer.

Six years after finishing college, 57 percent of computer science graduates are working as programmers; at 15 years the figure drops to 34 percent, and at 20 years — when most are still only in their early 40’s — it is down to 19 percent.

This same phenomenon is still alive today. Programmers drift away from their original work and move to management and other roles that have little to do with the programming profession.

I have always thought that this is sad. In my mind, management is something that almost anyone can do. It does not require any special skills or knowledge. Take a 2-month course in project management, and you will be able to do a reasonable job at it. Contrast that to the art of programming, which is a specialised skill that requires years of studying and practising before you can call yourself good at it.

Sadly, some of the best programmers get “promoted” to management roles. In this blog post, I explain some of the benefits of staying hands-on with programming throughout your whole career.

Learning strategies

Things change a lot in the IT industry, and the career of an IT professional requires constant learning throughout the whole career.

Let’s consider two different strategies that you can take when it comes to learning new technology during your career.

The first strategy is to stay on the same technology platform and hone your skills in it.
The second strategy is to take more significant leaps and choose to keep current with the latest development trends and innovation, regardless of where it happens.

If you got it, flaunt it

Let’s consider the first option first. You have some hard-gained experience on platform X and you want to keep flaunting that. This platform might not be the most fashionable right at this moment. It’s not where the most action and innovation is happening right now. Take Java, and consider that as an example. Java is still the most popular language today, but one would argue that it’s no longer the most fashionable one. It’s not the place to be where the innovators are at the moment. But because it has been hugely popular for many years, it will undoubtedly be in high demand for 40 years to come. Because of this reason, you will not be out of work if you choose to continue working on the Java platform.

Surprisingly, even COBOL which was created in 1959, continues to be relevant in some industry sectors. Apparently, Cobol developers are still in high demand. If you now Cobol and money is your primary motivator, it makes sense to continue and exploit this opportunity until it dries out. They are predicting that Cobol will stay a significant language for the next 20 years.

There might be good money to be made if you stay on a legacy technology platform, but this could be a boring strategy to take. The chances are that you will not enjoy this! A better option would be to keep learning new things because that is a way to stay motivated in your work. Let’s explore that option next.

Learn something completely new

Some of us want to keep up with the latest technology. We get bored if we need to work with the current tools and frameworks for more than a year or two. We want to learn new programming languages, new programming paradigms, and new tools and libraries.

If you are one of the few, who has not given up for the temptation to become a Manager, you have likely kept on learning all the time, and that has kept you motivated to continue in a technical career.

There is a study of StackOverflow data that explores the relationship between ageing and programming knowledge.

We observe that programmer reputation scores increase relative to age well into the 50’s

According to this study, your programming related knowledge increases with age. Programmers can learn and acquire new skills and knowledge well into the age of the 50 and older. Learning is not only a privilege of the young.

You can move into a completely new technology platform if you want. It can require significant investments of time and effort to learn the latest technology, but rewards of learning can be marvellous. You will be again in a place where the primary action is and where the bets of startups and innovating companies are. This kind of leaps in learning can be extremely motivating.

Go to Management

It feels like a promotion when you get an offer to be a manager. You have worked hard to become an excellent developer, and the management has noticed this. Your boss knows that you are the best in your team. One day there is a management position that the company need to fill, and they offer this position to you. What do you say? The job is challenging, and if you accept to take it, you will not have too much time for programming any more. Do you accept the offer and become a manager?

I decided to say “yes” when my boss asked this question from me some 20 years ago. I never wanted to be a team leader, but still, I accepted the job. It feels like promotion, and as an ambitious person, it was too hard for me to reject the offer and challenge. That said, I have never regretted making this decision. I learned a lot by taking the time to learn Scrum and in doing my best to lead a development team.

All the time, I tried to keep my hands dirty in programming. I had my side project with, and that kept me busy during my free time. Despite my efforts to stay hands-on with programming, I was not learning programming related things as much as before.

One can argue that my programming career was in decline because of my decision to go to the dark side of management. The temptations of the dark side are the reason for the short half-life of programmers. If you stay in a management role for too long, and you can no longer compete with the young fresh-out-of-school developers that are coming to the workforce.

In my case, things turned out good. I decided to leave my day job and start my own business, and that again involved a lot of coding.

Embrace the benefits related to your age

At the age of 40 or 50, you will have more time in your hands than before. Consider the following:

Your kids are already teenagers or adults. They might have moved out of the house already. , In any case, they are not spending much time with you any more. This is great :-)
Your marriage has gotten old as well, and your partner does not require much attention from you any more. This is also great.
During your 20-30 years of professional life, you have gained a lot of expertise. You know about corporate politics, how businesses operate, how to do teamwork, how to recruit new people, how to train junior workers, etc.
You have the soft skills that the younger workers are still missing.

At this age would be the perfect time to start a business. According to research done in 2018, The Average Age of a Successful Startup Founder Is 45.

The founders of successful startups are indeed this old, and we need to debunk the myth of the young entrepreneur.

Relative to founders with no relevant experience, those with at least three years of prior work experience in the same narrow industry as their startup were 85% more likely to launch a highly successful startup.

I realise that the startup game is not everyone, but for anyone who has dreamed of having a business of their own, this could be the perfect age to pursue that dream. You have more time than ever in your hands to make it happen, and on top of that you also have the work experience to increase the likelihood of success.

I started my first business at the age of 37. My open-source side project hobby started getting so popular that it made it possible for me to earn my income from it. I quit my day job and pursued my Flowplayer project full time as a business. This adventure as an entrepreneur lasted for ten years, but then, after some twists and turns, I exited from Flowplayer two years ago.

Today, I’m working as a Freelance developer and enjoying my work more than ever before. I’m again focusing almost entirely on programming.

Conclusions

Being a programmer is great, and your career can take many shapes and forms. You can continue programming for as long as you want. You have the potential to learn new skills and gains knowledge for as long as you need. Starting your own business, or switching technology platforms, are options that you can basically at any point during your career.

Just do it and enjoy the ride!

Why you should learn Functional Programming

2025-06-20T00:00:00Z

Introduction

The first 10 years of my programming career, I was doing Object-Oriented (OO) programming. I was working with Java mostly. I tried to master the art of OO and learned the design patterns to help me in coming up with class structures that avoid code duplication, and are flexible and adaptable for future change. My code was full of classes.

Things started changing after I started programming in JavaScript, which did not force me to put all my code into classes. In my first JavaScript projects, the codebase still resembled the ones that I had been putting together with Java. I was not using classes, but despite this, some of the files still had a look&feel of a class. The code had modules that grouped functions that were somehow logically related to each other, just like a typical "service" class in Java would have.

Today I have programmed in JavaScript for more than 5 years, and my coding has evolved a bit. I have started to think of my programs as data processors. There is always some data that needs to be processed. I think about what kind of processors and functions are needed to transform the data. My studying of Functional Programming has profoundly influenced me, and this data-centric approach arises from this studying and learning.

In this blog piece, I explain why it has made sense for me to study FP and why you should also learn it.

The Benefits

Experienced functional programmers can tell you about the many benefits of functional programming:

Functional code is easier to understand
There are fewer bugs
The code is more compact
Some even claim that it's easier to test and debug

I agree with these claims. The difference between paradigms is easy to see If we take a non-trivial programming challenge that has implementations both in a functional and in a traditional imperative style.

Imperative implementations for a complex problem can be hairy with nested loops and nested if-then-else statements, class inheritance structures and all the things that we typically see in imperative programs.

Have you ever studied a big object-oriented program that was done by an experienced OO practitioner? One that is well-factored to use classes with clear responsibilities. One that does not have any duplicated code and is DRY. Factoring code into classes with distinct, clear responsibilities removes code duplication. This kind of designs can include several hundreds of classes. It can be tough to see how this program works and how the different classes work during runtime.

A well-factored functional implementation, on the other hand, might look scary when you first look at it, but after a little bit of studying, you should be able to understand the pieces (pure functions) that it has and how those are composed together.

You can understand each function in isolation. You can trust that the program does what is promised.

Challenges

Contrary to what I just said in the paragraphs above, functional programs can be hard to understand for programmers that are not familiar with the functional style. Functional code can look quite different than the imperative counterpart. You cannot see many occurrences of elements that you are used to seeing in code: There are not many if statement, or for loops, for example.

All you can see is a bunch of small functions and weird-looking compose(), and pipe() calls that might make no sense to you are not yet familiar with these concepts.

There is a learning curve to understanding FP. First of all, you need to study the basics, and once you know the basics, you can start ramping up your knowledge little by little. There is a lot to learn before you are a master FP practitioner. I have been on this learning streak for one year now, and I'm still at the beginning of my journey. I'm sure that I'll reach the master-level status someday if I just continue working hard towards that goal.

I have a 10-year history with object-oriented programming using Java. I was a huge fan of the Eric Evans' book Domain Driven Design and took it's teachings about Entities, Services and Value Objects seriously. I have implemented thousands of classes using the patterns explained in the Domain Driven Design and the GoF Design Patterns books. Because of this background of mine, FP made little sense to me when I first looked at it.

I found debugging functional code to be challenging. Where do you add your breakpoints, when all you have is a list of functions linked together using pipe? Debugging is another area where you need to learn new tricks because the old ones don't work with FP. Luckily there are some good strategies for debugging functional code.

Learning Functional Programming

Why would you take the effort and learn FP? I guess the most important reason is that learning it makes you a better programmer. You can benefit from knowing about FP even if you continue doing object-oriented programming. Making functions pure and favouring immutability are great habits, no matter what your primary programming paradigm and programming language are.

You don't need to go full-on with functional and scare your co-workers by coming up with code that is so full of currying that you need a degree in Indian cuisine to understand it. I would recommend Kyle Simpson's book Functional-Light JavaScript to get you started. It provides a pragmatic, balanced way of doing FP in your JavaScript projects. It is the book that got me started with FP.

Ramda is an excellent functional toolkit library for JavaScript. You need something like it to ease your life. It contains the functional "primitives" that you can start using in your real-life projects.

Mastering FP takes time. I'm at the beginning of my journey, and my journey so far has looked like this:

I read the Functional-Light JavaScript book and got excited
I started sprinkling in FP to my daily projects. I started making my functions pure and started avoiding mutating my data.
But then I got busy with daily projects, and my FP learning ambitions got sidelined...
Then luckily, I became less busy again, and my FP learning was back on track.

Summing up

I think it's essential always to study and learn more. In this profession, it's a must. If you stop learning and improving, more ambitious programmers overshadow and take over you. Eventually, you give up programming and become a Manager and, for sure, that is a scenario that every self-respecting programmer wants to avoid :-)

Building an Electron application

2025-06-20T00:00:00Z

Intro

Back in March this year (2019), I stumbled upon a technology called Electron, which offers a new way of building cross-platform desktop applications. The first version of Electron appeared already in 2013, but somehow I had missed entirely that release (probably because at that time I was 110% occupied with Flowplayer).

I had always been interested in building desktop applications without ever doing that as my primary job. I had experimented with Mac development using Objective-C and XCode but did not advance far with those experiments.

I ended up trying Electron because I wanted to know how I could use my React.js and Node.js skills in desktop development.

I had also stumbled into Notable which is a "Markdown-based note-taking app that doesn't suck". I studied its code base and became convinced that this development platform has enough going on and I should try it out.

What is Electron?

Electron allows for the development of desktop GUI applications using web technologies: It combines the Chromium rendering engine and the Node.js runtime.

Wikipedia/Electron

React and other frameworks

I wanted to try if I could build an application like Postman. I had used Postman and also a similar Mac app called Paw earlier. I had some thoughts on how these applications could be better and wanted to try those ideas in my app.

I had been working with React since the summer of 2018. I had built a sizable app using it and was already quite familiar with it. That's why I wanted to use it in this new project. I started searching for React component frameworks that would be good for the desktop - the components would need to a desktop-like look and feel. After some research, I ended up using Blueprint.

I like the styled components library, which is a library that allows writing CSS as JavaScript template strings. My goal was to produce something usable quickly (like most of us want), and that's why I wanted to utilise existing code/libraries/frameworks to get up-to-speed quickly.

Productivity

The Electron and React combo is a killer platform when it comes to productivity. Indeed, web technologies are ahead of the tech that is currently used in traditional desktop development. To me, using a component library like Blueprint is a blessing: I can quickly look through their examples and pick the components I need to build any UI feature. The UI components are flexible, and I can change their styling and size the way I need. If something does not look the way I want out-of-the-box, I can pretty quickly resort to custom CSS to change the default look the component has.

It's not a surprise that the code Apple's SwiftUi looks a lot like in React's or Flutter's component-based systems.

Electron apps are cross-platform, and you can build your app from the same code base for Linux, Windows and Mac.

What did I learn?

I have been primarily a backend developer for most of my career. I accumulated most of my frontend web development experience in the past two years. This project was a good boost of confidence, making me realise that I can indeed work also on the frontend side. I ended up also developing a website for my app, which was another great experience.

I am now reasonably confident that I can build anything from start to finish. I could do it entirely on my own if I wanted to :-) I am convinced that I can come up with the backend, the frontend, the website, and marketing material. This realisation makes me think of the next idea for a startup I should bootstrap. Meanwhile, before the big idea emerges, I will continue working on this Dispatch project.

In our summer cottage in Lapinsaari, Savonlinna, Finland

I'm leaving Flowplayer

2025-06-20T00:00:00Z

I've resigned from Flowpalyer, the company I founded back in 2007. The decision to leave was not easy to make. Flowplayer has been my number one priority for ten years, and I'm finding it difficult to let it go, but still, I think it's the right choice for me.

Flowplayer merged with a Swedish online video company a year ago, and after that, my role has significantly changed. I used to be the CEO and also a developer (and a sysadmin, a secretary, and everything in between) and did my best to keep the company profitable and growing. The merge gave us more resources, and I stepped down from the CEO role and also gave much of my other responsibilities to other people in the company. That is something I wanted to do, and I don't have any regrets about it. But after successfully offloading many of my duties I started feeling a bit empty and began considering my options to take on some new opportunities.

I've always been a developer in my heart. Programming has been the only kind of work that is fulfilling for me and activities, like management and similar paper-pushing sort of work, has never felt like "real work" to me. After the merge, I was able to move away from the dark side of management and was able to concentrate more on work that is meaningful for me.

Since our merger, I have been on a mission to learn all the latest technology and honing my JavaScript and node.js skills. All this has been refreshing and highly motivating. It has been great to get back my mojo in programming -- I'm more productive as a coder now, and I think I'm also producing better-quality results.

What is the real reason that pushed me to resign? Here is a list:

I've been working in Flowplayer for ten years, and it's time to explore other stuff. It has been the longest streak I have ever been in the same company. Before Flowplayer, my most extended period in one job was 3,5 years.
I think Flowplayer is in good hands and can move forward and grow without me.
My plans for the upcoming projects are exciting and highly motivating.

My opinion is that if you start questioning whether you should move forward, it's time to move forward. Change can be difficult, but it's a way to grow as a professional and as a person. I've changed jobs several times in my life, and every change has been for the better.

I've decided to continue as a freelance developer, and see where it takes me. I've already started planning my next steps in this space and will post updates here in my blog about this. Having an online presence is essential for a freelance worker, and I'm planning to post more about work-related topics in the future.