Notes from Geekcamp 2017

Yesterday (Saturday, July 15) I had the opportunity to attend Geekcamp 2017 at Senayan City. Geekcamp is a tech conference organized by KMK Online and Karir.com — I’m not sure of its exact schedule since this was the first event I visited. The event featured seminars from regional and national technology figures as well as booths from tech companies.
What Was the Event Like?
The event was held for only one day with a full-day schedule from morning to afternoon. For a fee of Rp75,000, along with the event ticket I also received a T-shirt and snacks consisting of a slice of Domino’s pizza, a Krispy Kreme donut, and a bottle of a drink.
Upon entering the conference hall via a dedicated elevator leading to The Hall on the 8th floor, I immediately found the tech company booth area. The number of booths was not many — countable on one hand. Among the booths present (that I remember) were Karir.com, Hacktiv8, Grab, and Google Cloud Platform. What confused me a little was the lack of signage pointing to the registration desk. Fortunately, a staff member from one of the booths showed me the way to the registration desk next to the SCTV Studio — unfortunately I didn’t get a chance to introduce myself.
Upon arriving at the registration desk located next to the escalator, I realized I should have entered via the escalator from the 6th floor of Senayan City. That way, I could have gone straight to registration. After registering by showing proof of ticket purchase on Bukalapak, I then picked up a goodie bag from Google Cloud. After that, I was free to explore the conference venue.
There were two stages to attend: the main stage in the Hall and a second stage at the smaller SCTV Studio. Seminars at both stages ran in parallel from morning to afternoon. The Hall stage featured invited speakers such as Ditesh Gathani, Director of Engineering at Grab; Simon Stürmer, CTO of Kodefox; Mohan Krishnan, CTO of KMK Online; Willix Halim, COO of Bukalapak; and Jim Halkyard, Cloud Consultant at Google. Meanwhile, the SCTV Studio stage featured speakers who applied through a call for speakers selection process held some time beforehand.
The topics covered on both stages were equally exciting, so my friends and I went back and forth between stages several times to attend different seminars. The difference was perhaps that the Hall stage gave each speaker more time — around 30 minutes — while the SCTV Studio stage allowed only 10 minutes per speaker.
Things That Caught My Attention
First, of course, were the attendees. The number of participants was quite large, but not as packed as the Tech in Asia Conference I attended a few years ago. What made this event different was that the majority of attendees were IT professionals from various startups and companies. These IT professionals came from all levels, from junior level like myself all the way to CTO level. They also came from various backgrounds, ranging from front end developers, back end developers, data engineers, machine learning engineers, to researchers in natural language processing. There were also a few students attending. Everyone mingled and socialized without any apparent gap.
Second, the speakers. The speakers at this conference were quite impressive, as some came from a regional level (Southeast Asia), while the majority were from Indonesia. The topics presented by both groups of speakers were equally interesting and equally in-depth, demonstrating that the competency of Indonesian IT professionals is not behind at the regional level. Several of the speakers also represented services operating at a large scale, making it very interesting to observe the dynamics they described. For instance, Andreas Hadimulyono presented on scaling data handling at Grab, which serves customers across Southeast Asia. The talk described how their data infrastructure changed so rapidly to keep up with the growth of their user base.
Furthermore, most of the talks at this conference addressed technology at an architectural level, rather than at a practical level like one talk delivered by my colleague Mas Agung Setiawan on Vim. Most talks covered their software architecture, how each system communicates, how they handle scaling, and so on. One thing I also noticed was how microservices architecture is currently trending. It seemed like every talk I attended that presented a system architecture always mentioned microservices.
Lastly, and perhaps most interesting of all, was how almost every talk at both the Hall stage and the SCTV Studio stage always ended with the phrase: “We’re hiring!”. Personally, I found this slightly disrupted the conference atmosphere, because for me the event should truly be a place where geeks can satisfy their curiosity without being distracted by matters outside of technology. But it’s undeniable that it was useful for attendees who were looking for job opportunities. From that, I also got the sense that IT skills are still very much in demand, both in Indonesia and across Southeast Asia. This is the age of the geeks, baby.
Some Notes from the Seminars I Attended
Below are some notes from the seminars I attended at Geekcamp this time. These notes may not be 100% accurate as they are based on my memory and interpretation of the material presented by the speakers. Also, unfortunately I could only attend the event until midday due to other commitments, so only a few notes are available to share. Nevertheless, I hope they can be useful.
The Future of Front End Engineering by Simon Stürmer
Simon took the audience on a journey through the history of front end technology from the early growth of the web. From there, it was clear that as web technology develops, the focus of front end development increasingly moves toward productivity, performance and user experience, as well as the growing importance of JavaScript in today’s front end world.
At the core of his talk, Simon introduced the duo of React and React Native, where using both can boost developer productivity by offering a unified developer experience. This means front end developers can work in a similar environment for both web and native application platforms. This is achieved through the common language used to develop both platforms, namely JavaScript. The JavaScript code produced by React Native also runs with performance close to that of applications developed purely natively, for example with Java on Android. Additionally, the hot reloading feature in React Native development means developers don’t need to recompile and reinstall the application on the testing device when making changes. This feature creates a native app development experience similar to developing the front end of a web application.
Our Battle against Technical Debt by Ifnu Bima
In this seminar, Mas Ifnu Bima shared how his team at Blibli fought technical debt. Technical debt is the cost in the form of the responsibility to ‘clean up’ our work later because we chose an easy and fast solution rather than an optimal one.
Interestingly, technical debt can be analogized with financial debt — borrowing money. We can, especially for startups that mostly chase time-to-market, take on technical debt by implementing easy and fast technology for the sake of release speed. Like financial debt, technical debt also accrues interest over time: the longer technical debt is left unresolved, the harder it becomes to deal with later as a system’s codebase grows. Eventually, the interest piles up so much that we end up only paying the interest in the form of bug firefighting.
In this seminar, Mas Ifnu shared the journey of the team he leads in managing the front end code for Blibli’s website. In the past, Blibli’s website migrated from adaptive to responsive to reduce complications in development. But later, as Blibli grew, the responsive implementation caused problems because the growing file sizes slowed the website’s performance on mobile devices. They then returned to an adaptive web implementation with m. and www. domains. Based on his evaluation, responsive web development should be done mobile-first — meaning building the UI and UX for mobile devices first before moving to desktop.
The main problem resulting from their technical debt (and certainly almost all front end developers) was slow load times. The efforts they made to ‘pay off’ this technical debt included implementing a single-page application (SPA) along with server-side rendering to maintain SEO ranking; moving JavaScript instantiation to the end of the DOM and removing unused JavaScript; and implementing lazy loading for content outside the user’s viewport. Interestingly, he described how his team applied lazy loading not just to images, but also to CSS files.
Building a Programming Language 101 by Giovanni Sakti
I only caught the second half of this seminar. In it, Mas Gio explained the process of building a programming language. He showed assembly code — the machine-level instruction language obtained from compiling a high-level (human-readable) programming language.
He explained the process by which text is read and understood by a machine: the lexicalizing-tokenizing process and the parsing process. In the lexicalizing-tokenizing process, the compiler groups symbols into certain groups, which are then arranged in a tree during the parsing process to be processed into instructions for the computer.
In the end, he explained that the knowledge of building a programming language becomes very useful for building a domain specific language (DSL) suited to our needs. One example of a DSL we often encounter is the language we use when using Google’s search engine. For example, I can search with the keyword pulpen pilot site:bukalapak.com to find Pilot pens only on the Bukalapak site. He himself is currently building a DSL for document authorization that can be used by non-technical people at his workplace.
Real World DevOps - What Works and What Sure as Hell Doesn’t by Mohan Krishnan
In this seminar, Mr. Krishnan affirmed that DevOps is not a job title, but a culture that needs to be implemented by an entire IT team. DevOps unites the developer side with the operational side, where clashes often occur because developers want their features to go live in production quickly, while the operations crew wants to ensure server integrity is maintained and the server won’t go down due to developer code.
In this seminar, Mr. Krishnan outlined 3 do’s and don’ts each, namely:
- Don’t rely on production priests. Don’t give production access to only a handful of people (priests), as this will create a sense of exclusivity and disparity among engineers.
- Don’t create silos. Don’t allow barriers to form between teams or even between engineers. These silos can be in terms of information, knowledge, or access to resources. Don’t let teams or engineers be unaware of and/or uninterested in the work of other teams/engineers.
- Don’t have ops and devs working to different goals. Don’t let developers and operations have different goals — both must share the same vision and mission. Don’t let them have contradictory KPIs.
- Do provide power and expect responsibility in return. Provide the facilities and tools engineers need to carry out their duties. You can then expect their sense of responsibility to increase accordingly.
- Do constantly cross-train. Always encourage engineers to collaborate. This will reduce the formation of silos within the team.
- Do keep things simple. Automate all work that can be automated. Keep the stack simple to flatten the learning curve for engineers. Speed of work will increase productivity.
Why Geeks Make Awesome Growth Hackers by Willix Halim
In this seminar, Mas Willix explained that technological knowledge can greatly drive growth hacking efforts. He provided two case studies: first Hotmail, then Airbnb.
In the first case, in the early days of the web, the founders of Hotmail managed to grow their user count at a rate of 3,000 users per day, eventually reaching 6 million users in just a matter of months. Keep in mind, this happened when there were only around 17 million internet users!
That achievement was made with a simple trick proposed by Tim Draper: placing text with a link to sign up for a Hotmail account at the end of every email sent by users. The text read, “P.S. I love you. Get your free email at Hotmail”. The message would remain in emails sent by users, including when recipients forwarded those emails. This text became free advertising for Hotmail.
The second case is Airbnb. In its early days, to attract users to their platform, Airbnb built a post on Craigslist feature, where users could copy their Airbnb listings to Craigslist. This effort was made because Craigslist had a much larger existing user base, and Airbnb’s target market was there. Notably, at the time (and still today) Craigslist provided no API at all for communicating with their platform, so the Airbnb team relied on scraping using bots to copy user listings to Craigslist.
Both examples show that technological ability and knowledge can greatly assist growth hacking efforts for a product. Solutions like those employed by Hotmail and Airbnb would seem difficult to think of without solid technological insight.
However, it’s important to remember that there is a law of diminishing results in growth hacking technique innovations. That is, the more commonly a technique is used, the less optimal its results become. For instance, if we were to build a new email service today and copy the P.S. I love you technique pioneered by Hotmail, the results would not be as dramatic as what Hotmail witnessed.
In addition, Willix also shared growth hacking tips and tricks applied at Bukalapak. Two things were emphasized above all: track everything and test like crazy.
Track everything users do on our product in order to identify gaps that can be optimized. For example, if we have an e-commerce site and many users are abandoning their purchases at the checkout page, that means we can optimize that page to improve the conversion rate.
Run A/B Tests on every feature we develop. An A/B Test is hypothesis testing by presenting different feature alternatives to several sample groups and then measuring their success metrics. By running A/B Tests, we can prove the value of a feature with data, not just assumptions. It’s possible that when we assume a feature we’ve developed will increase the conversion rate, the opposite actually happens. If that occurs, it means we’ve wasted resources building something that actually hurts our product’s performance.
He then noted that overall, everything comes back to the simple formula CPA < LTV — the cost per acquisition must always be lower than the lifetime value of that user. That is why Bukalapak minimally uses paid marketing channels such as billboards, because in addition to their high cost, results are also difficult to measure, making it hard to evaluate the CPA and LTV they generate.
That’s all the stories I can share about the Geekcamp event yesterday — I hope it’s useful! Feel free to leave a comment below for feedback, suggestions, responses, or questions about this article!