The Remote Journey: references to start

Introduction

I started my professional career in an archipelago and I have been involved in Open Source for years so managing remote software related teams, departments and even organizations has been the default for me. I have been also working as consultant in a remote-friendly environment and now I am working at MBition remotely. I believe I am familiar with many aspect of the The Remote Journey, which is a topic I am interested on beyond my work, since it is tightly related to the way of life I want to live.

Remote work is a fairly mature topic at individual (software development), team and department level. It is maturing at company level too which means that there are already resources in internet that will cover most of the basic questions and topics that most of the companies struggling today with moving from colocated directly to remote-only environments might have.

This forced shift will have a major impact in every aspect of the company, in you as professional and in the way you understand your work, which is why I strongly recommend that you make yourself and your colleagues aware of the challenge and embrace it, which means to me at least two things:

  • Be ready to challenge most of what you currently know about how you work, how your colleagues work.
  • Be open to learn. Read and talk about what you and your colleagues are going through assuming that no, you do not have the situation under control. You will need to learn again what under control means.

The good news is that this worldwide crisis will change the way we all see remote work, hopefully for the better.

The Remote Journey

The journey from being co-located to a remote-only environment has different stages. There is no agreement on how to name them but in general, I will define them in the following way:

  • Co-located: teams/departments are located in the same physical location (office).
  • Distributed: teams/departments are located in different physical locations (office).
  • Remote-friendly: the workforce of the organization can work at a different location than the office part of the time. A mature remote-firnedly environment has a minority but significant part of the workforce working remotely and coming to the office frequently. Usually these workers are related with sales, support, business development… When it comes to product development or services, those remoters are senior professionals with wide experience in remote working so they can overcome the technical, process and cultural gaps they face on daily basis due to living in a colocated culture.
  • Remote-first: most of the workforce works remotely. The office is usually reduced to specific areas of the company like labs, administration, HR, junior developers… Mature remote-first environments usually have their workforce distributed across different time-zones/countries.
  • Remote-only: there is no office or when there is, working from it is voluntary. Employees are supposed to work from home/coworkings, including supporting services and departments like admin, HR, etc.

You can read a little about these definitions here:

There is one undeniable fact though, remote-only organizations not just exists, they are successful. In my opinion, it is up to each organization how they want to transit through this journey and which stage is their target. Obviously the current crisis has left many companies with no choice but to jump most stages and go directly to becoming a remote-only organization for a while, but still they can learn from other people journeys. There are plenty of additional articles about the different stages and how routines, processes, methodologies, performance, evaluations, etc. are affected at every level (individual, team, dept. and organization). They should be easier to find now that you know some of the nomenclature.

Team ceremonies need to adapt

It is my belief that in general, habits change mindsets instead of the other way around. When walking through The Remote Journey together with teams and organizations, I put emphasis in the ceremonies as a way to drive the needed change at every level: personal, team, department and organization. If you successfully adapt the ceremonies, your are in a great position to modify people’s habits.

Personal ceremonies are that, personal. I will not get into them. There is plenty of literature in internet about how to face remote work, the advantages, the challenges and how to approach them. I have my own routines. They are not static although some of them have been with me for some time now. Some have been affected due to the confinement state we are in right now in Spain so I am adapting them to evaluate how they work. My advice in this regard is that you read about other people routines, identify yours, track them and experiment to find the right combination. Again, assume they will evolve over time.

I have written in the past several articles about team ceremonies. These articles have helped me to explain certain basic topics. You will need to find the routines that work for you and your colleagues though, in the same way that it happens at individual level. The articles were written thinking mostly about team leads at any level but hopefully there is plenty of useful stuff for team members too:

  • Working in distributed / remote environments 0: presentation.  Motivations, introductions and some definitions. The article includes the link to the rest of the series.
  • Working in distributed / remote environments 1: daily short meetings. Tips and recommendations about adapting the team daily meeting that is so popular on colocated environments.
  • Working in distributed / remote environments 2: the calendar tool. Comments about the increase of relevance for any team that the calendar has in remote environments together with some tips on how to use it.
  • Working in distributed / remote environments 3: weekly meetings (I) and (II). Teams meetings are an essential ceremony to drive change, detect issues early, solve conflicts. They are essential in remote environments. These two articles provide an overview of how relevant they are, why and how to adapt them to the remote nature of the team.
  • Working in distributed / remote environments 4: one on ones (1:1s). in co-located environments, 1:1s are not perceived as a priority by many. Only when the organization grows beyond certain point, this ceremony gets the attention that in my opinion it deserves. In remote environments you cannot wait to get “big enough”. The nature of the work environment force you to establish proactive measures to align, define expectation based on company, department, team and individual goals and evaluate, together with the workforce, progress. The articles provide tips to adapt 1:1s to a remote environment.

You will see that in the articles I use the term distributed and remote environments (DRE) to avoid referring to the different stages of the journey. This is for simplicity. Ceremonies might slightly change depending on the stage the organization is at.

Companies

It is always good to have references, right?

Remote-first and specially remote-only companies need to pay an extraordinary amount of attention to company culture. They usually provide plenty of resources to their employees about this topic. These organizations start hiring experienced remoters at first but as they grow, they realize they need to educate their workforce in remote working, which requires the development of contents. These two links might be a good starting point to find the right companies, what are they doing and why:

  • FlexJobs is an online job board specialised in remote work. They publish the main list of companies walking through their Remote Journey regularly.
  • If you are focusing in tech companies culture, you probably will prefer this article.

Reports about remote work

There are three interesting reports I recommend to read if you like the remote work topic:

I have used them in the past to open conversations about this topic with managers and HR departments, for instance.

Books

I have to admit that I haven’t found yet THE book about the topic, and I have been searching for years. This is the one I recommend:

  • Remote. Office Not Required. It is from 2013 but still (sadly) the best. It is based on the experience of 37signals (now Basecamp). Their authors have accumulated an extensive experience in remote organization since then.

If you are not into buying books (what?), this is an online free book written by Zapier, a popular company in this field.

Social media

  • Twitter: follow the hashtags #remotework #workfromhome . Besides plenty of advertisements from coworkings, you will find useful resources once in a while as well as blog posts.
  • Other social media references: those of you interested in digital nomads or digital travelers, can follow #digitalnomad hashtag on Twitter. I joined some time ago the Digital Nomads Telegram channel.

Events

There are really good ones out there to learn about this topic:

  • The Remote Work Summit: a remote event with many interesting talks and material. You can get free passes to some content and online talks.
  • Nomad City: this event takes place in Gran Canaria, Spain (in English). It is a great one to meet digital nomads, digital travelers and remote workers as well as remote organizations leaders.
  • CoworkingEurope: it is not directly related with remote work but with flexible working spaces, but you can find useful references to companies and processes to follow from there. I have worked in coworking spaces at different locations around Europe. They are a great source of remote work knowledge.
  • I have been the last couple of years trying to join the Nomad Cruise. Let’s see if this year…

Summary

In my experience, going from colocated to remote-only environments changes way more things that you can expect at first. Keeping high levels of efficiency, alignment and workforce satisfaction requires time and effort. Do not underestimate them. The good news is that although not at the speed this crisis is forcing many to do, plenty of people and tech organizations have experienced such transition. Some have published lots of contents about their experiences moving through The Remote Journey or living and growing at a specific stage. Look for those content in internet. Hopefully they are easier to find after reading this article.

A single man experience is very limited though. You probably have experience too. Please share it as well as links to further content.

Interview candidates with an Open Source background

I often say that there are two actions that define the line management role: one-on-ones and hiring people. This is specially true in growing organizations. If you nail these two actions, you have a good chance to truly influence, the ultimate goal, in my view, of any line manager.

One of the common strategies to speed up the journey from being an Open Source contributor to becoming a Good Open Source citizen is to hire talent with a solid Open Source background. The process of hiring such talent is different from what most organizations and recruiters are used to. That is so true that we have now companies specialized in hiring these profiles.

One key part of the hiring process is the interview, obviously.

This article is another one of those I have written the last couple of years about management topics, based on my experience working in Open Source as manager and consultant. More specifically, it is an attempt to describe some of the key points that hiring managers with little or no experience in hiring Open Source talent need to consider to increase their hit rate.

As usual, I would appreciate if you add in the comments section or to me directly your experience, criticisms or missing points. I would add them to this article as update.

Evaluate the candidate’s work in advance

If you only have room in your hard disk for one takeaway, it should be this point.

Most of your candidate’s work is public. Take the time to evaluate it or have somebody else doing it for you, before the interview. If the candidate have public talks, watch the videos or check the slides. If she has written articles, read them. If she has code available, study it, test it, install it… .

Having the candidate’s work in the open is a double edge sword. It is an advantage for the hiring organization because it can reduce significantly the hiring process, since you can evaluate in detail many of the candidate skills in advance, so the interview process can be reduced to a single interview, for instance (I strongly recommend this, by the way).

At the same time, if the hiring manager do not take the time to evaluate the candidate’s work or even worse, if the manager acts during the interview as if that work is not public, trying to technically evaluate the candidate prior or during the interview, for instance, the failure is almost guaranteed.

I always mention how wrong it is to ask a music group with published records or videos of their concerts available on the group’s website if they know how to sing. Or even worse, to request an audition during the hiring process for your birthday party. Who does that? Instead, watch their performances, skip the audition and go directly to negotiate other relevant points. Their work is public, did you check it?

By the way, the world is significantly larger than GitHub, thanks God. The candidate might have a strong Open Source background without having a great GitHub profile… or no profile at all.

Interview goal

The interview is not just an opportunity to evaluate if the candidate fits in your organization, it is a chance to attract that professional and her colleagues. Remember, the candidates code, processes followed, tooling used… are public. Your organization’s most likely not.

Who has more to inform about?

As result of this reality, the interview should look more like hiring a senior manager/expert than about hiring an engineer.

In summary, the goal of the interview shifts. It should be balanced between what both, the organization and the candidate looks for. This shift represents a challenge for hiring managers with limited experience in hiring senior talent.

Candidate’s future upstream participation

During the interview, be clear about the amount of time the candidate will have to invest in upstream work, specially if he candidate is working upstream already a significant amount of time.

There are plenty of developers who prefer to keep their work in the open as a personal activity. On the contrary, some others want to make a living out of their participation upstream. The best way to ensure a sustainable relation over time is to be transparent about the expectations related with the effort put in internal work vs work done in the open as well as in which projects.

If by working in your organization, the developer will have to reduce her current involvement in the open, specially in specific periods of time, say it clearly. If you cannot guarantee that the technologies the candidate works with in the open will be part of the company’s tools set, state it clearly. If your organization has plans to move towards Open Source and you bring the candidate to speed up that journey, make sure she understands the timelines and expectations.

No matter how experienced you are as hiring manager, there is always room for a candidate to surprise you about her motivations to participate in the interview and potentially join your organization. This is most likely true with professionals coming from an industry you might not be very familiar with.

Tooling, languages, technologies…

One of the great advantages of being an Open Source professional is that, because you use open source tooling, you can take them with you throughout your career, which makes you very efficient. Professionals with a solid Open Source background do not depend on certifications paid by their companies to learn how to use their tools, or having to change their base tool-set regularly, limited by commercial decisions. In other words, Open Source professionals have made their career supported in specific tooling and associated practices they have chosen and mastered. Often, they have even helped to develop or polish those tools. Some of them love to try new tooling on regular basis and some others love to focus their energy in other aspects, not in the tooling or associated processes, so they are conservatives.

In some cases, this specific point is so important for the candidate that using those tools and associated practices represents a requirement to join your organization.

You will need to consider and potentially embrace this reality. If you cannot or do not want to use those technologies or tools, make the point during the interview. But before you do, I recommend consider the following…

Are you open to reconsider such decisions if somebody prove there is something better? Is it something that can be reconsidered next year, when the current support contract for tool X expires? Do you have any specific department or project where you are willing to try new tools, processes, languages…? Are you open to assume that you might have made a mistake in such decision or that those decisions will not stand the test of time?

Many Open Source professionals, for instance, consider that, doing Open Source with Open Source tools is significantly better that using proprietary ones. Why?

At scale, adapting the tooling to the needs of the specific environment and integrate them with other tooling to improve the development experience is essential. Even more that to use a feature rich tool. To have full control of the tool’s evolution in your specific environment is another interesting point… there are many other strategic and practical reasons that leads to that mindset.

Learn from the candidate about those arguments during the interview.

Very often hiring managers see the candidate’s position in this front as religious or philosophical. Instead, I would take it as an opportunity to improve and innovate within their organizations. I suggest to embrace such experience the candidate can bring to your organization as starting point during the interview and take the conversation from there, instead of questioning her criteria and define this point as a no-go early in the interview or the overall process.

Recommendations and referrals

Open Source is about trust and networking, based on the work the potential candidate does within one or several communities. In many cases, the candidate recommendations and referrals come from peers from those communities.

If you are a hiring manager, take those recommendations as seriously as any traditional referral from a senior manager or a relevant figure in any big corporation. They are frequently equally valuable.

In Open Source, you are judged by your work and your influence, not by your position in a hierarchy of any organization.

Get help for the interview

If you have little or no experience with Open Source, bring somebody that do have it to the interview, in addition to a technical expert, specially if you are interviewing engineers. It is not relevant if such person is not an expert in the candidate’s knowledge area of expertise.

I am not a technical person and, when I join such interviews, the hiring manager often learn new things about the candidate because we both (candidate with solid Open Source background and myself) share a similar working culture. This is specially true when the candidate starts to ask questions to evaluate if the company is a good fit for her. In addition, it often plays in favor of the company to show to the candidate that there is Open Source knowledge internally and peers that feel comfortable working there.

Assume the candidate knows about your organization already

Do not underestimate how much candidates with solid Open Source background know about your company before the interview, even if your organization is not an Open Source contributor.

These kind of professionals might learn about your organization not just by interacting directly with your engineers or evaluating your products, but also by interacting with your suppliers and partners in the open, in some cases on regular basis. They might know about the hardware you use, the versions of specific software you ship, tools you use, release strategies you have, updates policies, etc. They might even point at clear deficiencies and strengths of your products and services as well.

I suggest to ask the candidates early during the interview what do they know about your organization and why do they want to join it. It is also interesting to ask about their evaluation/perception of your organization as a whole and your products/services compared to others.

It is not only about getting information from the candidate but also about informed perceptions. Such conversation might help hiring managers to tune the description about what the organization does and avoid providing superfluous information during the interview. It also helps to understand if the candidate is one of those who want to work in industry leaders or help you to become one, which is something I am always interested to learn about them.

Why do you need a CV?

Even today, I still come across former colleagues and great Open Source professionals who do not have a CV. I have helped several of them throughout the years to create one or update it.

For an Open Source professional, their work speak for themselves. It is a better presentation that any CV will ever be, in my view. It is the outdated business culture the one that should change and adapt to this “not so new” way of “filtering candidates”. It is simply better for all parties involved.

Many great Open Source professionals have a mediocre CVs or no CV at all because they never needed it. For some, this lack of CV is a way to filter organizations they do not want to work with. Their thinking goes in the line of… if you need my CV to filter me as candidate or evaluate my work, I am not interested in working with you. Check my work!

Instead of questioning the quality of their CV, take the opportunity to ask yourself why do you or your organization need a CV when the candidate’s work is publicly available. It might be a great introspective exercise. Maybe you end realizing that only a bunch of links and his contact information are really needed, instead of a formal CV.

Myth: Open Source developers are not good communicators

Open Source professionals, specially developers, are used to great levels of exposure to other professionals worldwide. In general, they need to become good communicators to succeed within their communities.

Open Source developers as people incapable to communicate is a myth. Such perception often depends on what you understand by communicating and to whom, but specially it is based on myopia often from people with a limited technical background.

It is true in my experience though that in general, many Open Source developers do not do great interviews. But that is mostly because they do very few of them. They do not go to 10 interviews with four different companies to get a job. They do not need to. And what is more important, throughout their careers, interviews are not used to evaluate them technically, again, because their work speak for themselves.

Evaluate the candidate’s written communication skills. Check the mails they send to dissent with others or describe their position, read the blog posts they write summarizing their latest work, check their presentations, their slides… Check how they interact with their users, code maintainers… You will soon realize they interact with profiles or groups of people on regular basis that many corporate engineers do not. And those interactions often face ore limitations that within any corporation, due to cultural differences.

When talking to managers unfamiliar with Open Source about this point I always ask them how many professionals they know that having done good interviews, are still incapable of standing behind their opinions in a meeting with senior colleagues or customers. Or how many people in their teams excel at describing complex ideas in simple words (in a 10 min presentation, for instance).

Public exposure to peers and users in Open Source projects are an outstanding learning environment for developing certain communication skills. Be careful with this myth.

English level

In Open Source, most of the communication among developers take place in written form. This is due to the distributed and asynchronous nature of the environment they work in (software development at scale). Most of those developers have a better level of written English than spoken.

I always recommend to be careful when evaluating the candidate English skills only through the interview. To have a full perspective of the candidate skills, I always recommend to check her written communications and articles. If they have videos of their talks available, review them. You might perceive noticeable differences between their written and spoken English levels.

When doing an interview, it is very hard to be quick and provide sharp answers without thinking when you do not speak English on daily basis. I have experienced this myself.

My point here is that you might evaluate her English skills as poor based on the interview when, in many cases, they have solid written skills, so they need little time to develop the minimum level required to work in English.

Agile fans tend to underestimate how important it is to have a good written level in English compared to the spoken/conversation level. In Open Source (develop software at scale), the trend is exactly the opposite… for good reasons.

Remote Work

Many professionals prefer to live by the beach, in a cheaper place, than to commute for an hour to go to the office in a big city. At the same time, when developing software at scale, it is unrealistic to think you will find the talent you need in a single location; even in two different locations. It should not come to a surprise that the market is moving towards developing software in distributed environments where remote workers are not the exception anymore.

The number of “remote first” and “remote friendly” companies is growing in number and size at a fast pace. Open Source is about highly distributed, asynchronous and high latency environments. Some of the larger software engineering projects has grown and mature with those characteristics by design.

The candidate has probably made a career out of mastering working on such environment.

Instead of questioning the efficiency of distributed teams during the interview (common practice among remote work detractors, like radical agilists and traditional managers), take the opportunity to learn about it.

If you think that co-located, synchronous and low latency environments are more efficient, ask about how current tasks at your company could be performed remotely, how ceremonies can be adapted, how testing can be performed remotely. Learn from the candidate about how to develop software at scale, how he has acquire such experience and levels of efficiency in such environment.

I have worked in organizations where testing was done remotely, in a heavily distributed environment, for instance. Technology and creativity have made Open Source projects the best environment for developing software at scale. Even if your organization is small, the candidate skills might become an asset.

The network effect

Working in the open provides any professional the possibility of building a large network. That interview might well be the first and only direct interaction that such professionals might have with your company. If the experience is not satisfactory, her network will know.

Would you recommend a person you trust or respect to apply to a company that did not provide you a good experience during the hiring process? And I am not talking about hiring them. I have had good experiences with companies that chose a different candidate during the process. We are grownups. We can take rejection.

By ignoring the point on this article (or others i skipped), you are not just simply making harder for your organization to hire Open Source talent. You are shouting with a speaker your deficiencies.

It is not a coincidence that some corporation with pedigree have such a hard time hiring good Open Source professionals while some others less popular are so successful. It is partly because of the networking effect.

Do it right a couple of times and more talent will come. On the contrary, fail badly and you will pay the prize for some time.

How to move the candidate out of her comfort zone

Part of any interview’s goal is to get from the candidate things she did not plan to show or surface.

People used to work in the open, with high levels of exposure, develop a great sense of correctness and politeness when expressing opinions. That does not mean they are not passionate about what they do or that they do not have “radikal opinions”. They are and you want to know them.

Ask the candidate for her opinions about tools, technologies, projects from your competitors or technologies that the community project they participate on are struggling with. I believe these kind of questions are a fair way to move the candidate out of her comfort zone and get their “essence”.

But when you do, be aware about the trends and debates the candidate and/or the community she participates on have had about such topics. Be careful with making statements that are a no-go for the candidate simply because you did not prepare the interview well enough.

Avoid the typical myths around Open Source, the stupid arguments about battles between communities, superfluous statements about Open Source business models and their feasibility, etc. Instead, ask about, for instance, how do they see their community project in five years, what are the challenges they are facing, what are the deficiencies they need to overcome, etc. Do your homework about Open Source and the specific community the developer is involved in before the interview. Nobody wants to work for a person that seems a fool or lazy.

Again, if you do not know about these topics or had no preparation time, bring somebody with knowledge to the interview or state your ignorance up front.

Summary

Radical exposure to peers and users, development of public code, knowledge share with professionals from different industries and global organizations, etc. are characteristics about the candidate that cannot and shouldn’t be ignored during the hiring process, specially during the interview.

Instead of applying the same template that has worked fine in the past for your organization, hiring managers will need to evolve it or even change it in order to attract people with solid Open Source background. This is yet another of those transformations and culture changes that any organization will need to go through to fully embrace Open Source.

To me is very simple, if you want to become a Good Open Source Citizen, you will need to hire people with a strong Open Source background if you intend to speed up the journey. Either you adapt your hiring processes, including the interviews, or you will most likely fail in such goal.

To adapt, hiring managers and experts need to develop new habits. That can only come if they question the current ones. This evolution will take place faster and with a smaller impact for their organizations if they get help.

I think this topic has gotten less attention that it deserves.

Agile On The Beach: my first time

During 2017 and 2018 I got several interesting references at eagileonthebeachvents like Scale Summit and pipelineconf about an interesting event in the south-west of England about lean, agile and continuous delivery that got my attention. I decided that I could not miss it in 2019.

2019 edition of Agile On The Beach was the 9th one. The event has gain a good reputation among agilists for being a good mix of great content and relaxed atmosphere in a beautiful environment. This is not surprising for somebody coming from the Open Source space but is not a so common combination within the lean/agile/CD world.

I bought the tickets and reserved the accommodation on time (months before the event). As you know, I started in MBition in June. My employer was kind enough to make it easy for me to attend. So on July 10th I headed to Falmouth, Cornwall, UK to participate in Agile On The Beach during the following two days, coming back to Málaga on Saturday July 13th.

I liked the event. I felt like home. Like if I was at Akademy, for instance. There were some outstanding talks, a great atmosphere, talented and experienced attendees, reputed speakers, good organization and nice social activities.  Yes, the trip to get there was long but I had no delays in any of the several planes and trains I had to take (who said British trains are awful?) which allowed me to invest a few hours working on each way.

The videos has not been published yet. I will add as comments those I recommend you to check.

Update: please find the videos here.

Next year the event celebrates the 10th edition. They promised to do something special. If you are in the UK or are willing to invest several hours traveling to a good Lean/Agile/CD event, Agile On The Beach is a great one. But stay tuned, the number of tickets is limited and they are gone several months before the event starts.

A new door opens: MBition GmbH

This month of June I have started a new adventure. I have joined MBition, GmbH, a 100% owned subsidiary of Daimler AG focused on …

“MBition focuses on Infotainment-Software, Navigation-Software, Cloud-Software and UI-Software. ” (extracted from the MBition website).

Automotive is one of those industries that is going through disruptive changes. I think it is a very interesting place to be right now if you are looking for some excitement.mbition_logo_color_4

Back in 2018, I did a talk at the Autonomous Vehicle Software Symposium, in Stuttgart, Germany, where I said something like this, when referring to software platforms for automotive in the autonomous driving era:

  • What the industry is doing today will not work then.
  • What the industry knows today in this field will not be enough.
  • Learning fast becomes the only suitable strategy to succeed.

Then I asked if OEMs and Tier 1s were learning fast enough. I still believe today that in general no they are not.

Will we at MBition be able to make a positive impact in the way Daimler is learning about how to design, develop, deliver and maintain a software stack that meets the current and future industry requirements, providing at the same time a premium experience to customers, developers and partners?

I will work to answer YES to that question. It will be an outstanding challenge to face during the coming months. I am very excited about it.

Thanks Gregor, Johan and the rest of the MBition crew for giving me this opportunity. A new journey begins.

I will remain in Málaga working remotely for now but visiting Berlin frequently since MBition’s office is located there.

OpenSouthCode 2019 recap and new information added to my site

OpenSouthCode 2019 recap

OpenSouthCode is a FLOSS event that takes place in Málaga, Spain, every year. I have written about it before:OLYMPUS DIGITAL CAMERA

The event tool place this year in a new venue, significantly better than the previous one, in my opinion. More than 300 people were registered which is not bad at all for a free of charge event about Open Source that does not require pre-registration to participate.

Some workshops and talks were packed, although not the majority of them. Some people has commented that there did not feel a “sense of packed” which is was due to the fact that, during 2 days, the event offered 2 to 4 tracks and workshops simultaneously. Saturday was busier than Friday, I think.

I don’t feel that there is anything bad in having only a few people at your talk if they are truly interested. With such an interesting and diverse offering, motivated participants is almost guaranteed. I understand though that if you come from far away or your company send you to give a talk, having a full room is a good thing.

The event is little by little growing. The organization in general goes smoother, the quality of the talks and the speakers is better every edition, the workshops, specially those for kids, are gaining traction, the venue is better, there were sponsors this year… All signs are positive.

As a suggestion for the 2020 edition, I would organise a closing keynote so participants can get together afterwards for some drinks. This would improve the sense of community and would provide a good opportunity to thank the sponsors.

I am happy with how my talk went. Around 15 people attended. I could attend to 3 additional talks ramon_agustin_paul_opensouthcode_2019which were very good. I learned a lot. It was great news to see Ramón Miranda giving a talk about Krita, by the way. Thanks Paul for your advises about my slides and Gaby for the pics.

Special thanks to the OpenSouthCode organisers for putting the event together once again. See you next year. Follow them on Twitter to know more about the next edition.

Latest updates on my site

The past weeks I have updated some information on my site:

  • I have added the slides of my OpenSouthCode 2019 talk to the Talks page, together with some additional links from previous talks.
  • I have added a couple of great books I have read lately and/or use widely. Check them out in the Reads section of this site. A couple more will be added the coming weeks.