Last year seemed to come and go without the need of any real review. Seriously! If there was one, there be a linked above. 2019 was particularly filled with work on new and experimental tech at Glossier. The project that will go un-named was an exciting and ambitious project (like most). Like many ambitious projects, several months rolled around (September) and the project was paused.
This 'pivot' had a rather large impact on my quality of life, productivity, and developer happiness throughout the end of the year. Due to this, it's definitely a wonderful time to reflect on the highs and lows. The following is a list of 'things' that defined 2019. It's not so much a historical recount of the year, more a recollection of the chaos that ensued.
Overall the last couple of years here (on Cloudbacon) have been some of the more quiet ones. Sure the look of things has shifted but, the amount of content and sharing has dwindled to only several items a year.
My learning patterns haven't changed throughout this time. However, the amount of time that was usually put into sharing this knowledge has come to a grinding halt.
Andrew Chen put it best:
Writing is the most scalable professional networking activity
If you are one of the weird ones and still uses email, take the time to subscribe to his newsletter.
For the better part of the last 4 years, some of us have been organizing a hyper regional JavaScript meetup. TriadJS provides local developers (in the Greensboro Nc area) a space to come and share their ideas, wins, and loses. Larger cities can sustain developer meetups and community events. The real trick though? Foster and build one in a space where programmers aren't a dime-a-dozen.'
Hearing about people finding new jobs, learning new languages or frameworks, and helping people find a space in the community are always wins for community organizers. Like in life though, not everything is awash with positive feelings. These 'wins' only turn out to be 25 percent of an organizer's time. The rest of it is fighting for space to host meetups, figuring out what to do when Meetup folds, building backup decks for when people bail from speaking engagements, and etc.
It's not glamorous but, after a few years, the community burns brighter than ever.
Early on in the fall, I was 'commisioned' to write a CFP for a conference slot in Salt Lake City. Having not thought about speaking this year, my mind wasn't especially attuned to the idea of writing a somewhat quick conference talk proposal. The result was a CFP that was more of a Hail Marry than anything.
Within days, the talk was accepted and the actual conference loomed not that far in the future. I usually build in about 60 hours of write and reherse time for most talks. Due to time constraints, the total time to build this talk was going to be around half that.
Like most of college, constrained timelines bring out the best in me. The talk, while somewhat quickly sprinted through, turned out to be one of my favorite from the past couple of years.
It's available on Youtub right now: Breaking Up A Monolith with EQ
Innovation Tokens were birthed into popularity by the fine engineering folks behind Etsy. The idea behind them being that anyone starting a greenfield app should have x amount of tokens to spend on unknown technology. Some folks say there should only be three, others five. It doesn't matter due to the count being up to the team at hand. Choose an amount that makes sense to the team due to the skills of each individual on said team.
Above all else, don't cheat on using the tokens either. If someone doesn't have a deployed application running on AWS Lambda, that's a token. No experience with automating deploys using AWS tooling, there goes another.
New technology is hard and building new products that may not net a business revenue on day one, doubly so. Use innovation tokens to mitigate risk and find an MVP as quickly as 'humanly possible.'
Tearing up when finishing books is one of the few reasons to finish them... Right? A lot of reading (likely for most people) happens when stuck on a plane. Most flights from Greensboro to Ney York City aren't performed in posh pond hoppers. Due to this, these quick trips are perfect for consuming books of any type. One of the best books of the year and the one that I cried the most to was the following:
Specifically this quote:
“I’ll tell you what is convenient,” he said after a moment. “To sleep until noon and have someone bring you your breakfast on a tray. To cancel an appointment at the very last minute. To keep a carriage waiting at the door of one party, so that on a moment’s notice it can whisk you away to another. To sidestep marriage in your youth and put off having children altogether. These are the greatest of conveniences, Anushka—and at one time, I had them all. But in the end, it has been the inconveniences that have mattered to me most.”
Sam Altman wrote a 'small' post on how to be successful. In it he expoused the idea:
If you don’t believe in yourself, it’s hard to let yourself have contrarian ideas about the future. But this is where most value gets created.
Contrarians around the globe know it but, it's difficult being us. Glad that someone is writing about how we 'maybe' the creators of the future.
Line breaks aren't anything mind bending. However, when it comes to prose and source control, semantic line breaks blow people's minds. The idea might be too simple but, when writing follow this one rule:
By doing so you, make all prose easier to read and edit in source. For the last three years I have been exclusively writing README's, changelogs, and blog posts like this. Inevitably some ass clown will 'fix this' in a tangential pull request. Please don't be that person. Writing is hard for most programmers, make it easy by using semantic line breaks 🙏.
The following question comes up a lot:
What is the best way to introduce my child to programming?
My answer always is to buy them an abacus. However, the affending parent should always take the time to read this post of which expounds the finer points of the craft:
As an aside for the parent who wants their child to program at three and a half. Maybe have them read a book and leave programming to their later years.
And with that, Happy new year all!
