There’s always that one year that seems longer than all the others because of what happens in that day. Sometimes it’s predetermined, other times it just happens. I appropriately call this “The Longest Day of the Year.”
No, it doesn’t happen on June 21, although it could align with the summer solstice. Rather, it’s about the events that make up the Longest Day of the Year.
In my past journalism life, this day typically happened in late February or early March. Being that I reported on high school and semi-pro sports, the Longest Day of the Year sometimes meant covering several events in a day. In 2011, the Longest Day of the Year involved reporting on 5 games in a day.
In 2016, the Longest Day of the Year happened right before I went on a two-week vacation in July, because isn’t that how all last-day-before-vacation days happen? That day involved reporting on a motorsports event, covering a Little League championship game and interviewing a boxer for a story that would run while I was on vacation.
Those weren’t bad Longest Day of the Year days. If the events are fun, I have fun.
This year’s Longest Day of the Year didn’t involve journalism. It involved going to a tech conference and then a tech talk.
The first of the two events was Software Craftsmanship North America, held at USC. It was an opportunity to hear from software engineers and other tech professionals about the industries they’re in. It was a two-day event with the second day a hackathon but I couldn’t attend the second day.
The talks were varied in excitement and information. They all weren’t exciting but all of them were informative. I got something out of every speaker even if it wasn’t the greatest talk.
For this I’ll focus on the talks I enjoyed the most. There were some that were written speeches (mehhhh) and others where the speaker guessed everyone was on his or her level (I’m just a noob!) and I’d rather not spend energy on those.
The first best talk of the day — arguably the best talk of the day entirely — was from Woody Zuill, an agile coach who gets companies to adopt mob programming.
The idea is that teamwork makes the dream work. Mob programming allows for multiple people to focus on a project at the same time together. One person mans the controls and everyone tells him or her where to go.
It kind of reminds me of Twitch Plays Pokemon except it doesn’t involve thousands of people who don’t know what to do, but rather a few who are supposed to know what to do.
Now, obviously nobody’s trying to steer people the wrong way in true mob programming but the idea is to share ideas and tell the ‘driver’ where to go. I’ve done pair programming, where it’s me and someone else, but not mob programming.
The benefits, according to Woody Zuill:
— Everyone is focused on the same task together. There are many projects where people piece parts individually, everyone puts them together, and the corrections are made. The cycle starts over until everyone is satisfied or the deadline arrives. In mob programming, as Zuill put it, there is no piecing of a project separately.
— Only those who have something to say to contribute will say it. There are always one or two people in meetings who are wallflowers be it intentionally or unintentionally. Mob programming weeds out those people because they’re exposed by not contributing. Their energy gets put somewhere else.
— Projects get done more efficiently and, in many cases, quicker.
Zuill said mob programming is not for all businesses and he advised companies to try before doing a full dive in.
Overall, the goal of mob programming is to eliminate inefficiencies and downtimes.
I’m hesitant to say it would work for me.
If given a project, I’ll thrive with others if my teammates are family, friends I’ve known for a minimum 20 years (19 won’t cut it) and/or people whom I’ve done a blood ritual with (last one hasn’t happened yet but the offer is there).
But for everyone else, I’m terrible. It’s probably why the businesses I’ve tried to run all crashed and burned. So while I see the benefits to mob programming, I know I would have a difficult time adjusting.
Another great talk came from Sarah Aslanifar who talked about getting her kids to understand and accept math early. Using different games and even a robot called Cubetto, her kids understood how powerful math can be.
She showed how babies understand math without actually knowing that it’s called math. The babies were shown dolls that appeared and disappeared with other dolls via a puppet show. When repetition happened, the babies lost interest.
Going from two dolls to one or one to two weren’t interesting to the babies. But getting rid of one doll and there still being two, or adding one doll to one and there still being one made the babies show some expression.
The robot was hella cool. It stays on a squared blanket and moves based on a predetermined set of actions plotted on a grid controlled by a person. As I watched the robot I was thinking of how multiple robots could be on one blanket without hitting each other. That would be a challenge. The robot is designed for children to get them to understand programming, no computer needed.
After lunchtime and some opportunities to meet programmers and developers, there was tech Jeopardy. Some of the categories were way over my head, others I tried to follow along but had mixed results.
There was a sports category that involved decimal binary, and that was fun. The numbers were basic trivia that I think most people would get if you gave them a few minutes to think about it. Two examples: “Wilt Chamberlain once scored 1100100 in a game” and “The Bulls once held the regular season win record with 1001000 wins.”
(I’ve never dealt with binary but a couple of times, but here’s a fun note, a Giants fan once told me the binary for 54 is 110110. For Giants fans like myself, it’s notable because 11/01/10 is the day the Giants won the World Series for the first time since … ‘54)
So while I was thinking of the responses without a problem — 100 and 72 if you’re wondering for the two respective numbers above — the most surprising thing was seeing my friend Liz actually go through the math to get the correct number! That blew my mind.
There was another part of the conference that made it more enjoyable than others I’ve attended this year. It was the first time I talked to developers, software engineers and companies at an event without getting the aura of “Come back when you’re ready” that so many others have emitted previously.
Poll everyone who went to the conference and ask them about how much expertise they have in tech and coding, and I guarantee you I’m in last place. The difference here was people were understanding that I’m not at their level and still wanted to share a few minutes about the goings on. That was refreshing.
In the evening, I headed to the Google offices in Venice for a talk led by Google software engineer Anthony Mays. The talk was about nailing the technical interview, which is supposedly a key point in getting a job at every important tech company around today.
I had heard about the technical interview previously when first attending coding meetups, and they always seemed to be like this sword-wielding, steroid-infused goliath that could parry any attack, the thing that was bigger than the job itself.
Obviously, I’ve never had to do something on that level when it came to getting interviewed for a job. The toughest task I’ve had to do during an interview was prove I could plot an Excel spreadsheet and make it searchable on another sheet without using VLookup.
Hearing Mays talk about going through the interview was amazing. Yes, the task is daunting, but by preparing ahead of time, most of the fear can be eliminated.
There were other Googlers who shared their experiences of the technical interview. Some knew they failed, others weren’t sure but downplayed their chances. Their application process was also varied. One person was an intern who worked their way to the technical interview and then landed the job. For others it took a year and even as long as five years because of failed attempts or Google wanting to make sure.
A positive part? Mays and the other Googlers encouraged people to go for it. He wanted people to apply and get into Google. He’s had his own self doubts as he went through the process, but now that he’s in, he wants others to make the push and become a Googler.
After the presentation, I had the opportunity to meet others who attended the event (there had to be like 200 or so people there), and there were many people from all sorts of backgrounds, as is usually the case with the Learn Teach Code L.A. meetup group. There was one person who created mobile apps for a university medical center so deaf parents could understand what their babies wanted based on the cries. That was amazing.
There were other people who were curious about Google or wanted to be on the Google campus.
The long day ended with a trip back to Long Beach to think about all that went down and how I could use what I learned going forward.
— Don’t be afraid to go for it. I never would have considered going for a job at Google, but after Mays’ talk, I’m thinking about what I could do.
— Be flexible. The Googlers said they all knew one language but eventually had to learn another once they were hired, and it wasn’t the same language for all of them.
— On that note above, get hardcore focused on one language and then move to the next one. Fringe knowledge of two will likely show in the technical interview. Being super focused is a plus.
— Be open to working with people. As mentioned, I believe I’m terrible at it, so if I can can improve, things will get better not just for me, but for people I interact with.
Overall, it was one of the best Longest Day of the Year days I’ve had in a long time. I got to attend two great events, meet a lot of interesting people and learn about things I didn’t know.