A brief overview of hack.summit() 2016 (part 3)

hack.summit()

This is the last post about the 2016 hack.summit() conference. As with the previous two, you can read short excerpts from three of the talks. Managing quality in large communities, an introduction to React Native, and some life advices are the topics covered today.

Enjoy!

The Joel Spolsky

You can watch the video here.

The title of Joel's presentation is "How to Have Nice Things", which does not say much about the actual content. It's about his observation to manage communities and have "nice" crowd-sourced projects.

Joel's wit and the topic itself offers a unique glimpse on the challenges of managing large communities. It's interesting to see behind the scenes, and how simple rules and even wording can have a rippling effect and fundamentally change whether a service is successful or will fall apart.

The general idea behind his talk is that while small communities are awesome, when the numbers begin to increase, so as the problems. This makes most of the organizations, be them however fascinating, begin to fall apart. His idea is that in order to keep the awesomeness, you need to make and enforce rules that keeps the non-nice things out.

One of his example is Wikipedia. From the outside, it's like everyone can write articles and it's a collection of what's true. It was the case for some time, but then some rules were added. The problem with the notion that anyone can add information is that Wikipedia would quickly fill up with bad facts.

And that's why Wikipedia came up with the Notability rule. It means that only verifiable information can find it's way in, no matter other ones are just as true. This made some awkward situations where the author of a book is not a credible source of information.

But in the long run, this rule albeit repulsed many editors, ultimately allowed the content to be better overall. Instead of letting everything in, the remaining editors are working hard to provide high quality content, and it helps the visitors.

Joel's next example is Linux. Linus is making sure only a fraction of all the commits get merged, and that's essential to keep the quality high. If everyone would be allowed to bring commits to the kernel, things would fall apart quickly. And it's something that was different when the codebase was small and only a handful of people were working on it. But as more people got involved, new rules were needed.

Joel's third example is his very own StackOverflow. It is aggressively optimized for people coming from search engines, instead of the joy of it's users. It became the primary reasons why most developers are using it almost every day. They removed the non-nice things, so only the nice ones remain.

Bonnie Eisenman from Twitter

You can watch the video here.

As a React.js developer, I was enlightened to see a presentation about React Native. It's an excellent opportunity to have a glimpse on the technology from someone who is an expert in the field. Even though I hardly believe I'll use it in the near future, it's an interesting piece of technology.

React Native is about bringing the power of React and Javascript to mobile platforms. But contrary to the way Cordova did it, React Native is a truly native solution. With the so-called bridges, developers can interface with the native components and services, bringing true support to the underlying infrastructure.

React provides an easy-to-grasp and functional programming model that makes development much easier. React Native brings the same concept to mobiles, by substituting the DOM with a tree of app components. The same event model, the same virtual representation, and the same language are used as for the web.

What's the catch? Mobile platforms are quite different, and while small apps could benefit from the common codebase, I'd doubt that providing the true Android and IOS feeling at the same time would work without headaches. Even native platforms introduce major changes every few years, it's hard to keep up with only one of them.

That said, Bonnie's presentation is an excellent starting point that will give you a feel for the technology in less than an hour. If you are interested in either React of mobile development, you should give it a go and see for yourself.

Gregg Pollack from Codeschool

You can watch the video here.

Gregg's talk is about a list he wish he knew out of College. He is the CEO at Codeschool, worked at several places, and founded and also failed at a number of startups, so he surely speaks out of experience.

The first in his list is to find a mentor. The best one is who both cares for you and is giving clear and actionable advice.

The second is to surround yourself with craftsman. Go to meetups, join user groups, and go to conferences. This way you can stay up-to-date with technology and see the recent trends. People can easily get stuck what they are doing and miss out on the newest innovations. You should learn new things anyway, doing it with others is a huge plus.

The fourth advice is to delegate. If there is someone who could do the task more effectively or more eagerly, pass it on. If you are a manager, even though you could do a particular thing, but that doesn't mean that you should. Learn to delegate and do what you can do best. An example Gregg provides is about a company who hired a barista. They calculated that almost every employee drinks coffee and making them adds up to a level a dedicated professional is more affordable.

The other points are more targeted at a personal level. The fifth is to stay out of your comfort zone. Do the most daunting task (also called "eat that frog"), because it usually makes the biggest difference. And don't get carried away by filler tasks, like email checking; they are useless.

The sixth advice is to turn off notifications. It's something I'm practicing recently, and it really makes a difference. Notifications are the blight on deep work, and should be controlled. Check the emails at fixed times, and don't let them break you out from the flow.

The seventh is that the most sophisticaed solution is rarely the best solution. Developers fall into the trap of overengineering, while keeping things simple is often more valuable. Get rid of the features you're not absolutely sure are needed. The application will be more with less.

Number eight is to take risks when you can afford to. If you are just starting out and you don't have a profligate lifestyle or a family, you can afford losing. Take risks, and learn a lot; you'll be much better in the long run.

The ninth is to don't get sucked up into management if it's not your passion. Most career path starts with coding and ultimately leads to the management. But it's like military ranks; everyone eventually reach a level where he is bad at. If you don't feel like managing people is what you'd like to do and better keep coding, do that. If you current company does not offer this path, choose another one company.

The last advice, and the most powerful one, is to don't lose sight of the power of choice. By the time you are out of college, you are a grownup. Everything you do is your choice. If others impose things on you that you don't like, it's your decision. You can quit your job, you can quit your relationships. Don't act like a victim, change.