Episode 59

Last Saturday, on February 25, I attended Boiling Frogs – software development conference held in my home city, Wrocław. It’s the second edition of the event, this time it took place at Wrocław Congress Center near Cenntenial Hall, one of the city landmarks. There were 31 talks / lightning talks in total, spread across three tracks covering variety of subjects not tied to any specific programming platform but focusing mostly on more generic aspects of coding, building organizations, solving problems and software craftsmanship in general.

Unfortunately, I arrived a bit late and missed the keynote. Apparently, the closer you live to the place you are supposed to be on time, the lower are the chances of it happening – the universal rule. In addition, the day before I drove 300 km to Kraków and back again, and people need to sleep sometime.

Talks

I managed to be on six talks and one lightning talk in total, basically all of them were really good. let’s do a small recap of each of them.

Tomasz Dubikowski: Level up your culture

Tomasz is my former teammate from times when I worked for financial institution, who later choose career in grocery business. The talk was about building good organization culture, starting with putting a lot of effort into recruitment.  In order to engage people more, you can let them work for a day close to core business, for example with delivery driver. Creating working groups and for different organization aspects like recruitment, security or qa and letting people actually come up with decisions, implement them, experiment with them and sometimes fail with them is a great idea. There was something about wisdom of the crowds, autonomy, purpose, open culture where everyone can contribute, trust and role of leaders.

Mariusz Gil: Back to forgotten roots

Mariusz started with popularity trends of few things in the Internet – frameworks and technologies, but also stuff like “SOLID” or “object oriented”. We often happily dive into hype driven development and don’t care about basic stuff anymore. Developers should build their toolbox over time, but choose appropriate tools from it when needed, not force a fancy tech stack and overengineer. We like to erect cathedrals where simple sacrificial stone will suffice. Instead of building around database tables, we should identify core and supporting domains and build around. Code tends to be either too trivial to implement or too complex to maintain. Solve problems, not projects, even if it means quick consulting instead of fat project. Wise client will return anyway.

Michał Płachta: Developer on detox

Developers, artists, craftsmen, humans. Michał talked really fast and really a lot about psychology of stating an opinion and making decisions in software development and life in general. There is an illusion of confidence and of knowledge. People tend to overestimate their understanding of how simple items they use every day really work in detail and confidence does not really correlate with knowledge. Therefore, before stating opinion it’s good to ask oneself few “how” and “why” questions. There was a chapter about difficulty of naming, while names consist of 70% of source code and there is only about 10% chance that two developers will name one thing the same. There was Zeigarnik effect, the invisible gorilla and throwing the backlog away.

Jakub Kubryński: Microservices, the naked truth about maintainability

Paraphrasing one of Polish Prime Ministers –  you can tell the real developer observing how he ends, not how he starts. Everyone wants microservices, but it takes a lot of effort to get them right. People tend to underestimate the desired size of microservice, when deciding how many should we have. For example, Netflix has around 500 of them for roughly 1500 developers. SLAs are multiplicative, cloud is not that stable, failure is inevitable and should be embraced. End to end tests suck, percentiles should be higher, conventions strong, contexts bounded, infrastructure stored as code. Microservices should solve business problem, otherwise they should be libraries. Also, hunting with mathematician, physicist and statistician is fun.

Anna Konopka: How not to waste 8 hours behind the desk

A lighting talk from my current teammate. People want to learn and grow, but they complain that it’s difficult to carve from free time for that. Why not do that at job then? It doesn’t have to mean dumping the project. We should first learn to talk to other people and communicate effectively. Discuss problems, learn from other fields even quite remote, look for similarities and inspirations, connect the dots, keep an open mind. Teach people! When we do that, we reassess our own knowledge, find gaps and most likely learn something along. Ask questions to yourself, find causality, question the obvious and don’t be afraid to say “I don’t know”, there is no shame in that.

Michał Pipa: Date and time for programmers…

…is a nightmare from hell. There are many ideas on how to store time. RFC 2616, RFC 3339, Unix timestamp, universal time, coordinated universal time and finally ISO 8601. Start of first week of the year is not that obvious, as well as Easter date. There are leap years and leap seconds. There is daylight saving time but its switched on different days. Morocco suspends it for a month of Ramadan, which date is… variable. Time zone in India is different by half hour and in Nepal by three quarters more than you would expect. Difference between Warsaw and Sydney is between 8 and 10 hours depending on date. Do not save local time to database and do not perform backups at 2:30 AM.

Robert Pankowecki: 2 years and 40 000 000 domain events later – the Saga Pattern

The only reward for solving complexity is more complexity. Robert explains that validating a ticket for music performance is much more complex than one would think. Shows may last few days, you can get out or not, there are sectors, vip rooms, checkpoints, oh my gosh. To combat complexity, it’s good to bound contexts, move to smaller data models with clear ownership, try to work within the domain and communicate with outside via domain events. Payments come too late, multistage bookings fail, promotions are complex, some people like snail mail. A lot can happen between the lines and while resolving events you can emerge with the saga pattern over time.

OMG, The Frog is Boiling Alive!

The conference was actually better than I expected. Good, organization, Smart, beefy and enjoyable talks, positive energy, lots of people I know and I even got a prize for activity on Twitter :D I was offered a piece of clothing or a book, the choice was obvious.

Boiling Frogs easily earns a permanent slot in my calendar. I’m excited for the next edition, perhaps we will meet there, my dear reader ;) Meanwhile see you next week!