On the evening of the 14th September 2020, the women.code(be) community held their first online edition of their recurring TechTalks. For those who’ve missed it, don’t fret, we’ve got you covered!
Our guest blogger Silke has written a recap with her personal takeaways for each of the talks that were presented that evening.
- Ownership of the benefits of development by Sanne Vermeiren
- WeGoSTEM, the Corona edition by Nele Van Beveren
- Lessons learned from working remotely by Lien Van Den Steen
- Hoist the sails, we’ve got TailwindCSS! by Elke Heymans
- Best practices: A look back by Martin Van Aken
Becoming Young ICT Lady of the year has given her the opportunity to share her passion for technology with young girls and kick stereotypes ass. Her ultimate goal is to be able to explain technologies and concepts in a way that a non-technical customer can understand what the developers are talking about.
Sanne's talk was created while she was working at one project, and finished while working at another. This goes to show that benefit ownership is something that isn't constrained to one specific context, project or company. It's an idea that can be used in many different situations.
Be at the right level
Whoever benefits from the features should be present. They are the ones who are able to pinpoint the flaws and strengths of the current system.
Ask yourself, would my grandmother understand this?
Sometimes people are afraid to admit that they don’t understand what you’re saying. So drop the tech talk and jump into a functional way of talking to each other.
Teach the customer the basic lingo, how you work, what building blocks make up the project, how you’re going to test, etc.
As a developer, make sure you know the bigger picture, how the customer works, and how they want to work.
If a customer says they want to work with AI, blockchain, or some other fancy new technology, don’t immediately jump into development, no matter how tempting it is. Find out what they need, and work towards a good and proportionate solution together.
Nele graduated as Master Of Science in Engineering – CS, wants to help youngsters be prepared to create the future world, full of technology. As one of the ladies who made it into the top 5 of the DataNews SheGoesICT-contest in 2017, she wants to spread her enthusiasm. Together with other SheGoesICT-finalists and with Dwengo vzw, she founded WeGoSTEM, an initiative that enables thousands of children to immerse themselves in STEM by building an art robot in the classroom.
At 10 years old, Nele got her first computer. It could be frustrating at times, because of not having the internet or anyone at home who could help her when she ran into problems. At 18 she went to college and, with guidance from a math teacher, started an engineering degree, where she first learned to program. This experience led her to start WeGoSTEM, so that she could give kids the opportunity to learn about computers and programming sooner.
Their goal is to enable 10 000 children to build a robot this year. Which is already quite challenging, but Covid-19 has made this goal more complicated to achieve.
The main focus of WeGoSTEM is to encourage minorities. Their aim is to have 50% of their pupils to be girls, and to include children from disadvantaged backgrounds. They do this by giving their workshops in elementary schools. Last year they reached more than 7000 children in 170 schools in Belgium.
![2 main goals for WeGoSTEM 2020.
- Enable 10000 children to immerse in STEM by building a robot. 2. Organise a large-scale MOOC for 500 elementary school teachers.](https://dev-to-uploads.s3.amazonaws.com/i/l9l62p8qbem8z8gcvleu.png)
With the constraints of Covid-19 it was not possible to send their usual 3 volunteers to each class and give a hands-on experience. Their rather ingenious solution was to improve their existing digital materials, including an online simulator for the robot, and offer Massive Open Online Courses for elementary school teachers. This way the teachers can give the workshops themselves, of course still with guidance from the volunteers, albeit from distance. The materials for the actual robots are sent to the classrooms.
Even though the new way of working comes with considerable challenges, we’re sure that it will be a great success!
Lien likes automation and improving the lives of her colleagues through code. She’s a full-stack engineer and has enjoyed working primarily with Ruby the last 5 years. When she’s not behind her keyboard she can be found seeking sunshine, sipping a flat white, or at the gym.
Most of us have are now working in what Lien calls “Forced Remote“. I am really struggling with this, myself. What resonated with me a lot were the two tips she gives concerning this forced remote situation.
Working remote and working from home during a pandemic are two different things. But we can learn a lot from advantages and disadvantages of remote and apply them to our current situation.
There are 3 major disadvantages to remote work:
Most of your time is spent working, and you miss out on typical office social interactions. Try to recreate these interactions in your online setting. Plan a coffee break with someone else, have a simple poll like “what did you eat this weekend?” to spark a conversation, or even ask your company to plan some social time into a weekly meeting to just chat with colleagues.
At Lien’s work they’ve also been doing “Travel Calls” where you virtually visit a colleague’s favorite place.
For some people, not having a physical distinction between work and personal space makes it hard to unplug from work. I am definitely one of those people. One of the things Lien mentioned that might help with this is finding a routine that makes you think you are going to/coming from work. I used to do this by waking up a bit earlier and taking a fake commute to work. I would take a walk outside and then come back to the office, albeit still in my own living room. Other things you can try are putting on shoes or otherwise dressing up for work, not eating or taking your break at your desk, and keeping to a fixed schedule.
Working remote should not impact your career opportunities, but sometimes it does. Your boss might not really see the work you do, especially if not everyone is fully remote. It’s much easier to remember someone and link them with their hard work if you can see them working somewhere near you. To help combat this, make sure to check your company’s policies on growing your career and how they’re implemented for remote team members. However, this problem is much less prevalent if all of your coworkers are remote.
Elke is a front-end developer with a focus on Vue and TypeScript. She finds exploring new technologies and frontend frameworks to be a lot of fun. In her spare time you can find her taking photographs at events, training for half marathons or enjoying music by collecting records and attending concerts.
TailwindCSS is a utility-first CSS framework for rapidly building custom designs. I’ve seen it mentioned a couple of times on twitter, so it was nice to get a bit of a crash course on what it all entails.
Most CSS frameworks today are component based. Which means that they provide the necessary CSS to style a specific component, for instance a button. This is how they’re organized. These types of frameworks are ideal for prototyping, ready to use and provide uniform styling. However, these predesigned components can be limiting as well, making most things look very similar. Which is why every Bootstrap website looks at least kind of similar.
Utility classes are small pre-existing CSS classes to be used directly in your HTML. The names of these utilities follow a convention that’s more intuitive, making the styles easier to read. And because are no CSS class names, there are no extra CSS files to open.
Using TailwindCSS a button could look something like this:
<button class="text-white font-bold uppercase rounded-lg animate-pulse"></button>
At a glance we can see what it’s going to look like, without digging through CSS files.
The main idea is that you don’t need to write CSS classes for each item you need. Instead you use the utility classes provided. These utility classes already exist for a bunch of scenarios, like layout, grid, borders, effects, tables, and animations, with many more to come.
Of course, like any framework, TailwindCSS comes with pros and cons, and Elke spent quite a while showing us the nitty gritty details. All in all, the descriptive nature of TailwindCSS makes it very different from what’s already out there. So maybe give it a shot. If you want to try it out yourself, start here: tailwindcss.com
Pointy-end, half-full stackoverflow developer, designated Scrumbag. Martin is the CTO at BlueSquare, a Belgian global data company focused on digital health in low- and middle- income countries around the globe. He is also the Lead coach at LeWagon Brussels, where they teach students how to code their own startup MVP.
A joke that I’ve heard a few times is that when you ask a developer a question, they usually have one answer: “It depends“. I think that would be a good alternative title for Martin’s talk: Should You Use Best Practices? It Depends
Best practices are something that I have heard a lot about, especially people telling me that I really should be using them all the time. Martin points out a few key ones, and then proceeds to break them down a bit.
You should Unit Test all the things, preferably using Test Driven Development. It stops bugs in its tracks and makes debugging much easier.
But, not all unit tests are useful. In some cases, the unit tests could break, but not the application itself. So now we have bugs in our tests instead of in the code itself. Sometimes it’s also much faster to test something manually vs making everything go automatically.
Development is about adapting to change. The key to being able to adapt to change is to work agile. Every good company does this.
But, what if the project has very specific requirements that are mandatory by law? We cannot just cut these parts of the scope because that is the agile way. Also, agile tends to be implemented in companies using a lot of overhead: meetings, standup, boards, etc. In smaller projects this overhead can cause enormous delays.
If the same code is copied in several places it becomes a mess to change afterwards. You cannot know if you’ve changed every instance of that code snippet, resulting in inconsistencies.
Duplicating code is bad, but so is creating complicated abstractions just to remove the duplications. Sometimes, having a little bit of duplication is clearer than having unreadable code.
Any code benefits from the scrutiny of another developer. Code reviews improve the quality of the code, but more importantly, the quality of the coder.
Code reviews, when not done immediately, can make you switch context quite abruptly. Maybe you’re already knee deep into a completely different feature when a colleague messages you with questions about code you wrote more than a week ago. This causes you to lose focus and ultimately, lose time. Code reviews should be done in such a way that they’re not disruptive.
When it comes down to it, it’s important to remember that best practices should not always be followed. Nuance in how you use them will help you in the long run.
It has been quite some time since I went to a meetup. In fact this was the first one I’ve joined since the Covid-19 lockdown. Normally these TechTalks are in person, so we can see each other face to face, but due circumstances we had to make due with a virtual meetup. Nevertheless, we had 5 excellent lightning talks, and even had plenty of time for some questions. To be honest, I had really missed this.
Even though I am looking forward to in-person meetups again, it was really nice to see some fellow developers again, and learn something new.
If you enjoyed reading this, feel free to share this with your network ❤️