Ohio DevFest 2019 Recap

This weekend I attended Ohio DevFest 2019, a conference put on by local Google Developer Groups that is a few years old. One presenter called it “one of the best DevFests there are”, and I certainly enjoyed attending the conference even though its content was outside of my usual focus areas. In the rest of the post, I’ll go over my experience over the course of this one-day conference and give some opinions on the overall experience.
The Why?
I try to go to as many meetups and conferences as it makes sense considering my professional, personal, and financial situations at any given time. While I’ve always dreamed of having a job that paid me to go to a couple of conferences a month, I’m sure all that travel gets old pretty quickly. I probably tell myself that, in part, because it makes it easier to turn my mind back towards development from wanting to break into developer relations and travel like a rockstar.
While being unemployed or working for an employer without the pockets and time to fund my wanderlust, my main deciding factor ends up being on the financial side of things. I see a great lineup, a location I can travel to…and then there comes the price tag that makes me gasp a little bit.

I’m not going to discuss and argue about why conference ticket prices can reach into the thousands of dollars, but I was glad to see Ohio DevFest top out at $50 for a one day ticket that includes food in the price of admission. I’ve wanted to learn a bit more about Flutter recently and with only $50 to lose, I couldn’t resist picking up a ticket to this year’s event.
Check-In And Donuts
I had already visited the conference site before while attending a Columbus Google Developer Group meetup, so I didn’t have trouble finding the place, and I was even lucky enough to park at a garage that had special event pricing cheaper than their usual rates.
Check-in was quick and standard allowing me ample time to grab some donuts, a bagel, and some coffee. I wish conferences would provide more high protein, high fiber dietary choices for breakfasts but it’s not like this conference is different than any others. I still dream of the day I’ll walk into a conference and see piles of bacon, hard-boiled eggs, veggies, and fibrous carbs for me to chow down, but on this day I treated myself to an assortment of delicious donuts.
One piece of constructive criticism for the organizers here comes with the coffee setup. I arrived too late to get a full cup of coffee before the keynote. The conference seems big enough at this point to opt for the larger coffee urns that hold more java and dispense it more quickly.
Traits of an Inspiring Technical Leader

Michael Clark Jr of Kroger, Inc. gave the keynote presentation on the topic of being an inspiring technical leader. Michael is an experienced developer who now holds the position of Software Engineering Manager, and one of the first points I wrote down from his talk relates to how he views management as being distinct from leadership: “Managers make things, leaders lead people.”
It makes sense to me. I’ve had managers that weren’t all that inspiring, but I don’t think they were trying to provide inspiration to each and every one of their employees. Besides, I think every company only has room for so many leaders before cohesion and collaboration falls down; however, for this talk, Michael is only pointing out how managing someone is different from being an inspiring technical leader.
So what makes up a good leader? This brings us to one of my favorite quotes from Michael’s talk and a concept I’ve heard espoused in other leadership talks I’ve seen.
“The first responsibility of a leader is to define reality. The last is to say thank you. In between, the leader is a servant.” — Max DePree
Listening is key here. No good leader just takes an idea and jams it down their team’s throats until that idea becomes a reality. You might set the initial game plan, but if you don’t listen to the people doing the actual work, chances are the final product won’t be any good and your team may harbor resentment from the project that lasts the duration of their employment.
While you’re listening, you need to manage expectations. Under promising and over delivering will win you some friends, and you’ll have to say “no” sometimes in order to match expectations to what you’re producing.
If outsider's perceptions of your team’s performance don’t match what they expect, ask yourself where you failed in communicating your expectations to those outsiders. Was there some piece of context missing, maybe? Remember that “compassion will cure more than condemnation” when reviewing your failures so you opt for the carrot instead of the stick. The stick will never work…except for hitting balls in sports 😆!
“Missing deadline is Management’s problem, not the team’s.”
I’d like to say that quote to my boss someday, but I think it rings true. You can’t ask a dev team to write all the code and make sure it gets done on time. What else are project managers for if they don’t have to deal with missed deadlines?
For team engagement, Michael suggests developing a high level of emotional intelligence as well as allowing for an appropriate level of autonomy. I’ll add the concept of “psychological safety” into the mix, but the general idea is to not make people scared of failure and instead make them encouraged to go off and try to tackle hard problems hopefully from intrinsic motivations.
For pitfalls, Michael suggests:
- Avoiding “Ego driven development” and admit when you’re wrong
- Avoid setting a bad example by being sloppy or not following best practices
- How To Deal with jerks — do nothing, avoid or leave, and finally stand your ground
At the end of the talk, Michael told us the real secret to being a successful leader, and I like how much it parallels what I learned while working as a community organizer. If you’ve accomplished this goal, you’ve successfully passed the traits of being an inspiring technical leader down to the next generation.
“Strive to make yourself obsolete.”
Demystifying Machine Learning

I was especially interested in this machine learning presentation since I am studying algorithm design currently, although I’ve never liked the subject of math. Nikola didn’t mince words and started talking about “Math 101” from the start of his talk. He told us that machine learning always comes down to equations.
Nikola appeared to have a computer science degree and said he “was pretty good with math in college.” Despite those assertions, he mentioned how Khan Academy helped to refresh concepts he forgot about in four years of not using this kind of math at his work. I always wonder how much material you can actually “completely forget” after learning versus what happens when you get back on a bike after years of not riding. I bet the math knowledge was just hiding beneath his subconscious all those years, but I appreciate how he left the audience with a “you can do it!” attitude.
We went over the concept of linear regression and how that algorithm can be used to predict equations where you need to predict a single value, like predicting salary for a role based on years of experience. Independent/dependent variables, coefficients/weights, and a lot of math class flashbacks were involved, but what we were really doing is best described by reading about the gradient descent algorithm.
“Gradient descent is an optimization algorithm that finds the optimal weights (a,b) that reduces prediction error.”
Yep, sounds good to me…In order to demo some things, Nikola used Jupyter Notebooks, a popular tool for the data science crowd. Jupyter Notebooks allow for Python code to be executed in blocks right next to text and images that can be generated from the Python code.

Passing around the notebooks is a popular way to tinker with machine learning algorithms, and as you might guess, instructors like to use notebooks while teaching courses to make the material interactive and literally jump off of the page.
It was cool to see Nikola live coding the salary prediction in a notebook, but I was a bit dismayed to see him import the linear regression algorithm since they would probably make me write that out by hand in an interview. However, once you get past the interview, you’ll almost always use libraries, even for a lot of complicated machine learning problems.
One interesting tidbit relates to how you test your code in the domain of machine learning. Instead of doing TDD, they hide around 20% of data to test on the algorithm they developed with the other 80% of data. In other words, 80% of data trains the model, and then the rest is used to test predictions. I found that neat for whatever reason…maybe cause I’m not great at writing tests and would prefer not to write them.
Finally, Nikola provided the audience with some references for more on machine learning. Most questions from the audience related to “how can I break into doing ML, since I feel I’m not capable of learning it?” Just go here and read these:
- How to multiply matrices — apparently a lot of the equations dealing with matrices
- Tableau Recommendation Engines — Tableau is an analytics platform that has some tools that use machine learning to make recommendations for data analysis
- PyTorch — Machine learning framework for Python
- Machine Learning on Coursera — I couldn’t find/remember the exact course mentioned, but I’d probably look towards the one from Standford
- Essential Math for Machine Learning — Once again, I’m not 100% sure on the name of the course, but Nikola did mention it came from edX
In closing…
If your algorithm is 100% correct, it is wrong.
Chrome Developer Tools: Raiding the Armory

I use Chromium every day, but I never read the “new in version xx.x” notes so my knowledge of new features never really changes. I know bits and pieces of how to use the elements, console, network, and sources tabs that get me by, but I also know there are tons of developer productivity tools lurking in those tabs I haven’t spent the time to dig out.
Luckily for us, Greg did the hard work of reading through Chrome Dev Tools’ help documentation in order to give this presentation. Greg’s presentation was probably the most entertaining one I sat through at Ohio DevFest, and the whole audience enjoyed his wit and banter. For the presentation, “Wacky Wanda” kept pointing out bugs or changing requirements for features on her e-commerce store that Greg fixed in real-time using Chrome’s Dev Tools.
We first went over a CSS bug that caused styling to break around the iPad screen size media query. Greg opened dev tools, switched to mobile device emulation mode, and found an issue relating to the max-width property if I remember correctly. I already knew how to debug these types of issues within the dev tools and started to wonder if I would get anything out of the session.

It didn’t take long for me to backtrack on that concern, as the next example dealt with animation frames. I had no idea how to get to inspecting animations, but there is a good article on what you can do within Chrome regarding animations. We basically made Wanda’s logo spin in the header section of the site and went through how to make the animation smooth from initially appearing very choppy. I don’t normally work with any CSS animations, but now I can have fun changing all the parameters from a UI rather than the less intuitive way of learning strictly in the code.
Another large portion of the presentation dealt with editing source code from within dev tools as well as setting breakpoints and debugging while coding to help inspect variables as a feature gets built out. I’ve followed similar methods during my work so I didn’t see a lot of new functionality, but it is nice to see autocompletion working in the browser editor. I only really debug my source code in Chrome, but I could see using the editor in a pinch.
Several other bits of knowledge:
console.table()puts the data in a table. This blew my mind and is really helpful for lists of objects…and then I saw how many other methods theconsoleobject has on it.console.log()ain’t the only game in town.$0for reference to the selected element and$_to reference the previously selected element via the console. These variables are most useful for programming a Chrome extension, but you might find them handy.$1gets the second to last referenced element and$2the third…and so on.debuggerin source code automatically sets a breakpoint if dev tools are open. I can see myself using this often in the future.- Set “Disable cache” on the network tab when debugging. Having never checked this box, it makes me wonder why I don’t have this set by default. No more paranoid
cmd+shift+4refreshes maybe? - You can set breakpoints that fire on specific network requests. You can even use a regex pattern. A great method to use if you notice multiple network requests when there should only be one and you have no idea what code is causing the issue.
At the end of the day, you should read Chrome’s documentation. Greg learned all of what he presented on by reading the documentation.
Is all of this true for Chromium or how much is just for Chrome? I use the Brave browser and wondered if Chrome has special dev tools that a browser like Brave won’t have. Greg didn’t seem to think there are any differences based on what he presented, and I haven’t noticed anything different while reviewing my notes.
Lunch + Chats
We had chicken, mac’ n’ cheese, and a banana pudding dessert for lunch. I approved. A lot better than the typical boxed lunch sandwich you may know of or the ubiquitous slice of pizza. There may have also been tacos or something on the side…but lunch was good. We got some extra time to eat since they wanted to push back the end of the conference to align more with the start of the after part, and I used the chance to mingle…and take a brief nap 😴.
I talked to a few groups of boot camp students and boot camp graduates mainly about how they are prepped for technical interviews. I’m in the midst of interviewing myself and find the technical interview terrifying, as all of my previous jobs haven’t made me whiteboard anything before offering me a job. I lamented to them how much starting at a decent company, who probably has a challenging interview process, can accelerate your career path and how their boot camp experience almost seems to trump my six years of professional work experience.
It is so, so important to study and understand the fundamentals of algorithms, data structures, system design, and other things that aren’t tied to a language or framework in order for you to get the best job possible. I’m still a little baffled on how I spent the last six years working hard at my jobs and feel like I know little about any of those topics. Damn frameworks!…but I digress.
Flutter, Why it’s the Right Choice for Business

The afternoon was all about Flutter for me. I just used React Native in a project and have been trying to decide whether or not I wanted to try and use Flutter to build out cross-platform applications. I was on the fence.
Two weeks ago I saw Scott present “Flutter 101” to a local meetup group so I was a bit dismayed when he switched presentations to give the 101 talk again. I applaud Scott for choosing the right presentation for an audience of mostly developers, but I wanted to see what a Flutter advocate would say to product managers and people more on the business side of things.
I think the presentation was a bit better than two weeks ago, but I wrote a blog post on that you can read for more information on what Scott presented and my take on it.
Intro to Flutter Web

The second round of Flutter related to rendering on the web. It’s funny to me how Flutter started out using a rendering engine used in Chrome but is coming to the web platform after building out the project on iOS and Android.
Faisal gave us a theory on why this is the case. Early on in Flutter’s development cycle, someone mused that Dart’s aim was to kill of JavaScript, and the backlash from that misplaced notion killed interest in Flutter from web developers for some time.
Fast-forward to now, and Flutter for the web is still not production-ready. I give props to anyone who dares to try and give a live demo on alpha version code, but Faisal had some hiccups showing us how to work with Flutter for the web on a local development environment. Something in the SDK changed and so he had to wait for his machine to finish updating to a new version before an app successfully compiled.
So, yeah, I bet you will have to do a lot of sleuth work if you want to try out using Flutter on the web. Google is committed to the Flutter project enough that they are starting to partner with some larger companies to help build out new features using Flutter for the web, and I look forward to hearing more about that progress.
One interesting reason why Flutter for the web lags behind the iOS and Android platforms relates to UI component style guides. iOS and Android have a certain look and feel to their UI components written down and documented. However, the web is a wild west and there are no guidelines. Furthermore, you can’t edit the Flutter-generated code in your browser dev tools to mess around with styling.
Drawing to a canvas that makes mobile games look the same across all devices and run smoothly on lower-powered devices is huge for developers pushing apps into emerging markets, but it has some tradeoffs vs. using native UI elements of each platform. I’m so used to debugging web apps by clicking on elements in the browser’s dev tools, and I’m just not sure how great of a DX I’d get right now using Flutter for the web. So, I’ll still watch Flutter as the development goes along, but I’m pausing any deep dives.
There is one final tidbit Faisal dropped on us that I’d always wondered about: where does the Flutter name come from? I thought it had something to do with throwing darts, but the story is way more random than that. Apparently, some engineers went through a spreadsheet of companies Google bought out over the years so they could pick a name Google already owned while ostensibly reducing administrative costs. Google bought a company named Flutter awhile back and now they’ve recycled it for an open source project.
Journeying into open source

I almost went to another Flutter talk, but it was on testing Flutter apps, and since I had no app to test, I changed my mind. I’m a big proponent of open source though, and I like hearing people’s stories on how they got into working on open source projects.
In my experience, development communities can differ greatly on their relation to open source. I’ve primarily worked in small development teams with small budgets and luckily not had to deal with licensing fees or discussions relating to them. I’ve always used open source libraries and frameworks and generally contribute back when I can, mostly on documentation issues or small bugs.
Most of the attendees had little or no experience with open source work, and I’m not entirely sure how many open source tools they use at their day jobs. However, I did get a sense that people might be more used to paying for things than contributing to projects. And that’s totally fine. I hoped maybe we would discuss how to make open source sustainable and that would lead to more insights into how this community differed from other conferences I’ve been to, but that discussion was outside of the session focus.
You should contribute to open source:
- It helps you to develop a network
- You can control what you work on, and you might not be able to control what you work on in your day job
- You’ll grow more by working with different people rather than teammates you’ve had for years
- You’ll become a better developer by coding out in the open, being forced to write tests, and getting peer review from many different people
- Looking at other people’s code can really help you to level up your code and pick up new tips and tricks
Fireside Chat
I’m not used to seeing this part at a conference, but I think it worked out well. At the very end of the conference, all of the presenters gathered at the front of the largest room for a Q&A session. Any audience member could ask a question there wasn’t time for in a session as well as ask general questions to the audience.
Presenters answered questions on the worst bug they ever shipped, how they experience impostor syndrome, how they work with open source projects, and more. I didn’t take any notes during this portion, but I really like the idea for small enough conferences where you don’t have more than 20 speakers.
Afterparty
I was super tired and poor on the day of the conference so I didn’t go to the afterparty, but it was held at a barcade and they provided pizza. Once again, great value for a $50 ticket. You could walk to the after party from the conference venue, which isn’t always the case, so I applaud the organizers for setting it up like that. I’m sure it was a great time for all who went.
Summary
I would definitely consider going to Ohio DevFest in the future. It is a reasonably-priced conference that is jam-packed with various talks from a decently diverse set of speakers. As a solo conference-goer, I didn’t feel left out and mingled with several other attendees having some interesting discussions on hiring in tech.
My one regret is not going to some of the sessions with broader topics, like the one on voice interactions. Instead, I chose sessions where I knew some of what they were talking about, but I think I might have gotten more out of sessions I didn’t have any experience with. Oh well, there’s always next year!
