Petri Hänninen

Think back to when you started writing code. What actually got you interested and motivated to spend all the time and effort to learn to code? Was it the quality of code, or test coverage, or some performance metric? For me at least, the answer quite obviously is no. What instead truly got me going was the idea that I was able to make the computer do something it wasn't doing before.

This feeling, these moments and these results are, in fact, the reason why developers are needed and valued.

Big Bad Business?

Business requirements often get a bad rap for not valuing quality code, for incentivising dark patterns or for being plain stupid. This, though sometimes an understandable sentiment is somewhat lacking in perspective.

What business actually wants is to create a product that solves a problem for a specific group of people (users). A problem that is annoying enough that the users are actually willing to pay more for the solution than the cost of solving the problem is for the business. This idea captures everything from market fit to revenue to profitability.

Developers Focusing on Wrong Stuff?

Developers, on the other hand, get a bad rap for not seeing the big picture. Devs might argue for improving test coverage, maintainability, or God forbid try to speak business and talk about tech debt.

What is often missed in these requests is the reason why such things matter. I do not care about the test coverage number or performance metric itself. What I want is to create a piece of software that is able to do its thing now and in the future, and that does it without incurring unnecessary strain and thus cost for our infrastructure.

Common Ground After All

It might be obvious at this point that there is plenty of common ground here to build upon. Both the business and technical requirements strive for a solution that works, that solves problems and keeps solving them without the price of doing that becoming unbearable.

And this problem solving even is the very reason I fell in love with writing code in the first place!

So Why the Juxtaposition?

I think the clashes pretty much always come down to lack of communication skills on both sides of the table. We developers have a lot to improve on when it comes to explaining why some issues and metrics are better be dealt with before they really backfire. At the same time, the business need easily gets represetend as some vanity metrics or even cold hard cash.

If you're struggling to communicate, my suggestion is simple. First, take a big breath. Second, define the problem and suggested solution. Third, define what is the highest impact to effort improvement that you can do to make the solution even bigger, better or less costly to provide. Fourth, execute.

Note that especially step #2 is extremely easy to gloss over. "We all know what we're here for we've been doing this for 15 years" is not an acceptable answer. Every individual has their own answer to these, and even though a consensus and alignment may have existed at some point, these definitions have a tendency to drift apart unless explicitly managed. This driftage needs to be undone periodically.

After aligning yourselves towards the same target, step three should be quite painless. Even though the estimates on what's important can vary quite a lot, those differences can only arise from people not having the same information available or understandable for them. At this point the competing ideas are not "dev vs biz" but a concrete initiative against another, and those can be more easily scrutinized without the us vs them mindset coming in the way.

Having such a clear goal setting and structured approach to priorization is, in my opinion, the fastest and most efficient way for getting cool shit done together, as a team. If you find step three to cause trouble, take a look at for example the ICE scoring model, which in its simplicity is quite efficient.

Why should you want this?

First of all, you probably don't. Small and lightweight laptops hold plenty of umph for simple coding tasks and a proper desktop OS makes life way simpler. That being said, having even more portable setup that can be utilized to jot down a post or a note anywhere seems pretty cool.

Iteration #1: Github Codespaces on Safari

ATM I'm writing this post and testing this setup. For just writing text / code, this seems to be working quite fine. The setup is pretty much as easy as it gets, if you already have an existing repo: Just navigate to github.com, go to your repo, hit the green button choose Codespaces and rock on. A few hickups are outlined below, and I'll try to tackle them and doocument those solutions or give up trying.

E: Solved ~Local development environment~

Update: The port forwarding just miraculously started working automagically. Probably the solution is to just wait. Or start and restart the environment. Couldn't figure out a pattern yet.

Previous issue: It appears that I'm not able access the localhost, even though there's the port forwarding option. It errors with "Unable to forward localhost:4000. The host may not be available or that remote port may already eb forwarded".

2. Keyboard input randomly falls apart

This might have something to do with #1, as the issues happened when trying to do stuff with terminal, ports and write stuff down at the same time.

3. I can't alter the keyboard layout

I use Finnish keyboard with English primarily and especially when writing code and Finnish layout when writing Finnish. This is a quirky workflow that I've developed and probably doesn't concern you. Turns out this was something that needed to be fixed in the Ipad Settings -> Keyboard -> Hardware Keyboard.

This is just a note to self.

If you need captcha, rewatch Theo's video. Probably use hCaptcha for at least anything that's not absolutely huge or otherwise valuable/critical. Maybe could look into Radar by WorkOs.

I just stumbled into a pretty cool workflow for taking notes: Take a voice memo, ramble around as much as you like, grab the transcript and ask an LLM tool to summarize the mess into something more coherent. This can be pretty easily automated: Use something to record your voice, to transcribe it, to summarize it and to store it.

My approach outlined below is very much an Apple Ecosystem way of doing it. But these steps can be easily adapted to other platforms, software etc.

1. Record: We can use Voice Memos app to record the musings.
2. Transcribe: You can grab the memo transcript from the Voice Memos.
3. Summarize: Out of habit I use ChatGPT for pretty much everything, so just copypasta your transcript into ChatGPT for summarizing.
4. Store: Send the note to Apple Notes

I felt that the summaries could be a bit all over the place with just posting the transcript to ChatGPT. To improve the results, you can use an additional prompt that you can prepend to the transcription. What I have atm is:

Summarize the following transcription of a voice note. Write the summary from the first person (eg I think that … instead of speaker thinks …)

The first person bullet especially is quite significant for preserving my sanity. Your mileage and preferences probably will be different to mine, and the prompt can be modified accordingly.

To make this into a nicer workflow, you can use the Shortcuts app. This approach is quite heavily copied from Creator Magic's great YouTube video. To prepend the prompt, what I did was add a "Text" step with the contents of the prompt, "List" step with first item being the text step and second item the transcibed audio and finally "Combine" step that grabs the list and combines the contents with new lines. This could probably be improved (maybe have the prompt in a note or utilize some custom GPT type of deal?), but it seems to work fine for now.

An inspiration for building something came up as I was randomly browsing around and stumbled upon some CSS dad jokes. One was somehow related to sleepyness, waking up and the color #c0ffee. I can't remember the joke anymore, but that nontheless got the idea going: I'll make a library of all the colors that spell out words in some languages. As choosing colors and typography is always hard and there's rarely an objective reason to pick one, I thought maybe picking a funny word that suits the theme of the site might be an approach.

You can find this thingy here.

Basic design

I figured that I need:

1. List of all the words
2. A set of rules that check if a word is a color or vice versa

I guess I'll be running into some performance issues if I do all the calculations every time user visits the page. Probably pre-parsing all the words into a list that has only the "colorful" words would be beneficial, as well as storing the data in a database, but we'll cross that bridge when we get there.

All the Words

This I hoped would be a quick google search away, and the people of the internet did not dissapoint. Dwyl has a helpful english-words repo that has a list of all the english words. What I figured is that I'll just grab the words_alpha.txt and use it as is.

The Ruleset

For any kind of 1337 type of ordeal, there tends to be flavors and more complex rules that meets the eye. For example "1" can be interpreted as i or l but using "1" as both in the same word is frowned upon. To keep things simple, I started off with this conversion table that I'm most used to. I removed characters that are valid in hex as is (eg e: '3').

I might add on it as we go, we'll see. Wikipedia (obviously) has a nice, more expanded table for reference.

const conversionTable = {
  i: '1',
  r: '2',
  s: '5',
  g: '6',
  t: '7',
  o: '0',
}

Parsing

Getting a color out of a word should be quite straight forward. I just check if the word is of proper length and convert all the letters into their counterpart from the conversion table. To make things even easier, I just add all valid letters to conversionTable, not just the converted ones (eg a: 'a').

const getWordColor = (word: string) => {
  if (word.length !== 6 && word.length !== 3) {
    return null;
  }
  let color = '#';
  for (let i = 0; i < word.length; i++) {
    const letter = conversionTable[word[i]]
    if (!letter) {
      return null;
    }
    color += letter;
  }
  return color;
}

Storing the values

I'll just parse all the words at every build/page load from words_alpha.txt. This isn't the greatest approach but this isn't the greates site either.

Design

Just show a list of boxes with the colors and their hex codes. There's probably going to be quite a few matches, so allow some sort of searching / filtering.

Going forward, I probably wanna add some improved filtering options, eg by picking a color bucket "I want something green", or maybe lightness or something. Or using filters like Hue/Saturation/Lightness sliders or stuff.

Hi you! I'm Petri and I am a Software Developer among other things. I currently work at Duunitori as a developer. There I try to build the best experience for those who look for a job and those who are in a need of somebody to do something as well as enable our whole software engineer team to do the same.

I figured that I'd start writing and publishing some notes of mine. I will definitely not be keeping a strict schedule nor otherwise guarantee anything on this site. You could expect something interesting and I might deliver, or you could not, or I might not. Either way, we'll both be suprised.

The general idea is for the posts to be less like complete, coherent write-ups and more like living documents that get appended, edited, changed or otherwise modified at any time. So something like a digital garden. I have a feeling that this post, for example, will be morphing into an "about me" type of deal.