As a huge fan of live events, having to experience a conference digitally was an interesting change of pace, to say the least. However, my expectations for the virtual event were quickly surpassed. I was very impressed by the number of speakers and how diverse they were. I was also impressed by the wide range of topics the conference covered (3 days, 5000+ participants, 13 stages—check out the full DevTalks agenda).
TypingDNA @ DevTalks
If you’re curious, here are the TypingDNA talks from the conference. Laura Tamas and I approached theoretical and practical aspects of typing biometrics and passwords, as well as the reality of securing remote workforce. Check out our presentations using these links:
- The brave new ‘Work From Anywhere’ world and how to secure it
- To People Who Want To Integrate Biometrics – But Can’t Get Started
- As a bonus, we had the opportunity to give participants a short company presentation.
Now that you are familiar with our role in DevTalks, I’d like to share five of the more engaging talks I saw during the virtual event.
1. Are bots good or bad?
Michelle Sandford addressed this question by putting forward arguments that brought together aspects of technology and sociology.
While, at its core, code is simply mathematics, algorithms and logic statements, keep in mind that what was designed for good could be used for evil, too.
Besides the programmer’s bias, there is also the way people use and train the software (just look at Tay vs. Xiaoice), which is why developers must be accountable for what we deploy and have a sound understanding of the real impact that bots have on people’s lives these days.
To ensure each user gets fair and unbiased treatment, include diversity on your development team and enable support in multiple languages.
2. Following your passion
We have endless opportunities today to follow our passions and beliefs, and this idea was best showcased by Denis Radin through karmawheel.org.
Starting by comparing Buddhism to a peer-to-peer connection, he digitized a prayer wheel so it could serve many people around the world.
Regardless of what technology stack you decide to use, having an objective and being determined will keep you on the right track—and even open the door for unexpected collaborations.
3. UX vs. DX in Web Development
As developers, we get more productive by using the latest frameworks. But is this the best for our users?
Stefan Judis started a debate around the developer experience (DX) and user experience (UX), ultimately ascertaining that we should focus more on building websites that work and less on the technology behind them.
He encouraged devs to go back to the foundations (e.g., HTML, CSS, JS) and build complex apps only when it makes sense.
Also, the session was a reminder for us all that we have the responsibility to pick the right tools. A decision made today will stick around our companies’ tech stack for a while.
4. Product Metrics <> Developers
There are three types of metrics: business, product, and tech. Developers should be connected to the last two in order to assess existing features, investigate new releases, and perform incremental improvements.
With metrics being the only source of true data, as shared by Dmitry Salahutdinov, they ensure changes are impact-driven and reduce communication blockers.
Some tips and tricks he shared are: keep a naming convention that prevents entropy, have separate environments for production and testing, and organize events and properties.
5. Killing mutants – a different approach to testing
Want to ensure your code is meaningful and the unit tests are strict? Give Mutant Testing a try!
As per Dave Aronson’s explanations, first, you need to find the tests (or create them in case there are none). Second, you have to slightly modify the functions (create the mutants), and third, don’t forget to apply those tests on the mutants!
If at least one test fails, then the mutant is killed and you move to the next one. If no tests fail, then the mutant survives, meaning the code is meaningless or the tests are not enough. Although resource-intensive (e.g., CPU and time for interpretation), this approach has a lot of potential for identifying gaps.
Top comments (0)