Boiling Frogs 2019 – not so short relation

Last week in my „conference season” was unique

I am not speaking at any of the conferences.

I am not speaking at any of the conferences. And as I said in a post some time ago I am switching my blog profile to address quality from more wholesome position then just testing and testers. That’s why I went for both conferences Wroc# and BoilingFrogs
Yesterday we covered Wroc#. Today is time for BoilingFrogs.

My tweets from the event.

What is Boiling Frogs Confene?

This is an excellent moment to talk about Software Craftmanship,
There is a good book on the topic with the same title by Pete McBreen, but in short it is about recognising our hunger, for new technology, for the pursuit of a new and better toys, and reminding us that delivering value to customers is what matters.

Boiling Frogs is conference born out of this ideology, while Wroc# tried to show us how technology is changing and where its edge is now.
Boiling Frogs tried to ask you: Does the pursuit of that edge brings value to your customer? Does it make you and your product better?

There is a lot of contrast between both conferences, and I don’t think they were on purpose but steamed from different ideologies.
Hell, even the locations on the opposite end of the Wroclaw, seemed to be there to present difference in styles of the conferences.
While Wroc# was modern and grandiose, Frogs felt smaller and more comforting. (I don’t know headcount for the boiling frogs, but at a glance, it seems both events were similar in size).

Let’s talk about the event

The location was used to the full extent long hall was brimming with stands promoting different companies. But the hall was roomy enough, so you never felt squizzed well, outside of the rush after the opening ceremony it never felt extra crowded.

What Got my attention was the chill rooms on the second floor.

Masażownia” had one and were doing short, 20 minutes long, massages for free.
That was a great idea. I was lucky enough to put my name on the list while free slots were still available. Even after such a short session, I haven’t felt so relaxed in a long while.

Another room was occupied by Traze

Example of more exoctic Traze interface on
Iteratec  stand.

They had a great idea – setup an API with the tron-like game, and you can either program your bot to play it or create your own GUI –
I like the idea. Very much, they put their code on repo.

Time for Talks

Boiling Frogs had three tracks and honestly too much of good content.
So I made a resolution to vote with my feet. If I don’t enjoy the talk, I will go to another.
Unfortunately, I was only half successful in my resolution, I have left a few talks, but I never arrived at other ones, because there were too many interesting discussions in the corridors.

Since so far I had soo much positive to say I will start talks with the two negatives:

Problem sprytnego programisty – Piotr Kubowicz

The Issue of Clever developer

This presentation was for me greatest disappointment.

This presentation was for me greatest disappointment.
The day before I had a long discussion with a few people on the topic „How it is that engineering is built on a smart solution and yet such solutions are frown upon in IT.”
The consensus we reached was:
Smart solution aka, „simple and clean” are not disliked what we frown upon is cleverness for cleverness sake and overcomplication for the sake of making code little shorter or little faster.

This presentation was about such people. Don’t take me wrong.
I agree with the author points, but the presentation was full of preaching to the choir, truisms, and strawmen.
For example, the Author made a claim, that the recruitment process is responsible for creating developers who love over-engineering. He blamed usage of brain teasers for that. Someone made a counter-argument that it is to check how someone deals with stress. Speaker response was a claim that software development is not a stressful job.
Well, Firefighter and Police officer is much more stressful. But I think we all know how stressful are releases are and IT has one of highest burnout rate – stress is part of that problem. Also, don’t forget game development is part of our world – look for „Stress leave„.
At that point I left, I felt he wasted enough of my time

This presentation was a crystal clear example of the issue I’ve seen in a lot of other presentations here:
A lot of talks about how the pursuit of technology hurt the project. Yes, it is a real problem. Also, the first step to resolve the issue is to acknowledge its existence.
But the thing is, I felt that due to what Software Craftsmanship is about, I was expecting, that the problem was already acknowledged and we move a step forward looking for a solution.

My suggestion for organisers.

My suggestion for organisers.
Maybe next year it would be a good idea to create themed track „why software craftsmanship is needed” and such presentation put on that track.

Piramida Refaktoryzacji – Włodek Krakowski

Refactoring Pyramid.

This presentation started strong, with explaining that Refactoring and Refactoring patterns are great encyclopedias of refactors but
are not a good way to teach how to refactor code.

This is the goal of refactoring pyramid.
The first part of the presentation is excellent. I can already tell you then next time I will start refactoring I will go with the pyramid.

Unfortunately, then the presentation went south.
He started doing live refactoring demo. I love live coding but to take something from such experience you have to see the code and have time to process what you see.
Unfortunately, the speaker refused to use a presenter mode in IntelliJ. He did enlarge the font a little, but it was still too small.
I was sitting in the last row, and I didn’t see anything. Unfortunately, I wasn’t the only one, long before I finally give up, half of the room left. Using this as an opportunity I have moved much closer to the screen, and yet I still couldn’t see what going on. So I joined the rest in leaving.

Having said that. When this presentation is put on youtube, I will rewatch it.

Let’s move to the good stuff

My only regret is I don’t have time to make a full article on each of those talks.

Boiling Frogs: The Lasagne Industry – Tomasz Kaczmarzyk

Presentation by the organiser. In my opinion, this was an excellent introduction to what the software craftsmanship is about and what issues it tries to fight. It is also the main reason why I was confused by so many presentations later trying to do the same.

I won’t get into details here. It is sufficient to say this presentation was a high-level overview of the whole industry. If you speak Polish, I recommend watching it when it comes out on their youtube channel.
But I will quote my favourite catchphrases:

Archaeological layers of IT
  • „Hype-Driven-Development”
  • „Disco Polo of Computer Science”
  • „Wars of hype.”
  • „Spaghetti code for OOP is Lasagne code – too many layers.”

Jak wytrenować Juniora – Paweł Łukaszuk

How to train junior

We all were juniors once. I had a great teacher as a Junior. And I hope to be as good as them. That’s why I went for this presentation.
Paweł talk was content heavy, full of advice no matter what place you are, both for those who just start training juniors and those whose process is good but strive to improve it.

So what were Paweł recommendations:

Mentor! – he/she needs to :

  • be close, in the same location
  • be experienced
  • have at least two days a week (16 h!) available for his Mentee.

Paweł also made a recommendation for what project are best for teaching:
That old project that is already in production and still developed (developed! not maintained!) are the best place to start. Greenfields are too dangerous already and putting someone untested there will be hurtful both for him/her and project.

Another thing that is easy to forget junior has to get a task that is not crucial so he/she can finish them no matter how long it takes. There shouldn’t be the case that junior gives up on task, the senior may sit with junior to help it. But he cannot take over!

And as for pair programming Junior should also be the navigator.
Last thing: junior needs to be part of the team. And never be afraid to ask a question. He/she need to know we value his/her opinion.

Paweł Idea how to achieve it was great in its simplicity.
Tell Junior that on meetings he/she is first to ask a question.
But you need to tell him that.
„Listen, X on meeting before we present our thought we will ask you for your opinion, and questions you have. It is not to make fun of you. It is cause we value your opinion and we don’t want your point of view to be influenced by the more experienced member.”

I will finish with this quote.

„Junior is an investment. Not every investment pays off, and you need to know when to cut cost.”

Paweł Łukaszuk

Jak czysty kod i najnowsza technologia skrzywdziła mój produkt? – Jakub Sikora.

How clean code and new tech harmed my product.

This is one of those presentations I mentioned previously. What makes it different it also showed what they did to avoid the same mistakes in the next project.

There are two important takeaways

The customer is most important, but you need to know all your stakeholders, cause their interest is also significant (And it may turn out that most of your customers come to you via one of those stakeholders)

Impact Estimation Table is an interesting tool for understanding the needs of the stakeholder’s needs and their consequences.

That is all from Boiling Frogs.

I had a great time and got lots of material to ponder.
Next stop ConSelenium

Dodaj komentarz