It was a two-day conference with six different tracks each day, so there were always multiple good options to choose. The talks ranged from machine learning to office politics. Even though the conference did not have a specific focus, there were themes that came up repeatedly, such as the complexity of computer science, big data along with its capabilities and biases, and handling errors well.
Below, I have summarized some talks that reflected those key themes:
- Guide for the Perplexed was the opening keynote, addressing the complexity of today’s technology. The speaker, Joe Armstrong, created the functional programming language Erlang.
- Exploring Stack Overflow Data was given by Gabasova, an F# fan who has used big data in cancer research. The talk looked at ways that big data can be used to answer interesting questions such as, “What programming languages are mainly used at work, and what languages are used for fun?”
- Unconditional Code focused on creative ways to handle errors, such as adding them to the type system or changing the problem being solved.
Guide for the Perplexed (Joe Armstrong)
Armstrong suggested that we ask two main questions: “What problems are worth solving?” and “What is worth learning?”
There are many, many technologies to learn nowadays. To make things even more complex, the problems being solved in computer science classes are usually different from the problems industry is solving. And the problems the industry solves may be different from the problems end users have, such as, “How can I just make this thing turn on?”
To address all of this complexity, Armstrong made a list of lists. Some of his lists that stood out to me were:
Books to read
- Algorithms + Data Structures = Programs
- The Mythical Man-Month: Essays on Software Engineering
- How To Win Friends & Influence People
- Focus on technical writing.
- Don’t stick with a bad boss. You will not be able to change your boss.
- Engage with management early on, even if they don’t understand all the parts of the problem you are working on (and whose fault is that, anyway?).
What we can do
- Create applications that can communicate with each other, making it possible to “pipe” data from one application to another. User interfaces have made it difficult to take the output from one app and just hand it over to another app.
- Let individuals store their data on their own devices. Individuals should be able to decide what data to share.
- Developers should reduce entropy by writing less code and deleting bad code.
Exploring Stack Overflow Data (Evelina Gabasova)
Gabasova opened by making it clear that data itself won’t tell you anything. In order to learn from data, one must ask good questions.
She downloaded the Stack Overflow data and started asking questions about what technologies developers use in their free time. She looked at the time that questions and answers tagged with a specific language were posted to identify the times when those languages were being used. If the weekend traffic was heavier than the weekday traffic, she classified the language as “weekend” programming language–a programming language people learn in their free time.
Some of the languages most skewed toward weekends: Minecraft, D, Pygame, LWJGL. And the language most tied to weekdays? SQL reporting services.
Unconditional Code (Michael Feathers)
Feathers said errors were essentially “conditions we refuse to take seriously.”
Error handling breaks the main flow of the application, and it seems like noticeable error handling could point to bad design. So, what to do about errors?
Don’t return null
Returning null is often not the best option. Doing so forces the receiving application to do more work (i.e. check to see if the value returned is null). Instead, if a method has functionality that might fail (for example, such as I/O), throw an exception in the case of failure.
Another option is to add error types to the domain. For instance, if an item could not be found in a database, instead of returning null or throwing an exception, you could return a new “item not found” object.
Error handling prior to core logic
Aim to do all of your error checking before the core logic. The error checking will form a “protective shell,” and thus the core logic will not have to check for error cases.
Adjust the problem
In the face of messy code or an overly complicated problem, changing the problem might reduce complexity. You can do this is by changing the parameters of the problem or the default behavior.
For example, randomly picking a song from a playlist is a messy problem. To make the solution more straightforward, you could change the problem from randomly picking the next song to picking any song that has not yet been played.
After simplifying the problem, the developer could store the order of the shuffled songs in a list. Then, each time a new “random song” is asked for, return the next song from the shuffled list. Thus, by changing the parameters, you can reduce the complexity of the problem.
Hope you enjoyed my highlights from this conference. I’m looking forward to attending GOTO Chicago again in the future!