A brief overview of hack.summit() 2016 (part 2)
Commentaries on some of the hack.summit() 2016 talks
hack.summit()
This is the second installment of the overviews of hack.summit() talks. If you haven't already read the first part, you can do it here.
Sarah Allen from GSA
You can watch the video here.
Sarah's talk is about technical leadership. Fortunately she wrote a nice wrap-up about her talk, and hers is surely far better than mine would be. Go ahead and read the excerpt at her blog.
The one thought that appealed to me the most is that every mistake is an opportunity. People tend to see obstacles everywhere and fail to realize that they can also drive positive change. A bug is an opportunity to make the software more resilient, a misunderstanding can easily form a more collaborative relationship. Try thinking this way, and you can fix many things around you.
This concept is present in TDD too. If you see a bug, you first write a failing test for it, and only then fix the bug. The bug will be gone, but the test will stay, giving an early warning if the same bug gets reintroduced in the future. It makes the software more resilient.
Hampton Catlin from Wordset
You can watch the video here.
Hampton's talk is about hiring people, and what guidelines the process should be based on. Hiring is a complex and important process for a company. Working in the tech industry requires two ingredients: you and a laptop. This makes hiring the right people much more important than in other industries.
A good interview should be
- structured
- behavioural
- and situational
The exact structure should not matter too much. As long as there is a clear one in place, little tweaks make little differences. Behavioural is assessed by talking; you need to map the interviewee's personality and what he is good at. And lastly, situational, as you should present some situations and ask how s/he would act.
A general misconception is that people produce code, so that the hiring process should focus on programming skills. An interesting anecdote is that he applied to a freelancing site that hires only the top developers. He failed their test with 0%, even though he already launched 10-strong pages. It's also interesting to see that hiring people at several big companies conceded that they almost always get it wrong.
Diversity should be the number one goal when hiring people. Coding skills are necessary, but only at a team level. If someone is great at algorithms, while it is a nice skill, not all members are required to be.
An interesting concept is positive vs negative hiring practices. The former concentrates on what the candidate is good at, while the latter tries to find aspects s/he falls short. Following this thinking, Hampton admits he used the negative one. He had a veto role, where anyone in the team can veto. He is now transitioned to the believer role, where if anyone in the team sees potential, the candidate is hired; but the believer has to mentor s/he.
The last advice Hampton gives is not hire people who are openly hostile to teamwork or mentorship. Development is a team effort, and while most people like to work alone, openly against teamwork is pernicious.
Jon Skeet, the legend at StackOverflow
You can watch the video here.
Jon is the #1 answerer at StackOverflow. The title of the talk is Communicating ideas that we take for granted to new developers, but it's a bit ambiguous. This talk is not about onboarding new people to your project; in fact it is about how to communicate with people who are just starting in programming.
Jon call programming experience "battle scars". You get these as you struggle to surmount difficult problems, but finally you tackle them down. A mentor could help you on the way.
He details several common topic that new developers usually struggle, and a mental model that would help them to understand the underlying concepts. This mental model can be used to tell a story; if the new developer can finish the story, then most likely understands the concept as well.
The first model is to understand passing parameters by reference vs by value. This can be depicted using houses; a variable is just the address of the house. This is passing by reference - if someone paints the house, everyone sees the new colour. The address is passed by value, but the object is not.
The second model is encoding. Files are just a bunch of numbers, so if you want to write something, you need a way to convert that to sequential numbers. Like colours: You can encode RGB and grayscale colours, but if you just see the file, you have no idea which one is written there.
The third one is integers. Understanding binary and hexadecimal is usually a hard task to newcomers. Using dots and simply counting them makes this easier.
Continuing on numbers, the fourth one is floating-point numbers. It's a harder topic, but simplifying it to just three digits and a scale could help understand why some numbers are impossible to represent.
Then he moves on to natural vs human dates. It's a hard topic by itself, but understanding why daylight saving and time zones can screw up everything if you use human dates is the first step to use unix time where you can.
Then he moves on to parallelism. The story is to fry bacon and them simmer. Data parallelism is to have all the people have a fraction of the bacon. Task parallelization is when you have Alice do the frying and Bob do the simmering.
