Top 5 Craft conference talks you should not miss
Craft is a kick-ass Budapest based conference about software craftsmanship which was held between April 26–29. Coders flock to the event as it has remarkable speakers year on year.
At Supercharge we experiment, move fast and make things happen. To achieve this it’s important to be open-minded and learn every day. It’s part of our culture. Every team member has the chance to attend their favourite conference every six months. My choice was Craft and I think it’s an excellent place to visit to broaden my knowledge about software development.
Here are the most interesting talks from an iOS developer’s perspective:
Building a sustainable codebase: 7 years and counting by Peter Steinberger
Peter Steinberger(PSPDFKit) gathered the experiences from the last 7 years, how he managed to maintain a large codebase. For many developers his advice is maybe a little bit too obvious. But it’s always good to remind yourself now and then.
He mentions it’s best not to jump on the next big thing in the industry, but wait a little and see how it will work out. Also strive for the most boring solution, because it is much more maintainable.
“If you outsmart yourself, well, good luck fixing it”
Ugly hacks can hurt your codebase too. Unfortunately they are common while developing for any of the mobile platforms. If you don’t take enough care and create a sample project about it, it will hit hard in the future. With a simple project replicating the issue you can be 100% sure in the future if the problem is fixed. He wrote an excellent blog post about this last year: Writing good bug reports.
I also liked the format of the presentation. It was delightful to hear this advice with some personal background stories.
Scaling open source communities by Felix Krause
It is hard to maintain an open-source project. Especially if it’s the go-to solution in its field. Handling support on GitHub could take more time than working on the project itself. This is why they introduced a chat bot on the repository.
The bot checks if the reporter provided all information for the issue. If not, it responds with a comment that there you are missing something. This way the support load is significantly reduced.
Also, for a scale like this, it is crucial to keep the open issues moving. If there is no activity at all on an issue the bot notifies the participants. If no one answers, the communication is blocked. Now the reporter needs to open a new ticket if the problem still persists.
These insights were helpful because we have some open-source libraries and plan to open-source even more. It was also nice to see how these techniques work in a real project, not just in theory.
Another topic of the talk is about how to handle pull requests with the help of Danger. It is a tool that warns you on predefined rules for a pull request.
Growing A Development Team’s Process Guided by Tests by Orta Therox
The problem he faced in the open-source world is that the same questions arise again and again. Could you please add unit test to your new classes? Could you please fix X? The build is failing, please fix it before submitting the pull request. There is no changelog entry, please add one. etc.
You can integrate it into all major CI tools. This way, if a pull request is not following the defined rules in the Dangerfile, your build could fail. With automated feedback, it dehumanises the whole story. There’s no one to blame for the pull request gets rejected again. Moreover you can set “cultural baselines” for your project that the team agreed upon.
It is important to integrate it into your processes with care. Don’t rush and add 10–20 rules at first. Talk to your team and settle for one simple rule. Then, step-by-step add another one. Did somebody forget to ship the localisation for the app in the new release? Add another rule to prevent it next time.
And the cold start performance goes to… 2.3 seconds by Valera Zakharov
Most teams only do ad-hoc performance analysis. They work great at caching obvious performance issues. The main flaw of this approach is that it cannot reveal cumulative performance shortcomings. An example would be Google Chrome which started as a fast and lean browser.
The systematic approach guarantees to catch issues as early as possible. You can integrate it into the development lifecycle of the project. The only thing you should provide them is information.
“developers are who own quality, who own performance, you just have to empower them”
You could track trends like the timing of operations, resource usage. You should exclude the network from the equation. Record your real network traffic and play it back when running performance benchmarks.
The second part of the talk is demonstrating how Slack approached this problem.
Tech Lead Skills for Developers by Patrick Kua
A tech lead’s mission is to align the developer’s ideas about how to reach the common goal. He divides the responsibilities into programming, people, process.
If you become a tech lead it’s natural that you code less. Ideally not less than 30%. This doesn’t mean actually writing code alone. It can be also pair programming and code review as well. You should prefer consistency over cleverness because simple and maintainable solutions last longer.
Your responsibility as a tech lead is also dealing with people. Identify their strengths. Maybe some of the team members have more of an analytical way of thinking. Others are great at getting things done. Help people to reach their greatest potential. Create an environment where they feel safe to share their ideas or confront each other about things they disagree upon.
Team cohesion is not built in a one-day team building event. You should organise activities that encourage people to get together.
The situational leadership model tells you how can you reach a point where you can delegate your tasks.
An interesting question from the audience was how to handle a team full of senior colleagues. He said that you should resolve debates with facts. Don’t rely on gut feeling, tell them to prove it with real data, spike project etc.
+1 Knowing what bad code looks like by Llewellyn Falco
I added Llewellyn Falco’s hands-on session because of the interesting style of presentation. It is about how to identify specific code smells without any context at all.
We learned how to recognise smells the same way how pigeons learn to diagnose cancer.
You should try it yourself!
Thanks for reading! If you have any comments, questions do it below or hit me up on twitter!
At Supercharge we build digital products making the life of millions of users easier. If you would like to learn more please visit us at: www.supercharge.io