Slush 2017 anticipation

Reading Time: < 1 minute

Guys and gals!

it’s that time of the year again! For Finns, slush has been significant for hundreds of years. It’s that strange substance that rains from the icy sky and barely resembles snow. You can see slush in various trendy cold drinks; but nowadays Slush definitely means the go-to startup/venture capital/networking event.

Slush brings a really nice buzz into Helsinki. The event takes place traditionally (also this year) in Messukeskus, the premiere exhibition center located quite conveniently in a spot of its own near one of the major developmental hubris of Helsinki, Pasila.

Just today I read a blog posting about a techie conference in Las Vegas; Re:Invent. Las Vegas for me personally is a very warm memory of the times during the height of so called IT boom around year 2000. I was part of the company that went to exhibit hey software product in COMDEX. We worked our ass off literally juggling between presenting, contacting and being true geeks in uniform corporate outfits. Boy it was fun!

Slush has grown significantly from its rather humble beginnings as a very ad-hoc pioneering organization which was and — I believe still is — largely based on the effort of volunteers.

I hope the event greets you with warmth, sizzling energy and lets you completely forget the slush outside. And remember; nothing feels better than to dash a hundred meters in slush to cool down! Have fun!!!


Essential Growth Hormone For Business

Reading Time: < 1 minute

Essential growth factors for companies

“Getting” social media – you can’t dismiss it. Too valuable. Rather train yourself than diss it.

Choosing productive (not “interesting”) tools

Automation. Automation. Automation. Aut…

Going out! Meeting & learning. Sitting still? Busted.

Making sure that rote work doesn’t wear out creativity.

Polls constantly on your own staff – opinion data. At least 1 simple poll per week. Anonymize the polls to get max truth.

Do and present the “post-mortems” of projects. Take pain professionally. Give tips that are active and positive; guidance, not nuisance.

(Do the polls as soon as you have 3 or more people.)

Always pay attention to calculating product margins.

Tracking projects!! Using that precious data: What were the costs? What was profit Margin? Customer satisfaction? Learning points? In practice: action points!

How were the margins re-invested?

ROI, ROE. Yes ­čÖé

“Act like pro – don’t merely dream about it.”


Refactoring and the Code Gremlin

Reading Time: 3 minutes

Refactoring aims to change software’s static┬ástructure – the source code.┬áIt’s not often so much about the performance (run-time), but rather how a developer perceives the source code. You might even say, the ‘elegance’ or ‘beauty’ of the code.

Refactoring itself can be a beneficial mental process, during which developer takes a second glance at the form of the solution; it might also reveal bugs.

Let’s take a look at 2 fundamental cases.


Especially with a novel tech stack, copy-paste is good way to accelerate learning. Be it Ruby, CoffeeScript, or some latest twist of JavaScript, having examples is a soothing and very often used way to kick-start our own code. There’s certainly no scarcity to source available nowadays: GitHub, Stack Overflow, blogs, you name it.

I remember in 2015 when learning “real JavaScript” how many things were cute tricks on the language, since JavaScript was (and basically┬áis) a very simplistic but kind of crude language. Only lately it has started to have some syntactic sugar in it, so you don’t have to write so much tricky stuff to get ordinary things done.

A Stretch (and its rebound)

Many times there are phases in a software project, during which a developer ‘stretches’: makes an adamant commitment to work until a feature works; however rudimentary, but still it “works”.

Say, you’re making the network connectivity features, and the first RESTful API call requires some more boilerplate code than you ever thought.

The concept is something that you know is viable, so you start stretching the solution: create all variables you might need; crunch the call string (don’t care yet how it looks), and fire a first call to see what possibly happens. You get an answer, so lo and behold! You know the server has received your packet of data! That’s great!

Encouraged by this you add bit more to the code to really get going. In fact, you need to do some parsing on the return packet. Then you need to wire the error handling code, and… more. You now got some 50 lines of code, which indeed seems to work.

You are pacing forward, doing the simplest and most rudimentary code that will get the job done. The intermediary product, you know for sure, is full of bad practices, but that’s ok – for a while. You know that the code gets a second review and things will be refactored.

Stretch as combat experience

Making brave stretches is indeed quite an important part of programming. During a stretch, it might feel uncertain and being out there in a jungle, without a compass, you as a developer are also putting a lot at stake: there’s a chance that the solutions a) won’t work b) was completely the wrong one to begin with. But nevertheless those stretches are crucial for keeping the velocity (going forward) in a project. You are trading risk for risk: by taking some risk you alleviate the risk of being faced with an unknown task, of whose complexity you cannot say anything certain. Now that you’ve done the rudimentary code, you know a thing is doable, and you know the basic solution structure. Even if you wouldn’t accomplish a working solution, you have gained experience of the problem domain.

What about the promise of cleaning up?

If you ever played with LEGOs, or had a hobby that required building stuff with your hands and tools, you know how lucrative it is to “forget” cleaning up. Putting tools in their own place, cleaning trash, collecting and organizing stuff is rote task compared to the challenge of conceiving something novel. Having spent time in perfect flow, and probably feeling either accomplishment (or apathy for the lack of it), cleaning up and restructuring the code feels like an inferior task.

So, to recap: the tendency to favor even hasty development to stagnation is actually very healthy. The thing that’s often forgone is that if you never clean up the mess, it’s going to be what you’ll stare for a long time – maybe not this month, or even this year, but believe me – there are no code gremlins that tidy up things automatically for you, when you’re asleep.