Jana Rekittke from the Engineering gave us a recap of the EWIT16* conference she attended, presenting some topics and ideas. Enjoy reading the summary of her talk!
Tech workplaces tend to be often typically male dominated. Women might find a “Brogrammer” culture in which they may feel out of place, uncomfortable, or less valued. An unappealing workplace could also be a reason for women to not consider it in the first place. Yet, changes in the workplace tend to only happen when more women start working there.
So the question is: How do we achieve gender parity? And do we actually want that? Does it make sense for a company? Quite probably so: a mixed workplace (think of “not only white middle aged male”) will give the company access to a more diverse pool of ideas. If everyone who makes decisions has the same background, similar ideas and opinions, how can a company/country/… evolve and adapt to ever-changing requirements?
How about women in leadership? Do we need more women in middle/upper management and on company boards? Several studies (see links below) indicate that companies with women in upper management and on boards are more successful than their male-run counterparts by achieving greater productivity, creativity, and profitability. However, companies founded by women receive less funding. Which is odd considering that a company run by a woman is more likely to succeed than a company run by a man.
Sadly, the percentage of companies that have women in upper management is around 70% (big companies, first world), and the percentage of women vs. men in management positions of these companies lies between 0 and 30%. The percentage of women in tech teams is just as low.
We are therefore far from parity - and those who say that feminism or gender studies are outdated and not needed should reconsider their position. There is obviously still work to be done.
For further reading on this broad and interesting topic, please consider these:
As your project grows you might have found the need to split it into several modules. This becomes even more prominent when you’re working in a company where several teams develop the same app, but different features.
It’s not so uncommon to have the same library dependencies accross the modules. Usually modules tend to use the same library to achieve similar things and keep the number of used libraries to a minimum. However, it’s also not so uncommon to accidentally use different versions of the same library in this setup.
Here at Babbel we recently faced this issue and in this blog post I’ll share with you a possible solution to overcome this.
Lots of ideas, people, Club Mate and pizzas. Hello again, with our own review after a successful Hackday.
The 6th Hackday was held at Magazine in der Heeresbäckerei, an impressive industrial monument with a prominent appearance in Kreuzberg, directly next to the Spree. It is extremely important to have a amazing location for such a long, intensive day and we’re happy that we could spend it in this wonderful venue! To make sure nobody was hungry we had lunch from Knofi and delicious Italian pizzas from our good friends at LaPausa.
Unlike the participants of the hackday, our organization team had a little longer than 10 hours to prepare their ‘product’: the first steps towards the event were taken already a couple of months before. It is very satisfying to see how all the small parts we’ve been working on are coming together like puzzle pieces, creating one big event that so many people can enjoy.
Enough background, let’s talk about the actual Hackday!
The 6th Babbel Hackday started at 8 o’clock in the morning - which is considered the middle of the night for some of the Babbellonians - with coffee and sleepy faces, and people happily putting on their work uniforms: this year’s Babbel Hackday T-shirts. With every zip of hot beverage, more and more smiles appeared and our day with ten hours of hacking was ready to begin. The energy levels were rising by the minute and if this Hackday would have had background music, it would definitely be Reel 2 Real’s ‘I like to move it’!
At Babbel, we’re constantly looking for new and unconventional ways to get our customers over the hurdle of speaking in a foreign language. As a result, finding talented people to help move our organization forward can also come in unexpected ways. This week, we invited Jeanny (Director of Product) and Clyde (Product Specialist) to share one of our more amusing hiring stories.
Powered by lightning fast internet, lasagne and tons of Club Mate, our 5th Hackday was a success!
So, here we are with our own review about a day full of projects, sun - and caffeine.
This year’s Hackday took place at Colonia Nova, a proper Berlin-style venue in the famous Neukölln district.
Let’s be honest, the huge and sunny rooftop terrace on the 5th floor made our day even better. It was great to enjoy the sunshine while hacking with our colleagues - because yes, we set up the wifi there too!
If you started your Android development around the time instrumentation tests were the only tests supported out of the box, you probably remember how tedious it was to test drive an app. In fact, writing tests, whether before or after the implementation was written, was so complicated and frustrating that some of us chose to avoid them entirely.
Well times have changed and what we now have at our disposal is enough to not only write a reasonable amount of tests but also to develop our apps and libraries driven by tests. In this article I’ll share how I do TDD in Android. I won’t dive deep into the concept of TDD, I’ll simply explain the approach I use and how it has greatly improved my development. I’ll approach this with a concrete example.
Want to simplify your infrastructure and reduce your operations overhead?
Consider using AWS Lambda, and let Travis help you with the deployment.
If you don’t know AWS Lambda, here’s how Amazon describes it:
AWS Lambda is a compute service that runs your code in response
to events and automatically manages the underlying compute
resources for you.
Put simply, you write the code and AWS runs it for you. The “runs it for you” part can be
either event-driven, scheduled, or via a manual trigger.
If you’re on the move to a more decoupled service architecture like we are, this can be a big help.