mks

SEEKING WORK | Europe | Remote Worldwide

I am an engineering lead with 20+ years of experience in software engineering in startup, scaleup and enterprise. I bring both product and technical sides together in my experience, so I can help you flesh out ideas, systematically analyze them, prioritize, architect solution and bring it to life. Available for consulting or full time team involvement.

# Areas

• Product ideation, analysis and architecture

• Team and technical leadership

• Independent software development

• Technical and software development best practices coaching

• API design

• Technical writing and documentation

# Contribution examples

• Increase frequency of releases by standardizing the release process and educating people

• Technical architecture and development of new features, often in high risk, high uncertainty environments

• Improve data team effectiveness by introducing better support process and documentation

• Work with external vendor to drive implementations of new payments methods

• Build out skills of multiple developers via code and architecture reviews, delegating tasks that help the

# Technologies and tools

Web and APIs: Java+Spring, JavaScript, TypeScript, Node.js+Express.js/hapi, React, OpenAPI

Cloud: AWS - EC2, ECS, S3, ...

Data: Python, Airflow, Kafka, Flink, Aero, Redshift, MS SQL server, MySQL, MongoDB, Couchbase, SQL

# Contacts

Location: Slovakia, remote, relocation OK

LinkedIn: http://www.linkedin.com/in/michalkostic

Web: https://michalkostic.com/

E-mail: michal.kostic@gmail.com

I am bored of AI - it produces boring and mediocre results. Now, the science and engineering achievement is great - being able to produce even boring results on this level would be considered SCI-FI 10 years ago.

Maybe I am just bored of people posting these mediocre results over and over on social and landing pages as some kind of magic. Now, the most content people produce themselves is boring and mediocre anyway. The Gen AI just takes away even the last remaining bits of personality from their writing, adding a flair of laziness - look at this boring piece I was too lazy to write, so I asked AI to generate it

As the quote goes: "At some point we ask of the piano-playing dog not 'Are you a dog?' , but 'Are you any good at playing the piano?'" - I am eagerly waiting for the Gen AIs of today to cross the uncanny valley. Even with all this fatigue, I am positive on the AI can and will enable new use cases and could be the first major UX change from introduction of graphical user interfaces or a true pixie dust sprinkled on actually useful tools.

Your hands are the most practical brain-computer interface you have. With touch typing it really feels like you are controlling computer with your mind - for me it's absolutely worth the time investment.

I was lucky my father prompted me to self-learnt it in high school. I have started with learning basic hand positions and technique from a book. Once I could barely type without looking, I started transcribing handwritten drafts of my school essays to the computer. Painfully slow for first few days but gradually I got to decent speed (and tidy looking essays).

Oddly, when writing documents, I still prefer pen and paper for taking notes and writing first draft. Afterwards nothing beats the power of editing on computer where touch typing is the ultimate power up.

Add the persistent anxiety that you are missing something you should not have and you end up with constantly refreshing the feed instead of working - just like social media and exact opposite of what you want.

MS Teams cause enough headache by sorting the messages by "latest updated thread" completely obliterating the mental model of the conversations in the channel I have.

Some ideas for ideal team chat:

* Automatically build threads or tag messages by topic in threads so you can easily filter out the topics interesting to you - often there are multiple discussions intertwined that should have been in separate threads but people just reuse the threads

* Collapse the resolved discussions into a conclusion (with option to view the discussion) - when the discussion goes into shootout of messages you might be interested only in the conclusion, not how they got there

* Announcements - sometimes you really just want to announce something (on company wide scale, team scale, or just personal Tweet sort of thing) - make these separate and browsable - here the automatic feed construction sounds appropriate

* Activity digest - at last workplace I liked the Confluence digest email as it brought attention to projects and topics I was not directly involved with - nothing happened if I missed those, but was nice to keep an eye on some of the initiatives

It is super important to make a tool the people can trust - no one likes to make or hear excuses like "sorry I did not see the message".

We definitely need better tools for communication, so keeping fingers crossed for your success.

There's so much more to CSV file import than just uploading and parsing - service like this can become backbone of any enterprise data exchange pipeline. For real mission critical use cases you need features like being able to ingest multiple gigabyte sized files reliably, quickly revert the import or switch to a specific version, detecting errors and recovering from partially corrupted files, detecting the new version is available, possibly importing just changes, publishing metrics on imported files to observability platforms, alerting if anything goes wrong...

If CSV import is not enough of a product (I believe it is) you can add exporting functionality (e.g. export this table to CSV and deliver to SFTP exactly once, but make sure to handle target downtimes) and you have an "Enterprise File Gateway" that could reduce development costs in many companies.

This site is quintessential Czech humor, similar in spirit to recent Kralovec annexation and Jara Cimrman. Thank you for linking it here.

Great video. It shows how much climbing (and lot of other things) is in your head and your repeated experience. The route (5.9/5a/VI) must be laughably easy for Midtbø who climbs 5.15/9a/XI+ yet he is quite understandably fighting for life while Honnold is walking around, enjoying no-hand rests and recording. Gradual exposure takes some of the scariness away I guess.

Maybe the SkySail could own the sail system and sell the "thrust" - basically charging a success fee for saved fuel. In a similar vein in how the airlines don't own the engines of their airplanes but rent them from manufacturer - https://aviation.stackexchange.com/questions/12528/jet-engin...

Of course this is an armchair thought experiment, but I am curious about your opinions.

It will be difficult and frustrating, but can be also fun and rewarding in addition. Here are some pracoval tips that worked for me in similar situations.

Treat everyone with respect - everyone has a story and being competent developer is not the only metric for human beings.

Reduce scope - better deliver few solid features than many half baked. You will need to get heavily involved in implementing those features so better not spread yourself too thin.

Start with authoritative management style - it's ok to say "do this and do it like this". Particularity with hierarchy based cultures, this could be even expected. At the beginning it can be uncomfortable as Western developers are often used to servant leadership style that supports freedom, outlet for developer creativity and individual autonomy.

Set precise rules - people are usually able to follow checklists and step by step guides. Have process ready and thought through, but tailor it to the situation on the ground. An example could be: implement task, write unit test with 80% coverage, build and run test locally with no tests failing, send for review.

Don't expect creativity - be as precise as possible specifying the tasks. Include design in the description, any names of the classes you want to have. Ideally have a pointer to code or example on internet that can be copy paste and modified. Specifying tasks this way is doubles the work it usually takes but otherwise you get into endless reworks and headaches. The level of detail needs you to be very well prepared in the technology, design and domain knowledge. Read up ahead on the stack they are using, patterns used for the type of app you are building, look at the code and get familiar with the domain.

Use the hierarchy - identify the one or two promising team members and with with them. Let all other team members consult them first and only then approach you. It's easier to work in depth with two people than get drowned in random questions from five or six.

Expect to get your hands dirty - you will still need to do lot of individual contributor low level implementation work to set standards and so that others have place to copy from. Your code needs to be near perfect the first time as it will get copied over many times. This is painful, but make it work now and refactor later often doesn't with great, when there are 5 people multiplying the work that needs to be refactored.

Distinguish the work from the person - it keeps amazing me how much I like some people on personal level yet hate their work output.

On the other hand this can be a great adventure, getting to know new people and country while working on a common goal. Crisis often bonds people together anyway.

Hope that helps and keeping fingers crossed for you.

Feynman: Surely You're Joking, Mr. Feynman! - great inspiration for regaining playfulness. Particularly this quote applicable to many burnt out developers I believe:

Physics disgusts me a little bit now, but I used to enjoy doing physics. Why did I enjoy it? I used to play with it. ... So I got this new attitude. Now that I am burned out and I'll never accomplish anything,...I'm going to play with physics whenever I want to, without worrying about any importance whatsoever.

Maybe the times are different now than in the past or the food industry works on different timescales before they kill off something. Possibly because the investment is much bigger than software - they mention building a whole new factory for an untested product - that made me shiver. I might be just spoilt by ease of pivoting in software, but what led them to believing into the new drink - were they acting just on a hunch and feeling it tasted good?

It intrigues me that the experts and their market research told them it will fail. Did they just do a lousy research or was the idea too innovative? How is it possible to distinguish between those cases (bad research vs no one will buy it vs innovative idea people don't understand yet)?

The best observation from the article is that payment system complexities are not entirely technical. Some that we experience:

The domain is really complex - credit card transactions have many variables that can make endpoints unhappy, add internet payments to the mix (like PayPal) and you are in for a madhouse

External systems are full of surprises - you get an error response to your payment request, but then money suddenly appear on the merchant account. Or API changes without notice. Or test environment behavior is different from production. Or any other surprise that can come up from integrating to third party service.

Every transaction counts - you need to carefully consider which errors you ignore and move on, for which you try to cancel the transaction and which are just fatal failures.

Logging, logging, logging - having good information in logs is half the battle in disputes (which come up regardless of how fault tolerant your system is).

Your clients come from all walks of life - you don't have any guarantees about the user agents - IE8 support anyone? Odd mobile browsers? Paranoid browser settings? All of that can cause havoc in your presentation layer and cause endless mysteries.

I am not sure if Erlang (or any platform for that matter) could help with such issues. The key is having development team of technically competent people who care about the project. The rest is implementation details.

Your issuer could talk directly to your private wallet (e.g. on your phone or on server). You could preapprove requests coming from your issuer to be automatically executed so that there is no payment delay. This scenario would be somewhat similar to Direct Debit transaction and would require wallet software supporting automated requests.

Implementing interactive approval would be more difficult to integrate. Authorization systems typically respond pretty fast, so there might be automatic timeout in the payment chain (terminal, acquirer, schema network, issuer) if the transaction was waiting for your interactive confirmation. Maybe some magic with initial pre-auth and subsequent post-auth attempts at regular intervals could work but would be no fun to implement either.

Sorry for the linkbaity cliffhanger.

Occasionally there exists a situation when there is huge demand for shipments in one direction (e.g. Hong Kong to Singapore) while there is not much traffic the other way round.

Shipping companies then need to get those containers back to origin, so the prices go down (better ship full container where at least handling is paid rather than empty container where carrier has to cover all the costs).

Not sure how often this happens currently, I got the information from friendly trade lane manager few years back.

I fondly remember interning at major freight forwarder during university. The main input interface was paper which was them keyed into the mainframe application. Only the biggest partners have been integrated via EDI. So just putting sensible API in front of all this sounds like good idea.

I have been working on operations data mart most of the time (and saving cca 30 000 dollars on carrier volume discount on shipped containers) but I always felt my most appreciated contribution was stitching together few Excel macros to make Request For Quotation evaluation easier.

So here are my two free ocean freight startup ideas:

- precise container reporting for carrier disputes (10 FCL 40 footers from HKG to HAM), including error detection when port is incorrectly filled in just because it has similar code

- RFQ evaluator - as simple and accessible as excel, but capturing the specifics of ocean freight (tens of port pairs, container specifications, splitting price to freight, terminal and surcharges etc).

Did you know you could have your container shipped for free - only for cost of terminal handling (on certain routes, at certain times)? Fascinating industry.

For me this means 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.

It is not uncommon to reveal bugs during code review just by looking at code when the author claims they have tested everything and it works fine. Of course they have missed some test case, but how do you make sure your quality assurance does not miss something as well?

I believe it is cheaper and faster to understand the code, side effects and interactions than to rely only on testing (which is immensely important of course).

In order to grow as a developer one has to understand there is no magic - you need to strive for understanding.

The checklist oscilates between high level (does it work?) and very specific - even stuff auto format could take care of (braces).

Creating such an checklist is great exercise though - writing my own made me think heavily on what is important. Then I realized writing it down is not enough - how do I know it is not bunch of made up rules? So I have also tried to provide rationale for each topic. At the same I have tried to keep the list actionable.

You can judge if I di well here: http://www.michalkostic.com/post/104272540521/code-review-ch...

This

  > NoFlo graphs instead are only the coordination layer 
  that manages the control flow of your software.

These kind of tools focus on the wrong side of the problem. It is not about how to connect the nicely designed services, but how to actually get services to be nicely designed. Once you have service that can be easily connected in the visual tool, it can be trivially used from the conventional programming language as well.

Reasons why services can not be just trivially composed include:

  - every service that is comprehensively mapping real problem is inherently complex 
  (even for seemingly simple things like address geocoding)
  - any two services will have slightly different APIs 
  (consider various signatures of substring method in various languages)
   and oftentimes the backend system details 
  - limitations are leaking over the service API
  (datatypes, formats, paging, ...). 

For restricted domains - it could probably work. But for general service integration within larger company, the best approach so far has been a lightweight approach with mixture of Spring Integration and plain old Java.

OOP is great when your main focus are data structures. Many enterprise applications are basically just transforming data from one system to another. Being able to come to an unknown code and figure out what is the format of input and output just by reading couple of classes is a godsend. Even in this case use OOP features sparingly (beware of deep hierarchies, contrived polymorphism etc).

On the other hand when your problem is more about algorithms and evaluation of data you might choose more functional approach.

Hybrid (object+functional) approach is getting even to the enterprise world - SOA suggests to have dumb (possibly immutable) data objects for business objects (just like struct in C) and service objects that perform operations on these data objects (not unlike functional programming). Similar pattern is with dependency injection frameworks that rely heavily on singletons (Spring) - many beans become just containers for stateless functions.

OOP is not silver bullet (nothing is for that matter), but it is a very useful tool.

We (plumgine.com - in private beta) have been using Java with a success with Play Framework and asynchronous AJAX fronted (some parts with Backbone.JS).

I have been using Java for a while (8 years - J2EE, Android, some desktop utils) and back in the JSF days I used to hate the Java web with a passion. Then I found Stripes (step in a good direction) and Play Framework (absolutely awesome Java web framework).

These days I can whip out prototype in Java+Play Framework faster than anything else.

Some of the reasons:

* I don't have to worry about naming methods/members because I can safely rename them later

* I can easily map Java objects to JSON and back using Jackson

* most of the time I don't worry about database schema - Hibernate (JPA) generates it for me

* Play Framework works in the "hit refresh" mode to see changes

* deployment to Heroku is as seamless as any other.

There is increasingly more action going on in the browser in JavaScript and I think Java (with Play Framework) is a great tool for building backend APIs that will be consumed by your JavaScript client.

Ok, thanks. It seems that apart the obvious stuff (Menu+Back buttons) it is mostly tweaking the app to use the correct widgets/APIs for the task.

Based on various comments about porting I was affraid I am missing some grand user experience pattern that exists on one of the platforms but not the other.

I often hear about important UI changes when porting from iPhone to Android to make the app look more native. Could you (OP or anyone else with the experience) be more specific of what they are? Some examples?

We have got into minor issues with Honeycomb - the new selection/copy/paste in the text areas took our app by surprise. The other thing was TAB key events that don't get fired from the Honeycomb keyboard even if tab is inserted to the text correctly. However these are probably edge cases.

My biggest gripe is that Honeycomb emulator is dead slow, so testing anything on it without a real device is really painful.

Google has put quite an effort into documenting how to take care of multiple screen sizes - check http://developer.android.com/guide/practices/screens_support...

I am not sure how it helps to game developers but it is pretty concise guide for general app development.

We have gone through the screen size adjustments and minor incompatibilites across versions when porting to Galaxy Tab (I have summarized the experience in the blog: http://touchqode.com/blog/008_developing_for_galaxy_tab.htm ) and then when Honeycomb came out.

But more often than not it is our hackiness or vendor fancy tweaks that cause problems rather than the android itself.

Just two ideas off the cuff:

- have your methods and variables put into "categories". Then you could quickly choose category and you would be presented with limited choice in the category

- code snippets - templated pieces of code (control structures, database access...) where you would just choose variables/methods to fill in the template

I am visual programming skeptic (or better said pragmatic). I've seen quite a few visual environments where at the end of the day (once you've learned the language) it was faster to switch to text mode. Visual programming was great for learning the language though.

The main problem visual programming encounters is the sheer number of options you have when you are entering code in text form.

Just consider that on almost any new line in code you can type in control structure, variable declaration, assignment, function/method call etc. And it is almost always faster to type "if" or "for" than to click through some decision tree to get to your required command.

In touchqode we try to overcome this limitation using prefix tree when showing code suggestions - e.g. when you have methods showTime(), showDate() and showLocation() you can type "s", press "tab" and you see longest common prefixes of methods starting "s" - so you would see "show". Then you can click it and see the actual method names.

Needless to say - templates for structured commands (e.g. "if") are probably necessary for programming on mobile devices.

I have few experimental features for touch programming in my mind, so I hope I'll get to implementing them sooner than later. If anyone has interesting ideas I'll be glad to discuss them.

It has some nice UI ideas - I particularly like the idea of calculator-like editor.

Environments with limited text input ability get significant advantage from staticaly (or at least strong) typed languages - code autocomplete is really killer weapon when editing text.

As a sidenote something similar can be achieved on Android phones using Touchqode [1] and Scripting Layer For Android [2]. It does not have specific language but you can use any of its supported languages - Python, Ruby, BeanShell (Java), Rhino (JavaScript)

Disclaimer: I work on touchqode

[1] http://www.touchqode.com [2] http://code.google.com/p/android-scripting/

This is our quick demo inspired by "share the air pitch" video. Done in 2 days, built on Google Appengine, Java and Stripes framework (excellent lightweight Java web framework).

Very simple app just lets you point your location on map and write some nice things about the air you are willing to share with other people. When you are logged in (currently using GMail account) you can send message to published air offers.

That exactly captures the idea. And to make this process even easier I've just been testing experimental implementation of FTP client in touchqode. The new version will be probably coming within a week. And we have some more things up our sleeve.