@nikoheikkila@fosstodon.org
@nikoheikkila@fosstodon.org avatar

nikoheikkila

@nikoheikkila@fosstodon.org

Hey there! I'm a Software Craftsman and Extreme Programmer. Currently, I do DevOps at Polar Squad.

I build proprietary software for a living and I love it as much as free and open-source software.

I geek about music, films, history, and geography, too. Check my links for more.

Originally in Mastodon since 2018.

This profile is from a federated server and may be incomplete. Browse more on the original instance.

nikoheikkila, to random
@nikoheikkila@fosstodon.org avatar

When refactoring code, below is my general workflow:

  1. Find out what keystroke or command in my IDE allows me to perform the refactoring.
  2. Perform the refactoring.
  3. See that tests still pass.

Often, in the first step, there might not be a single relevant shortcut available. I welcome this as a challenge to adjust my thought process.

How can I split a larger refactoring to baby steps and still remain safe?

nikoheikkila,
@nikoheikkila@fosstodon.org avatar

When I feel the need to step out of the IDE and refactor manually using the keyboard, I recognise a leap of faith, which can result in a broken codebase.

In case of failure, I must immediately revert back to the latest working state* and repeat the refactoring in smaller steps.

(*) See: micro-commits

nikoheikkila,
@nikoheikkila@fosstodon.org avatar

Many developers modify large chunks of code while refactoring without running tests on the side at all. The outcome is a messy diff with failing tests or perhaps the code is not even compiling. This is a refactoring anti-pattern.

When you can't take any smaller steps, you're on the right track.

nikoheikkila, to random
@nikoheikkila@fosstodon.org avatar

The primary purpose of the Daily Scrum is to inspect progress towards the Sprint Goal and resolve blockers. 🧵

nikoheikkila,
@nikoheikkila@fosstodon.org avatar

While the idea sounds good in theory, in practice, we often fail. I've seen many teams where the Daily Scrum focuses on ensuring everyone has a task to work on. For this, we divide stories into subtasks and assign tickets in Jira.

Some teams practising Scrum don't even have a Sprint Goal. Instead, they have a shallow goal to deliver as many stories as possible and keep everyone at 100 % utilisation because idle hands are considered slackers.

nikoheikkila,
@nikoheikkila@fosstodon.org avatar

Even worse practice is when a blocker for delivery is identified, and people are tempted, or even recommended, to grab another task instead of the whole team promptly resolving the blocker.

nikoheikkila, to random
@nikoheikkila@fosstodon.org avatar

"Estimates are not merely waste, but are actually very harmful. We so desperately want to feel we are in control that we start believing we can predict the future. We can’t. We so much want to have some mechanism that allows us to plan and schedule meaningfully, we start believing estimates for time and money must be useful. And we aren’t willing to reimagine possible alternatives beyond estimates, and beyond trying to predict the future."

— Woody Zuill

nikoheikkila,
@nikoheikkila@fosstodon.org avatar

When you…

– stop pretending you can predict the future
– start working together to eliminate handovers
– continuously communicate with customers
– deliver small batches of work frequently

…you will quickly notice the vain and harmful nature of estimates.

In my current team, we don't bother with estimates nor story points. We have replaced those with continuous communication and delivery.

nikoheikkila, to random
@nikoheikkila@fosstodon.org avatar

Every line of code going to production is considered malicious until reviewed by at least one other developer.

Yeah, not really. Code review is often a rubber-stamping mechanism used to hide the fact that other techniques of building safety and quality are at a profoundly inadequate level in the organisation.

nikoheikkila, to random
@nikoheikkila@fosstodon.org avatar

Are you testing the behaviour or implementation?

A customer orders a vehicle for travelling from you. As a professional software engineer, you start designing the product functionality by writing tests first.

Which of the following test approaches sounds best to you?

nikoheikkila, to random
@nikoheikkila@fosstodon.org avatar

I'm often asked to help a fellow developer solve a problematic situation with the Git version control. Typical scenarios include but are not limited to:

– Fixing conflicts after merging the latest changes from the mainline
– Cleaning up the messy history tree
– Moving commits between branches
– Undoing a disaster
– Recovering lost changes

nikoheikkila,
@nikoheikkila@fosstodon.org avatar

Indeed, Git provides us with powerful commands and workflows to tackle these pesky issues. However, instead of getting good at Git, we should remember that nearly all the need for advanced Git tactics stems from insufficient working methods.

nikoheikkila,
@nikoheikkila@fosstodon.org avatar

I know you will hate me for telling you this obvious trick, but it bears repeating. If you practice continuous integration and push to the mainline as often as possible, you have less or no need for…

nikoheikkila,
@nikoheikkila@fosstodon.org avatar

– Fixing conflicts because local and remote states have less risk of diverging
– Cleaning up the history because you and the team are continuously integrating small units of work in a linear fashion
– Moving commits between branches because you don't use branches at all, or they live only a few hours
– Undoing a major disaster or recovering lost changes because the last known good state is usually a simple remote reset away

nikoheikkila,
@nikoheikkila@fosstodon.org avatar

Back then, I studied all the possible Git commands, mapping the most helpful ones to terminal aliases. Today, I only need a handful of commands. I have also happily forgotten some of the most intricate ones. Instead of reaching out to the Git handbook, revise how you could work differently and eliminate the root cause of your problems instead of recurring symptoms.

nikoheikkila,
@nikoheikkila@fosstodon.org avatar

The history of Git shows we started with a solution fresh in our minds and decided it was best to build a problem to make it worthwhile. It turns out that the more you know Git, the more you need to improve your craft.

Gina, to random
@Gina@fosstodon.org avatar

We need to destroy Margot 😤

nikoheikkila,
@nikoheikkila@fosstodon.org avatar

@Gina Meanwhile, Margot: https://media.giphy.com/media/BiW4r1OAGwin6/giphy.gif

nikoheikkila, to random
@nikoheikkila@fosstodon.org avatar

A random person on LinkedIn (where else?) kindly let me know that I'm not allowed to criticise a tool unless designed specifically for my needs.

This person, without a doubt, has all their software custom-made for them by special software tailors and pays thousands for that.

nikoheikkila, to random
@nikoheikkila@fosstodon.org avatar

It seems that https://devternity.com has vanished — can anyone access the site now? We can only speculate if it comes back online with an updated speakers list or if this was the end.

Nevertheless, I have asked the team to refund my ticket, but I haven't heard anything. Upcoming days will tell if I need to contact my credit card issuer.

nikoheikkila, to random
@nikoheikkila@fosstodon.org avatar

One thing I'd like to see implemented with AI is an obnoxious content blocker.

Suppose I'm scrolling through my LinkedIn feed and about to read a typical post with dozens of two or three-word paragraphs; the blocker extension would flag it under "embarrassing influencer garbage" and hide it.

Does something like this already exist? If not, maybe your company should start iterating on that instead of enriching your text input fields with GPT support.

nikoheikkila, to random
@nikoheikkila@fosstodon.org avatar

Everyone following me knows I'm writing and talking extensively about software testing. Sometimes, I think people might confuse me as a quality assurance specialist.

While I've done some QA work during my career, I'm still far from a specialist. Instead, I consider myself a business developer through means of well-crafted software. Tests — the automated ones, mind you — are merely a visible artefact of my work.

The reason I mention tests often should be apparent, but allow me to rehearse.

nikoheikkila,
@nikoheikkila@fosstodon.org avatar

Without tests, it's unlikely to produce a clean and maintainable software design.

What during the early days of the product looked like a concise and maintainable codebase will, without tests, grow to an unmaintainable cruft over time. The future contributions towards it will become extremely risky and impossible to estimate reliably.

As a result, your business will lose value.

nikoheikkila,
@nikoheikkila@fosstodon.org avatar

Without tests, building a continuous delivery pipeline offering you a rapid feedback loop with A/B testing capabilities is impossible.

The delivery pipeline will flag most defective changes as acceptable for release. After a few costly production fires, you invest significantly into manual regression testing.

If you can't receive feedback on your experiments in due time, you will lose valuable business opportunities and commit to risky decisions not backed up by concrete data.

nikoheikkila,
@nikoheikkila@fosstodon.org avatar

Furthermore, it's expensive to allocate QA specialists for manual regression testing to verify defects "fixed" in the past won't reappear instead of discovering improvement opportunities through exploratory testing.

As a result, your business will lose value.

nikoheikkila,
@nikoheikkila@fosstodon.org avatar

Without tests, it's challenging to maintain a satisfying developer experience and keep your teams motivated due to the increased mental burden when attempting to improve legacy codebases.

I know from first-hand experience that it's always tempting to jump ship when working on a code you don't know well, and you can't change fearlessly. Greener pastures will take away your best talent.

As a result, your business will lose value.

nikoheikkila,
@nikoheikkila@fosstodon.org avatar

Perhaps it's clear now why writing tests is crucial for business longevity.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • JUstTest
  • kavyap
  • thenastyranch
  • ethstaker
  • osvaldo12
  • mdbf
  • DreamBathrooms
  • InstantRegret
  • magazineikmin
  • Youngstown
  • ngwrru68w68
  • slotface
  • GTA5RPClips
  • rosin
  • megavids
  • cubers
  • everett
  • cisconetworking
  • tacticalgear
  • anitta
  • khanakhh
  • normalnudes
  • Durango
  • modclub
  • tester
  • provamag3
  • Leos
  • lostlight
  • All magazines
    •