michalkostic - Tumblr blog

[michalkostic]

My latest article on how GoHealth delivers a great customer experience in the highly seasonal market. Take a peek behind the curtain of the leading health insurance marketplace to see what it takes.

[michalkostic]

My recent article - learn how we have sped up our release process at GoHealth.

[michalkostic]

Lean Canvas Example - Machine Project Manager

Which office job is most likely to be replaced by machines? I believe project management is one of the top candidates. With all the manual progress tracking and status checking it is ripe for automating away. Imagine all the tedious work done by an AI - bot would check progress on tasks, make sure everything is on track and follow up on open questions.

With advances in machine learning, natural language processing and AI in general, this scenario is closer than expected.

Automation of tedious project management tasks has been bugging me for some time. To get it out of my head I decided to draft the idea via lean canvas technique as an experiment. Here is the result.

Problem

Project managers spend time on manual work without added value - e.g. reports need recurring supervision, backlog needs regular grooming

Uncertain project status - issue tracker often does not reflect reality and is difficult to keep consistent and up to date

Solution

Alerting when report deviates from key developer metrics - e.g. task takes too long

Automated process enforcement - e.g. alert developer via chat on too many tasks in progress or too slow progress

Predefined metrics to watch for healthy project

Unique Value Proposition

Deliver more projects with less management

Key Metrics

Developers tracked - measures how big impact we have on business

Number of reactions to alerts (remind etc) - measures how useful the product is

Number of alerts that need adjustment (snooze) - measures where to make the product better

Unfair Advantage

Management and developer experience in one person

First hand corporate project management experience

Customer Segments

Medium to large companies with significant software development department - provide better project visibility and ease overloaded managers

Buyers - company CEO/VP of engineering

Users - project managers, technical leads

Inflicted upon - developers

Startups, small dev shops - manage more projects with less people

Buyers - co-founders

Users - co-founders, technical leads/senior developers

Inflicted upon - developers

Channels

Word of mouth

Free offer to limited audience (e.g. project managers in Toptal)

Guerrilla adoption - enable easy quick start for single user who can convert whole company - provide standalone utility app

Cost Structure

Development

-- MVP - $10,000 if externalized - two person month for local developer

-- Ongoing development if mildly successful cca $10,000/month

Hosting - 20$/month VPS

Revenue Stream

Jira plugin marketplace - 1$/user/month

Hosted instance - connectable to publicly available data sources (GitHub, BitBucket) - $10/user/month

Self-hosted server (connectable to multiple data sources - jira/redmine/trac, gerrit/phabricator/github) - tiers per tracked user - $3000

Add own plugin marketplace - 20% of plugin price

Prices based on project management products that target similar market (Basecamp, Trello, Jira)

Basic monthly expenses would be covered by 1000 paying users, or few medium sized companies, which looks realistic in terms of achieving profitability.

Big Vision

Machine learning project management bot that handles communication, understands comments (e.g. recognizes no feedback was given in expected time) and tracks progress. Even if we do not replace the human managers yet, we can give them new superpowers - there comes an age of an augmented project manager.

[michalkostic]

Edge case bias

Have you ever come across unimportant but nicely done part of an application? I have observed this quirk myself few times.

For example in an e-shop, user preference settings can be oddly polished - feature that is mostly unused by me and I am willing to suffer through it once in a while workout impact on overall experience. However from development standpoint, updating user preferences can be tricky - there are many validations and you might need to integrate several external services to promote profile changes. The screen needs a lot of debugging and is heavily used by the developer to update settings for testing. Naturally the preferences screen gets nicely polished via multiple iterations and sheer need to work efficiently (eat your own dogfood principle).

On the other hand putting item to basket can be seen as straightforward task - update the cart, store it in the session and you are done. Do one test transaction to make sure everything is fine and you are ready to move on to the next feature. Of course nothing is as simple as it seems and lot of issues can go overlooked - What if I add items from multiple open tabs? What if I am already in the checkout? Unfortunately you will not notice as there are other features needing attention.

I see this example as an edge case bias in building UIs. The complex parts get lot of attention while the seemingly simple ones are typically handled in once and done manner.

Of course it is obvious which functionality brings more value to the customer and developers typically understand this, but being engrossed in the problem causes all types of myopic behavior. As a result, friendly nudging is sometimes useful.

For me this serves as a reminder to regularly take the step back when I am deeply involved in some problem to not miss the forest for the trees.

Also, keep in mind to always spend extra love on the main user flow.

[michalkostic]

How to Become a Senior Developer

Sometimes it seems like junior and senior labels are applied to developers rather randomly. Obviously seniority is not a function of age or number of years of work experience. It is also not exclusively bound to technical skill - if it was, there would be no difference between whiz-kid and senior developer. If you want to be treated as senior developer, try to apply following behaviors.

Think

Thinking is fundamental prerequisity. If conscious thinking is not present, no other skill can balance it out for senior position. You are not humanoid voice controlled robot - so use your brain to evaluate what it’s asked from you instead of either doing exactly what being told or dismissing everything en-block. If you have lazy mind you still can be valued professional practicing software development trade, but do not complain if the most complex and exciting tasks get assigned to someone else.

Provide Value Beyond Specification

All software specifications are faulty, incomplete or contradictory. Try to understand the intention and infer the best solution. This behavior usually goes together with thinking but it is important enough I have special section for it.

Mind the Users

Always keep users in mind and decide in their best interest. Taking shortcuts and imposing unnecessary constraints on users just because they are easy to implement is a big no-no!

Develop Feeling for Trade-Offs

All decisions have trade offs. People with more experience should see various options and consciously choose one that fits the constraint best. Typical juniors tend to pick the first solution they stumble upon or blindly follow whatever they are instructed to do.

Strive for Understanding

Understand codebase, understrand problem you are fixing or understand the underlying technology. You have to be able to reason about your code. When you write a piece of code you need to understand what it does, how it behaves and why it behaves the way it does.

Become Comfortable at Any Abstraction Layer

You should be able to consider IO impact of the change, application design, user experience and business value in one breath. Move between abstraction layers with ease and focus on the audience appropriate level during discussion, but keep checking other levels in the background (e.g. to cross check business requirement with technical feasibility).

Push back

Having enough insight and courage to challenge the dubious ideas. Do not confuse with constant complaining.

Other Characteristics

I find following behaviours obvious and kind of buzzwordy, but they are still important and necessary for any developer who strives for seniority.

Listen and make compromises - nothing is black and white

Independently solve problems

Focus on quality

Pay attention to details

Bring solutions

Take responsibility

[michalkostic]

UX of a 5 euro MP3 player

I never felt a need to have a dedicated music player, at least until I started working at the company where YouTube is super slow.

After going through couple of options, I decided to get a small, cheap MP3 player from China. I thought - what a chance to conduct a one person UX test. Here is what I have learnt as a web developer from junk MP3 player.

First impressions

Keep realistic expectations

Ordering was smooth and easy - order at eBay, pay via PayPal, wait for three weeks and voila - new 5 euro MP3 player landed in my mailbox. Five star user experience so far.

Even though three weeks sound long, I didn't mind the wait - it was clearly communicated on eBay, the package arrived on time, maybe even a few days early and the time wasn't really critical for me.

Hint for software developers - if something is going to take ages, make sure users are aware of it in advance. Also make sure the wait is worth the time.

Set expectations correctly for timing.

Norman Nielsen: Everything I Needed to Know About Good User Experience I Learned While Working in Restaurants (https://www.nngroup.com/articles/ux-learn-in-restaurants/)

UNIX philosophy: Do one thing and do it well

I was curious if 5 euro player would even work. After hasty unboxing, I eagerly turned it on, just to faced with a blank screen. Luckily the player came to senses after a few seconds and started up properly. With everything ready, I hit the play button and was amazed. It's tiny, it's simple and it plays music like there is no tomorrow.

Obviously it's not a smart device - it can't make phone calls, take photos or learn my music taste. But when I hit the play button, I get a song and that's what counts - my goal of listening to music is satisfied, leaving warm fuzzy feeling inside.

Of course many successful applications subscribe to the UNIX philosophy (which is often their reason for success). One obvious example is Google Search - search and only search - nothing else.

Design is how users feel when experiencing product

Rocket science is cool and everything but how someone can produce this small piece of electronics and ship it across the world for few euros, is beyond me. They say user experience is also about how you make user feel - when I received the mail I felt like I'm living the future.

For me one of the feel-good applications is Jira issue tracker. It makes me feel like the whole project is at my fingertips - it really helps fostering the idea that the project is under control. Jira achieves this with the right dose of clean design, information density and in-place editing.

Design is how users feel when experiencing product

http://radar.oreilly.com/2015/08/design-is-how-users-feel-when-experiencing-products.html

Reality strikes in

The honeymoon period took about 3 minutes. As I was progressing with the usage I found various quirks that lead me to love-hate relationship with my new toy.

Reliability

The thing is super unreliable and that breaks the whole UX. Play button either continues playback or turns off the device, shuffle always gravitates toward the same song (the player seems to like Astrud Gilberto very much) and it randomly turns off by itself. All the failures happen without any pattern or obvious workaround. The inconsistency is really driving me crazy - interacting with UI where all features are controlled by random generator is a new kind of hell.

This struggle has made me much more aware that reliability is actually a feature. Users can work around the lack of functionality, but can't work around the crashes and poor performance. When you have to choose - picking better reliability over new features is a safe bet.

Here's my personal anecdote - I had to abandon Ubuntu on my new laptop because I just could not get wifi working consistently - even if Ubuntu is considered the most user friendly distribution, all the nice touches meant nothing if my computer could not access internet.

Blessing in disguise

There are no directories - the device shows all MP3s in one huge list. What at first seemed like a deal breaker, sparked a new cool behavior. With such a limited navigation I play songs on shuffle until I like something, then switch to regular playback. Shuffle over a large set of songs I found interesting sometimes in the past, is cool music discovery algorithm. Even though "Latino - 80s - Jimmy Hendrix" is a crazy mix, at least I don't listen to the same three albums all the time. Apparently lack of functionality can bring interesting emergent features (more variable music discovery in this case).

Poster child for the the web - Twitter character limit brought more concise messages and soundbite blogging.

Feature convergence

Play, shuffle and repeat are merged into one setting - indicated as R-A, R-R and R-0 respectively. At first sight it is not obvious how to change the setting (or even what the setting does in the first place) but with couple of tries, it is easily discoverable.

It is best solution considering the limitations and a good reminder that merging concepts is fine as long as there's underlying consistency and logic. Player designers get extra points for making me feel safe to experiment.

Google Keep is good example for concept convergence - text note is also a list (every new line is separate item). It's not obvious either, but it's super helpful.

Final thoughts

Considering all the quirks and clever hacks, the player is a value device where you get exactly what you paid for - no more, no less. And that makes me feel like there's still a justice in the world.

My final takeaway is (apart from owning cute little device): reliable product and smart tradeoffs take you long way.

[michalkostic]

Architectosis

Architectosis is a dangerous disease affecting software developers as they progress through the ranks of corporate organization. I am going to describe this condition and propose cure in hope of increasing the awareness of this silent killer.

Architectosis - disease of increased self confidence, contracted by people holding the role of software architect

The symptoms include

Compulsive handwaving - "I have given you high level solution, the rest is easy - just figure out implementation details"

Argument deafness - "Whatever... I will again explain to you why I am right"

Delusive problem solving - "I have designed this complex solution to the problem I imagine you might have"

Bullet pointisim - "This product is obviously much better - it has more check marks in the comparison table on its website"

Academicism - "All problems can be solved if we discuss them long enough - the less we work on the actual problem the better"

Technostalgia - "I have last programmed five years ago and I base all my decisions on that"

Disease results in dysfunctional bullshit detector. Even worse, victims are prone to generating increased amounts of bullshit of their own. As result they grow disconnected from actual problem at hand and get isolated into the role of enterprise architect, solution architect or other fancy form of solitary confinement.

Prevention is the most important way to avoid the condition. Use high doses of honest self reflection and exercise programming regularly. Watch out even if you are symptom free - noone is 100% immune!

Architectosis can be cured by involving affected people in day to day programming tasks and treating them as equals. The medicine called "eat your own dog food" shows some promise. Protecting patients from grunt development work worsens their condition.

As precaution, do not assign susceptible people any title resembling word "architect". It might cause fit of latent architectosis in otherwise healthy individuals.

Share this with your friends who might be at risk but remember - stay healthy and watch for your own symptoms.

[michalkostic]

Advantages of Rapid Prototyping in Java

When it comes to rapid prototyping, dynamically typed languages are considered way to go. Java is usually considered okay for large scale projects with careful planning where performance is a concern. I believe Java is good prototyping language as well. Here is why.

There are many reasons to choose Java for quick and dirty projects. Of course it's rather simple language and I know it quite well (10 years and counting). It is also known you have many libraries in maven repositories at your fingertips. But for me biggest catch is Java frees me from worrying about following considerations.

Naming - you have statically typed language - renaming is single keyboard shortcut away. Try to come up with most reasonable name you can get to in 10 seconds (preferably one second) and rename if you find better

Correct class structure - just put method wherever it fits and redactor later

Configurations - you don't need to be afraid of absolute paths hard coded in your program. Make sure they are isolated in at least local variable and refactoring them will be a breeze.

Integration - forget database, logging, parsing - everything can be added later. Spring makes integrating external systems particularly easy.

Remember to practice one thing - always be refactoring. Move your methods, adjust class hierarchies, rename everything. If you shy away from ruthless refactoring of your code, you will end up with giant pile of mess.

You never know what your prototype will end up, but with Java you will be able to scale your codebase as you go.

Note: this of course is valid for other statically typed languages with great tooling support.

[michalkostic]

Code review checklist

I spend significant amount of time at work doing code reviews - here are some lessons I have learnt.

Overview

I tend to accept code that correctly implements required functionality, code that is easy to read and easy to extend (in this order). I try not to reject commits on the topics that are up for debate or for which there is no "One True Way" of doing them.

What is the problem?

My first step is looking at linked issue. This check is just a click away since we require every commit message to contain a issue number. I highly recommend this policy. As result, all our commit messages look something like this:

PROJ-123: I have change this and that.

Adopting issue number in the commit message is useful both ways. From the commit you can get to the original issue definition and from the ticket you can see how the problem was solved. You will be thankful for the links from the ticket to the code when you are trying to fix a similar issue in three months.

Is it solving the issue?

As a second step I try to understand what the code does and check it against to the required functionality.

Is it solving the issue? Great! Are there obvious errors, forgotten edge cases or decreased usability? Reject with a vengeance.

Do I understand the code?

In case I do not understand either the problem (issue) or the solutions (actual commit) I contact the commiter via phone or message. No exceptions here - I do not dare to review code I do not understand.

After I feel I understand enough I go for one of the following:

I had a weak moment and the code is obvious

I suggest adding appropriate comment to the code so next person does not have to figure it out

I update the system documentation on the project wiki

I update the issue description to make the problem definition clearer

Is the code of good quality?

During the review for correctness I keep an eye on overall code quality. Here are some of the issues I watch for.

Naming

Well named methods, classes and variables are the most important part of documentation. Holding this belief I am very strict when it comes to naming.

Sometimes there is no clear way how to name things. For that cases I tend to accept the name chosen by original developer, maybe suggesting to add a comment.

Simplicity

I have a strong urge to reject complex code. Problems should be solved in as simple and straight-forward manner as possible.

My rule is: Do not create new classes or abstractions unless you specifically need them. You never know what future will look like and chances are you won't guess.

I like the "Rule of Three" as presented by Jeff Attwood (http://blog.codinghorror.com/the-delusion-of-reuse/). Roughly paraphrasing:

If you need it once, build it. If you need it twice, copy it. If you need it a third time, abstract it.

Flexibility/Extensibility

Keeping the previous point in mind, my next rule is - code should be easy to change.

Easy example of the rule is "no literals in the code" (use at least local variable if not a constant). Another example is ruthlessly extracting functionality to separate methods.

Single Responsibility Principle (Cohesion)

One class - one responsibility. Simple enough. I will probably reject a commit that has a class that breaks this rule.

If the class is in the gray area (kind of feels wrong but I can't really put a finger on it) I do not reject. That uncertainity often comes from lack of information on how this class will be used. Wait with refactoring until the usage is clearer.

Idioms

Non idiomatic code is a big no-no. It confuses people and can introduce subtle bugs. Unless your unusual code is really well justified it is going to be rejected.

This might spun a question: "What is idiomatic java?". To answer that I try to find examples on reputable sites (StackOverflow) or in the famous Java libraries. If all else fails I rely on my hunch coming from years of experience.

Some good justifications for non-idiomatic code are:

improved API of the class

overcoming known issues of the used library

improved readability on many places of the code, thanks to your clever hack.

Code smells

Code smells ask for an explanation. I tend to leave a comment requesting more details or discuss directly.

If you need a refresher on code smells see http://blog.codinghorror.com/code-smells/ (yes I like coding horror blog :)

Trade offs

The main goal is to make customers happy. Customers are happy when the application is reliable and works as expected. You get bonus points for accomodating their change requests.

Code improvements coming from code review should always keep this in mind.

Some questions to ask yourself:

Is the development effort worth the improvement?

Will we be able to introduce new features faster thanks to this?

Will we produce less bugs?

Is the improvemnt in code quality worth the time spent?

Positive communication

Important goal of code review process is to help people write better code. For me this means providing suggestions for improvement instead of pointing out what is wrong.

I believe all my teammates are smart and capable people. With this in mind I ask for explanations so I can understand better. It is too easy to push my way of doing things - let the commiter explain the code and leave some space for self expression.

Communication levels

too big or complex change, complete WTF, too serious issues - talk in person or on the phone with the commiter

major issues - leave comments in the code review tool

minor issues - possibly accept the commit and create a new issue for the improvements.

Conclusion

All hints mentioned above need to be considered on case by case basis. Some code that looks complex needs to stay so and some seemingly simple code is breaking the project in unknown ways. Defining where to put line for single responsibility is sometimes tough. Figuring idiomatic vs non-idiomatic is more art than science.

Keep the communication with the author positive and issues will sort out.

Most importantly - beautiful code is means to an end, not a goal itself.

[michalkostic]

When pieces start fitting in

One of the great joys of programming is when nearing a complicated new functionality and pieces just start fitting in. After hours of running various tests, helper functions and proxies you finally start seeing the whole thing moving. Priceless!

[michalkostic]

Feature implementation workflow

Every time I need to implement a new feature there is a small discussion within myself: \- Is it aligned with the goal we have right now (e.g. increase retention, catch up with competition...) Yes! \- Is it simplest solution possible? No, but i have a great alternative solution that will greatly help us in the future. \- Will it take extra time? Max few hours. \- Ok, go for it. Some time later: \- You have spent more than 2 days extra on the feature already! Erm... yes. \- Just go with the simplest solution! Now! Moral of the story: you can try out new stuff, but know when to stop.

[michalkostic]

Idea - hot or not?

or *Framework for Evaluation of Acceptable Startup Ideas* This is mixture of my own findings, popular approaches like Lean startup canvas and things investor say they look at in startups. I use these kind of questions both to evaluate my ideas or when someone is asking for feedback on their idea. ###Idea inception Make notes - scrap papers, mobile phone, plain text file. Every idea counts - you can often extract good parts even from the worst idea you've had. ###Problem What does it solve? B2B -> does it earn money or help them earn money? B2C -> entertainment, social interactions What is done today to overcome this problem? ###Users Who is going to use it? Think of detailed persona - e.g. people who own iPhone and check in on foursquare or women 40+ who play Farmville. Vague definitions like - everyone or kids are not enough. Why will they use it? Will the usage pattern fit the users (e.g. young adults vs seniors/retirees)? Does it fit social interactions (e.g. open vs closed cultures)? Chiken&egg? (how to get providers for the service) Hyperlocal? (start at one location - Bratislava? Vienna?) ###Solution How do we solve the problem for the people? Will it add value to them? Will it be simpler than status quo or will it add significant value? Focus - is it simplest solution for the problem possible? ###Team Do you know domain OR are you interested in it enough to get it know (e.g. would you be able to write a blog about the domain, are you interested in reading news about the domain etc.)? Do you get things done? Are you willing to go through the trouble - to do the legwork? ###Reality check - money, resources and market How will you earn money? Won't it take too long to implement? (1-2 years for first version is usually too long) Will the market size/earnings warrant resources invested? Can it be done simpler? (see Focus) Competition: * Exists and successful - How will you make people switch? Why should they switch? Is there significant lock-in? * Exists but none successfull - Why they aren't successfull? How will you be different in order to become successful (more features is not enough or "we won't suck" is not enough)? * Does not exist - Why? No market? Are you too early? Are you able to build the market? Most important - **DO SOMETHING** - iterate, move forward (Start with something! Do it! Evaluate! Pivot if needed!)

[michalkostic]

Get sh*t done

Software development tips for startups.

Presentation given at MozgoHouse/BrainHouse - the coolest startup co-working in Bratislava, Slovakia.

[michalkostic]

Presentation tips

These are tips for tech geeks who are novice speakers. If you are next incarnation of Steve Jobs, please stop reading. I have read most of the tips somewhere or they have been advised by people who are way better at public speaking than me. All of them have proven useful and would improve speaking of many of my peers. ###Talking technique **Practice** - seriously, just practice! I mean it! I really, really mean it! Pretty please with sugar on top, practice the f*cking speech [1]. **Be civil** - talk fluently. If you bark out words with pause after every one of them you will sound like a pathetic politician wannabe. Make pauses when required by interpunction - commas and fullstops. **Talk slowly** - when you feel you are talking painfully slow, you are at about OK speed. Slow talking is not bursting out word and then making a long pause. **Gesture box** - keep your hands in front of your body between waist and shoulders. Move them outside for extra impact - use sparringly. ###Presentation content **Have a story to illustrate your point** - don't just tell, show them by a short example. Example: "startups are hard" - ok. Better: "When doing startups you will only sit at the computer, talk to customers and eat. Sleep is optional. Probably best: "When I was doing startup I slept six out of seven nights under my desk in the office". **Talk first** - Create slides around your talk, not your talk around your slides. **Build from 2 minutes up** - Think what you would tell if you had 2 minutes of time and build up from there. [1] [http://www.youtube.com/watch?v=-ZRUaDGW7WQ](http://www.youtube.com/watch?v=-ZRUaDGW7WQ)

[michalkostic]

Older presentation shown at Java Students User Group in Vienna ([jsug.at](http://www.jsug.at)) as part of our Touchqode presentations roadshow.

[michalkostic]

Train and rest

I have been doing rock climbing for quite a while but only recently I have started doing some more progress. The trick is **regular training** (twice a week, even if I don't have time for full session I go at least to boulder for 1 hour) and then take **a week off** every few weeks (say once a month) - no climbing at all. It helps your brain tremendously to sort out the movements in the background and maybe even supercompensation to kick in. The same is important for me when working on startup - **push hard** but don't forget to **take rest** once in a while. It may take a day or two to get back to full speed after few days off but it will be quickly compensated by supercharged performance in the next few days.

[michalkostic]

Sex, startups and death metal

We have organized a startup event for which we needed a title. One of the suggestions was: let's call it Sex, startups and DEATH METAL.

I find it very fitting:

Sex - you get screwed and f*cked more times than you'd like to

Startups - they are close to drug addiction

DEATH METAL - most of the startups die at the end anyway